Shulou(Shulou.com)06/03 Report--

This article mainly explains "why css needs modularization". The content in the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn why css needs modularization.

Css "partial" style

Sass and less partially solve the problem of css modularization through @ import.

Because css is global, if there is a duplicate name between the imported file and the current file, the style of the former will be overwritten by the latter.

When introducing some common components, or when multiple people work together to develop the same page, it is troublesome to consider whether the style will be overwritten.

/ / file A.name {color: red} / / file B@import "A.scss"; .name {color: green}

Because of the characteristics of css global style, css is difficult to maintain, so a css "local" style solution is needed.

That is, complete css modularization, @ import into the css module, need to hide their own internal scope.

CSS Modules principle

By putting a unique hash value after each class name, there is no problem of global naming conflicts. This is tantamount to forging a "local" style.

/ / original style styles.css.title {color: red;} / / original template demo.htmlimport styles from 'styles.css'; Hello World// compiled styles.css.title_3zyde {color: red;} / / compiled demo.html Hello Worldwebpack and CSS Modules

The css-loader component of webpack comes with CSS Modules, which can be used through simple configuration.

{test: /\ .css $/, loader: "css?modules&localIdentName= [name] _ [local]-- [hash:base64:5]"}

The naming convention extends from BEM.

Block: corresponding module name [name]

Element: corresponding node name [local]

Modifier: corresponding node status [hash:base64:5]

Use _ _ and-- to distinguish between the split nodes of the words in the block.

The final class is named styles__title--3zyde.

Used in a production environment

In the actual production, it will be more convenient to combine with sass. The following is the configuration file for webpack used in conjunction with sass.

{test: /\ .scss $/, loader: "stylepowered CSSS modulesimportLoadersThe localIdentName = [name] _ [local]-- [hash:base64:5]! sass?sourceMap=true&sourceMapContents=true"}

Usually, in addition to local styles, global styles are required, such as basic files such as base.css.

Put the common style file and the component style file under two different destinations. As follows.

.├── app │ ├── styles # Common style │ │ ├── app.scss │ │ └── base.scss │ ││ └── components # component ├── Component.jsx # component template └── Component.scss # component style

Then, through webpack configuration, the (exclude) scss file outside the app/styles folder is "localized".

{test: /\ .scss $/, exclude: path.resolve (_ _ dirname, 'app/styles'), loader: "stylepowered cssss modulesimportLoadersimported localIdentNameName= [name] _ [local]-- [hash:base64:5]! sass?sourceMap=true&sourceMapContents=true"}, {test: /\ .scss $/, include: path.resolve (_ dirname,' app/styles'), loader: "styleworthy csslinks, sources Mapmaps trueworthy sourceMapContentstrue"}

Sometimes, an element has more than one class name, and you can add multiple class names to the element through join ("") or string templates.

/ / join-react.jsx Hello World// stringTemp-react.jsx Hello World

If you can define the style with only one class, it is best to write all the styles in one class.

So, if we use more than one class to define styles, we usually bring some logical judgment. It will be a lot of trouble to write at this time.

The introduction of classnames can not only solve the problem of writing multiple class names to elements, but also solve the troublesome problem of writing logical judgment.

ClassNames ('foo',' bar'); / / = > 'foo bar'classNames (' foo', {bar: true}); / / = > 'foo bar'classNames ({' foo-bar': true}); / / = > 'foo-bar'classNames ({' foo-bar': false}); / / = > 'classNames ({foo: true}, {bar: true}); / / >' foo bar'classNames ({foo: true, bar: true}) / / = > 'foo bar'// lots of arguments of various typesclassNames (' foo', {bar: true, duck: false}, 'baz', {quux: true}); / / = >' foo bar baz quux'// other falsy values are just ignoredclassNames (null, false, 'bar', undefined, 0,1, {baz: null},'') / / = > 'bar 1' Thank you for your reading, the above is the content of "Why css needs modularization". After the study of this article, I believe you have a deeper understanding of why css needs modularization, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.