Blog Post Review

[laurieontech]

As recommended by @gaearon, it would be great to have a place to share and clarify additional content related to React 18.

Feel free to share write-ups below and ask for feedback below. This ensures we're sharing accurate information and not misrepresenting things as we try to engage with the wider community.

[laurieontech]

Tried to give a summary of some of the terminology and topics that have come up related to React features and where they stand related to this release.
https://laurieontech.com/posts/react-18/

[gaearon]

Thank you so much for writing and sharing! I love how concise and to the point this post is.

I'll add a few notes — there is no need to change anything, but I want to use the opportunity to share additional context for future readers (and future writers!)

Specifically, the pre-React 18 Suspense implementation is now referred to as Legacy Suspense and the new implementation is Concurrent Suspense.

This is correct, but outside of the narrow scope of discussing the migration itself (which for most people shouldn't take more than an afternoon), the feature itself is still just called Suspense. So we'd like to avoid creating an impression that "Legacy Suspense" and "Concurrent Suspense" are going to be important terms that one would use very often. It's still just Suspense! I know you know it but wanted to clarify for others who could misread this.

"Concurrent" is the word being used to describe a suite of new features that rely on a specific type of internal implementation.

There are a couple other headline features, but the big takeaway is that concurrent React is a way of getting, and keeping, your pages interactive--even if they're actively doing other things.

This is really a great way to explain it, in my opinion!

In this video they talked about writing React components server side that would then get sent to the client and rendered.

Minor nitpick: Server Components themselves stay on the server (and don't get sent to the client), but their output does. This is contrast to the familiar Client Components (all the ones existing today!), for which the code is always sent to the client.

Overall, great post. Thank you.

[laurieontech]

Thanks Dan! Super helpful.

[chantastic]

I jumped the gun on this bit of self exploration because of my fear of asking too much from the group. But I've been gently encouraged to get over it 😆. I'll edit with changes discussed here. And ask for feedback pre-launch for future posts

This is a post I wrote on the the changing language of React 18. I'd love to know if these terms are in bounds or if they're just working language.

Thanks in advance for your help.

Concurrent Mode is Dead. Long live Concurrent…

Three years ago Dan Abramov introduced Suspense and Async Rendering with React at JSConf Iceland 2018.

In the three years since, terminology took some twists and turns.

"Suspense" was relegated to use with React.lazy.

"Async React" became "Concurrent Mode" — a top-down rendering mode that could be "enabled" for Strict Mode-compatible applications.

React 18 has new-new language. And I'd like to start my tour of React 18 changes by rebasing on new terminology used in the ReactWG (React Working Group).

Concurrent Mode => Concurrent everything

"Concurrent Mode" is no more. Bye 👋. We barely knew ya!

Instead of a concurrent mode, concurrency is possible in all React 18 apps.

A "Concurrent Renderer" is used for the "Concurrent Rendering" of component trees where "Concurrent features and APIs" — like "Concurrent Suspense" — are used.

It's a subtle but important shift.
Concurrency is no longer something that you opt into at the root of your application. It's an enrichment that happens as you use "Concurrent features and APIs" like startTransition.

Concurrent rendering is not a mode.
Concurrent rendering is React.

New-new, React 18 termonology

Here's the state of React 18 termonology shifts I've seen in ReactWG discussions:

Fired:

• ❌ Concurrent Mode
• ❌ Suspense (unmodified)

Hired:

• ✅ Concurrent React
• ✅ Concurrent Rendering
• ✅ Concurrent Renderer
• ✅ Concurrent Suspense
• ✅ Legacy Suspense
• ✅ Concurrent features and APIs

[chantastic]

Thanks for your patience. The exercise of having to put this in my own words helps me understand it all better.

There are two things that are starting to come into view. Let me know if these track:

There are several personas we're writing for…

The work that we're doing here will result in different forms of published communication:

1. v18 documentation (fresh v18 app)
2. v16/17-18 migration (stable-to-stable upgrade)
3. Experimental Suspense to v18 Suspense migration (experimental-suspense-to-18 upgrade)

Moving forward I'll try to keep those in mind and speak clearly about which persona I have in mind.

Verbose terminology "Concurrent Suspense vs Legacy Suspense" is migration language

Inline with the previous revelation, the "Concurrent"-prefixing of everything is only important for the the experimental-suspense-to-18 conversations. React 18 doesn't have two discrete rendering approaches, it just has features that allow you to unlock next-level Suspense features.

Is that accurate?

[chantastic]

For posterity, here is the updated post: https://chan.dev/posts/concurrent-mode-is-dead/

In addition to the changes above, I added two section to the bottom:

Takeaway

In React 18, Concurrent React is React. Concurrent features and APIs — like startTransition — expose controls for opting into concurrent rendering.

Acknowladgements

This post was reviewed and improved by the fantastic folks in the reactwg. Lessons learned while writing this post are available via the reactwg GitHub discussions

[gaearon]

The work that we're doing here will result in different forms of published communication:

Great insight. I agree these are three different cases/personas.

React 18 doesn't have two discrete rendering approaches, it just has features that allow you to unlock next-level Suspense features.

I think it’s still fair to say that there are two separate rendering algorithms. They reuse much of the code (almost all today?) but they’re distinct. The algorithm is chosen based on what kind of update we are handling.

The “simple” explanation is that we use the concurrent rendering for updates triggered by new features, and we use the old rendering algorithm for everything else. That’s the messaging for the general audience.

The more nuanced and technical explanation goes like this. I’m sharing it here for extra clarity but I wouldn’t explain it like this everywhere because it gets a bit confusing.

• Concurrent rendering is the main algorithm. It is triggered for updates wrapped in startTransition, by using useDeferredValue, <SuspenseList>, and by <Suspense> retries (after the Promise resolves). Conceptually, it is our “simplest” algorithm. We try to render a tree. If a part suspends, we throw that part away (and render fallback instead). We let the browser “breathe” every 5ms. When there’s nothing left to render, we decide whether to update screen now or just a bit later. Then we’re done. As you can see, it’s interruptible.
• Synchronous rendering: Conceptually, you can think of this as a separate algorithm. But you could also think of this as a version of the algorithm above with “no brakes”. Meaning, once we start rendering, we don’t stop until we’ve updated the screen. It has no gaps (and is therefore used for “urgent” updates). That’s the algorithm we use for all the other updates.
• However, there’s a nuance. If you haven’t yet migrated to createRoot and are using the deprecated render which warns, you get the third algorithm:
  • Temporary synchronous algorithm with additional legacy behavior. It’s the same for all updates. New features don’t work at all in it (they are ignored—for example, all transitions become urgent). This one almost exactly matches what React 17 and earlier are doing. It has no automated batching. It also does many weird contortions for <Suspense> specifically in order to preserve all the legacy guarantees (like that UNSAFE_componentWillMount corresponds 1:1 to componentDidMount). It prevents us from throwing away suspended trees, and prevents us from fixing a number of common application-level Suspense bugs.

We don’t describe the legacy synchronous rendering algorithm in our messaging because it has no future. It has significant unfixable flaws. This is why render warns and you need to consider createRoot as part of the 18 upgrade. The legacy behavior has no automated batching and it also has the old Suspense semantics.

You can see there is a bit of a trick here. We needed to decide what to do about Suspense. The old quirks existed solely to make UNSAFE_ methods work exactly like before. That prevented throwing away trees. But it also prevents us from fixing bugs and adds a ton of complexity. So what we’ve done is essentially “reclassified” Suspense itself as a concurrent feature. Meaning that using it doesn’t try to preserve the old UNSAFE-motivated semantics. While we’re at it, it also opts you into concurrent rendering specifically for retries. This is really nice because it lets urgent updates interrupt results of data fetches or lazy load completion.

We thought it might turn out to be a problem and we’d have to rethink the strategy. But we updated a few large apps using Suspense a lot and they worked just fine with createRoot aside from one or two small issues (had to remove a buggy impure shouldComponentUpdate in a few components). This gave us confidence to just treat <Suspense> as a concurrent feature. In fact, even UNSAFE_ methods would mostly work like before with it because the part of the tree that can be “thrown away” is the part between <Suspense> and what suspended. Which is often a single component deep. In either case, if for some reason your code doesn’t work, you can always just remove Suspense there and replace it with a user-space implementation of the lazy pattern. Since it wasn’t officially supported for anything else, and unofficial data fetching solutions always have non-Suspense versions.

[gaearon]

So you can also now see what happened to “Concurrent Mode”, “Blocking Mode”, and “Legacy Mode”. They correspond to these three algorithms. The key changes to the strategy was to unify Concurrent and Blocking modes into a single one based on the type of the update. Once we did that, we no longer needed the “mode” concept. The non-createRoot trees still get the legacy behavior (and warn) but it’s no longer a hassle to just get to createRoot. Since if you don’t use new features and don’t deeply combine UNSAFE code with Suspense, the behavior is almost the same anyway.

It’s really quite neat.

[chantastic]

@gaearon if i haven't said it recently, it bares repeating. you are an incredibly technical writer. even your responses here in this "less formal" arena are polished and well considered. thank you for sharing this skill with us and inspiring me to push it further :)

The algorithm is chosen based on what kind of update we are handling.

This is a helpful clarification. The goal is to see it all as "just React" but there are discrete algorithms being used, depending on the API.

The information you provided here is helping me see the challenges in supporting the "gradual adoption strategy" mentioned in other posts. And I really appreciate the priority put on keeping React (to developers) simple — even if though it React (the codebase) more complex.

I’m sharing it here for extra clarity but I wouldn’t explain it like this everywhere because it gets a bit confusing.

I wonder if there is a way to share this in a publicly digestible way.

I'm reminded of "Virtual DOM". In the end it was so not important to understand. However, being able to identify and talk about it gave folks permission to trust the magic.

Is this an area where we should help make supplementary content? Or is the goal to have a document on reactjs.org that communicates the gradual adoption strategy in more technical terms?

While we’re at it, it also opts you into concurrent rendering specifically for retries. This is really nice because it lets urgent updates interrupt results of data fetches or lazy load completion.

Good to know!

The non-createRoot trees still get the legacy behavior (and warn) but it’s no longer a hassle to just get to createRoot. Since if you don’t use new features and don’t deeply combine UNSAFE code with Suspense, the behavior is almost the same anyway.

Love this!

Again, painting a really good picture for what gradual adoption means and how to think about this createRoot transition. Thank you

[shrutikapoor08]

I would love a read on this blog post I created on "What's new in React 18". Please let me know if my understanding is correct or if I am missing something. Much appreciated!

https://github.com/shrutikapoor08/blogs/blob/master/React-WhatsNewInReact18.MD

[shrutikapoor08]

gotcha! Thank you for reviewing Rick. I will make the edits

[gaearon]

Root API (new feature)

I would not call it a new feature. It's more like expected part of the upgrade. It enables Automatic Batching and also makes all new features available (otherwise they're always off even if you try to use them).

[gaearon]

Regarding this example:

  function handleClick() {
    console.log("=== click ===");
    setCount((c) => c + 1); // Does not re-render yet
    setFlag((f) => !f); // Does not re-render yet
    // React will only re-render once at the end (that's batching!)

    const callbackInHandler = () => {
      setCount((c) => c + 1);
      console.log("count inside handler", count); //output 0
    };

    callbackInHandler(); //output 0
    setTimeout(callbackInHandler, 1000); //output 0
     
    console.log("count outside handler ", count); //output 0
  }

I think it's a bit confusing. It focuses a lot on console.log(count) outputting 0. But that's neither something a user wants in particular (in fact people often complain about this) nor is unique to React 18 (it always worked this way with Hooks).

In this example, we don't actually have any updates where automatic batching "shows up". Because we don't have any sequence of setState calls one after another that don't happen during an event.

May I propose a different example?

function handleClick() {
  // These are two setStates:
  setCount((c) => c + 1);
  setFlag((f) => !f);
  // But React only re-renders once at the end.
  // That's batching. It's good for performance.

  setTimeout(() => {
    // Previously, batching didn't work inside timeouts
    // or asynchronous callbacks like fetch().
    // These two setStates cause two re-renders in React 17:
    setCount((c) => c + 1);
    setFlag((f) => !f);

    // But with React 18, they only cause one re-render.
    // That's automated batching!
  }, 1000)
}

[gaearon]

Everything else looks great to me. Thank you for sharing!

[shrutikapoor08]

Thank you @gaearon . This makes a lot more sense!