React is one of the web’s most popular frameworks for building JavaScript applications. 

If you know what you’re doing, React can drastically simplify how you build, use, and maintain code.

Whether you’re a React newbie or you’re ready for advanced techniques, you can level-up with egghead. Explore our in-depth courses, lessons, and community resources to build more powerful applications and crack open your career.

react

Kamil Khadeyev

In this lesson Michael Chan explains the design of React 18's gradual adoption strategy, what it means for your apps, and further in the course you'll see how to start testing with prerelease React 18 today.

Gradual Adoption Strategy of React 18

In this lesson we'll explore React versioning, release channels, and npm tags. 

Then install the latest react and react-dom 18 prerelease versions using the @next  version tag.

Update React Dependencies with the @next Version Tag


For the better portion of a decade, React has shipped with the `render` root API. This changes with React 18 — mostly. React 18 is a transitional release, supporting `render` (legacy root API) and `createRoot` (new root API). React 18's legacy root API operates exactly the same as v17.

Replace Legacy Root API with New Root API

Utilize both React root APIs to migrate your app. We can render a portion of our app using the legacy root API (v17 compatible) and a second using the new root API (v18 exclusive). This option makes it possible to migrate portions of your app at a time.

Use React 18's New Root API Alongside the Legacy Root API

React's legacy root API (`render`) took a callback function. React called this function once the post-render. With new streaming capabilities scheduled for React 18, this feature becomes unpredictable. Replace it with a ref callback — or one of these other strategies.

Replace Legacy Root API's Callback Argument

React 18 supports the legacy root API (`render`) and a new root API (`createRoot`). Utilize this to conditionally render based on environment, user preference, or audience sample.

Conditionally Render with Legacy Root API or New Root API

In previous versions of React, state update batching only happened inside of event handlers. In React 18, all updates are batched, regardless of when or where they are called. Opt into automatic batching with `createRoot`.

Opt-in to Automatic Batching with createRoot

React 17 exposes an undocumented API named `unstable_batchedUpdates`. It batches multiple useState update calls — inside of asynchronous callbacks — and reduces extraneous renders.

In React 18, all `useState` updates are batched, making `unstable_batchedUpdates` inert. Remove all uses of `unstable_batchedUpdates`.

Remove unstable_batchedUpdates Calls

In React 18, useState update calls are batched for improved performance. A new API — `ReactDOM.flushSync` — lets us selectively escape batching. This option is useful when reading the DOM after state changes. Use `ReactDOM.flushSync` to exempt specific state updates from batching.

Opt-out of Automatic Batching with ReactDOM.flushSync

React 17 had an edge-case that meant that `this.state` could show partial state changes. This was never intended and has been patched in React 18. In cases where you need that same behavior, `ReactDOM.flushSync` to achieve the same result. While it's an available option, it is not recommended.

Handle Class Component setState edge-case with ReactDOM.flushSync

Michael Chan shows you where to stay up to date on React 18 changes and showcases in-process React Working Group discussions on GitHub!

Stay up-to-date on React 18 progress with the React Working Group

Migrate a Client-Side Application to React 18 Beta

https://app.egghead.io/api/v1/lessons/react-gradual-adoption-strategy-of-react-18/subtitles

Instructor: [0:00] Hey, friends. Welcome to this course on migrating client-side apps to React 18 Beta. React 18 is an extremely exciting release. It's something that we've been waiting for for a long time.

[0:13] If you think about it, it boils down to, we want to introduce a bunch of groundbreaking features but also don't touch anything. We want everything to work the way that it did before. React calls this their gradual adoption strategy. What does that mean?

[0:29] In the short term, it means that, despite React 18 shipping with a host of new features, using the same APIs in the same ways as you do with React 17 will yield the exact same results as you had in React 17.

[0:43] However, there's a bunch of performance improvements that can be gained by changing our root API and updating the way that we interact with state updates. That's what this course focuses on, is going through all of the changes that are a result of changing that root API and places in your app that you might need to update to get the most performance benefit from these changes.

[1:07] Once you've made those changes, your app is in a stable place to take advantage of all of the new and upcoming features in React 18. Without further ado, let's dive in.

https://app.egghead.io/api/v1/lessons/react-gradual-adoption-strategy-of-react-18/transcript

https://app.egghead.io/api/v1/lessons/react-update-react-dependencies-with-the-next-version-tag/subtitles

Instructor: [0:00] To update our React dependencies, we first need to know a little bit about how versions work for the React package. Here, I have the npm page up for the React package, and we're going to go right to versions. Here, we'll see all of the current tags that we can choose from when installing React and, consequently, ReactDOM.

[0:21] In this table, we see the available tag and then the version that it relates to. We have Latest, Next, Alpha and Experimental. Latest is the one that you're probably most familiar with. This is what you'll get by default by typing npm install React or yarn add React. Next and Alpha are what we'll focus on today.

[0:43] Right now, those are both mapping to the Alpha version of React 18. I'm going to choose Next because I want it to be the next version that's going to, theoretically, be released. However, both of these will have the API that we expect to have in React 18. How do we utilize these?

[1:02] Over here, I have a Create React App set up. I'm going to stop the server and install our new dependencies. We use yarn add react@next and react-dom@next. Hit Enter and watch it do its magic. You'll see that, in the package.json file, these versions are now up to date with those that we saw on nextjs.com.

[1:29] All that's left is to restart our server and see what happens. Hit yarn start Enter and go back to our App tab. Let's hit Refresh, and we get a new error. This is perfect. This is exactly what we wanted to see to confirm that we're using React 18.

[1:46] It says "Warning -- ReactDOM.render is no longer supported in React 18. Use createRoot instead. Until you switch to the new API, your app will behave as if it's running React 17" with a link to learn more.

[2:01] The link conveniently takes us to a React Working Group article on how to migrate the legacyRoot API, which we're familiar with, to the new createRoot API. Conveniently, that's what this course is about too.

https://app.egghead.io/api/v1/lessons/react-update-react-dependencies-with-the-next-version-tag/transcript

https://app.egghead.io/api/v1/lessons/react-replace-legacy-root-api-with-new-root-api/subtitles

Instructor: [0:01] ReactDOM 18 ships with two root APIs -- the one that we're familiar with, ReactDOM.render, and also a new one, ReactDOM.createRoot. As of React 18, these are referred to the legacy root API and the new root API.

[0:19] When we use the legacy root API, we get a warning saying that everything that we render will be rendered as if it is in React 17. Nothing has changed. If we want to utilize the performance improvements of React 18, as well as the new concurrent features, we need to use createRoot, the new root API. How do we do that?

[0:41] Things change just a little bit. We're still going to keep this render() method, but we're only going to render the component tree. This gets put into createRoot. Format, Save, and Refresh in our browser. Now that we're using the new root API in React and ReactDOM 18, that warning goes away. With this one change, we've been able to update our app to opt into all of the new performance enhancements in React and ReactDOM 18.

https://app.egghead.io/api/v1/lessons/react-replace-legacy-root-api-with-new-root-api/transcript

https://app.egghead.io/api/v1/lessons/react-use-react-18-s-new-root-api-alongside-the-legacy-root-api/subtitles

Instructor: [0:00] One of the nice outcomes of ReactDOM shipping with two root APIs is that we can render to different parts of our page using the different root APIs. If part of our app isn't quite stable yet, with the new root API, we can migrate those selectively. Let's render to both of these roots.

[0:19] For Root 1, we'll use the new React root API, ReactDOM.createRoot from root1.render(<App />). Hit refresh in our browser. This takes a root API, so we can pass that along to keep track of these differences. To Root 2, we'll use the legacy ReactDOM.render() API, providing the component as the first argument.

[0:50] Let's save, re-render our page, update this to Root 17, not that it is 17 but that it behaves like 17. There we go.

[1:03] Because we added this one second, we can confirm through this warning message that, indeed, it is using the ReactDOM 17 legacy root API, rendering everything in that root as if it were version 17.

https://app.egghead.io/api/v1/lessons/react-use-react-18-s-new-root-api-alongside-the-legacy-root-api/transcript

https://app.egghead.io/api/v1/lessons/react-replace-legacy-root-api-s-callback-argument/subtitles

Instructor: [0:01] ReactDOM's legacy root API allowed us to pass in a callback function that would get called as soon as React rendered. It would get passed in something like console.log("React rendered")

[0:12] If we try that with the new createRoot API, we get an error, "Warning -- Render does not support the second callback argument. To execute a site effect after rendering, declare it in a component body with useEffect()."

[0:26] There's several recommendations for how to solve this, but let's follow this warning first. Let's take out the second argument and move it into our apps component body with a useEffect(). Paste it in, and our error goes away. We also see this rendered out to the console.

[0:47] With a legacy root API, this only rendered the first time. To get parity with that, we would need to add an empty array to this useEffect(). Doesn't change the result except for the fact that it will only render on that first render.

[1:01] Of course, there's another option if you don't want to modify this component. Let's copy this, comment that out. We can use setTimeout() or requestIdleCallback() right after calling ReactDOM.createRoot(). window.setTimeout() -- handy little autocomplete there -- you change this to zero and paste in our function. Clear this that we don't need.

[1:27] What this does is a little bit different. Get the same result in this simplified app, but this version isn't precisely coordinated with React rendering. It will simply render as soon as React yields two low-priority updates.

[1:42] There's a third option that might come in handy to you if you need a ref to the DOM node that React rendered to. Here, we can provide a callback as a prop, take the ref as an argument, and log it out, ref.tagName.

[2:00] On the component side, we take that callback as a prop and use ref on this React element. Save, refresh, and we have access to that DOM element that React rendered.

https://app.egghead.io/api/v1/lessons/react-replace-legacy-root-api-s-callback-argument/transcript

https://app.egghead.io/api/v1/lessons/react-conditionally-render-with-legacy-root-api-or-new-root-api/subtitles

Instructor: [0:00] When migrating to React 18, you may want to conditionally use the legacy API or the new Root API, depending on an environment variable or a feature flag. Let's do this in a very simplified way.

[0:14] Let's create a new constant for React 18 and set it to true. If we're in a React 18 environment, we want to use the new createRoot API. Else, we'll use the legacy root API. Let's copy this, paste it up here, and do our transformation. Take out that argument, insert createRoot, and we're good to go.

[0:40] Now, based on environment or feature flag, we can conditionally render using the legacy root API or the new Root API. To test it out, change it to false and see our warning again.

https://app.egghead.io/api/v1/lessons/react-conditionally-render-with-legacy-root-api-or-new-root-api/transcript

https://app.egghead.io/api/v1/lessons/react-opt-in-to-automatic-batching-with-createroot/subtitles

Instructor: [0:00] Automatic batching of state updates is React 18's most important performance feature. To understand how it works, we need to go back to a world of React 17 using the legacy root API.

[0:14] Our app here is relatively simple. We have a count() and isOdd(). count() starts at one, and isOdd() starts with a value of true. With those, we have two state-updating functions. The app consists of a single button that calls a handleClick, onClick and renders these two pieces of state.

[0:35] The handleClick() function is where things get interesting, where we update both of these pieces of the state simultaneously. React 17 is smart enough to know that we should batch these. Every time I hit this, we only increment this console.count() one additional time, even though we're calling two state updaters.

[0:56] React 17 was only able to do this inside of the event handler callback. If the function got called later, let's say, as a result of a Fetch request, they would each increment this counter.

[1:09] Let's simulate that with setTimeout(). We can use zero seconds because the timing itself doesn't matter. Move these inside and save. Now, for each click, we see two updates. I've clicked twice. We saw a second and third for the first one and a third and fourth for the second one.

[1:30] This has been solved in React 18. If we change to the new React root API using createRoot, we see the same behavior as when the update() functions were called directly inside of the event handler. One rerender per click, this makes things consistent. No matter where these update callbacks are called, we see the same behavior.

https://app.egghead.io/api/v1/lessons/react-opt-in-to-automatic-batching-with-createroot/transcript

https://app.egghead.io/api/v1/lessons/react-remove-unstable_batchedupdates-calls/subtitles

Instructor: [0:00] React 17 didn't automatically batch updates inside of functions that got called outside of an event handler. This includes setTimeout or any promise-based callback like fetch. In an effort to reduce renders for multiple state updates, we need to wrap our updates in ReactDOM unstable batched updates.

[0:23] This was an undocumented API and largely used by library maintainers. It was a manual way to get the automatic batching that's available in React 18. In React 18, all state updates are batched, no matter where they're called.

[0:40] Let's try this again using the unstable batched updates with the React 18 Root API and see that, effectively, it's a no-op. It's best practice when updating to React 18 to remove these.

https://app.egghead.io/api/v1/lessons/react-remove-unstable_batchedupdates-calls/transcript

https://app.egghead.io/api/v1/lessons/react-opt-out-of-automatic-batching-with-reactdom-flushsync/subtitles

Instructor: [0:00] ReactDOM 18 provides a way to opt out of automatic batching of state updates. Because of automatic batching, these two state updates always happen in the same rerender. We can split them using ReactDOM flushSync, simply wrap the update in ReactDOM.flushSync.

[0:26] With this, we're separating these updates by forcing this one to flush to the DOM first. Now, every time we click our button, we see two individual updates. We can repeat this process for as many state updates as we like.

https://app.egghead.io/api/v1/lessons/react-opt-out-of-automatic-batching-with-reactdom-flushsync/transcript

https://app.egghead.io/api/v1/lessons/react-handle-class-component-setstate-edge-case-with-reactdom-flushsync/subtitles

Instructor: [0:00] React 17 had a pretty strange edge case when using class components. In this class component, we have two pieces of state, a count() and isOdd(), and we want them to update together, even though we're updating state twice.

[0:13] These are batched whether or not they're in the handleClick() directly, or a callback is called later on as a result of setTimeout() or a promise. Running this in a React 17 environment, we see something strange happen, where these console log statements can log partial states after these updates. Let's check it out.

[0:36] We see count() incremented, but isOdd() is false for the first console.log. Then, for the second, we see that state updated as well. This behavior changes as soon as we enable React 18 through the new createRoot API. Let's try this again. Here, we see that both log the original state before the update.

[0:58] While it's not recommended, we can enable the behavior that we had before with ReactDOM flushSync. We wrap this update in a function, and we can leave our console.log exactly where it was right here. Let's try that again. Here, we see the first partial updates, so that part is working.

[1:17] In order to get the same exact behavior, we need to wrap both of these in this flushSync. Any console log is going to need this flushSync wrapped around it. Let's Save that again, Refresh, and now, we see the behavior as it was before. This is not recommended, but it is an escape hatch should you need it.

https://app.egghead.io/api/v1/lessons/react-handle-class-component-setstate-edge-case-with-reactdom-flushsync/transcript

https://app.egghead.io/api/v1/lessons/react-stay-up-to-date-on-react-18-progress-with-the-react-working-group/subtitles

Instructor: [0:00] You've made it. You successfully updated a React app to React 18 pre-release and are ready to explore concurrent features as those new Suspense APIs stabilize. Where can you find information about those APIs as they start to come online? I'm glad you asked.

[0:18] Something new to React in 2021 is the React Working Group. Here, you'll find discussions between the React core team, library maintainers, and educators on features that are coming down the pipe. Not all of them are ready yet. They're being discussed, and they're being built and finalized as we speak.

[0:36] If you want, you can stay in the know by tracking these. It all happens in discussions. You don't have to be a source expert or track GitHub issues to stay in the know. I'm a member of the React Working Group. If you have questions or concerns, I would love to give your thoughts a voice there.

[0:56] Until then, I thank you for taking this course, and I can't wait to see what you build with React 18.

https://app.egghead.io/api/v1/lessons/react-stay-up-to-date-on-react-18-progress-with-the-react-working-group/transcript

Migrate a Client-Side Application to React 18 Beta

Michael Chan

Credits

Course Content