Code separation. The purpose of this chapter is reuse and basic caching

First, the first part is to put forward the common, for example, loadsh is the common part.

If released normally, index.js and another-module.js. Loadsh is packaged.

index.js

import _ from 'lodash';

console.log(_.join(['index','loaded'], ' '));
Copy the code

another-module.js

import _ from 'lodash';

console.log(_.join(['Another', 'module', 'loaded!'], ' '));
Copy the code

The 01 code separation approach actively chooses which modules to share

entry: {
           index: {
              import: './src/index.js',
              dependOn: 'shared',
            },
            another: {
              import: './src/another-module.js',
              dependOn: 'shared',
            },
            shared: 'lodash'
}
Copy the code

The shared keyword gives examples of common modules. DependOn select shared in the specific path.

You can choose which dependencies. Shared can also be an array. I thought of another possibility, that I had multiple shared modes and there were multiple possibilities, so I tested it.

entry: {
        index: {
            import: './src/index.js',
            dependOn: 'shared',
        },
        another: {
            import: './src/another-module.js',
            dependOn: ['shared', 'shared1'],
        },
        shared: 'lodash',
        shared1: 'moment'
}
Copy the code

That’s ok, too.

This is relatively flexible.

There’s just one line in the document that I really don’t understand

If we want to use multiple entry on an HTML page, still need to set up optimization. RuntimeChunk: ‘single’, otherwise will run into the trouble that described here.

After I looked at the link, I understood the question.

Is the different entry should be re-instantiated object, to solve the article Chinese problem.

But why add optimization. RuntimeChunk: ‘single’ can solve, I checked the meaning

Optimization. RuntimeChunk what your role is?

It’s really about caching, although I haven’t experimented with it yet, so I don’t understand it here.

02 Code separation method automatically separates common modules

Back to the original entry

    entry: {
      index: './src/index.js',
      another: './src/another-module.js',
    },
Copy the code

But there are ways to do it automatically without having to choose

optimization: {
        splitChunks: {
            chunks: 'all'
        }
    }
Copy the code

It automatically isolates the common modules, so I looked up splitChunks

SplitChunksPlugin

    splitChunks: {
      chunks: 'async',
      minSize: 20000,
      minRemainingSize: 0,
      minChunks: 1,
      maxAsyncRequests: 30,
      maxInitialRequests: 30,
      enforceSizeThreshold: 50000,
      cacheGroups: {
        defaultVendors: {
          test: /[\/]node_modules[\/]/,
          priority: -10,
          reuseExistingChunk: true,
        },
        default: {
          minChunks: 2,
          priority: -20,
          reuseExistingChunk: true,
        },
      },
    },
  },
Copy the code

I was beginning to worry that extracting into a public chunk would be too big, but these attributes prove that I was overthinking it.

The main thing about code separation is optimizing speed. The thing that you change a lot is the business logic, the common components are rarely changed, extract them out and maximize the browser cache.

It’s something like this, and the properties can wait until they’re used.

03 dynamic import

Dynamic import this stuff has a poor knowledge of WebPack. It seems that there was a similar way to dynamically load and split modules, using jSONP to dynamically load modules, but the syntax seems to be different.

It’s easy to say, first I introduce moment, then I write a method to load dynamically.

dynamic.js

export default async () => {
    let { default: m } = await import("moment");
    let timeString = m().format('MMMM Do YYYY, h:mm:ss.SSS a');
    console.log("-----dynamicImport in test------");
    console.log(timeString);
    return timeString;
}
Copy the code

Then after external reference, compile directly.

Moment will have two, a language pack and a program, normally one.

See here for an in-depth look at how WebPack modules load

Jsonp loading.

Another way to use it is to write it in button events or other delayed loading methods.

   dynamicImportBtn.innerHTML = 'dynamic import btn';
   dynamicImportBtn.onclick = async () => {
        let { default: m } = await import("moment");
        let timeString = m().format('MMMM Do YYYY, h:mm:ss.SSS a');
        console.log("-----dynamicImport in test------");
        console.log(timeString);
    }
    element.append(dynamicImportBtn);
Copy the code

Sure enough, after clicking the button, the corresponding JS will be loaded.

04. Preloading

Prefetch: Resources that may be required in future navigation. Preload: Resources that may be required in the current navigation

< link rel = "prefetch" as = "script" href = "http://127.0.0.1:5500/dist/762.bundle.js" > < link rel = "prefetch" as = "script" Href = "http://127.0.0.1:5500/dist/700.bundle.js" >Copy the code
< link rel = "prefetch" as = "script" href = "http://127.0.0.1:5500/dist/762.bundle.js" > < link rel = "prefetch" as = "script" Href = "http://127.0.0.1:5500/dist/700.bundle.js" >Copy the code

The application in the code is, you put in this comment ahead of time, telling WebPack what strategy do you need to implement with this code

let { default: m } = await import(/* webpackPreload: true */ "moment");
Copy the code

Eventually it will be generated in HTML, but the important thing to note is that you are generating HTML from WebPack

At first I thought this was webPck through JS implementation, originally is HTML standard.

You can refer to these two articles

www.webhek.com/post/link-p… www.cnblogs.com/cangqinglan…

So in conclusion

Preload Parallel download Prefetch is downloaded when it is idle

Estimate your own usage scenarios and choose the preload and the order in which to preload

I’m not going to do much research and testing here, but I’m going to use it later and then I’m going to learn and test it

05. end

Again, the purpose of this chapter is to teach us how to use WebPack to split code.

Several ways are given

  1. Extract the common code and separate the common code to reduce the size and take full advantage of the browser cache.
  2. Split code, code with different logic is split to achieve the same effect
  3. Preload, whether it’s images or modules. Preload requests that reach the optimal speed

Finally, several methods of analyzing package, plug-in, are given.

We’ll have a chance to experiment later.