The main struggle I see people have with act (which I have myself) is that all the updates aren’t flushed. The solution is usually to await act. If that doesn’t work, send me a test and I can take a look.
The flow there is: - click - transition: navigate - suspend: fallback
Transitioning here should be fast so no time slicing needed, and then Suspense waits on the network data. Suspense will prewarm the tree while waiting on network, and use time slicing to yield to user input.
The place time slicing can help (in any UI library) is for navigations because mounting the DOM for new pages is going to take more than a frame, so you want to yield to user input. But that’s Suspense, not transitions.
A lot of people think startTransition is only for time slicing expensive updates, but that’s a side quest of the actual feature which is coordinating async with Suspense.
I don’t think anyone has really solved the problem in JavaScript. React devs struggle when they want to opt out of reactivity, other library users struggle when they want to opt-in.
the API is powerful because it completely turns off reactivity for the code inside. however, that’s also very dangerous if used all over the place because you don’t know where along the chain reactivity might disappear. the constraints prevent that
we did plenty of talks that explained "async react" over the years, but all of the talks were forward facing, like "in the future, you'll be able to do x,y,z".
all those features exist now, but i think people forgot or don't know all the benefits of those features.
i think what i want to do in this talk is to kind of throw out the CPU benefits, because they really don't matter, and explain Fiber and concurrent rendering just as async features built into react.
yeah the time slicing demo was a classic. it's so good that everyone still talks about it, but it over shadowed the second half of the talk for the I/O benefits and the vision for "async react"
