If you’re a React developer, there’s no
doubt you’ve heard about React 18. Now, while there is still a lot more to come,
I thought you might want to see what are its top new features. The first one is automatic batching. Long story short, batching in React is whenever
multiple state updates are combined into a single re-render. In this example, the component would only
be rendered once after handleClick is called, although we might think setCount and setClicked
would trigger two re-renders. Now, while this works well at the moment,
if you’re calling multiple state updates in a different context such as a promise,
a callback, or a timeout, React won’t batch these two updates into one and you’ll get
two re-renders when only one would have been needed. With React 18, all these use-cases will now
be covered and state updates will be batched automatically no matter what’s the context. This might remind you of unstable_batchedUpdates
that was doing exactly this, well now, React will do it for you by default. Also, if you happen not to want these updates
to be batched, you’ll need to use flushSync that will re-render your component every time
it’s done running the function you’re passing it to. So with the following, your component would
render twice instead of just one time. Moving on to transitions, a really big new
feature, which allows you “to tell React which updates are urgent, and which are not”. A good example of that is a search input that
should filter out a list of elements. So if you’re updating a search input, you’d
want its value to change as we type, although the search results might appear in a second
phase when we’re done typing. This is where we could mark the input value
change as an urgent update, and the elements filtering as secondary also called now a transition. Transitions can be interrupted by urgent updates
and previous transitions that are no longer relevant will be dismissed. This allows the user interface to only show
its most up-to-date state and skip secondary updates, transitions, that might be slower
to compute and sometimes return intermediate states that are irrelevant. As you can see here, we’re marking the input
value change as urgent, and run our secondary update inside a transition as it might trigger
slow computations and could freeze or slow down the whole user experience as we type. startTransition is great for any update “you
want to move to the background” such as slow and complex rendering tasks or when
updates rely on fetching data that might take time due to a slow network. If you have a React application, you might
know that if you’re not using Server-Side Rendering aka SSR, your website always appears
blank when you run it for the first time. That is because the browser needs to fetch
and read your JavaScript which takes some time before your components load and the page
becomes interactive. With SSR however, the user sees how your app
looks directly but without all the interactions while the JavaScript is being loaded. The way it works is by rendering all the
components on the server first, then sending the result as HTML to the browser. After that, the JavaScript is loaded as usual
and the HTML magically becomes interactive by what is called hydration. This turns your static HTML elements into
your dynamic React components as you know them. The main problem with this approach is that
as long as the JavaScript hasn’t been fetched, loaded, and your HTML hydrated, your page
won’t be interactive. To solve this waterfall issue, React 18 now
offers two new features for SSR: Streaming HTML and Selective Hydration. Put simply, streaming HTML means that the
server can send pieces of your components as they get rendered. This works by using Suspense, where you’d
say which parts of your application will take longer to load and which ones
should be rendered directly. If you think of an article with comments where
the article is the critical part of the page, you could say load the article but don’t
wait for the comments to be ready to send HTML to the browser. You could show a spinner instead using
Suspense and once the comments are ready, React will send new bits of HTML that will
replace the spinner in place. Now, the second new feature, selective hydration,
is quite a game-changer. Where before you’d have to wait for every
component to be rendered to begin hydration, leading to code splitting problems, components
now wrapped with Suspense won’t block hydration anymore. In other words, if we go back to our article
page, the comments that we wrapped with Suspense won’t block the article and other
components to be hydrated. Every ready component will start hydrating
and the comments will too, once the browser gets both its content and JavaScript code. The last crazy thing about selective hydration
is that if you happen to interact with one of the components before it’s been fully
hydrated, meaning you click somewhere, for example, React will prioritise this
component’s hydration. This ensures that the most critical interactions
are to be repeated as soon as we can hydrate the related component, making sure it’s
hydrated before the others. All right, that’s all for today. You can find great explanations of all these
new features on the official repository which is linked in the description. Remember to subscribe if you don’t want
to miss more videos like this one. Thanks for watching and see you next time :)
Very nicely done.
Thanks! This is really helpful.
Is SSR automatic or something that needs configured on React 18?
Nicely presented
Well done! Nicely explained and got me up to date :)
Very nice! No fluff, straight to the point, useful examples, and clear explanations. Thank you very much!
This is so helpful, please continue making content!!
Very nice explanation!
Great, thank you