Alex Eagleson

Posted on Dec 9, 2021

Learnings from React Conf 2021

#javascript #react #webdev #programming

I recently had the opportunity to join the digital React Conf 2021 and listen to some talks from a really great list of speakers.

This post aims to summarize (in many ways for myself) the big take-aways that I learned from the conference. For example there were some great talks on design/UI that I found interesting, but since I am more involved with the coding side, those will be the areas that I focus on primarily.

So without further preamble, here's an unordered list of some of the new topics I found most compelling:

Conference Video Link
React 18 Release Candidate
Updating to React 18
Suspense and Server Components
React Docs
Unusual React Environments
Cross Platform with React Native
Developer Tooling
The Future of Memoization
Shopify's Hydrogen
All the Rest
Bonus Tips
Wrapping Up

Conference Video Link

The entire 5 hour conference is currently available on Youtube for anyone to watch for free.

(Note they have stated they will be releasing individual videos of each talk, so it is possible this video link will go down in the near future. I will aim to update links to the individual talks if that occurs)

React 18 Release Candidate

The official release candidate for React 18 was released to coincide with the start of the conference. This version is considered to be the "expected version for the official release in early 2022" barring any major issues found in the next couple of months.

So although you may not want to upgrade your critical production applications just yet, as of today React v18 is as close as its ever been to finalized. You're definitely encouraged to use it from the get-go with any new projects you create.

Of course the big topic of discussion in the conference were focused around the new features of React 18 itself.

Updating to React 18

Run the following command in your existing React project:

npm install react@beta react-dom@beta

Note that as of today you can also install the RC version rather than beta as 18 is now a release candidate. Check the versions on NPM to see what is available.

Then all you need to do is change the app mount point (presumably in your index file) from:

const container = document.getElementById('root');
ReactDOM.render(<App />, container);

To:

const container = document.getElementById('root');
const root = ReactDOM.createRoot(container);
root.render(<App />);

And you're ready to begin working with React 18!

Suspense and Server Components

Suspense is already available in React 17, you may have worked with code before that looks like this:

const MyComponent = React.lazy(() => import('./MyComponent'));

const App = () => {
  return (
    <Suspense fallback={<Loading />}>
      <MyComponent />
    </Suspense>
  );
}

However this use of code splitting with Suspense is happening on the client side, where development is driven now is implementing Suspense on the server side.

Currently SSR (server side rendering) is an "all or nothing approach". If we have a page with a header, nav, content and comments that we are generating with SSR -- then the time it takes to serve that page will be equal to the slowest of its individual components. If every other component takes 0.1s and comments takes 1s then you still need to wait for comments before the app can be sent to the client.

This is no longer true with React server components. It's now possible that despite being rendered on the server, you can wrap your <Comments /> in a <Suspense /> with a fallback loading spinner (or whatever you want) and the app will be sent with the fallback in place until it is ready.

Once it is ready, the bundle containing the rendered comments will be sent to the client to replace the fallback component.

As a bonus, the React is smart enough to watch for user interaction. If one suspended component has been clicked while it's still loading, React will immediately stop what it is doing elsewhere and prioritize the loading of that component!

The key takeaway for server components is that they are always rendered on the server, and never sent to be rendered on the client. There are two critical take-aways from this:

Server components will have no impact on your bundle size, since they always render on the server
Server components can have direct access to your database

If you would like to learn more about server components, here's a great talk from Dan covering all the details:

And if you would like to see Suspense in action, Dan Abramov of the React team has created a codesandbox example.

Hit the refresh button to see the effect. You'll want to open the full link in another tab to see the example of the code and how it's composed.

React Docs

The React documentation has finally been modernized with hooks-first content.

They've already been released in beta and are planning to be released officially to replace the current documentation when React 18 ships.

Discussion of the new React docs starts around 2:15

Unusual React Environments

I really enjoyed Sarah Rainsberger's talk which focused on "unusual" development environments for React.

My wife has been working with React this year for the first time and really connected with this talk, particularly the idea that someone would be able to learn React and its concept without necessarily having to go through a prerequisite stage of learning command line tools, NPM, etc.

Thanks to online coding environments like codesandbox, glitch and repl.it for example, you can begin writing real programs in React in a few seconds without installing any dependencies, and that's really powerful.

One of my favourite trends in conferences I've seen is the push to include speakers who are relatively new to the technology, talking about their experiences and aimed at new developers in similar positions. It helps a lot to break down the walls that people often hit when they are overwhelmed with the amount of new tools and concepts they need to learn when getting started.

The talk begins around 2:34

Cross Platform with React Native

The React team seems to be really pushing for parity of developer experience between all kinds of platforms.

There was a lot of talk about what React Native is being used for these days and how optimizations being applied for one platform (Android for example) end up being applied to other platforms (iOS) in ways that they were not expecting.

They discuss how React Native is being used to develop native experiences on not only mobile platforms, but OS's like Windows (parts of the Microsoft Office suite) and Xbox (the dashbaord for the new Xbox Series X) as well.

Here's an image that really demonstrates what they are trying to achieve:

If you want to watch it yourself, this talk starts around 3:34.

Developer Tooling

There was a lot of focus on new and coming updates to developer tooling for React with a talk from Brian Vaughn.

He summarized the big focuses the tooling will be seeing in the coming months:

Integrating the profiler and timeline to work together
React Native support
CPU and memory profiling

This talk starts around 1:41

The Future of Memoization

One of the most interesting talks (that at times, went completely over my head) was from Xuan Huang about the future of memoization in React.

In the context of React, memoization is used primarily to indicate to React which components may or may not need to re-render depending on some kind of state. Typically for a component, you can explicitly state that if the props do not change you do not need to re-render the component.

More info on React.memo.

With the useMemo hook we can create a memoized value that will not be recalculated if values in the dependency array do not change. Setting up this kind of scenario is notoriously cumbersome sometimes, requiring the use of a lot of extra code and potentially the useEffect hook to achieve your goal. It also has the unfortunate side effect of making the flow of your code less linear (less likely to follow logically from top to bottom).

Xuan's talk demonstrated this concept by showing an example in real time, then did a 180 and started writing a "theoretical example" of how it "could" look. To be hones the new example looked a lot more complicated than the original...

But he brought it all together by explaining that all the code he was writing -- if everything goes well (this idea is still in development) -- could be handled for you automatically. A tool that detects areas where memoization would help optimize your components and be applied automatically. Crazy stuff.

Check it out yourself: the talk begins at 1:54.

Shopify's Hydrogen

Shopify is part of the React Server Component working group and has bet heavily on the power of server components for their new React framework called Hydrogen.

Hydrogen is a brand new React-based framework designed to unify the combination of server components, smart caching, and Shopify's API.

Shiopify maintains their own documentation on Hydrogen's support for React server components which they claim to maintain their own stable abstraction layer over server components so you can use them with confidence, despite their current state.

All the Rest

There were still more talks! Some I missed simply due to time constraints, or lunch or kids or whatnot; others were outside the scope of the work I normally do (though I'm always interested in learning anyway even if it's not directly applicable.)

Either way I'd encourage you to check out some of the other talks:

Bonus Tips

Here's a couple simple and practical things I picked up that are easy to pick up and use today.

Like most of the talks, these are new features of React 18. Fortunately the upgrade path to React 18 is aimed to be very simple and completely backward compatible.

See the update section at the start of this post for a simple example of how to make the update in a couple of lines.

Batching

Previous state updates would always be batched into a single render, even if they were called multiple times in a row. There was a limitation for this however, if the function calling these state updates was asynchronous, the updates would not be batched.

This is no longer true as of React 18. The below code example in v17 would trigger two separate state updates, in v18 they will be batched together:

fetchFromApi().then(()=> {
    setLoading(false);
    setError(false);
})

Deferred State

One of my favourite new hooks I learned about that I thought was great was the useDeferredValue hook.

The first time they showed it in Shruti Kapoor's talk I thought it was fantastic. Not surprisingly it kept coming up at least another 2-3 times in other talks as it seems to be extremely useful in a lot of scenarios.

Basically what it does is allow you to specify a piece of state that you know will take longer to process than the other state of the component, and allow the component to render itself without waiting for the "big one". When the big one is ready, it will render that one in.

To give an example, large lists usually meet this criteria. If you have a filter button that changes the state of a large list of items being rendered.

The below example comes from the React documentation on the feature:

function App() {
  const [text, setText] = useState("hello");
  const deferredText = useDeferredValue(text, { timeoutMs: 2000 }); 

  return (
    <div className="App">
      {/* Keep passing the current text to the input */}
      <input value={text} onChange={handleChange} />
      ...
      {/* But the list is allowed to "lag behind" when necessary */}
      <MySlowList text={deferredText} />
    </div>
  );
 }