useIsSSR with I18nProvider breaks Virtualizer in react-aria-components 1.9.0 in Next.js

[korri123]

Provide a general summary of the issue here

See reproducer repository, to test run npm run dev and open the page in http://localhost:3000
Happened upgrading react-aria-components to from 1.8.0 to 1.9.0

Error: Error: Cannot destructure property 'key' of 'reusableView.content' as it is null. in Virtualizer component

If you remove the useIsSSR hook, or any hook that uses that hook such as useFilter it stops breaking.
Just calling

React['useSyncExternalStore'](subscribe, getSnapshot, getServerSnapshot)

Which useIsSSR does is enough to reproduce as well

🤔 Expected Behavior?

It will work as it did previously

😯 Current Behavior

There will be an error Error: Cannot destructure property 'key' of 'reusableView.content' as it is null.

💁 Possible Solution

No response

🔦 Context

Next.js app, we noticed a regression in our table components

🖥️ Steps to Reproduce

Steps to reproduce:

1. In Next.js app, base layout.tsx, include <I18nProvider locale={'en-US'}> around children through a client component
2. In page.tsx, include client component with <Virtualizer/>, <Table>, <TableHeader> and everything required for a table and a useIsSSR hook call, or the useSyncExternalStore call with a server snapshot callback

For a reproducer, I've made a repository here: https://github.com/korri123/react-aria-issue

Version

^3.40.0

What browsers are you seeing the problem on?

Chrome

If other, please specify.

No response

What operating system are you using?

macOS

🧢 Your Company/Team

No response

🕷 Tracking Issue

No response

[snowystinger]

Thanks for the reproduction, would you be willing to use the nightly versions to bisect?
https://www.npmjs.com/package/react-aria-components?activeTab=versions
version is defined as 3.0.0 (arbitrary), followed by git commit hash, followed by date yymmdd

There can be multiple commits within one nightly, but this gives us a rough idea of where the break happened

[korri123]

I can do that tomorrow, thanks for the swift response

[korri123]

I can confirm that the breaking version is 3.0.0-nightly-c1fd8af79-250510

[korri123]

This seems like a likely suspect:

[snowystinger]

Thanks for tracking that down. I verified that reverting the line did fix the problem outlined here. Will bring to the team and see if there are other ideas for here.

[LFDanLu]

Doing some digging right now, at a glance it seems we can change

react-spectrum/packages/react-aria-components/src/Virtualizer.tsx

Line 141 in 79505ba

if (node.type === 'item' && renderDropIndicator && layout.getDropTargetLayoutInfo) {

to be node?.type === 'item' and things seem to render alright. For the version of the code that is currently part of 1.9.0, you could try patching https://github.com/adobe/react-spectrum/blame/77b3442e4150116f3d35995b5a98b582d9e6f231/packages/react-aria-components/src/Virtualizer.tsx#L140-L141 so that it checks if reusableView.content is defined, seems like it is null sometimes, but still trying to figure out why that is.

Unfortunately, we can't just revert the state.contentSize.area change mentioned above since it fixes some scroll into view behavior with Selects.

[LFDanLu]

So the flow that seems to be happening is that during this time the collection is processing/building out the contents of the table itself, mapping out the cells/rows/etc. At this time we hit this line since the new collection now contains the processed cells/rows/body/columns/etc

react-spectrum/packages/@react-stately/virtualizer/src/Virtualizer.ts

Lines 271 to 274 in 79505ba

	if (opts.collection !== this.collection) {
	mutableThis.collection = opts.collection;
	needsLayout = true;
	}

and prep the existing views for reuse via

react-spectrum/packages/@react-stately/virtualizer/src/Virtualizer.ts

Lines 205 to 214 in 79505ba

	private updateSubviews() {
	let visibleLayoutInfos = this.getVisibleLayoutInfos();
	let removed = new Set<ChildView<T, V>>();
	for (let [key, view] of this._visibleViews) {
	let layoutInfo = visibleLayoutInfos.get(key);
	// If a view's parent changed, treat it as a delete and re-create in the new parent.
	if (!layoutInfo || view.parent !== this.getParentView(layoutInfo)) {
	this._visibleViews.delete(key);
	view.parent.reuseChild(view);

. This clears out the content of the ReusableView via

react-spectrum/packages/@react-stately/virtualizer/src/ReusableView.ts

Lines 55 to 59 in 79505ba

	prepareForReuse(): void {
	this.content = null;
	this.rendered = null;
	this.layoutInfo = null;
	}

, resulting

react-spectrum/packages/react-aria-components/src/Virtualizer.tsx

Lines 140 to 141 in 79505ba

	let node = reusableView.content!;
	if (node.type === 'item' && renderDropIndicator && layout.getDropTargetLayoutInfo) {

in throwing an error since we expected content to always be defined. This used to always be true since we wouldn't call renderChildren if the contentSize.area === 0 as mentioned above, something that happens specifically during this portion of relayout, but now that we don't early return there anymore that assumption no longer holds true.

I think adding node?.type as mentioned in my previous comment is correct here since future renders afterwards will run with fully defined content, but will need to test further. If you are able to patch that line to check if reusableView.content is defined and/or defaulting it to {} if it isn't, definitely let us know if that fixes your table components.

[korri123]

I'm on vacation at the moment, but I'll be back with a response as soon as I'm home. Thank you for taking a deep dive into this.

[snowystinger]

@LFDanLu and I verified it in their reproduction repo locally. Here's the fix branch fix: Virtualizer with useIsSSR