top

React 17- What’s new in the future?

Not too long ago React 16.3 alpha made its debut on npm.js, unveiling changes such as a new version of React Developer Tools, Strict Mode, and a new Context API . Don’t worry it’s super usable now and you’ll definitely want to try it out when handling basic state management concerns. It’s fair to say we didn’t get settled in with React 16.3 when JSConf 2018, Dan Abramov, creator of Redux and a core team member of React unveiled the new features of React 17. The React team does a great job at making React even better and this time their concerns were:How the state of an application is managed on devices with low processing capabilities.How the quality of network reception would influence the loading state of your application and its impact on a user’s general experience.Let’s have a glimpse into the future of React 17Time SlicingDuring the creation of React Fiber, async rendering was kept off due to the following reasons despite facilitating quicker responses in UI rendering:Issues with backward compatibilityPotential occurrences of race conditions and memory leaksTo make async rendering easier and safer to use, the concept of Time Slicing was created. Here’s one of Dan’s keynote slides at JSConf 2018:Applications of the future will have heavy user interfaces. When rendered on devices with low processing power, a user may feel stuck while trying to navigate through the app thus leading to a forgettable user experience. Time slicing splits computations of updates made on children components into various chunks during idle callbacks thus rendering can be executed over multiple frames. Instead of waiting for a high priority update to finish before rendering low priority updates, React simply rebases and continues to work on the low priority update while the high priority update is uninterrupted.Time Slicing is an awesome “under the hood” feature as it handles every CPU allotting and scheduling task while taking minimal attention from the developer.SuspenseLet’s say the UI of your app has a parent component which contains different components that all have different data dependencies. Basically, that’s a tree with async requests that trigger other async requests. Redux would solve this problem by having parent components handle requests for similar sibling components — React Suspense does things differently.With Suspense, React can pause any state update while loading asynchronous data. Suspense allows multiple state management — should there be a case of poor network reception, certain parts of the app are displayed while other parts load ensuring that the app remains accessible instead of displaying loading spinners and displaying all parts of the app only when all the requests have responded. Here’s a tweet from Dan stating explicitly, the core function of Suspense:In the process of demonstrating how Suspense works, Dan used createFetcher, an API which is basically a cache system that allows React to suspend the data fetching request from within the render method. Andrew Clark, also a core member of the React team, demystified createFetcher in a tweet:In his tweet, Jamie Kyle, also another core team member of React breaks down createfetcher :TL;DR function createFetcher(method) {   let resolved = new Map();   return {     read(key) => {       if (!resolved.has(key)) {         throw method(...args).then(val => resolved.set(key, val));       }       return resolved.get(key);     }   }; }Do note that createFetcher — at the time of writing this post is an extremely unstable API and may change at any time. As such, it shouldn’t be used in real applications. You can follow up on its development and progress on Github.To show you how Suspense works, I will be adopting excerpts from Dan’s IO demo at JSConf 2018:import { createFetcher, Placeholder, Loading } from '../future'; In the image above, the createFetcher API imported from the future has a .read method and will serve as a cache. It is where we will pass in the function fetchMovieDetails which returns a promise.In MovieDetails, a value is read from the cache. If the value is already cached, the render continues like normal else the cache throws a promise. When the promise resolves, React continues from where it left off. The cache is then shared throughout the React tree using the new context API.Usually, components get cached from context. This implies that while testing, it’s possible to use fake caches to mock out any network requests. createFetcher uses simple-cache-provider to suspend the request from within the render method thus enabling us to begin rendering before all the data has returned.simple-cache-provider has a .preload method that we can use to initiate a request before React gets to the component that needs it. For example, in a cinema app, you’re switching from MovieReviews to Movie, but only MovieInfo needs some data. While the data for MovieInfo is being fetched, React can still render Movie. With Suspense, the app fetches data while still being fully interactive at the same time. Potential occurrences of race conditions while a user clicks around and triggers different actions become minimal. In the picture above, using the Placeholder component, if the movie review takes more than a second to load while waiting for async dependencies, React displays the spinner.As seen above, the Loading component lets us temporarily suspend any state update until the data is ready and then add async loading to any component deep in the tree. It does this by rendering a prop called isLoading that lets us decide what to show.Like createFetcher, Loading is also part of simple-cache-provider and also unstable. Avoid using it in real applications.Deprecation of certain Component Lifecycle MethodsIn a recent blog post from the React team, the future of component lifecycle methods was discussed. Of course, you wouldn’t expect the React team not to make new changes to certain component lifecycle methods having made async rendering a more adaptable feature in React. React’s original lifecycle model was not intended for async rendering and with increased adoption of the latter, some of these lifecycle methods will be unsafe if used.Here are the lifecycle methods that will soon be deprecated:componentWillMount componentWillUpdate componentWillReceivePropsDue to the fact that all three methods are still being used quite frequently, their deprecation will occur in phases. First, they’ll be classified as unsafe in React 16.3, then they’ll have deprecation warnings added to them in any release after that and then finally, they’ll be deprecated in React 17.Does deprecated mean they’re gone for good? Not really, in React 17 the three methods will be renamed and two new methods will also be introduced:UNSAFE_componentWillMount UNSAFE_componentWillUpdate UNSAFE_componentWillReceiveProps getDerivedStateFromProps getSnapshotBeforeUpdate componentWillMount, componentWillUpdate and componentWillReceiveProps will be prefixed with UNSAFE. This implies that they shouldn’t be used at all or if they must be used, it should be with caution. For instance, the use of componentWillMount alongside async rendering will trigger multiple rendering of your component tree — this reason alone has deemed it unsafe.In this tweet, Dan explains how server-side rendering will work in the future with just componentDidMount:Let’s go on to demystify both of the newly created methods: getDerivedStateFromProps and getSnapshotBeforeUpdategetDerivedStateFromPropsThis method is static and handles what componentWillReceiveProps was able go do along with componentDidUpdate. It was created to be a safer replacement for componentWillReceiveProps. It is called after a component is created and also called when it receives a new prop.static getDerivedStateFromProps(nextProps, prevState) { // ... }getderivedStateFromProps returns an object to update state in response to prop changes. To indicate no change to state it returns null. React may call this method even if the props have not changed.getSnapshotBeforeUpdateThis method is called just before the DOM is updated, it handles what componentWillUpdate was able to go along with componentDidUpdate. The value that is returned from getSnapshotBeforeUpdate after the DOM is updated is passed on to componentDidUpdate.getSnapshotBeforeUpdate(prevProps, prevState) { // ... }A good use case for getSnapshotBeforeUpdate is resizing the window of an app during async rendering.SummaryTime Slice handles all our difficult CPU scheduling tasks under the hood without any considerations. Suspense enables us to manage multiple states by delaying the rendering of content for a few seconds until the entire component tree is ready while keeping the previous view intact. Here’s a short reiteration of the points noted by Dan at JSConf 2018:I recommend that you watch Dan’s full presentation at JSConf 2018 where he gave further details of the reasons behind what’s new in React 17.
Rated 4.5/5 based on 13 customer reviews
Normal Mode Dark Mode

React 17- What’s new in the future?

Raphael Ugwu
Blog
08th Oct, 2018
React 17- What’s new in the future?

Not too long ago React 16.3 alpha made its debut on npm.js, unveiling changes such as a new version of React Developer Tools, Strict Mode, and a new Context API . Don’t worry it’s super usable now and you’ll definitely want to try it out when handling basic state management concerns. It’s fair to say we didn’t get settled in with React 16.3 when JSConf 2018, Dan Abramov, creator of Redux and a core team member of React unveiled the new features of React 17. The React team does a great job at making React even better and this time their concerns were:

  • How the state of an application is managed on devices with low processing capabilities.
  • How the quality of network reception would influence the loading state of your application and its impact on a user’s general experience.

Let’s have a glimpse into the future of React 17

Time Slicing

During the creation of React Fiber, async rendering was kept off due to the following reasons despite facilitating quicker responses in UI rendering:

  • Issues with backward compatibility
  • Potential occurrences of race conditions and memory leaks

To make async rendering easier and safer to use, the concept of Time Slicing was created. Here’s one of Dan’s keynote slides at JSConf 2018:

Time Slicing

Applications of the future will have heavy user interfaces. When rendered on devices with low processing power, a user may feel stuck while trying to navigate through the app thus leading to a forgettable user experience. Time slicing splits computations of updates made on children components into various chunks during idle callbacks thus rendering can be executed over multiple frames. Instead of waiting for a high priority update to finish before rendering low priority updates, React simply rebases and continues to work on the low priority update while the high priority update is uninterrupted.

Time Slicing is an awesome “under the hood” feature as it handles every CPU allotting and scheduling task while taking minimal attention from the developer.

Suspense

Let’s say the UI of your app has a parent component which contains different components that all have different data dependencies. Basically, that’s a tree with async requests that trigger other async requests. Redux would solve this problem by having parent components handle requests for similar sibling components — React Suspense does things differently.

With Suspense, React can pause any state update while loading asynchronous data. Suspense allows multiple state management — should there be a case of poor network reception, certain parts of the app are displayed while other parts load ensuring that the app remains accessible instead of displaying loading spinners and displaying all parts of the app only when all the requests have responded. Here’s a tweet from Dan stating explicitly, the core function of Suspense:

In the process of demonstrating how Suspense works, Dan used createFetcher, an API which is basically a cache system that allows React to suspend the data fetching request from within the render method. Andrew Clark, also a core member of the React team, demystified createFetcher in a tweet:

In his tweet, Jamie Kyle, also another core team member of React breaks down createfetcher :

TL;DR

function createFetcher(method) {
  let resolved = new Map();
  return {
    read(key) => {
      if (!resolved.has(key)) {
        throw method(...args).then(val => resolved.set(key, val));
      }
      return resolved.get(key);
    }
  };
}

Do note that createFetcher — at the time of writing this post is an extremely unstable API and may change at any time. As such, it shouldn’t be used in real applications. You can follow up on its development and progress on Github.

To show you how Suspense works, I will be adopting excerpts from Dan’s IO demo at JSConf 2018:

import { createFetcher, Placeholder, Loading } from '../future';

Suspense

In the image above, the createFetcher API imported from the future has a .read method and will serve as a cache. It is where we will pass in the function fetchMovieDetails which returns a promise.

In MovieDetails, a value is read from the cache. If the value is already cached, the render continues like normal else the cache throws a promise. When the promise resolves, React continues from where it left off. The cache is then shared throughout the React tree using the new context API.

Usually, components get cached from context. This implies that while testing, it’s possible to use fake caches to mock out any network requests. createFetcher uses simple-cache-provider to suspend the request from within the render method thus enabling us to begin rendering before all the data has returned.

simple-cache-provider has a .preload method that we can use to initiate a request before React gets to the component that needs it. For example, in a cinema app, you’re switching from MovieReviews to Movie, but only MovieInfo needs some data. While the data for MovieInfo is being fetched, React can still render Movie.

 React 17- What’s new in the future?

With Suspense, the app fetches data while still being fully interactive at the same time. Potential occurrences of race conditions while a user clicks around and triggers different actions become minimal. In the picture above, using the Placeholder component, if the movie review takes more than a second to load while waiting for async dependencies, React displays the spinner.


As seen above, the Loading component lets us temporarily suspend any state update until the data is ready and then add async loading to any component deep in the tree. It does this by rendering a prop called isLoading that lets us decide what to show.

Like createFetcherLoading is also part of simple-cache-provider and also unstable. Avoid using it in real applications.

Deprecation of certain Component Lifecycle Methods

In a recent blog post from the React team, the future of component lifecycle methods was discussed. Of course, you wouldn’t expect the React team not to make new changes to certain component lifecycle methods having made async rendering a more adaptable feature in React. React’s original lifecycle model was not intended for async rendering and with increased adoption of the latter, some of these lifecycle methods will be unsafe if used.

Here are the lifecycle methods that will soon be deprecated:

componentWillMount
componentWillUpdate
componentWillReceiveProps

Due to the fact that all three methods are still being used quite frequently, their deprecation will occur in phases. First, they’ll be classified as unsafe in React 16.3, then they’ll have deprecation warnings added to them in any release after that and then finally, they’ll be deprecated in React 17.

Does deprecated mean they’re gone for good? Not really, in React 17 the three methods will be renamed and two new methods will also be introduced:

UNSAFE_componentWillMount
UNSAFE_componentWillUpdate
UNSAFE_componentWillReceiveProps
getDerivedStateFromProps
getSnapshotBeforeUpdate

componentWillMount, componentWillUpdate and componentWillReceiveProps will be prefixed with UNSAFE. This implies that they shouldn’t be used at all or if they must be used, it should be with caution. For instance, the use of componentWillMount alongside async rendering will trigger multiple rendering of your component tree — this reason alone has deemed it unsafe.

In this tweet, Dan explains how server-side rendering will work in the future with just componentDidMount:

Let’s go on to demystify both of the newly created methods: getDerivedStateFromProps and getSnapshotBeforeUpdate

getDerivedStateFromProps

This method is static and handles what componentWillReceiveProps was able go do along with componentDidUpdate. It was created to be a safer replacement for componentWillReceiveProps. It is called after a component is created and also called when it receives a new prop.

static getDerivedStateFromProps(nextProps, prevState) {
// ...
}

getderivedStateFromProps returns an object to update state in response to prop changes. To indicate no change to state it returns null. React may call this method even if the props have not changed.

getSnapshotBeforeUpdate

This method is called just before the DOM is updated, it handles what componentWillUpdate was able to go along with componentDidUpdate. The value that is returned from getSnapshotBeforeUpdate after the DOM is updated is passed on to componentDidUpdate.

getSnapshotBeforeUpdate(prevProps, prevState) {
// ...
}

A good use case for getSnapshotBeforeUpdate is resizing the window of an app during async rendering.

Summary

Time Slice handles all our difficult CPU scheduling tasks under the hood without any considerations. Suspense enables us to manage multiple states by delaying the rendering of content for a few seconds until the entire component tree is ready while keeping the previous view intact. Here’s a short reiteration of the points noted by Dan at JSConf 2018:



I recommend that you watch Dan’s full presentation at JSConf 2018 where he gave further details of the reasons behind what’s new in React 17.

Raphael

Raphael Ugwu

Blog Author
A software developer, taking my time to learn what I can and make an impact, one step at a time. JavaScript is where the heart lies.
Website : https://github.com/fullstackmafia

Leave a Reply

Your email address will not be published. Required fields are marked *

Top comments

sunil

16 November 2018 at 4:07pm
I absolutely love your blog and find the majority of your post's to be exactly what I'm looking for

Monte

January, 28th at 3:32pm
Great explanation! Easy to follow and detailed! Thanks

SUBSCRIBE OUR BLOG

Follow Us On

Share on

other Blogs

20% Discount