Type 'bigint' is not assignable to type 'Key | null | undefined' when trying to use virtualItem.key as react component key

[akinnee]

Describe the bug

<SomeItem key={virtualItem.key} />

results in:

Type 'Key' is not assignable to type 'Key | null | undefined'.
  Type 'bigint' is not assignable to type 'Key | null | undefined'.ts(2322)

index.d.ts(98, 9): The expected type comes from property 'key' which is declared here on type 'IntrinsicAttributes'

I suspect this may be due to being on an older version of React than what the Key type is targeting? But I don't think this should matter.

const key = String(virtualItem.key); works fine as a workaround, but it'd be nice if either:

• Key type from installed version of React is used
• Key type is inferred from getItemKey
• Key type could be passed to useVirtualizer, like useVirtualizer<TItemKey>(...)

As always, great job with this library. I love it! ❤

Your minimal, reproducible example

https://stackblitz.com/edit/tanstack-virtual-pksf2gfh?file=src%2Fmain.tsx

Steps to reproduce

• Open StackBlitz link
• In main.tsx, scroll down to key={virtualRow.key} and see the type error

Expected behavior

Shouldn't get a type error

How often does this bug happen?

Every time

Screenshots or Videos

No response

Platform

• MacOS 14.4
• VSCode 1.98.2
• TypeScript 4.9.5

tanstack-virtual version

@tanstack/react-virtual@3.13.5

TypeScript version

4.9.5

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.

[SaeWooKKang]

This issue occurred when the #814 was merged.
The @types/react version in the codesandbox uploaded by the author is v17.0.83, while this update was added in v18.2.22.

• [react] Add support for BigInt in key DefinitelyTyped/DefinitelyTyped#66723 (comment)

However, the react adapter still states that it supports react versions from 16, 17

virtual/packages/react-virtual/package.json

Lines 68 to 70 in c325326

	"peerDependencies": {
	"react": "^16.8.0 || ^17.0.0 || ^18.0.0 || ^19.0.0",
	"react-dom": "^16.8.0 || ^17.0.0 || ^18.0.0 || ^19.0.0"

The actions the author can take might include 1. upgrading the React version or 2. downgrading the tanstack/virtual version.

I think there are two ways to solve a more fundamental problem.

1. Discontinue support for react 16, 17 versions
2. Revert fix(virtual-core): add bigint to Key to align with @types/react implementation #814

I think option 2 is appropriate since option 1 is destructive.
@piecyk If you assign this task to me, I'm willing to proceed with it. Thank you.

[akinnee]

What did you think about the 3 options I proposed for making it compatible?

• Key type from installed version of React is used
• Key type is inferred from getItemKey
• Key type could be passed to useVirtualizer, like useVirtualizer<TItemKey>(...)

Other than this one issue with the types, there are no issues using this library with React 17, so I will not downgrade the version of react-virtual.

And I'm blocked on upgrading React for now because this is in an app that is mounted as a remote component using module federation, and I'm waiting for the host app to upgrade React.

[SaeWooKKang]

@akinnee First of all, thank you for the good comments. Looking at the first and third comments, I think it is appropriate to keep the previous version compatibility and at the same time solve the problem of react.

If you look at the following issue #819 , this is not just a problem of React. Therefore, I think it is appropriate to solve the problem of core, not adapter, to solve this problem.

I'm sorry, I didn't understand the second opinion

[piecyk]

Hey! @akinnee thanks for laying out the options, I was actually thinking along the same lines.

After looking into it more, it seems like the only reliable fix for the type issue is to explicitly pass the key type to useVirtualizer.

Inferring the key type from getItemKey alone runs into TypeScript’s generic constraint issues (TKey could be something wider), so the generic parameter is really the only way to make it work

Also worth noting: if we go with the generic + default param approach (e.g. TKey extends Key = Key), this change won’t be breaking. Current users wouldn’t have to change anything.

I’ll try to work on this soon-ish. 👍 Thanks

[akinnee]

Awesome! I'd be happy with the solution of passing in TKey. Thanks. 😁