Set physical row index

Tags: #<Tag:0x00007efc656296f8>
#1

Is there a way to set the physical row index when inserting a new row? When calling:

alter(‘insert_row’, visualIndex)

the physical index is automatically set to the same value as the visual index. This causes issues when inserting new rows into a sorted or filtered view. For instance, say I have filtered a 10 row table down to rows 8, 9, and 10, and then I insert a row in between 8 and 9. The visual index in this case would be 1, but I would want the physical index to be 8 so that when I remove the filter, the new row is still in between the original rows 8 and 9. Instead, the new row will still show up as the second row in the unfiltered view, because the physical index is set to the same as the visual index.

I have not been able to find an API function that allows me to set or change a physical row index, and I’m hesitant to directly modify the source data structure in case that causes unintended problems.

#2

Hey @rgay

you can use the toPhysicalRow method inside the alter method.

Here’s an example when I sort the rows and add the empty new row in the physical index of 0 https://jsfiddle.net/Lbe5q19d/

#3

Hi @aleksandra_budnik,

I don’t think your example quite illustrates the issue. Here’s one I created which hopefully explains it better: https://jsfiddle.net/g9Lfocnu/18

My goal is if the column is sorted desc, and a new row is inserted, it looks immediately visually correct, but then also looks correct if the sort is removed (and the column is displayed ordered by physical indices).

As I commented in the example, if I use hot.alter('insert_row', 1); to insert a row in between 6 and 4 (and use afterCreateRow to set that cell value to 5), it immediately looks visually correct, but the physical indices are out of order when the sort is removed.

If I use hot.alter('insert_row', hot.toPhysicalRow(1)); both initially and after removing the sort, everything looks incorrect because hot.toPhysicalRow(1) returns 4, which is set at the visual and physical index of the newly inserted row.

If I use hot.alter('insert_row', 5); the immediate view looks incorrect (the row with the 5 is out of order), but removing the sort it looks correct because at least the physical index was correctly set to 5 (and of course, subsequent sorting looks correct).

The ideal solution when calling hot.alter would be to set the visual index to 1 (so the immediate view looks correct) and the physical index to 5 (so when the sort is removed, the default physical ordering looks correct). If this is not possible, I’ll probably go with the third line of code so that at least the physical index is correct.

Thanks,
Ryan

#4

There is no way to add a row with different visual and physical index. Once you add a new row (even when data is sorted) the physical index = visual index it is visible when you call hot.getData() and hot.getSourceData().
You’d need to call the sort() method once again to push the 5 to the correct position.

#5

Ok thanks - I’ll use the method of re-applying the sort after creating the new row. Is the ability to set the visual and physical indices to different values a potential enhancement, or is there something fundamental to Handsontable that would prevent that from being feasible?

#6

At first glance, I do not see any possible conflicts but for some more complicated structures that combine more plugins - it might get tough. My colleague’s currently working on a project called index mapper. That is something that we should have made years ago but haven’t had time or knowledge to proceed. This mapper is a key to pass the indexes between the core and the plugins. Seems obvious. But currently (and it was like this since the beginnings) the logic is decentralized and there’s no ‘brain’ to progress the visual and physical indexes being used by multiple plugins.
I guess that once we get this mapper running we’ll be able to add possibilities like the one you’ve described.

#7

Great, thanks for the insight!

#8