Most React applications currently require it
code splittingChoose to use good ones
react-loadableTo handle the test to see if the code segment is loaded. However, with the release of React V16.6, we have a very rare opportunity to remove our third-party dependencies!

Suspense is a new feature added to the core React library. It is basically the same as react-loadable, so let’s take a look at replacing react-loadable with Suspense.

The first is code splitting.

If you’re not familiar with this feature, WebPack basically helps you bundle your code into chunks. When a user opens your application, a main bundle is downloaded, and then when the user navigates to pages containing other logical and static resources, these chunks are loaded on demand. However, it is very complicated to manually process this effect. Of course, this process can effectively reduce the user’s white screen time, and let mobile users have a better experience. Webpack (or any other solution) plays an important role in handling the complex logic of these bundles as they are created, and then downloading them as needed. So all we need to do is incorporate this functionality into our application so that users can have a seamless experience.

Upgrade to React 16.6

For V16 users, you can upgrade to 16.6 directly, but for V15 users, follow the official migration instructions.

Step 2: Identify your asynchronous components

In react-loadable, loading on demand might look like this:

const Loading = ({ pastDelay }) => {
  if (pastDelay) {
    return <Spinner />;
  }
  return null;
};
 
export const johanAsyncComponent = Loadable({
  loader: () => import(/* webpackChunkName: "johanComponent" */ './johan.component'),
  loading: Loading,
  delay: 200
});Copy the code

In the code above, we do a few things:

  1. We define a Loading component to display between the time the component is requested and the time the component is loaded and ready to render.
  2. johanAsyncComponentIn theloadingParameters are components that are displayed in the request/response cycle, where we define a custom Loading component
  3. By setting a delay, we only display the Spinner after loading for more than 200 milliseconds, which is a good way to avoid “flashing” loaded components when the request completes quickly.

Suspense 3: Change to React.suspense

Suspense code is obviously more elegant using React.suspense code.

const johanComponent = React.lazy(() => import(/* webpackChunkName: "johanComponent" */ './myAwesome.component')); export const johanAsyncComponent = props => ( <React.Suspense fallback={<Spinner />}> <johanComponent {... props} /> </React.Suspense> );Copy the code
  1. We use React. Lazy to encapsulate the dynamic import, similar to the ‘loading’ parameter in the first example.
  2. Let’s define aReact.SuspenseComponent, which contains a set offallbackJSX for rendering while we wait for asynchronous loading. Typically, this will be a spinner or other wait indicator.
  3. We have defined some JSX for children that are included using React.lazy.

Ok, at this point, we’ve implemented the same functionality as React-loadable. Suspense doesn’t have delay parameters, as you may have noticed. Suspense does not have built-in delay support, so fallbacks will be executed even if the loading project only takes a few milliseconds. In this case, the Spinner will blink if the resource is loaded very quickly. For now, you’ll need to handle the logic yourself in fallback components, such as setting a timer in componentDidMount so that it doesn’t render until some future time.

Step 4: Handling loading errors

What happens if a chunk load fails?

react-loadable

Good libraries, of course, have built-in methods to handle load failures

const Loading = (props) => { if (props.error) { return <p>Error! </p>; } else if (props.pastDelay) { return <p>Loading... </p>; } else { return null; }}Copy the code

Suspense

React 16 has a new feature Error Boundary, which is just an error-aware component that catches and handles errors from its children. To deal with the problem of asynchronous loading, we can simply define a custom ErrorEdge component and wrap the use of asynchronous components in it.

<MyCustomErrorBoundary>
  <MyAwesomeAsyncComponent />
</MyCustomErrorBoundary>Copy the code

The last step

npm uninstall  react-loadableCopy the code

What are the benefits of substitution?

Obviously, when we think about upgrading or refactoring, we often use the excuse that “it works just fine the way it is” as an excuse. So is it worth upgrading?

Smaller bundles: The React-loadable gzip was about 2K, so the packaging time wasn’t much reduced by removing the third-party library, but it was definitely 2K less.

Increased maintainability: Use the React core library, which is always easier to maintain than a third-party library.

conclusion

In general, I wouldn’t say that this is a must-replace feature, but considering many factors, the two functions are basically the same, and the code is relatively easy to change, so it is recommended to use this new feature for on-demand loading.