共计 1098 个字符，预计需要花费 3 分钟才能阅读完成。
参考文章
款式模块化计划
webpack 打包款式介绍
postcss 插件实例
预处理语言
less/sass/xxx
- css 语法自身不提供编程语言很多个性，个别满足我的项目要求得应用预处理语言，把握在我的项目中理论罕用的。
1.1. 变量，嵌套，mixin 次要是解决复用和模块化问题，须要无意识去保护 css 模块的拓展性
1.2. less-loader，css-loader，style-loader 在古代脚手架都是主动反对，要理解各 loader 的作用
1.3. postcss 它负责把 CSS 代码解析成形象语法树结构（Abstract Syntax Tree，AST），再交由插件来进行解决 (解决特定场景的需要能够自定义插件)
1.4. 能够看到具体 DSL 的语言都存在编译或者生成 AST 的过程，都离不开运行时或者编译时的话题
- css 常见模块化计划
2.1. css 命名提供命名空间（BEM 等），手动约定存在局限性
2.2. css Modules: 借助构建工具编译生成惟一的 hash，不会全局抵触
2.3. css-in-js：对于组件化复用是劣势，然而目前没有支流计划
2.4. 组件款式批改：以业务批改组件库为例（组件库个别采纳 BEM 规定），最初编译的款式文件找到具体类名笼罩即可；相似的父子组件款式批改不采纳 scoped 代码的可读性更好
- 我的项目款式打包计划
3.1 对于 spa 我的项目，款式打包后果古代脚手架个别有最佳实际，在浏览器查看动态资源有 app[hash].css/chunk-vendor.css/module.css 等，个别在发展性能治理和优化场景会针对性解决
3.2 css 文件自身没有模块化，后加载的笼罩之前的类名
3.3 post-css 解决一些 css 的兼容和插件问题
业务场景
- 组件库款式计划
1.1 组件库思考到款式的模块化和可拓展性个别围绕 BEM 设计款式，组件自身和款式资源都是分包模块化的
1.2 款式自身作为子包，有大量的款式变量和模块化例子 - 我的项目款式计划
2.1 我的项目款式设计思考这几点，组件自身款式；全局可复用款式（变量，模块，第三方组件）
2.2 其中组件款式反复的能够模块化，提供变量能够做主题切换
2.3 微利用款式计划（跟组件相似不赘述）
动画计划
- 原生动画
1.1 全局提供款式公共类
1.2 框架自带虚构组件 - 应用第三方库
总结
- css 自身不好把握，然而个别业务场景不会太简单，遇到组件库设计款式计划曾经是绝对深水区了
- precss/css/postcss 各种 DSL 和插件，都是相似解决编译时和运行时的问题，跟跨端框架遇到问题思维类似
- 构建工具提供成熟的 loader 和打包计划，在遇到性能优化时针对性解决，总体来说 css 的边界效应不显著，想做好有难度
正文完
