Analysis of dynamically loaded modules by webpack import()

This article shares with you the analysis of dynamic loading modules of webpack import(). The content is very good. Friends in need can refer to it. I hope it can help everyone.

import

webpack implements the import() method for dynamic loading according to the ES2015 loader specification.

This function can load our code on demand, and uses a promise-style callback to obtain the loaded package.

All modules that are imported() in the code will be packed into a separate package and placed in the directory where the chunk is stored. When the browser runs this line of code, it will automatically request this resource and implement asynchronous loading.

Here is a simple demo.

import('lodash').then(_ => {
  // Do something with lodash (a.k.a '_')...
 })

As you can see, the syntax of import() is very simple. This function only accepts one parameter, which is the address of the reference package. This address is exactly the same as the address used by es6's import and CommonJS's require syntax. Seamless switching can be achieved [Write a regular expression to replace Meizizi].

And it uses Promise encapsulation, which makes it feel very comfortable to develop. [Wrapping an async function is even more fun]

However, the above is just an appearance.

It’s just an appearance.

I encountered a problem during development. The scenario is this: an object stores routing information at all levels and its corresponding page components. To reduce the main bundle size, we want to load these pages dynamically.

At the same time, react-loadable is used to simplify the lazy loading encapsulation of components. The code is shown below.

function lazyLoad(path) {
 return Loadable({
  loader: () => import(path),
  loading: Spin,
 });
}

Then I happily started writing lazyLoad('./pages/xxx') in the code. Sure enough, it died. The browser said that there were no fish balls or thick noodles, and I didn’t know where this stupid module was.

So I checked the official documentation and found a yellow bar prompt.

emmm, it seems that the problem lies here.

This phenomenon is actually highly related to the implementation of webpack import(). Since webpack needs to package all import() modules separately, webpack will collect dependencies during the project packaging phase.

At this time, webpack will find all import() calls and process the incoming parameters into a regular pattern, such as:

import('./app'+path+'/util') => /^\.\/app.*\/util$/

In other words, all variables in the import parameters will is replaced by [.*], and webpack searches for all packages that meet the conditions based on this regular rule and packages them as packages.

Therefore, if we pass in a variable directly, webpack will package (the entire computer package [no trouble]) and think you are kidding him, and throw A WARNING: Critical dependency: the request of a dependency is an expression.

So the correct way to import is to express the path of the package as statically as possible and minimize the area controlled by variables .

If we want to reference a bunch of page components, we can use import('./pages/' ComponentName), so that we can encapsulate the references and avoid packaging redundant content.

Another point that affects function encapsulation is the relative path in import(), which is the relative path of the file where the import statement is located, so there will be some trouble when further encapsulating the import.

Because the path in the import statement will be processed into the relative path of the webpack command execution directory after compilation.

Related recommendations:

How to use token in vue Refresh processing

The above is the detailed content of Analysis of dynamically loaded modules by webpack import(). For more information, please follow other related articles on the PHP Chinese website!