Bundle Splitting & Lazy Loading — Reactjs and Webpack

Lazy Loading Modules and Webpack Bundle-Splitting (React, Webpack & Babel)

Spoiler

Configuring webpack correctly can have a huge effect on how your application will run. Subsequently, reflecting the user’s experience.

Let’s imagine a big puzzle with thousands of pieces that don’t fit the screen.

Whenever a player wants to see the result of a sub area of the puzzle, he gathers the pieces that are needed for this sub-view of the puzzle and assembles them in order to see the sub-view.

If the player assembled ALL the pieces in order to see ONLY a sub area of the puzzle, it will be a waste of time and he will be doing unnecessary actions and logic that will not be reflected in the sub area.

Imagine a robot that if you tell him what area you want to see, he gives you the right and the only pieces needed to assemble in order to view the sub area you intended to see.

So whenever we assemble a sub area of the puzzle we keep it assembled so eventually we will get the whole puzzle assembled.

Full Advanced React Course on Udemy

Advanced React (Render Performance Best Practices Patterns)

Connecting The Dots

Let’s say you have an application that includes

• Login Page “puzzle pieces”
• Table Page “puzzle pieces” (some data in table)
• Graphs Page “puzzle pieces” (some analytics, many d3 charts)

When some user loads your application and intends to see the TablePage, it will be a waste of:

• Time Waiting
• Network requests
• Heavy Loading

consequently leading to bad UX if we loaded in memory also the GraphsPage

Modularity

Keeping our application Modular (Modular Programming) and our concerns separated is key concept for achieving our goals

Webpack, React & Babel

• React 16.8+ Offers “Lazy Loading” for components (https://reactjs.org/docs/code-splitting.html)
• babel-plugin-syntax-dynamic-import offers parsing the dynamic imports
• Webpack offers bundle-splitting of every dynamic import statement

Combining these offers can get us a nice and beautiful component for bundle-splitting with loader and fallback Component (spinner, progress…).

Reusable Component

loadable.js

import React, { lazy, Suspense } from 'react';
export default (importCallback, { loader }) => {
    const TargetComponent = lazy(importCallback);
    return props => (
        <Suspense fallback={loader}>
            <TargetComponent {...props} />
        </Suspense>
    );
};

Usage

GraphsPageLoader.js

export default loadable(() => import(/* webpackChunkName: "GraphsPage" */ './GraphsPage'));

When Webpack encounters a statement like this it will split this ./GraphsPage module and its own sub-modules into a separate bundle (chunk) file with the name specified in the webpackChunkName.

My full course on Udemy:

Advanced React Ninja Course

Wrapping Up

• Loading resources takes some time, and applying logic on these resources also requires some computation time. If we strictly loaded only needed resource we will achieve application better performance and better ART.
• When we open the LoginPage we will not load also TablePage and GraphsPage, so we reduced the loading time of our application by third (roughly estimating worst case)
• When we navigate to the TablePage, we don’t have to calculate also all the d3 Charts that is found on the GraphsPage so we reduced our load time of the TablePage and we didn’t send any additional Network Requests for the GraphsPage.
• In terms of Scalibility, loading resources should be managed strictly, consequently achieving healthy application performance and good user experience.

Resources:

Code-Splitting — React

Code Splitting | webpack

for more information eymaslive@gmail.com