|
| 1 | +<p align="center"> |
| 2 | + <a href="https://www.npmjs.com/package/webpack-flush-chunks"> |
| 3 | + <img src="https://img.shields.io/npm/v/webpack-flush-chunks.svg" alt="Version" /> |
| 4 | + </a> |
| 5 | + |
| 6 | + <a href="https://travis-ci.org/faceyspacey/webpack-flush-chunks"> |
| 7 | + <img src="https://travis-ci.org/faceyspacey/webpack-flush-chunks.svg?branch=master" alt="Build Status" /> |
| 8 | + </a> |
| 9 | + |
| 10 | + <a href="https://lima.codeclimate.com/github/faceyspacey/webpack-flush-chunks/coverage"> |
| 11 | + <img src="https://lima.codeclimate.com/github/faceyspacey/webpack-flush-chunks/badges/coverage.svg" alt="Coverage Status"/> |
| 12 | + </a> |
| 13 | + |
| 14 | + <a href="https://greenkeeper.io"> |
| 15 | + <img src="https://badges.greenkeeper.io/faceyspacey/webpack-flush-chunks.svg" alt="Green Keeper" /> |
| 16 | + </a> |
| 17 | + |
| 18 | + <a href="https://lima.codeclimate.com/github/faceyspacey/webpack-flush-chunks"> |
| 19 | + <img src="https://lima.codeclimate.com/github/faceyspacey/webpack-flush-chunks/badges/gpa.svg" alt="GPA" /> |
| 20 | + </a> |
| 21 | + |
| 22 | + <a href="https://www.npmjs.com/package/webpack-flush-chunks"> |
| 23 | + <img src="https://img.shields.io/npm/dt/webpack-flush-chunks.svg" alt="Downloads" /> |
| 24 | + </a> |
| 25 | + |
| 26 | + <a href="https://www.npmjs.com/package/webpack-flush-chunks"> |
| 27 | + <img src="https://img.shields.io/npm/l/webpack-flush-chunks.svg" alt="License" /> |
| 28 | + </a> |
| 29 | + |
| 30 | + <a href="https://gitter.im/webpack-flush-chunks"> |
| 31 | + <img src="https://img.shields.io/gitter/room/nwjs/nw.js.svg" alt="Gitter Chat" /> |
| 32 | + </a> |
| 33 | +</p> |
| 34 | + |
1 | 35 | # webpack-flush-chunks |
2 | 36 | `flushChunks` is the equivalent of `renderToString` or `renderToStaticMarkup` when it comes to code-splitting. It's to be used in |
3 | 37 | server-rendering to extract the minimal amount of chunks to send to the client, thereby solving a missing piece for code-splitting: |
@@ -31,14 +65,15 @@ don't want to just send all the chunks down to the client for that initial reque |
31 | 65 | if your strategy is the former, *checksums* won't match and an additional unnecessary render will happen on the client. |
32 | 66 |
|
33 | 67 | As a result, the goal becomes to get to the client precisely those chunks used in the first render, no more, no less. `flushChunks` does exactly |
34 | | -this, providing strings you can embed in your response: |
| 68 | +this, providing strings containing those scripts and stylesheets you can embed in your response: |
35 | 69 |
|
36 | 70 | ```javascript |
37 | 71 | const app = ReactDOM.renderToString(<App />) |
38 | | -const { js, styles } = flushChunks(stats) |
| 72 | +const moduleIds = ReactLoadable.flushRequires() |
| 73 | +const { js, styles } = flushChunks(moduleIds, stats) |
39 | 74 | ``` |
40 | 75 |
|
41 | | -If you can provide these chunks to the client, *React Lodable* will perform the first render synchcronously just like the server. |
| 76 | +If you can provide these chunks to the client, *React Lodable* (or comparable) will perform the first render synchcronously just like the server. |
42 | 77 |
|
43 | 78 | ## How It Works |
44 | 79 | *React Loadable*, when used on the server, skips the *loading* phase and syncronously renders your contained component, while recording the ID of |
@@ -224,8 +259,7 @@ export default function render(stats) { |
224 | 259 | } |
225 | 260 | ``` |
226 | 261 |
|
227 | | -Here the React Components `<JS />` and `<Styles />` are returned from `flushChunks` for use in composing the final component tree passed to `renderToStaticMarkup`. |
228 | | -Notice the components are in the `<body>`--this is because until *React 16* container `spans` are needed, and if used in the `<head>` will produce warnings. |
| 262 | +> Here the React Components `<JS />` and `<Styles />` are returned from `flushChunks` for use in composing the final component tree passed to `renderToStaticMarkup`. Notice the components are in the `<body>`--this is because until *React 16* container `spans` are needed, and if used in the `<head>` will produce warnings. |
229 | 263 |
|
230 | 264 | This is just one option though. There are several other things **returned** from `flushChunks`, which fulfill most other common needs: |
231 | 265 |
|
@@ -305,7 +339,7 @@ const html = ReactDOM.renderToStaticMarkup( |
305 | 339 | ``` |
306 | 340 | > **note:** the `publicPath` is also returned, for convenience |
307 | 341 |
|
308 | | -Though you will have no need to manually create your stylesheets and scripts, here you can see what data you have available to you in case you need to perform some other logic |
| 342 | +Though generally you will have no need to manually create your stylesheets and scripts, here you can see what data you have available to you in case you need to perform some other logic |
309 | 343 | on the array of scripts/sheets returned to you. |
310 | 344 |
|
311 | 345 |
|
@@ -353,15 +387,16 @@ plugins: [ |
353 | 387 |
|
354 | 388 | The key elements above are first the `namedModulesPlugin` which insures the module IDs generated for your |
355 | 389 | client bundle are the same for your server bundle (aka "deterministic"). Secondly, the `CommonsChunkPlugin` with |
356 | | -`"bootstrap"` entry which doesn't exist insures that a separate chunk is created just for webpack bootstrap code. |
| 390 | +`"bootstrap"` entry *which doesn't exist* insures that a separate chunk is created just for webpack bootstrap code. |
357 | 391 | This moves the webpack bootstrap code out of your `main` entry chunk so that it can also run before your dynamic |
358 | 392 | chunks. Lastly, the `ExtractCssChunks` plugin in combination with its loader insures CSS also gets multiple |
359 | 393 | CSS files created. If you're familiar with how `extract-text-webpack-plugin` works, you will be right at home. |
360 | 394 |
|
361 | 395 |
|
362 | 396 | Check out [faceyspacey/extract-css-chunks-webpack-plugin](https://github.com/faceyspacey/extract-css-chunks-webpack-plugin) |
363 | 397 | to learn more--it has some advanced features including HMR, and the ability to generate javascript chunks that don't |
364 | | -contain CSS injection plus simultaneously chunks that do for future asynchronous loading of chunks. |
| 398 | +contain CSS injection plus simultaneously chunks that do for future asynchronous loading of chunks. I.e. 2 versions |
| 399 | +of each javascript chunk. |
365 | 400 |
|
366 | 401 | ### Server Development |
367 | 402 | ```javascript |
@@ -538,7 +573,7 @@ compiler.plugin('done', stats => { |
538 | 573 | }) |
539 | 574 | ``` |
540 | 575 | > **note:** a callback can be passed to `webpack(config, stats => ...)`, but it does not provide the complete set |
541 | | -of stats as the `done` plugin callback does. Do NOT use it!* |
| 576 | +of stats as the `done` plugin callback does. Do NOT use it! |
542 | 577 |
|
543 | 578 | In this case `serverRender` is a function you call once with the stats that returns a function that |
544 | 579 | can be used by express on every request: |
@@ -581,8 +616,8 @@ its forked from (`extract-text-webpack-plugin`) does not provide, not even for a |
581 | 616 |
|
582 | 617 | In terms of server-rendering, it achieves a lot of the same things that solutions like *Aphrodite* |
583 | 618 | and *StyleTron* achieve where you extract the rendered CSS, *except its JS bundles are a lot smaller since CSS is completely moved to CSS files;* **and it |
584 | | -doesn't add to your runtime/render-overhead by performing work during render;** ***and it doesn't require cluttering your code with HoCs or specialized components.*** |
| 619 | +doesn't add to your runtime/render-overhead by performing work during render;** ***and it doesn't require cluttering your code with HoCs or specialized components; you can import a styles object just like you can with React Native (therefore you can use the same components for React as RN)*** |
585 | 620 | *The list goes on...* We |
586 | | -think we may have stumbled upon a solution that completes the intent of CSS Modules and value you can derive from it similar to how *Webpack Flush Chunks* completes the thought of code-splitting for *React Loadable*. It certainly produces the most minimal set of bytes corresponding to CSS |
| 621 | +think we may have stumbled upon a solution that completes the intent of CSS Modules and the value you can derive from it, similar to how *Webpack Flush Chunks* completes the thought of code-splitting for *React Loadable*. It certainly produces the most minimal set of bytes corresponding to CSS |
587 | 622 | you'll send over the wire in initial requests. You be the judge of that. We look forward to hearing your |
588 | 623 | opinion. |
0 commit comments