[RAC] Table components do not play well with Suspense

[levrik]

Provide a general summary of the issue here

I started building a design system on top of React Aria Components. The application that uses it is built using TanStack Router and Apollo Client. Both of them use Suspense for data fetching. At first this seems to work fine but things are starting to get very weird when it comes to things like infinite scrolling (meaning loading more data on scroll) for example. While wrapper components properly re-render with the updated data these updates aren't displayed by RAC components. It gets even weirder: When a component got into this broken state, simply clicking anywhere on the screen causes the table to be simply emptied. No errors or warnings.

I'm still trying to come up with a minimal reproducible example but wanted to open this issue already as you might be aware of undocumented shortcomings with RAC and Suspense already. I suspect that the fake DOM implementation that tables use might the culprit here but I'm still collecting details.

🤔 Expected Behavior?

Things to not break. More details on reproduction case below.

😯 Current Behavior

As described in summary.

💁 Possible Solution

No response

🔦 Context

No response

🖥️ Steps to Reproduce

https://codesandbox.io/p/sandbox/tender-resonance-76wlzv?file=%2Fsrc%2FLocationsTable.jsx%3A47%2C15

RAC.Suspense.Issue.mp4

fetchMore of Apollo Client re-suspends by default, meaning it should show the nearest Suspense fallback. Which it does but instead of replacing all rows it only shows it (Loading...) in addition. While this might seem correct from a UX perspective it's not what would be expected from a technical viewpoint. You can try the same with raw HTML tags and it will replace the whole body by Loading... instead of temporarily appending a new row.

It gets even worse when wrapping the fetchMore call in startTransition. This should be done to avoid suspending to the nearest fallback and instead keep the previous UI mounted while the fetch is ongoing. At first this seems to work but as soon as the component re-renders the table simply doesn't display the newly fetched rows. The wrapping component gets correctly re-rendered, also the new rows are there (see console.log).

Version

1.1.1

What browsers are you seeing the problem on?

Microsoft Edge

If other, please specify.

No response

What operating system are you using?

macOS

🧢 Your Company/Team

No response

🕷 Tracking Issue

No response

[levrik]

Added Codesandbox and screen recording of a minimal reproducible example.

[devongovett]

Will need to do some debugging in the collection implementation to determine what's going on. In the meantime, can you move the Suspense boundary outside the Table instead?

[levrik]

@devongovett Yep. This seems to work fine.

I also already tried to debug the collection internals but I think I'm lacking too much knowledge of what's going in there actually 😅

[cyco130]

I believe I'm running into the same problem but moving the Suspense boundary doesn't seem to be of any help in my case: It's already outside of the component rendering the table (in main.tsx). I'm using useSuspenseQuery from @tanstack/react-query.

See the repro or see it on StackBlitz. It renders a ul element on the right to show the expected output.

As an added data point, wrapping the setState call in startTransition seems to fix it. But I can't do it in my real case because the data query key actually comes from the URL and I don't have control over the router.

I have no knowledge of the RAC internals but React.useRef is usually the culprit when used for "caching" some data: It doesn't play nice with interrupted renders.

[snowystinger]

Another potential workaround has been found #6801 (comment)

[alecmev]

I think I'm experiencing something similar with Next.js and Breadcrumbs: https://codesandbox.io/p/devbox/dry-night-97f3nx No querying, just suspense-wrapped navigation.

[mwannewitz]

I'm also experiencing issues with Suspense, Next.js and the collection API, in this case Tabs.

Naive implementation with loading.tsx and Next Links: Sandbox

• initial tab switching shows the loading state
• the selected tab is switched right away (optimistically) before loading its content

Using Tabs with href, wrapping the TabContent in Suspense: Sandbox

• Tab is not switched immediately

⚠️ everything else looks fine as long as in dev mode. but when running npm run build && npm run start and looking at the production build, it suddenly is not working anymore:

• no loading state is shown
• Suspense with a key not working as mitigation

[jakubriedl]

We're having the same issue when using GridList in combination with Jotai. Interestingly while the GridList is originally rendered inside Suspense boundary, the jotai atom update is client only and shouldn't afaik cause another suspension.

[vezaynk]

I have dug deep into the code and think I’ve gotten close to the root cause, but I haven't managed to apply a fix yet. I'm doing this write-up to have a public reference for where I left off before the weekend.

The short version is that there is an outdated assumption in the implementation (or usage) of BaseNode. BaseNode fakes an incomplete DOM API for React, which is not fully compatible with Suspense.

The issues are two-fold. First, let's talk about the "Loading" indicator appearing alongside the what-should-be the suspended component.

Suspense without Transitions

What is happening here is that when a component is Suspended, React doesn't discard the DOM elements since it expects to re-use them afterward. Instead, it just hides them.

It applies an inline style display: none !important for complete DOM nodes to remove it from view.

Relevant code: https://github.com/facebook/react/blob/a6ce56d9a9162c295ef0086762b76506534de201/packages/react-dom-bindings/src/client/ReactFiberConfigDOM.js#L977-L988

For text nodes, it removes the text: https://github.com/facebook/react/blob/a6ce56d9a9162c295ef0086762b76506534de201/packages/react-dom-bindings/src/client/ReactFiberConfigDOM.js#L990-L992

Both of these are paired with un-hide functions in the same file.

BaseNode needs to implement support for both of these scenarios, OR, hook into unsafe internals of React to detect if the element is being rendered during Suspense or not.

Suspense with Transitions

Transitions use off-screen rendering, where they render a DOM out of sight until it is ready to be displayed. Very similar to the way Collections work in react-aria!

I haven't figured out the root cause here, but something about it causes Document Collections to miscount the number of transactions any time nodes are meant to be added. This prevents updates from being applied. A dirty fix I made was to simply ignore the checks for transactionCount, which outright fixed the issue (but likely with some performance penalty).

Tagging @devongovett, I hope you can provide me with any pointers to help me dig further into this one.

[vezaynk]

Following up.

RE: Suspense without Transitions

The stack is very thick. I'm still looking for a decent way to pass the "this component is suspended and should be hidden" information to the rendered screen. Haven't found one yet.

RE: Suspense with Transitions

startTransition is called in the constructor and the corresponding endTransition is called in setProps, which in turn is called from useSSRCollectionNode via a ref:

  let itemRef = useCallback(
    (element: ElementNode<any> | null) => {
      element?.setProps(props, ref, rendered, render);
    },
    [props, ref, rendered, render]
  );

// ...

return <Type ref={itemRef}>{children}</Type>;

This is clearly not being called consistently when using Suspense without transition. The reason is that all lifecycle methods are skipped when performing an off-screen renders. This includes effects AND refs.

The end result is is that for every suspended component, it calls createElement twice, and setProps once.

[vezaynk]

RE: Suspense with Transitions

After trying to make a stop-gap patch, I still haven't found a way to replace the need for element?.setProps(props, ref, rendered, render) without a fundamental re-architecture. It's very much a necessary call for the functioning of collections, so I can't just not make it affect the counting.