React v3.13.13 causes infinite re-renders after setting `getItemKey()`

[RaenonX]

Describe the bug

As title. Only happens after going from v3.13.12 to v3.13.13.

Your minimal, reproducible example

See below.

Steps to reproduce

Run the following code, which is grabbed from the example with just an getItemKey() addition

import { useVirtualizer } from '@tanstack/react-virtual';

function App() {
  // The scrollable element for your list
  const parentRef = React.useRef(null)

  // The virtualizer
  const rowVirtualizer = useVirtualizer({
    count: 10000,
    getScrollElement: () => parentRef.current,
    estimateSize: () => 35,
+    getItemKey: (index) => index,
  })

  return (
    <>
      {/* The scrollable element for your list */}
      <div
        ref={parentRef}
        style={{
          height: `400px`,
          overflow: 'auto', // Make it scroll!
        }}
      >
        {/* The large inner element to hold all of the items */}
        <div
          style={{
            height: `${rowVirtualizer.getTotalSize()}px`,
            width: '100%',
            position: 'relative',
          }}
        >
          {/* Only the visible items in the virtualizer, manually positioned to be in view */}
          {rowVirtualizer.getVirtualItems().map((virtualItem) => (
            <div
              key={virtualItem.key}
              style={{
                position: 'absolute',
                top: 0,
                left: 0,
                width: '100%',
                height: `${virtualItem.size}px`,
                transform: `translateY(${virtualItem.start}px)`,
              }}
            >
              Row {virtualItem.index}
            </div>
          ))}
        </div>
      </div>
    </>
  )
}

Expected behavior

No error.

How often does this bug happen?

Every time

Screenshots or Videos

Platform

Windows 11 Edge (But I guess all browsers have this issue)

tanstack-virtual version

v3.13.13

TypeScript version

No response

Additional context

No response

Terms & Code of Conduct

• I agree to follow this project's Code of Conduct
• I understand that if my bug cannot be reliable reproduced in a debuggable environment, it will probably not be fixed and this issue may even be closed.

[j-marty]

Move inline function for getItemKey to a callback function as a workaround. Like this:
const getItemKey = useCallback((idx: number) => {...}, []);

[J4v4Scr1pt]

Same here, above solution worked for me as well. 👍

[israel-lpz]

Same here, above solution worked for me

[marcelpanse]

Came here for the same bug. Putting it in a useCallback worked.

Edit: we still had some problems in production with some users so we had to revert back to 3.13.12. This change breaks backwards compatibility.

[channyeintun]

Even with React Compiler, I still have to wrap it up inside useCallback?

[RaenonX]

Even with React Compiler, I still have to wrap it up inside useCallback?

Using default strategy (syntax inferred or something), if you are not wrapping the function in a use* hook then yes

[zerkms]

Now with this release it's now unclear what functions should be memoised, and which not.

Eg, in the first post example:

    getScrollElement: () => parentRef.current,
    estimateSize: () => 35,
    getItemKey: (index) => index,

it was mentioned that getItemKey must be memoised, but what about other two? Is it possible to know which must be memoised from documentation?

I came to this report because I also have the same problem, but I do not use getItemKey and desperately try to find which of the options to blame 🤷

[RaenonX]

Now with this release it's now unclear what functions should be memoised, and which not.

Eg, in the first post example:

    getScrollElement: () => parentRef.current,
    estimateSize: () => 35,
    getItemKey: (index) => index,

it was mentioned that getItemKey must be memoised, but what about other two? Is it possible to know which must be memoised from documentation?

I came to this report because I also have the same problem, but I do not use getItemKey and desperately try to find which of the options to blame 🤷

This needs someone authentic enough to confirm about how it should work, but what I think should work is getItemKey() shouldn't also be memorized as well. It's more like a bug introduced in this version. For the other 2, the tutorial and my usages have them un-memozied and so far so good

[zerkms]

Ok, I found what change happened to me: now (in 3.13.13) the onChange handler IS triggered when number of rows changes (no actual scrolling).

And in 3.13.12 it DID NOT trigger 🤷

[mallio]

The documentation does mention that getItemKey needs to be memoized, but I had missed it and it wasn't causing trouble before.

I'm fine if the solution is to memoize it, but in addition to the documentation mentioning it, I think there should be examples of it in use. I also wish it was more clear what needs to be memoized, because I pass a lot of unmemoized functions to createTable and they don't trigger rerenders..

[channyeintun]

It was working fine without using useCallback in the previous version. I just installed the latest version and got this issue. It is BREAKING CHANGES?

[zerkms]

@channyeintun given it's been documented - it's not a BC but a bug fix.

[lott-ai]

The infinite re-rendering issue was introduced in #1085

@piecyk updated the docs to include a note about memoizing getItemKey in #1103. I'd consider this a breaking change, since this memoizing requirement was not necessary before 🤷‍♂️

[piecyk]

@lott-ai Yeah, my bad, I agree this should be released as a major version. Even though the fix itself is reasonable, requiring getItemKey to be memoized wasn’t necessary before, and existing users can now run into infinite re-renders without any obvious indication of why.

Personally, I’ve always memoized getItemKey since it’s part of the caching mechanism. There was already a real performance issue there, which is probably why I didn’t notice this earlier. Still, changing this behavior without a major release was a bad call, and it should be clearly communicated.

[zerkms]

@lott-ai it was documented even before #1103: piecyk@106a0be