Why do dynamic import?

Dynamic import is called something I don’t know why, load on demand, lazy load, Code Splitting, Code paging, etc. In short, in SPA, JS code is divided into N pages of files, not all introduced as soon as the user comes in, but wait for the user to jump route, and then load the corresponding JS file. The benefit of this is to speed up the first screen and reduce the waste of resources.

Why WebPack 3?

  • Higher performance
  • Scope Hosting eliminates the need for rollup to handle code redundancy
  • Can be combined with the React-router, more elegant dynamic import
  • The most important point is that when I was studying Webpack, 3 had already produced –

The full React SPA project address

GitHub project address

This is a complete project, and the related content of this section can be found in router/ RouterMap.jsx.

Step 1: install babel-plugin-syntax-dynamic-import

Babel uses babel-env, use method can go to Babel official learning, practice can see my project source code.

NPM I -d babel-plugin-syntax-dynamic-import, plunges “syntax-dynamic-import” into the.babelrc file.

Step 2: Install react-loadable

After NPM i-s react-loadable, we can happily do dynamic import.

Step 3: Edit the routerMap

import React from 'react';
import { HashRouter as Router, Route, Switch } from 'react-router-dom';
import createHistory from 'history/createBrowserHistory';
const history = createHistory();

import App from 'containers'; // Import Loadable from'react-loadable';
const MyLoadingComponent = ({ isLoading, error }) => {
    // Handle the loading state
    if (isLoading) {
        return<div>Loading... </div>; } // Handle the error stateelse if (error) {
        return <div>Sorry, there was a problem loading the page.</div>;
    }
    else {
        returnnull; }}; const AsyncHome = Loadable({ loader: () => import('.. /containers/Home'),
    loading: MyLoadingComponent
});
const AsyncCity = Loadable({
    loader: () => import('.. /containers/City'),
    loading: MyLoadingComponent
});
const AsyncDetail = Loadable({
    loader: () => import('.. /containers/Detail'),
    loading: MyLoadingComponent
});
const AsyncSearch = Loadable({
    loader: () => import('.. /containers/Search'),
    loading: MyLoadingComponent
});
const AsyncUser = Loadable({
    loader: () => import('.. /containers/User'),
    loading: MyLoadingComponent
});
const AsyncNotFound = Loadable({
    loader: () => import('.. /containers/404'), loading: MyLoadingComponent }); Class RouteMap extends React.Component {render() {
        return (
            <Router history= {history}>
                <App>
                    <Switch>
                        <Route path="/" exact component={AsyncHome} />
                        <Route path="/city" component={AsyncCity} />
                        <Route path="/search/:category/:keywords?" component={AsyncSearch} />
                        <Route path="/detail/:id" component={AsyncDetail} />
                        <Route path="/user" component={AsyncUser} />
                        <Route path="/empty" component={null} key="empty"/> <Route component={AsyncNotFound} /> </Switch> </App> </Router> ); / / that / / the empty Route / / https://github.com/ReactTraining/react-router/issues/1982 to solve: PFight // react-router V4 does not refresh or reload components when changing query parameters}}export default RouteMap;
Copy the code

You’re done

We can run webpack and see the effect. (See devDependencies and Dependencies for details.)

The original address

Github.com/CodeLittleP…

Refer to the article

Code Splitting in Create React App

Q&A

Some students said that my method of page separation is not good, because each page depends on the code of the three-party library, so there is a lot of redundant code in the page. It is great to think about this, and I have started to think about architecture. However, notice that this idea is correct in the dev environment.

What about the build environment, or the release environment? Indeed, I did not mention it in this article. Please see the difference between devDependencies and dependencies in my other article. This article explains the difference between devDependencies and dependencies in package.json of NPM.

After watching this, we can see why I said “Notice this idea in the dev context, this student is right.” Because, after we NPM run build, WebPack will package the three party package into vendor.js file, the page logic code will not be involved, every page will reference vendor.js file, so that there will be no redundant code introduced repeatedly.