Save key of the same item when prepending items in a list

[shachar731945]

As i have been using the component i have come to notice that when i prepend items in Virtuoso (not grouped or grid mode) even when the same component stays on screen (even in the same place) the key prop of the item increases (by the amount of items that were prepended). This causes the component to un-mount and right then re-mount itself (not re-render). I double checked and the same happens on the example on the virtuoso documentation site about prepending items. This is not the case when appending items. Maybe I don't understand the rational properly, but shouldn't the list have the same key for the same item in the list? I have looked at the code and noticed that maybe the call to const key = computeItemKey(index) could be changed to something like const key = computeItemKey(index + firstItemIndex || 0) to achieve this (plus since firstItemIndex should be negative), in the List.tsx and Grid.tsx files. I can make the pull request myself but I would like to know if this is a desirable result from the package? I assume this is a breaking change and may only come into effect in another major version so right now using computeItemKey may do the trick.
Thanks from ahead for the consideration and long read :)

[petyosi]

That's a good observation and indeed, the implementation you suggest would make more sense as a default one. However, it is, indeed, a breaking change. A very small one, but I am trying to stick to not releasing such (at least not intentionally), for the sake of not scaring people away.

Can you open a PR? If I gather enough material (or sufficient time passes), I will merge it. Thanks!

[shachar731945]

#380
adding the pull request of the wanted change.
Would you consider merging it in another major release? (Seams like a good place to add a breaking changes)
Thanks from ahead!

[petyosi]

Yeah, that's the plan. I will also think if we can introduce it in a non-breaking way by an additional prop.

[shachar731945]

I do not know if this is the best approach. If it would be done, the "correct and wanted behavior" will not the default one. (I assume this prop will be default false to not break anything existing) Therefore, I would consider waiting with it until the next major release. Even so, maybe we can introduce it as a false default prop to make the process of switching to this correct behavior more gradual and lenient.

[petyosi]

This is merged in v2