React Conf 2024. React v19 RC
The first day of React.js Conf just concluded. This much-anticipated conference took place almost 3 years after the previous one. The React updates were just as eagerly awaited. The conference began with these updates and this article will be dedicated to them. And yes, as you saw from the preview — version 19 has moved into the release candidate status. The full release is promised within two weeks.
Overall, as a next.js developer, most of it was familiar to me. Dozens of articles on the hub have already talked about almost every part of this update, and I partially touched on the updates introduced in next.js.
It can be said that the main directions of this update were achieving “High UX at high DX”. Maximum performance with maximally simple code. At the same time, there was almost no mention of server components in part of the updates, only indirectly. And so, let’s move on to the conference itself.
As usual in such conferences, everything starts with a description of growth. React downloads reached One Billion per year. The growth of the tool is inevitably linked to the growth of the community. Therefore, Stackoverflow statistics were also shown — 40% of developers use react in web development, 36% are learning it.
Also of interest, React functionality has become possible to a greater extent only within frameworks, so now React.js has started recommending specific ones. The slide showed remix, redwoodjs, next.js, and expo. Interestingly, there is no react router in this list.
Yes! React Router can now be added to this list. The first conference report was about him from Ryan Florence. Now with react router, you can not only do SPA but also SSR and SSG. This is now possible in conjunction with Vite. Hooks are available for working with data and server components.
But for now, let’s return to the changes in React.js. The problem of coordinating elements and expanding the application was described next. JSX solved the problem of coordinating elements in UI development. Then they added Suspense, which solved the problem of coordinating elements when loading elements (what to do during loading and what to show to the user at this time).
In React 19, the following were also added:
- Server components. Among other things, such components can solve the problem of loading data and their further transfer to components (using familiar props);
- Embedding metadata. Metatags can be embedded anywhere. React itself will add them to the right place and leave only one copy.
- Preloading methods. In addition to manually adding tags, methods for preloading links were also added — preinit, preload, prefetchDNS and preconnect. The documentation also describes the preloadModule and preinitModule methods, but for some reason, they were not shown at the conference.
- Embedding styles. Similar to meta tags, work will be done for styles. However, here an option of prioritization is added — depending on it, it will be determined which styles are more important (and accordingly will be lower in the DOM).
The style loading of the component is now tracked by suspense. That is, you can display the loader not only while the component is rendering, but also while its specific styles are being prepared.
With the advent of server components, React took on more responsibility in terms of server rendering, as a result, hydration takes on even more logic and potential problems. The React.js team improved hydration errors.
In addition to significant changes in working with the construction of a real tree, the logic of interaction with forms has been updated in React.js. First of all, the form component was included in react-dom, which means significant changes over the element. And first of all, this change concerns the change of the “action” attribute — as an alternative to submitting a form through onSubmit or a native attribute.
Adding action itself looks just like onSubmit, but instead of an event, it immediately takes FormData.
Also, for form fields and buttons, the formAction prop has been added, which works in an identical manner.
Perhaps the basic advantage of using action instead of onSubmit is that with client actions, if the user calls form submission immediately (even before loading the form logic) — its submission will be postponed and will be performed as soon as the logic is ready. In server actions, the submission will occur immediately because it does not require client js.
But, in addition to the basic difference, there are significant changes in interaction with form submission — these are new hooks. useOptimistic, useFormStatus and useActionState.
Sam Selikoff shared examples of working with them in his presentation “React unpacked: A Roadmap to React 19”. For example, this is what replacing onSubmit with action + useActionState looks like:
Then you can add optimistic render:
And again, let’s return from the report to the key changes. A relatively small change was shown next, but very, very valuable. In React.js 19, you can pass ref to a functional component as props. Right away. Without forwardRef.
Also, when passing ref to components, you can return a callback on unmount.
The final key change was the React Compiler. An advanced loader with memoization out of the box. Together with him, React will automatically set up memoization in the application. Lauren Tan elaborated on this in her presentation “React Compiler Case Studies”.
So, to understand how to set up memoization, React analyzes the relationships from the place that triggers the rerender to the endpoints:
Based on these relationships, the compiler can imagine a full graph of dependencies:
And then, depending on these connections, set up memoization with the necessary dependencies. In this case, since songs do not change — filteredSongs should remain the same (they will be memoized with a dependency on songs), and if the song is changed by setSong, NowPlaying should be rerendered (it will be memoized with a dependency on song).
“Maximum performance with maximally simple code”.
A great solution, however, it will be interesting to see how memoizations will be set up in practice — where developers should write them, and where it is worth not complicating and leaving this logic to the compiler.
You can install the compiler right now on all major frameworks and build systems that support babel. It is already being used in Instagram, Facebook, and Bluesky (the company where Dan Abramov now works).
Also, to increase reliability and quality of compilation, you can install an eslint plugin, which will indicate all problems with code optimization. In general, the plugin can be used independently of the compiler.
npm install eslint-plugin-react-compilerYou can also use a command-line utility that will check the application for possible optimization by the compiler
npx react-compiler-healthcheckAnother innovation was shared by Lydia Hallie — the use function. Yes, it’s not a mistake — it’s not a hook.
The key difference between use and hooks is that use can be used within conditions
Use itself can take either a promise or a context. It’s hard to imagine a situation where you can’t be sure what argument will be passed to use — a promise or context and why not just make two independent functions.
In conclusion, I will note the amazing reports, presentations, examples, and performances in general. The React.js team was really able to show the possibilities of all improvements (next.js team forgive me but they didn’t even come close). Also, from a pleasant difference, I note that the React.js team refused to include in the core the rewrite of the fetch API and rolled back already finished changes.
The general list of changes looks like this:
UPD: Seems like I can leave some advertising here.
If you’re using next.js — you might want to check out the solutions from nimpl.tech, you might find some of them useful (like for example the getter getPathname for server components or the package for configuration config set up for all next.js environments)
UPD2: There are still entries here, so I’ll leave another update.
I just submitted a PR for the addition of getPageContext functionality in next.js (for non-next.js readers — the huge pain of working with contexts in server components [because there simply isn’t one and there are no alternatives]). Leave a reaction if you’re familiar with this pain.
