React 18 : Possible Transition use case? Rendering large table with filtered tabs

[ksaldana1]

Apologies if this is an inappropriate place to ask this type of question. When reading about React 18, in particular the startTransition API, I started thinking of problems I've run into in the past where I had to do lots of manual management of renders to provide good UX. I tried to recreate the original problem (at least a contrived version of it) in a CodeSandbox:

https://codesandbox.io/s/usetransition-tab-test-575cu?file=/src/App.js

I attempted to describe the problem in the sandbox, but basically I am trying to optimize the interaction and navigation of the Tab components onClick—the "high priority" update—and defer the rendering of the table data (through a loading spinner or delay of table data rendering).

Reading through the startTransition explanation, I'm not sure if this an appropriate use case. My tab component is not a native browser component, and it seems that I only have the ability to mark "low-priority" updates and not the opposite (eg. wrapping handleClick as a high-priority update).

I was hoping to get some clarification if my mental model is off here. I am aware there are other ways to deal with this problem (eg. list virtualization), but I'm mostly trying to understand the scope of the startTransition API.

Thanks for all the hard work! I'm very excited about the new developments in React 18 and appreciate your team's commitment to pragmatism.

[ksaldana1]

Playing around more I landed on this solution:

https://codesandbox.io/s/usetransition-tab-test-forked-mjvvz?file=/src/App.js

This seems to cover my use case. I'd be curious to hear if you this is how you would approach this problem with this API, but feel free to close this issue, as it seems I might have figured it out on my own.

edit: I found some tweets from Dan that go over this use case 😄 .... Well at least I learned something lol. Awesome stuff, looking forward to using it more!

[gaearon]

So there's multiple ways to approach this depending on what UX you want.

The canonical case where you'd use startTransition is if you want to keep old data on the screen. In that case you'd want to slightly dim it or give some other visual appearance that it's out of sync with the data. You can do it like this: https://codesandbox.io/s/usetransition-tab-test-forked-41mvy?file=/src/App.js. Note I've added memo() around the table just in case you later want to add some urgent state updates into the parent components, and don't want those updates to re-render the table.

If you want to show the new screen ASAP but show some kind of a spinner while it's rendering, we have a different feature for this that isn't documented: #19936. Here is an example: https://codesandbox.io/s/usetransition-tab-test-forked-4b3zx?file=/src/App.js. Specifically, presence of the unstable_expectedLoadTime prop (value is currently ignored) activates a new mode where Suspense displays fallback while the components inside are rendering (if they're computationally expensive). I've had to add a key to the Suspense boundary so that switching tabs actually creates new Suspense boundary (instead of reusing the existing one), which is what makes the tab clicks fast.

Hope this is useful.

[ksaldana1]

Thanks for the additional info, I really appreciate it! I was curious if there was a "delay" or "load time" prop for that specific use case, because that starts getting into functionality that is very hard (not even sure if possible) to replicate in user code.

Looking through the codebase, it seems that, at least at some point, the useTransition hook had a timeoutMs prop. Though it seems like that is just a relic from an older iteration of the API, since the new hook does not have that signature.

The suspense example with the key manipulation is pretty neat—looking forward to seeing the final iteration of these features.

Thanks again, Dan!