css "partial" style
sass, less through@import
, partially solved css is modular question.
Since css is global, if the imported file and the current file have the same name, the former style will be overwritten by the latter.
When introducing some public components, or when multiple people collaborate to develop the same page, you need to consider whether the style will be overwritten, which is very troublesome.
// file A .name { color: red } // file B @import "A.scss"; .name { color: green }
The characteristics of css global styles make css difficult to maintain, so a solution to css "local" styles is needed.
That is to say, complete css modularization.@import
The incoming css module needs to hide its own internal scope.
CSS Modules Principle
By adding a unique hash value after each class name, there will be no global naming conflict. This is equivalent to forging a "local" style.
// 原始样式 styles.css .title { color: red; } // 原始模板 demo.html import styles from 'styles.css';Hello World
// 编译后的 styles.css .title_3zyde { color: red; } // 编译后的 demo.htmlHello World
webpack and CSS Modules
webpack’s owncss-loader
component 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 is extended from BEM.
Block: Corresponding module name
[name]
Element: Corresponding node name
[local]
#Modifier: Corresponding node status
[hash:base64:5]
The final class name is
styles__title--3zyde.
{ test: /\.scss$/, loader: "style!css?modules&importLoaders=1&localIdentName=[name]__[local]--[hash:base64:5]!sass?sourceMap=true&sourceMapContents=true" }
Put the public style files and component style files into two different targets. as follows.
. ├── app │ ├── styles # 公用样式 │ │ ├── app.scss │ │ └── base.scss │ │ │ └── components # 组件 ├── Component.jsx # 组件模板 └── Component.scss # 组件样式
app/stylesfolder.
{ test: /\.scss$/, exclude: path.resolve(__dirname, 'app/styles'), loader: "style!css?modules&importLoaders=1&localIdentName=[name]__[local]--[hash:base64:5]!sass?sourceMap=true&sourceMapContents=true" }, { test: /\.scss$/, include: path.resolve(__dirname, 'app/styles'), loader: "style!css?sass?sourceMap=true&sourceMapContents=true" }
join(" ")or string template.
// join-react.jsxHello World
// stringTemp-react.jsxHello World
So, if we use multiple classes to define styles, we usually have some logical judgments. It will be a lot more troublesome to write at this time.
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 types classNames('foo', { bar: true, duck: false }, 'baz', { quux: true }); // => 'foo bar baz quux' // other falsy values are just ignored classNames(null, false, 'bar', undefined, 0, 1, { baz: null }, ''); // => 'bar 1'
styles.xxxevery time, which is also very troublesome.
react-css was mentioned in "In-depth React Technology Stack" -moduleslibrary to reduce code writing. Interested students can study it.
css video tutorial"