乐趣区

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

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

  1. 我的项目款式打包计划
    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 的边界效应不显著,想做好有难度
退出移动版