This article considers the new features that have just been included to React 18, its applications, and other essential things worth knowing.
React 18 will provide out-of-the-box improvements functions in the form of automated batching, new APIs (such as
), and a new streaming server renderer with built-in support for
by the time it will be launched and ready to use.
These capabilities are made available via a new opt-in method which will be included in React 18. And this opt-in will be known as "Concurrent Rendering" because it allows React to create many UI versions simultaneously. This update is generally invisible, but it opens up new opportunities for improving users' app's real and perceived performance.
When several state updates are bundled into a single re-render in React, this is referred to as batching.
If you don't want these updates to be batch-processed, you may use
, which will re-render your component every time the function you've sent it to be completed.
A significant new feature that enables you to "inform React which updates are urgent and which are not." A search input that should filter out a list of elements is an excellent illustration of this. So, if you're updating a search input, you'd want the value to update as we type, even if the search results may display in a second phase after we've finished entering.
This is where we may designate the input value change as an urgent update and the items filtering as secondary, which is now referred to as a transition.
Urgent updates may cause transitions to be disrupted, and earlier transitions that are no longer relevant will be disregarded.
This lets the user interface merely present its most recent state and omit secondary updates, transitions, and sometimes irrelevant intermediate states that are slower to compute.
As you can see, we've marked the input value change as urgent. We've executed our secondary update inside a transition to avoid causing slow computations, which could cause the entire system to stop or slow down the whole experience from the user the more we type.
is helpful for any update that you wish to transfer to the background, such as rendering sluggish and sophisticated operations or updates that rely on downloading data that may take a long time owing to a slow network.
SSR (Server Side Rendering) renders all of the server components first and then sends the HTML to the browser.
This transforms your static HTML elements into the React components you're familiar with.
React 18 adds two new features for SSR: HTML Streaming & Selective Hydration to overcome the waterfall issue.
Streaming HTML: this refers to the ability for the server to send portions of your components as they are rendered.
This is accomplished through the use of Suspense, which allows you to specify which sections of your application will take longer to load and which should be presented immediately.
Selective Hydration: Selective hydration is a fantastic idea.
Previously, you'd have to wait for each component to be rendered before hydration could begin, but now Suspense-wrapped components won't obstruct hydration.
The most essential characteristic of selective hydration is that if you interact with one of the components before it has been fully hydrated, for example, by clicking anywhere, React will prioritize the hydration of this component. This ensures that the most crucial interactions are repeated as soon as the associated component can be hydrated, ensuring that it is hydrated before the others.
There are no substantial breaking changes to component behavior in React 18 because concurrency is opt-in. With a degree of work comparable to a typical major React release, you may upgrade to React 18 with minimal to no modifications to your application code.
For this release, we're attempting something different: we've invited a panel of experts, developers, library authors, and educators from throughout the React community to join our React 18 Working Group to provide comments, ask questions, and work on the project. We weren't able to invite everyone we wanted to this first tiny group, but if this experiment proves successful, we'll expand it.
The React 18 Working Group's mission is to prepare the ecosystem for the seamless and progressive adoption of React 18 by existing apps and frameworks. The Working Group's discussions are held on GitHub Discussions and are open to the public. Working group members can provide input, ask questions, and discuss ideas.
The core team will also share our research findings in the talks repo. Any critical information will be communicated on this blog as the stable release date approaches.
The conversations in the React 18 Working Group repo are open to the public.
Only invited members will create or comment on threads, as we anticipate a spike in interest in the Working Group. On the other hand, the threads are fully available to the public, allowing everyone to see the same information. We believe this is a decent compromise between fostering a productive working environment for working group members and retaining transparency with the general public.
You can always use our issue tracker to submit bug reports, questions, and general comments.
The @alpha tag is used to publish new alphas to npm on a regular basis. The most recent commit to our main repo is used to create these releases. When a feature or bugfix is merged, an alpha version will be released the following weekday.
Between alpha releases, there could be significant behavioral or API changes. Please remember that alpha releases should not be used for user-facing or production applications.