Skip to content

Commit

Permalink
docs(guides): merge and rewrite code-splitting and lazy-load guides (#…
Browse files Browse the repository at this point in the history
…1338)

Merge Code Splitting guides by removing all caching discussion 
and other extraneous content. Focuses on code splitting approaches 
instead. Move certain `import()` documentation to the Module API 
page. Use links to prevent content duplication. Replace lazy-load-react 
with a short, framework-agnostic lazy-loading guide.
  • Loading branch information
skipjack authored Jun 29, 2017
1 parent 690eb55 commit 15f8155
Show file tree
Hide file tree
Showing 14 changed files with 433 additions and 882 deletions.
54 changes: 47 additions & 7 deletions content/api/module-methods.md
Original file line number Diff line number Diff line change
Expand Up @@ -53,7 +53,11 @@ export default {

### `import()`

Dynamically load modules.
`import('path/to/module') -> Promise`

Dynamically load modules. Calls to `import()` are treated as split points, meaning the requested module and it's children are split out into a separate chunk.

T> The [ES2015 Loader spec](https://whatwg.github.io/loader/) defines `import()` as method to load ES2015 modules dynamically on runtime.

``` javascript
if ( module.hot ) {
Expand All @@ -63,8 +67,33 @@ if ( module.hot ) {
}
```

The compiler treats this as a split point and will split everything from `lodash` into a separate bundle. This returns a promise that will resolve to the module once the bundle has been loaded. See the [async code splitting guide](/guides/code-splitting-async) for more information.
W> This feature relies on [`Promise`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise) internally. If you use `import()` with older browsers, remember to shim `Promise` using a polyfill such as [es6-promise](https://github.com/stefanpenner/es6-promise) or [promise-polyfill](https://github.com/taylorhakes/promise-polyfill). See [Shimming](/guides/shimming) for more information.

The spec for `import` doesn't allow control over the chunk's name or other properties as "chunks" are only a concept within webpack. Luckily webpack allows some special parameters via comments so as to not break the spec:

``` js
import(
/* webpackChunkName: "my-chunk-name" */
/* webpackMode: "lazy" */
'module'
);
```

`webpackChunkName`: A name for the new chunk. Since webpack 2.6.0, the placeholders `[index]` and `[request]` are supported within the given string to an incremented number or the actual resolved filename respectively.

`webpackMode`: Since webpack 2.6.0, different modes for resolving dynamic imports can be specified. The following options are supported:

- `"lazy"` (default): Generates a lazy-loadable chunk for each `import()`ed module.
- `"lazy-once"`: Generates a single lazy-loadable chunk that can satisfy all calls to `import()`. The chunk will be fetched on the first call to `import()`, and subsequent calls to `import()` will use the same network response. Note that this only makes sense in the case of a partially dynamic statement, e.g. ``import(`./locales/${language}.json`)``, where there are multiple module paths that could potentially be requested.
- `"eager"`: Generates no extra chunk. All modules are included in the current chunk and no additional network requests are made. A `Promise` is still returned but is already resolved. In contrast to a static import, the module isn't executed until the call to `import()` is made.

T> Note that both options can be combined like so `/* webpackMode: "lazy-once", webpackChunkName: "all-i18n-data" */`. This is parsed as a JSON5 object without curly brackets.

W> Fully dynamic statements, such as `import(foo)`, __will fail__ because webpack requires at least some file location information. This is because `foo` could potentially be any path to any file in your system or project. The `import()` must contain at least some information about where the module is located, so bundling can be limited to a specific directory or set of files.

W> Every module that could potentially be requested on an `import()` call is included. For example, ``import(`./locale/${language}.json`)`` will cause every `.json` file in the `./locale` directory to be bundled into the new chunk. At run time, when the variable `language` has been computed, any file like `english.json` or `german.json` will be available for consumption.

W> The use of `System.import` in webpack [did not fit the proposed spec](https://github.com/webpack/webpack/issues/2163), so it was deprecated in webpack [2.1.0-beta.28](https://github.com/webpack/webpack/releases/tag/v2.1.0-beta.28) in favor of `import()`.


## CommonJS
Expand Down Expand Up @@ -132,24 +161,35 @@ require.cache[module.id] !== module

### `require.ensure`

W> `require.ensure()` is specific to webpack and superseded by `import()`.

``` javascript
require.ensure(dependencies: String[], callback: function([require]), [chunkName: String])
require.ensure(dependencies: String[], callback: function(require), errorCallback: function(error), chunkName: String)
```

Split out the given `dependencies` to a separate bundle that that will be loaded asynchronously. When using CommonJS module syntax, this is the only way to dynamically load dependencies. Meaning, this code can be run within execution, only loading the `dependencies` if a certain conditions are met. See the [Asynchronous Code Splitting guide](/guides/code-splitting-async) for more details.
Split out the given `dependencies` to a separate bundle that that will be loaded asynchronously. When using CommonJS module syntax, this is the only way to dynamically load dependencies. Meaning, this code can be run within execution, only loading the `dependencies` if certain conditions are met.

``` javascript
var a = require('normal-dep');

if ( /* Some Condition */ ) {
require.ensure(["b"], function(require) {
var c = require("c");
if ( module.hot ) {
require.ensure(['b'], function(require) {
var c = require('c');

// Do something special...
});
}
```
The following parameters are supported in the order specified above:
- `dependencies`: An array of strings declaring all modules required for the code in the `callback` to execute.
- `callback`: A function that webpack will execute once the dependencies are loaded. An implementation of the `require` function is sent as a parameter to this function. The function body can use this to further `require()` modules it needs for execution.
- `errorCallback`: A function that is executed when webpack fails to load the dependencies.
- `chunkName`: A name given to the chunk created by this particular `require.ensure()`. By passing the same `chunkName` to various `require.ensure()` calls, we can combine their code into a single chunk, resulting in only one bundle that the browser must load.
W> Although the implementation of `require` is passed as an argument to the `callback` function, using an arbitrary name e.g. `require.ensure([], function(request) { request('someModule'); })` isn't handled by webpack's static parser. Use `require` instead, e.g. `require.ensure([], function(require) { require('someModule'); })`.
## AMD
Expand Down
6 changes: 3 additions & 3 deletions content/guides/asset-management.md
Original file line number Diff line number Diff line change
Expand Up @@ -136,7 +136,7 @@ bundle.js 560 kB 0 [emitted] [big] main

Open up `index.html` in your browser again and you should see that `Hello webpack` is now styled in red. To see what webpack did, inspect the page (don't view the page source, as it won't show you the result) and look at the page's head tags. It should contain our style block that we imported in `index.js`.

T> Note that you can also [split your CSS](/guides/code-splitting-css) for better load times in production. On top of that, loaders exist for pretty much any flavor of CSS you can think of -- [postcss](/loaders/postcss-loader), [sass](/loaders/sass-loader), and [less](/loaders/less-loader) to name a few.
T> Note that you can also [split your CSS](/plugins/extract-text-webpack-plugin) for better load times in production. On top of that, loaders exist for pretty much any flavor of CSS you can think of -- [postcss](/loaders/postcss-loader), [sass](/loaders/sass-loader), and [less](/loaders/less-loader) to name a few.


## Loading Images
Expand Down Expand Up @@ -440,7 +440,7 @@ __project__
|- bundle.js
|- index.html
|- /src
+ |- data.xml
+ |- data.xml
|- my-font.woff
|- my-font.woff2
|- icon.png
Expand Down Expand Up @@ -530,7 +530,7 @@ __project__
|- bundle.js
|- index.html
|- /src
- |- data.xml
- |- data.xml
- |- my-font.woff
- |- my-font.woff2
- |- icon.png
Expand Down
2 changes: 1 addition & 1 deletion content/guides/caching.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
---
title: Caching
sort: 9
sort: 11
contributors:
- okonet
- jouni-kantola
Expand Down
Loading

0 comments on commit 15f8155

Please sign in to comment.