This is the third day of my participation in Gwen Challenge
Original text: reactjs.org/blog/2021/0…
The React team today announced the core content of the next big release, V18:
-
The addition of concurrent rendering made several other major updates possible
-
Automatic batching
-
The new API startTransition
-
New Streaming Server renderer
This major version update is similar to V17, there are no changes to the original interface, should be able to rest assured painless upgrade.
It is currently available via the @alpha tag:
npm install react@alpha react-dom@alpha
Copy the code
Expect to see a public beta in a few months. Interested students can try to join their working group and work with the gods to help the official release of V18.
Let’s take a look at some of the big features:
Batch Status Update
Batch status updates are nothing new. V18 existed long before that, but for some reason, like v17’s choice to only merge a series of state changes triggered by event handling callbacks that React took over. For example setCount and setFlag in this example:
function App() {
const [count, setCount] = useState(0);
const [flag, setFlag] = useState(false);
function handleClick() {
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!)
}
return (
<div>
<button onClick={handleClick}>Next</button>
<h1 style={{ color: flag ? "blue" : "black}} ">{count}</h1>
</div>
);
}
Copy the code
But if those setStates are wrapped up in another layer, triggering a merge in a Promise, setTimeout, etc., won’t work.
V18 solves this pain point by automatically merging status updates in any event callback you can think of.
But just in case we run into strange problems and want to avoid automatic merging, we can use the reactdom.flushsync () interface:
mport { flushSync } from 'react-dom'; // Note: react-dom, not react
function handleClick() {
flushSync(() = > {
setCounter(c= > c + 1);
});
// React has updated the DOM by now
flushSync(() = > {
setFlag(f= >! f); });// React has updated the DOM by now
}
Copy the code
For more details: github.com/reactwg/rea…
StartTransition interface
This new interface optimizes the application response delay caused by large-scale updates caused by state changes. It treats status updates labeled “transition” as low-priority tasks that can be interrupted, ensuring that other user interactions continue.
Flag the method also through a callback:
import { startTransition } from 'react';
// Urgent: Show what was typed
setInputValue(input);
// Mark any state updates inside as transitions
startTransition(() = > {
// Transition: Show the results
setSearchQuery(input);
});
Copy the code
In addition, a useTransition tick is provided to indicate state changes for “transitions”. For example, before the update is complete, you can display a friendly loading icon like this:
import { useTransition } from 'react';
export default MyComponent() {
const [isPending, startTransition] = useTransition();
return isPending
? <Spinner />
: <div>What you want to display</div>;
}
Copy the code
For more details: github.com/reactwg/rea…
Streaming server rendering
A major innovation in server rendering is coming! The nightmare of the server waiting for all the data to be in place to generate full HTML and then send it to the front end is finally getting somewhere.
First revealed in V16, the ‘Chocolate’ mechanic allows the server to render some of the rest to the client to speed up the rendering while restoring the client’s ability to interact, but it has a fatal flaw — it has to wait until all the relevant code is loaded on the client.
V18 uses the long-lurking components in Suspense, the React. Lazy interface and the new React-dom /server interface pipeToNodeWritable to implement local updates in the context of server rendering.
It’s also very easy to use, wrapping up components that are low priority or are expected to load slowly in Suspense, like react.lazy:
<Layout>
<Banner />
<Suspense fallback={<Spinner />} ><LowPriorityComponent />
</Suspense>
</Layout>
Copy the code
But this does not solve the problem of Hydration. So Dan emphasized that this is best done with code separation using react.lazy and the packaging tool to load code in chunks.
React.lazy and
are not supported in SSR prior to V18 and need to be removed in SSR for the UI to be displayed. After that V18 can rest assured bold use! Users can also interact with the page more quickly.
And then there’s a little optimization. If a user tries to interact with a part that is still on Hydrate, React tries to prioritise it to make it available faster.
For more details: github.com/reactwg/rea…