race condition with new getItemKey
I have a race condition that I can't reproduce (yet) in a sandbox. so I will try to describe what it looks like:
the result:
I get to a situation where the first items in virtualItems, up to index k, are with prev keys, and the items after k are with new keys.
in my case I get a duplicate key because an item moved from being first in the list to being in a different place.
what I think happens
I get to
getMeasurements with pendingMeasuredCacheIndexes = [k] and a new getItemKey. it start iterating from k and misses the key updates to the first item in the cache.
suggested solution
empty pendingMeasuredCacheIndexes when getItemKey changes.
how did we get here
this is a long story, but the gist of it:
1. state changes -> after render resizeObserver of item k is fired
2. at the same time state changes again -> changes getItemKey5 Replies
flat-fuchsiaOP•3y ago
it doesn't happen with my refactor, but I think it's luck
flat-fuchsiaOP•3y ago
https://codesandbox.io/p/sandbox/react-virtual-simple-w0hd3m?file=%2Fsrc%2FItem.tsx&selection=%5B%7B%22endColumn%22%3A17%2C%22endLineNumber%22%3A23%2C%22startColumn%22%3A17%2C%22startLineNumber%22%3A23%7D%5D
click on change enough - it will happen. (you will have duplicate key)
**I believe that after we fix this, we will be able to get a similar result if we wrap the virtualRow with react transition or deferred value - this should be fixed by my refacor for real, but we need to fix this issue to test 🙂
react-virtual-simple
CodeSandbox is an online editor tailored for web applications.
genetic-orange•3y ago
Ooo good catch 👏
genetic-orange•3y ago
suggested solution empty pendingMeasuredCacheIndexes when getItemKey changes.yes that will work, something like this https://github.com/TanStack/virtual/pull/511/files
flat-fuchsiaOP•3y ago
I don't know if
this.options.count should empty the this.pendingMeasuredCacheIndexes but it should solve the issue.
thank you for the quick response as always 🙂