Geekly Articles each Day
📜 ⬆️ ⬇️

Import () from the webpack will soon master JS + CSS, but how you can use it now

image

A month and a half ago, the creator of webpack Tobias Koppers released the “Big Plan” for CSS in a Webpack in his article “ New Workflow for CSS (step 1) ”.

The very first conclusion that can be made is that the separation of CSS code will become a first-class priority. You can get the css-files generated for each of your dynamic code fragments, and the import() calls will return 2 files to you: JS + CSS.

Here is a quote from the article:
')

Big plan


In the long run, we want to add a “first class” CSS support module to the webpack. It will work as follows:

  • We add a new type of module to the webpack: Stylesheet (next to Javascript)
  • We set up slice templates to record two files. One for javascript and one for style sheets (in the .css file).
  • We customize the block loading logic so that style sheets can be loaded. We need to wait for CSS to be applied, or at least load it, before running JS.
  • When we generate the loading of the code snippet, we can load the js part and the stylesheet part in parallel (in combination with Promise.all)

The basis, of course, is the ability to create CSS files for each dynamic fragment. Currently the extract-text-webpack-plugin module does not implement this. The currently available beta version 3.0 does not support this functionality. There is of course my extract-css-chunks-webpack-plugin , which has been in active use for some time, but it is not good enough. It is not good enough because compilation is slow and does not increase browser caching. The reason is that it creates 2 different JS fragments so that the whole idea should be based on an indivisible whole. These fragments are:


The reason this happens is that your initial rendering gets a minimal set of bytes, and, the same minimum, cached style sheets. Therefore, in all subsequent calls to import() not enough css.

Prehistory


In order for all this to make sense, if you hear about it for the first time, then you most likely will be interested in the following article: Code Cracked for Code-Splitting + SSR in Reactlandia: React Universal Component + Webpack Flush Chunks and more [RUS]

If you summarize what was written in the article mentioned above, there are the following components: react-universal-component and webpack-flush-chunks by means of which you can easily and universally render your application simultaneously with the separation of code. For the first time as an open source NPM package (no framework is required). For those who are not in the know, the takeaway is as follows: server-side rendering (SSR) is a solved problem, code separation is a solved problem, but until now the use of both remained an unresolved problem.

You no longer have to sacrifice SEO / SSR for code separation and / or vice versa.

It also means that your primary mechanism for storing bytes sent to clients is code separation. And if you decide to minimally optimize your application, then you do not want to send the CSS code of a private participant to all your public visitors, or vice versa. If, of course, you have several areas for your application, then these are just communication problems.

In fact, through statically shared CSS, you send fewer bytes to clients than the popular render path du jour solutions (since they have to send your CSS definitions to both JS snippets and extra CSS). And, more importantly, it also saves a lot of wasted cycles, generating CSS during rendering on the server and client sides.

Because the ability to control which static CSS files you send to clients is really a good way to handle this problem.

Introducing Babel-Plugin-Dual-Import + Extract CSS Chunks Webpack Plugin 2.0


babel-plugin-dual-import converts your request to Promise.all and, as a bonus, it automatically gives you a webpackChunkName. “Magic comments” are so magical that they disappear! Of course, under the hood, I use them to generate the names of your code snippets.

As for extract-css-chunks-webpack-plugin 2.0 , I have bypassed a serious performance problem in terms of build time (no more than two JS fragments), and now all you are dealing with are stylesheets that are browsers of your users can cache. And yes, fast module replacement (HMR) still works (better than ever actually).

Also note: all these four packages work seamlessly together. I conditionally call this the “universal” family of packages. Of course, all of them can be individually used, because this is what flexible framework development is about. But naturally they work best together. Enjoy.

Installation


Since we first introduce the babel plugin, we’ll focus on that:

 yarn add --dev babel-plugin-dual-import

.babelrc:

 { "presets": [whatever you usually have], "plugins": ["dual-import"] }

App.js:

 import('./Foo.js') ↓ ↓ ↓ ↓ ↓ ↓ import { importCss } from 'babel-plugin-dual-import/importCss.js' Promise.all ( [ import( /* webpackChunkName: 'Foo' */ './Foo'), importCss('Foo') ] ).then(promises => promises[0]);

And if you use all this dynamically, you need to add:

 import('../base/${page}') ↓ ↓ ↓ ↓ ↓ ↓ import { importCss } from 'babel-plugin-dual-import/importCss.js' Promise.all([ import( /* webpackChunkName: 'base/[request]' */ `./base/${page}`), importCss(`base/${page}`)] ).then(promises => promises[0]);

If you’ve previously watched how webpack-flush-chunks works, the new add-on is cssHash, which is similar to what webpack puts in the bootstrap script, matching javascript fragments with their identifiers. cssHash orients css fragment names in their style files. Babel-plugin-dynamic-import requests style sheets from there in parallel with javascript import.

Conclusion


There is not much left to say, because the git clone demo works for all four packages from here and on.

If you are completely unfamiliar with the React Universal Component + Webpack Flush Chunks, I advise you to at least look at the description diagonally. Currently, this is the only solution that unites all of this for React developers who fear an excessive number of frameworks. Developers who had similar problems, you know, those days are over.


Please note that the article is more than relevant and I hope that it will be considered useful even by people who are familiar with the technology of using these four packages. I would be grateful for any corrections, indications of shortcomings and / or information on whether habr needs translation of articles to which the author refers.

References:

Source: https://habr.com/ru/post/332974/

More articles:


All Articles