What’s New In React 16.6 — By Example

Meet Memo, Lazy, and ContextType

React 16.6 officially landed yesterday, and the release comes with some new tools.

Since it’s only a minor version, React teams should feel comfortable upgrading because there aren’t any breaking changes — only new features and bug fixes.

The new API additions — Memo , Lazy , and contextType — are all briefly explained in React’s official blog post, but we’re going to break down each new feature by explaining how it’s useful and providing a practical example.

Context Type

This is, in my opinion, the most exciting addition in 16.6.

The context API had its stable release in 16.3, but one feature it sacrificed was removing this.context as a way to interact with context. This feature has been missed among developers who are uncertain about placing all their bets on render props.

With 16.6, you can now declare a contextType in a component and then access this.context to get the context from your provider without having to pass down render props.

It’s important to note that the context value is from the closest matching Provider above your current component in the tree.

This means you’ll still have to wrap your entire app (or at least the current component) in your Provider, but then that provider is easily accessed with this.context

For example, if you have a simple counter that’s using state in a context provider, you’d previously have to do something like this:

Now, you can add static contextType to your component and access this.context directly:

If you want to see an example in action, I created a CodeSandbox to demonstrate how to use contextType.

Memo

Although the name of this new API has been met with mixed feedback, the Memo API is essentially a wrapper / higher-order component that provides the benefits of a Pure Component for function components.

There’s been plenty written about the benefits of Pure Components. But the short version is that Pure Components can provide a performance boost by preventing a component from re-rendering if the props don’t change.

But be warned, if you’re using deeply nested data PureComponent will only do a shallow check for performance reasons, so try to limit it to simple data or use immutable objects.

Anyway, enough theory, let’s see it in an example.

Let’s say you have a “dumb” component that just renders a user’s name and avatar in the top right of a dashboard. You have a simple functional component because it doesn’t need to have state, it just needs to render out its props:

Now let’s say you have this component and a “search” input component both in the header of your site.

Each time your user types into the input and changes the input of your header, UserInfo is going to actually trigger a re-render, even if the props for the UserInfo component don’t change.

If you’re already using a full React component, it’d be easy to switch over to React.PureComponent and remove this unnecessary render. But now with React.memo, you can leverage that same performance boost with your functional components:

I created this quick CodeSandbox to demonstrate the differences. Type into the search input and notice how UserInfoNormal is actually re-rendering on every keystroke, even though the props aren’t changing. Compare that to UserInfoMemo, which is only doing one initial render and not re-rendering when the main App component’s state is changing.

React.lazy code-splitting

Now, just be warned, this is a feature “from the future” that’s mainly intended to set things up for the upcoming release of React Suspense. Also, this feature isn’t available for server-side rendering just yet, so don’t try and mix this into NextJS (which luckily does code-splitting by default, anyway).

Code splitting tries to solve one of the trickier issues with monolithic Javascript apps: the dreaded Bundle Size.

React.lazy allows you to only load components when they need to be rendered.

That means when you load into any page on your React app, you don’t have to load the source code for every single other component that exists in your app.

What this means is you can drastically increase initial loading speeds for React apps using a built-in APIs (although the React blog notes that React-Loadable is still a great options and currently offers server-side rendering).

Although the benefits of this API are a bit complicated, the implementation extremely easy. Below is the example from the official React docs, since it’s fairly straightforward.

Something to be cautious about, however, is that when MyComponent is initially rendered with React.lazy wrapping OtherComponent , the inner OtherComponent will initially render nothing while it loads in the source.

The React.lazy docs provide a solution: Using the even newer Suspense component.

I haven’t included Suspense in this list because it may be confused with the upcoming asynchronous React Suspense release, but for now the Suspense component can be used to provide a fallback while loading in component asynchronously.