[GH-DEV#2122] Migration from 13.1.0 to 14.6.1 breaks table when trying to paste values into columns with locked cells

Tags: #<Tag:0x00007efc64e61ad8> #<Tag:0x00007efc64e618f8>

After updating the handsontable library, I got a problem. The table breaks when I copy values and paste them into column with blocked cells.

In the old version, nothing happened when I tried to paste values into column with blocked cells.


But in the new version, the table broke when I put values into a column with blocked cells. The table expanded down and there was a scroll on the right.

I didn’t change the code. The new version fixed the problem with copying values (See the topic: Copying values from locked cells does not work), but it made the problem worse with putting values into columns with blocked cells. Also, it doesn’t happen when I put values into columns with unblocked cells.

I was wrong. The table also breaks when inserting into a column with unlocked cells

bug2

Hi @mr.fursy

It seems that there is the same origin of the issue. Meaning it should be fixed unless you use checkboxes in further columns or the imeFastEdit is on (we have mentioned some issues related to those two functionalities and copyPaste).

Could you please send me a demo where the issue can be replicated? Based only on the following image it would be hard to create the same setup. I tried to create a similar demo here: https://jsfiddle.net/0Lnf7jx3/, but I couldn’t replicate the issue (pasting data into readOnly cells does not create new rows).

I’m not sure if I reproduced the situation correctly, but the behavior seems similar.
Try copying the values ​​and pasting them before the two locked rows. The table will start to lengthen.
https://jsfiddle.net/1ybL4829/15/
image
And one more question. Is it normal library behavior if when pasting values ​​go to the next cell after the locked cells in the edited cell (enabled row)? Or must the values stop being inserted as soon as they hit the first blocked cell? The wall effect.

I have fixed this problem on my project via adding maxRows setting to the spreadsheet options (GridSettings)
maxRows: spreadsheetData.length
To dynamically determine the number of rows, since my table component is reused

And one more question. Is it normal library behavior if when pasting values ​​go to the next cell after the locked cells in the edited cell ( enabled row)? Or must the values stop being inserted as soon as they hit the first blocked cell? The wall effect.

Could you please help me with this moment? How to implement this behaviour? I need the insertion of values ​​to stop after it hits the first locked cell.

Ok, so you enabled the last row to be edited - that is why you can pass the data and Handsontable pastes as many rows as it was copied. If you do not want that to happen (and pasting should not create new rows) than you can use the beforePaste hook to truncate dataset. Similair to what we have in the following code from the documentation

 beforePaste: (data, coords) => {
    // data -> [[1, 2, 3], [4, 5, 6]]
    data.splice(0, 1);
    // data -> [[4, 5, 6]]
    // coords -> [{startRow: 0, startCol: 0, endRow: 1, endCol: 2}]
  }

ref: https://handsontable.com/docs/javascript-data-grid/api/hooks/#beforepaste

With a little addition for a condition statement to check if cords.

You’ll need

  • hot.countRows() - to tell you how many rows there are
  • coords[0].startRow - to tell you what is the first cell index of a change
  • data.length - to tell you how many cells are going to be changes

If hot.countRows() < coords[0].startRow + data.length, then you are good. Data can be pasted, and no new lines will be added. Otherwise, you can truncate data.

ps. I am not sure why you added this block of code to the demo

 afterChange: function(changes) {
        // Recalculate SUM and MIN if data changes
        if (changes) {
            this.render();  // Re-render to show updated values
        }
    },

but that causes the table to double-render causing performance degradation. When the changes happen the table has already been rerendererd so calling render() again brings no effect.

1 Like

I forgot to remove that from your snippet (https://jsfiddle.net/0Lnf7jx3/).
I’ve fixed it now: https://jsfiddle.net/8tp2jsz5/

Am I right in understanding that without adding maxRows the table expands downwards by default when adding copied values ​​to a column?
In this case (https://jsfiddle.net/8tp2jsz5/): maxRows: data.length,

Yes, maxRows is another option you can choose to limit the size of the table (row-wise or column-wise).

It all depends on the requirements that you have. For example, if data comes from a server that can alter the number of rows or the user can add rows between the selected range and summary rows it would be more efficient to use the method with a conditional data truncation via beforePaste hook. Calling updateSettings(maxRows: value) each time you get new data from the server or before you run the method from a context menu doesn’t seem the best solution.

1 Like

This is a very useful clarification. Thank you very much! :innocent:

@aleksandra_budnik
Should I create a separate topic or can I ask a couple of questions here so as not to create new ones?
They also concern the migration from version 13.1.0 to 14.6.1

1) Performance has dropped significantly. Interaction with the table has become less responsive. It takes longer to switch to edit mode, copy/paste, save and reset values, and so on. What could this be related to? I saw somewhere that the logic in table virtualization has changed, but my table in the project is small, but it has a lot of logic (validation, formulas, etc.). I see how the responsiveness of the table increases when rolling back to 13.1.0

2) In cells where validation has worked, in which there are comments, quick input does not work.


But if I move the focus from this cell to any other without validation with a comment, then quick input from the keyboard works (no need to double-click on the cell to go into edit mode)

I suspect it’s something to do with the IME change (https://handsontable.com/docs/javascript-data-grid/migration-from-13.1-to-14.0/#changes-to-ime)
But passing imeFastEdit: true to the table config object doesn’t fix this behavior. Maybe I’m missing something?

It might be better to do so for all those folks who are looking for the same topic on the Internet. However, for this one, we can remain within the same thread to avoid duplication.

PERFORMANCE
With each version, we run a test on Performance Lab to check if there are regressions. We have a lot of simple tests there, but they may not cover advanced functionalities or connections between plugins. Maybe the issue is related to a more complex setup. I recommend commenting out options one by one to specify which one of them is causing the issue.

QUICK INPUT
The imeFastEdit option is only useful for non-standard keyboards

input text in a language that can’t be represented easily on a standard QWERTY keyboard

ref: https://learn.microsoft.com/en-us/windows/apps/design/input/input-method-editors

Not sure if you need it. If your users use a default QWERTY, QWERTZ, or AZERTY keyboards you do not need to enable imeFastEdit.

Could you provide a demo where I’ll be able to replicate that issue?

I noticed that this is the default behavior on your demos (https://handsontable.com/docs/javascript-data-grid/comments/#basic-example). A cell with a comment does not allow you to enter edit mode if you click on it once and then press the keyboard.
For example, if you select a cell with the value 10 on the 2nd row (where the comment is “Some comment”), then pressing the key does not turn on the edit mode.
At the same time, the next cell on the 3rd row is immediately available for editing when you select it and press the key.
In version 13.1.0, all cells available for editing immediately go into edit mode when you select and press the key, regardless of whether there is a comment in the cell or not.

Ah, I see. Thank you for the explanation. You are right. I did not see that one before.
I do not see this behavior being specified as a ‘new way,’ so it might be a regression. I will report it internally and notify you as soon as this gets fixed.

1 Like

I think another behavior is also related to this problem. If I click on a cell with a comment and then navigate the table using the keyboard (arrows), then editing also does not work. It is as if the presence of a comment blocks the ability to edit. But if I remove the mouse hover over the cell with the comment, then the cells are again available for quick editing.