Code Examples

[debs-obrien]

I think it would be really useful to have the list of features in one place with code examples as it's hard to find them amid all the discussions and @gaearon has posted some really cool ones. For example this is a great code example/demo of using <Suspense> including using a nested <Suspense>.

Suspense

https://codesandbox.io/s/wispy-haze-q62vr?file=/src/index.js

[Andarist]

Not sure if this is the most appropriate place to ask this - we can repost to another thread later on if needed.

I've played with this simple Suspense demo and I couldn't get rid of "cascading spinners" - are rules regarding that written down anywhere? I mean - what are preconditions for inner Suspense to show its placeholder when the outer Suspene resolves?

[Andarist]

This makes sense - the difference is quite subtle and might be a source of confusion to people. I understand that you don't want to tie yourself into any particular semantics as those might evolve with time. OTOH I feel like this kind of thing should be documented - this will pop up in questions/conversations anyway.

Thank you for explaining this to me.

[debs-obrien]

Im gonna write a post on it, which basically summarizes all this. Will share it when finished. For now it's just in note format. Hopefully tomorrow can type it up and send for review. But agree that it's super useful to understand how this works and for sure should appear in docs when they are released 😊.

[gaearon]

might be a source of confusion to people

In practical terms if I hadn't wrote that it exists, 99% people would likely never notice that it does. That's the case with heuristics like this. Since they depend on timing you don't really consciously think about them or notice them. You see a bit fewer loading states but likely not enough that you'd go debugging them. Since if it feels too slow, the heuristic is bad and needs to be adjusted. Like, timing-wise, these updates could've just gotten batched together anyway.

I may be slightly regretting posting about it. :D There's a bunch of small heuristics in React that we'll be adjusting, but not every one deserves an official writeup.

Im gonna write a post on it, which basically summarizes all this.

I think we need to be careful with how and when to approach this. It's a super subtle detail that most users will never think about. There's a difference between a post that goes like "here's a subtle detail you didn't notice but that improves UX when you use React 18" and something that makes people feel they need to learn it or know about it, or even stress about understanding it. It's also not impossible we'll completely remove or change how this heuristic works by the time 18 is stable.

[debs-obrien]

yeah understood. Ok will write something up without going too deep and send for review and if not ok will just keep it for my personal learning. I guess not everyone likes to or needs to know the internals of how things work so will focus it on just Suspense and nesting rather than what happens if deeply nested.

[Andarist]

I may be slightly regretting posting about it. :D There's a bunch of small heuristics in React that we'll be adjusting, but not every one deserves an official writeup.

I understand the sentiment and that I agree that you shouldn't feel tied to any particular heuristics here. I think though that documenting them is important (with a note that they are subject to change). It doesn't matter for people until it does. I would much more appreciate a model that I can reason about than a magic blackbox one. This might be especially frustrating when learning a feature and experimenting because we don't know what to expect and yet we try to build up a mental model from experiments etc. We try to learn how to use a feature and how to incorporate it into our projects - not knowing those details (or not being able to learn about them) undermines trust in a feature.

[drcmda]

i collected some use cases: https://twitter.com/0xca0a/status/1402558011357470720 they mostly contain codesandboxes, too. i know this canvas stuff isn't relevant for frontend dev but these use cases are for sure and they're all a little out of the box, not always concerned with loading and spinners but also orchestrating async behaviour (if this is done, do that).

[gaearon]

New SSR

This server rendering demo shows what's unlocked by the new SSR Suspense architecture (#37), including Streaming HTML rendering and Selective Hydration. Notably, it shows lazy() "just working" on the server.

https://codesandbox.io/s/festive-star-9hfqt?file=/src/App.js

Keep in mind it doesn't have a real data fetching integration yet so those parts are faked out.

[gaearon]

Suspense for Data Fetching (Cache + libraries like React Fetch)

This still has open questions and likely won't be a part of 18.0.0 (#49). But I wanted to link to these so that you can see a more realistic example of how it's supposed to look in the code. (Our early examples like the one you linked in the post don't reflect that!)

This example uses react-fetch to grab some data from Reddit API: https://codesandbox.io/s/sad-banach-tcnim. It also uses useTransition (#41) to show old data while refetching. It uses the (unstable) Cache API (#25) to invalidate the cache when refetching.

This example further builds on it and shows how an (unstable) <Cache> component (#25) lets you have separate parts of the tree with separate caches: https://codesandbox.io/s/laughing-almeida-v3gk5

Finally, https://github.com/reactjs/server-components-demo shows the preferred data fetching strategy, where react-fetch would instead run on the server where the latency is low.

[gaearon]

startTransition

We're planning to add more demos/examples but I'll just to link to a few I already saw.

Fractal demo

This demo is pretty cool: https://react-fractals-git-react-18-swizec.vercel.app/. (source code)

See the blog post.

React is not the best tool to render a fractal (you're probably better off with using WebGL!) but this demo does show a few cool things. In the source, updates to the slider are "urgent" while updates to the graph are marked as transitions.

Increase the tree depth (left slider) and then drag the "lean tree" slider left and right. You'll notice the input is lagging a lot because it's blocked by the fractal rendering.

Now tick "use startTransition" checkbox. Notice how you dragging the slider is now (more or less) fluid even though the fractal is just as slow to re-render! This is the key feature startTransition gives you: it lets you keep UI responsive despite large re-renders.

For extra effect, tick the "make each square block the thread for 0.1ms" box. This activates code that artificially slows down each square in the fractal. This shows a unique capability that libraries that claim to be "faster" than React might have difficulties replicating. If each square is updated, and each square takes 0.1ms, there is simply no way for a UI library to speed it up. It all comes down to whether all rendering is urgent, or if it's possible to split it up (like React does with transitions). You'll notice that if you tick "use startTransition", even artificially slow rendering does not hurt the slider's responsiveness. If you untick the checkbox, it will lag very badly.

[gaearon]

Switching tabs with startTransition

In this example, we use startTransition to render a large table of content in background. Note that even though it takes a long time, switching tabs is instant: https://codesandbox.io/s/usetransition-tab-test-forked-dxukf?file=/src/App.js. While a transition is pending, we dim out the table visually.

Try changing

    // setValue(newValue)
    startTransition(() => setValue(newValue));

to

    setValue(newValue)
    // startTransition(() => setValue(newValue));

and then click on tabs fast to compare the user experience with or without transitions.

[gaearon]

Real-world startTransition demo

We've posted a demo of adding startTransition to improve a real app's performance here: #65