关于css:样式工程化方案

参考文章

款式模块化计划
webpack 打包款式介绍
postcss 插件实例

预处理语言

less/sass/xxx

1. 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 的过程，都离不开运行时或者编译时的话题

2. css 常见模块化计划
   2.1. css 命名提供命名空间（BEM 等），手动约定存在局限性
   2.2. css Modules: 借助构建工具编译生成惟一的 hash，不会全局抵触
   2.3. css-in-js：对于组件化复用是劣势，然而目前没有支流计划
   2.4. 组件款式批改：以业务批改组件库为例（组件库个别采纳 BEM 规定），最初编译的款式文件找到具体类名笼罩即可；相似的父子组件款式批改不采纳 scoped 代码的可读性更好

3. 我的项目款式打包计划
   3.1 对于 spa 我的项目，款式打包后果古代脚手架个别有最佳实际，在浏览器查看动态资源有 app[hash].css/chunk-vendor.css/module.css 等，个别在发展性能治理和优化场景会针对性解决
   3.2 css 文件自身没有模块化，后加载的笼罩之前的类名
   3.3 post-css 解决一些 css 的兼容和插件问题

业务场景

1. 组件库款式计划
   1.1 组件库思考到款式的模块化和可拓展性个别围绕 BEM 设计款式，组件自身和款式资源都是分包模块化的
   1.2 款式自身作为子包，有大量的款式变量和模块化例子
2. 我的项目款式计划
   2.1 我的项目款式设计思考这几点，组件自身款式；全局可复用款式（变量，模块，第三方组件）
   2.2 其中组件款式反复的能够模块化，提供变量能够做主题切换
   2.3 微利用款式计划（跟组件相似不赘述）

动画计划

1. 原生动画
   1.1 全局提供款式公共类
   1.2 框架自带虚构组件
2. 应用第三方库

总结

1. css 自身不好把握，然而个别业务场景不会太简单，遇到组件库设计款式计划曾经是绝对深水区了
2. precss/css/postcss 各种 DSL 和插件，都是相似解决编译时和运行时的问题，跟跨端框架遇到问题思维类似
3. 构建工具提供成熟的 loader 和打包计划，在遇到性能优化时针对性解决，总体来说 css 的边界效应不显著，想做好有难度