Add support for rendering BigInt

[eps1lon]

Summary

Closes #20492

Adds support for rendering BigInt behind enableBigIntSupport (experimental only). This includes support for values of input, option and textarea as BigInt for consistency. Otherwise <div>{5n}</div> would work but not <option>{5n}</option>.

BigInt values are now rendered instead of being treated like no value was given. For example, <div>{5n}</div> would previously render <div></div>. Now it renders the stringified value of the BigInt i.e. <div>5</div>.

The only negative impact I can imagine is the same mistake make people for numbers like <div>{length && items.map(...)}</div> which results in the infamous "0" display in your UI. With BigInt you didn't have this but now you have. But then I'm not aware of any built-in that uses BigInt for collection size.

How did you test this change?

• CI
• https://codesandbox.io/s/react-missing-bigint-support-uclq9i renders something with a build from this PR: https://codesandbox.io/s/react-missing-bigint-support-l6i9pn

[sizebot]

Comparing: 4cd788a...a87598f

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-stable/react-dom/cjs/react-dom.production.min.js	+0.08%	131.79 kB	131.89 kB	+0.09%	42.40 kB	42.44 kB
oss-experimental/react-dom/cjs/react-dom.production.min.js	+0.08%	137.06 kB	137.16 kB	+0.10%	44.00 kB	44.04 kB
facebook-www/ReactDOM-prod.classic.js	+0.05%	457.17 kB	457.39 kB	+0.04%	83.22 kB	83.25 kB
facebook-www/ReactDOM-prod.modern.js	+0.05%	442.41 kB	442.63 kB	+0.03%	80.94 kB	80.96 kB
facebook-www/ReactDOMForked-prod.classic.js	+0.05%	457.94 kB	458.16 kB	+0.03%	83.33 kB	83.36 kB

Significant size changes

Includes any change greater than 0.2%:

Expand to show

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
facebook-www/ReactDOMServer-prod.classic.js	+0.31%	48.03 kB	48.18 kB	+0.24%	11.21 kB	11.24 kB
facebook-www/ReactDOMServer-dev.classic.js	+0.29%	157.79 kB	158.24 kB	+0.37%	39.99 kB	40.13 kB
oss-experimental/react-noop-renderer/cjs/react-noop-renderer.production.min.js	+0.24%	12.35 kB	12.38 kB	+0.14%	3.68 kB	3.69 kB
oss-stable-semver/react-noop-renderer/cjs/react-noop-renderer.production.min.js	+0.24%	12.35 kB	12.38 kB	+0.14%	3.68 kB	3.69 kB
oss-stable/react-noop-renderer/cjs/react-noop-renderer.production.min.js	+0.24%	12.35 kB	12.38 kB	+0.14%	3.68 kB	3.69 kB
oss-experimental/react-noop-renderer/cjs/react-noop-renderer-persistent.production.min.js	+0.24%	12.42 kB	12.45 kB	+0.14%	3.70 kB	3.70 kB
oss-stable-semver/react-noop-renderer/cjs/react-noop-renderer-persistent.production.min.js	+0.24%	12.42 kB	12.45 kB	+0.14%	3.70 kB	3.70 kB
oss-stable/react-noop-renderer/cjs/react-noop-renderer-persistent.production.min.js	+0.24%	12.42 kB	12.45 kB	+0.14%	3.70 kB	3.70 kB
oss-experimental/react/cjs/react.shared-subset.production.min.js	+0.22%	6.40 kB	6.42 kB	+0.27%	2.62 kB	2.62 kB
oss-stable-semver/react-server/cjs/react-server.development.js	+0.22%	130.50 kB	130.78 kB	+0.29%	32.67 kB	32.77 kB
oss-stable/react-server/cjs/react-server.development.js	+0.22%	130.50 kB	130.78 kB	+0.29%	32.67 kB	32.77 kB
oss-experimental/react-server/cjs/react-server.development.js	+0.21%	131.37 kB	131.65 kB	+0.29%	32.88 kB	32.97 kB
oss-stable-semver/react/cjs/react.production.min.js	+0.20%	6.91 kB	6.93 kB	+0.30%	2.70 kB	2.70 kB
oss-stable/react/cjs/react.production.min.js	+0.20%	6.94 kB	6.95 kB	+0.33%	2.72 kB	2.73 kB

Generated by 🚫 dangerJS against a87598f

[gaearon]

If we support this, should we also support them as keys? What are the arguments for and against? What about attribute values? Does it already work there?

[eps1lon]

What about attribute values? Does it already work there?

It works for attributes that don't get any special treatments (tested with data-test). But from looking through all the typeof val === 'number' occurences in the codebase, it probably doesn't work for <input value /> or <option value />. I left this as a TODO in the PR description.

If we support this, should we also support them as keys? What are the arguments for and against?

I'd probably just support BigInt for key for consistency with children and other attributes. An argument against it would be that bigints as keys allows lists with a huge number of items though that argument isn't all that convincing since lists with Number.MAX_SAFE_INTEGER items are probably already too big.
An argument for BigInt as key would be if you have items whos ID is a BigInt

I find the following two argument against bigint support the most convincing:

• implementation work (now and future): almost every typeof value === 'number' check needs to consider 'bigint' whereas it's fairly trivial to just do String(someBigInt) in your codebase
• unclear how this works with React Server Components (you can't JSON.stringify BigInt so you need to special case (de-)serialization

[harish-sethuraman]

Suggested change

	itRenders('a biging', async render => {
	itRenders('a bigint', async render => {

👀

[sebmarkbage]

Needs to be flagged or landed as part of next major.

[react-sizebot]

Comparing: 239d06e...ad6e64f

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-stable/react-dom/cjs/react-dom.production.min.js	+0.01%	176.86 kB	176.89 kB	+0.02%	55.13 kB	55.14 kB
oss-experimental/react-dom/cjs/react-dom.production.min.js	+0.11%	179.01 kB	179.20 kB	+0.07%	55.77 kB	55.81 kB
facebook-www/ReactDOM-prod.classic.js	=	594.00 kB	594.04 kB	=	104.93 kB	104.94 kB
facebook-www/ReactDOM-prod.modern.js	=	577.29 kB	577.33 kB	=	101.95 kB	101.96 kB
test_utils/ReactAllWarnings.js	Deleted	66.35 kB	0.00 kB	Deleted	16.24 kB	0.00 kB

Significant size changes

Includes any change greater than 0.2%:

Expand to show

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-experimental/react-noop-renderer/cjs/react-noop-renderer.production.min.js	+0.33%	15.37 kB	15.42 kB	+0.19%	4.68 kB	4.69 kB
oss-stable-semver/react-noop-renderer/cjs/react-noop-renderer.production.min.js	+0.33%	15.37 kB	15.42 kB	+0.19%	4.68 kB	4.69 kB
oss-stable/react-noop-renderer/cjs/react-noop-renderer.production.min.js	+0.33%	15.37 kB	15.42 kB	+0.19%	4.68 kB	4.69 kB
oss-experimental/react-noop-renderer/cjs/react-noop-renderer-persistent.production.min.js	+0.33%	15.45 kB	15.50 kB	+0.19%	4.69 kB	4.70 kB
oss-stable-semver/react-noop-renderer/cjs/react-noop-renderer-persistent.production.min.js	+0.33%	15.45 kB	15.50 kB	+0.19%	4.69 kB	4.70 kB
oss-stable/react-noop-renderer/cjs/react-noop-renderer-persistent.production.min.js	+0.33%	15.45 kB	15.50 kB	+0.19%	4.69 kB	4.70 kB
oss-stable-semver/react/cjs/react.react-server.production.js	+0.32%	33.45 kB	33.56 kB	+0.37%	9.96 kB	9.99 kB
oss-stable/react/cjs/react.react-server.production.js	+0.32%	33.47 kB	33.58 kB	+0.34%	9.99 kB	10.02 kB
oss-stable-semver/react/cjs/react.production.js	+0.28%	38.29 kB	38.40 kB	+0.34%	10.67 kB	10.71 kB
oss-stable/react/cjs/react.production.js	+0.28%	38.32 kB	38.43 kB	+0.31%	10.70 kB	10.74 kB
test_utils/ReactAllWarnings.js	Deleted	66.35 kB	0.00 kB	Deleted	16.24 kB	0.00 kB

Generated by 🚫 dangerJS against ad6e64f

[eps1lon]

If we support this, should we also support them as keys? What are the arguments for and against?

We already support it in keys since we just stringify keys. The only requirement for keys is that they stringify to something unique within a collection.

Needs to be flagged or landed as part of next major.

Added a flag. I don't think this constitutes a breaking change so I wouldn't block 19 on it and defer it to a minor if we need more time to test it.

[sant123]

This does not work on 18.3.1 😕

[eps1lon]

It wasn't intended for 18.x. It's part of React 19

[sant123]

Ohhh got it, thanks!!

[bernaferrari]

I really hate this change. React.Children.toArray(children) won't work anymore because Type 'bigint' is not assignable to type 'ReactNode | ReactNode[].

This breaks: (Spread types may only be created from object types.ts(2698))

   {React.Children.map(children, (child) => {
          if (!React.isValidElement(child)) {
            return null
          }

          return React.cloneElement(child, {
            ...child.props,
            variant: child.props?.variant || variant,
          })
        })}

Also createPortal won't work anymore: vercel/next.js#64753

And finally, you need to wrap some things with <>{children}</> instead of using {children}.

[eps1lon]

And finally, you need to wrap some things with <>{children}</> instead of using {children}.

You shouldn't have to. What makes you say that?

[bernaferrari]

If you check the discussion there is more people with the same problem: vercel/next.js#64753

Not sure it is shadcn/ui, nextjs or what.

[eps1lon]

Then let's identify the issue first before concluding this is a bad change. I'll check out the repro. But let's confirm things first before opening up multiple issues.