Thread by @dan_abramov

It's another Friday night indoors, so being the nerd I am, of course I am playing with adding startTransition to open source apps to see if it works. Don't judge me

We really need to make some demos but maybe I could record a few short videos if y'all are curious (but no FOMO please, it's still an Alpha, etc)

Okay so this one shouldn't be hard to follow. There's an input and a table. Currently, table state update is delayed and debounced so it doesn't stutter typing. But stutter is noticeable if I type slower. (Caveat: we're in DEV mode so the real app is faster—but nice for demo.)

I wonder what happens if we remove debouncing and just update the table on every input update? OUCH. That's why it's debounced. Makes sense.

Now let's switch the app to createRoot() and add this little friend around the table update: github.com/reactwg/react-…

This is the result. Literally no other changes to the app code. Unlike the debounced version, it starts handling the input immediately. But it also doesn't lock up the browser to re-render a table because that update is marked as a transition. Typing again interrupts it.

I hope we can put the "this is only useful to Facebook" argument to rest right here.

The cool thing about this is that it adapts to the computer.

On a fast computer, it responds instantly because it re-renders the table between keystrokes. So no unnecessary delay like debouncing.

On a slow computer, table update "catches up" but the input stutters much less.

It wasn't easy to find an app to test it on because larger examples often use state managers. While we'll definitely make state managers compatible with 18 (ongoing work!), this feature is unlocked by using... plain React state. I hope it'll let you use state in more places.

But unlike our previous strategy, there are no big global changes you have to make. No scary "mode" to prepare your app for.

Need to keep using a state manager? Keep using it! But you can move a bit of UI state back into React and then try startTransition for that part of it.

Oh, this UI looks pretty cool. Seems like it's fast even without startTransition. Nothing to do here. Or maybe?...

Would be a shame if something happened to it... Like if we slow it down 4x to simulate a slow device. You can optimize your code, but if all updates are urgent, at some point synchronous rendering won't fit in a single frame. Hello, jank.

You could write fancy coordination code to manage animation frames and throttle chart rendering. That could be a project to show off at next sprint. Or you can just throw in startTransition in there. Still 4x slowed down! The chart "catches up" slower but the input doesn't lag.

Again, on a fast computer, it's just fast. On a slow one, it "catches up". Of course you could still add throttling or debouncing if you wanted to. But why would you?

One thing that feels a bit annoying is that on a slow device, there's no visual feedback that something is happening. So let's replace startTransition with useTransition, which gives us back the isPending flag:

I put a small delay on the CSS transition, so on a fast device isPending immediately goes from true to false, and we don't show anything special. But if it stays true for a while, the CSS transition kicks in, and we see the pending chart dimmed to reflect its content is stale!

Actually, why not use the same strategy in the filter table example? Although the table state lives "above" the input, it's the input that wraps a parent call into a transition. So this input can display the visual feedback regarding its progress. No manual coordination!

So now if the device is slow, we can show a pending indicator... in the input... that reflects whether the parent table re-render in progress... while you can still type at any point without stutter. Thanks, concurrency!

Five lines of code.

That 6x slowdown (with additional ~3-5x slowdown due to DEV mode) is nasty. Watching that spinner gets a bit tiring! But just for fun, let’s run the exact same code in today’s React without startTransition.

Yeah.

Imagine going back to this.

It’s great when you can “just make it faster” or “optimize rendering”. But with other things being equal, it’s just better for non-critical updates be interruptible. On a slow device, it matters. It’s common sense.

We want React users to have that option. With 2-5 lines of code.

The irony is that we haven’t even optimized for this “slow rendering” use case. We left many optimizations until after React 18 because we were focused on the async use case. (The same startTransition API also integrates with data fetching.) But that’s a story for another day.

I want to give a shoutout to @acdlite for doing a vast amount of technical work on these features over the past five years. He’s been thinking about this nonstop so that you can just plug it in. We can’t wait for you to be able to.

I hope this gives you a glimpse of what we’ve been working on. You can see that it actually *works*. It’s not a demo anymore. It’s real. But yes, there will be challenges. We’ll work with the ecosystem maintainers to fix library issues. We’ll be filling in the gaps on our side.

To ship these features, we’ll need your patience and your help. We will work with a few projects first via the React 18 Working Group to determine our guidance and any gaps in APIs for libraries. We’ll need your help spreading that knowledge later. github.com/reactwg/react-…

It’s been a long journey. Stick with us for a little bit longer. We’re in a final phase now. But it’s also a new beginning. The examples above are just small optimizations compared to the actual features we can build on this new foundation. Concurrent rendering is awesome.

PS. One thing you might’ve noticed is that when slowed down, the chart “waits” for me to stop messing with the input. We used to have an optimization to prevent this, but removed it to fix bugs. We’ll re-add it someday. Then it won’t need to wait and will be even more responsive.

https://twitter.com/dan_abramov/status/1403542926026739712

If you remember our very first 2017 “triangle demo” (which was widely misunderstood because it was incomprehensible) — that’s what it meant to show. That it’s able to perform a “slow” update (numbers incrementing) despite being interrupted by “fast” updates (animating scale).

I think the React repo might still have that demo lying somewhere. I’ve seen it copied and used as example that some other library can render a moving triangle faster. But that missed the point because the demo was artificially slowed down to simulate a deep tree with user code.

The irony is that our very first demo won’t work in React 18. It’s because of that missing optimization that’s necessary to “resume” interrupted work instead of starting from scratch. We’ll get there but just allowing rendering it be interrupted is such an improvement by itself.