如何为大型项目规划可扩展的 CSS？

在参与过几个大型项目之后，我开始对如何在多模块单页应用中实现 CSS 有了一定的看法。以下是一些我对此主题的思考和疑问。

前言

我特别受到hoangbkit 和 Rachel Andrew 的CSS 网格作品“你认为你知道 CSS”系列的启发

0. 定义最佳（和非最佳）实践

从全公司范围来看，这一步是最简单的。
不良做法可以在代码审查期间剔除，并最终解决。

我在一篇旧帖子中讨论并学习了一些最佳/不太好的做法

正式版 CSS 应该是什么样子？分享你的布局到网页的工作流程

Jen Chan ・ 19年1月10日

#讨论 #初学者 #css #sass

1. 预处理器的选择

通常这由技术主管决定，或者 JS 框架的命令行版本可能自带预处理器。我相信在使用这些预处理器时，应该充分利用它们提供的一切功能。

萨斯

PostCSS

样式化组件

与以下选择相关的是，公司或产品是否已经拥有设计系统或样式指南。如果有的话，合理的方法是更深入地执行 CSS 模式。

后两者也支持我从未尝试过的“JS 中的 CSS”方法，但似乎遵循“编写一次并重复使用组件”的思路，任何更常见的样式都可以轻松地从全局样式资源中导入。

2. CSS 方法/模式

以下很多理念彼此重叠。而它们之间的差异，也让我看到了在不同发展阶段的诸多优势。

边界元法

BEM，即块元素修饰符样式，需要慢慢适应。我刚开始接触开发的时候，似乎有很多人喜欢它。我觉得在很多框架里也看到过它（比如 Ng-Material，咳咳！）

虽然这种语法比原子模式更具语义，并尝试将作用域构建到选择器命名中，但如果我们使用提供嵌套作用域的 SASS 或 JS 框架，则无需这样做。其实现结果非常冗长。

示例：菜单栏

1. 默认组件样式进入名为.navigation
2. 编写另一个选择器来设置.navigation__li导航下所有列表项的样式
3. 然后使用.navigation__li--active指示列表项的活动状态

...并且必须声明上述所有样式只是为了表明一个元素是活动的navigation navigation_li navigation_li--active

现在，针对与元素相关的所有不同状态或需求进行冲洗并重复。

Atomic（也称为“函数式 CSS”）

Atomic是一个库，也是一种使用别名样式单元来动态实现类（如内联样式）的精神。

虽然这种方法非常适合快速制作原型设计，但我并不喜欢这种方法。

例如：带有容器的标题。每当我想在特定元素上添加 1px 边框时，我
都会记得使用。然后，如果该元素包含文本，我会使用来表示它的行高为 1.5em，字体大小为 3em。BdLh(1.5)f1

现在对于每个标题我都会得到：
<div class ="f1 Bd Lh(1.5)"></div>

它难以辨认，如果我有很多页，标题又很多，样式又多，那就真的烦人了。亚当·萧华的长篇大论就在这里。

然而，tachyons是一个原子原则库，它有足够少的类来实现代码的快速原型设计，当我需要快速登陆页面时，它就是我的首选。

DRY（不要重复自己）

在《可维护的 CSS》中，Adam Silver 将 DRY 分组定义为将语义类应用于可重用样式分组的策略。

我喜欢更进一步，将组件编码为 Sass mixin，以便在应用程序中需要复用时将其引入/重新应用。（相反，有些人可能不喜欢这个想法，因为它每次都需要解析导入的权威样式文件）

斯玛特-麦克斯

这涉及根据基本样式、模块、组件和状态分离样式，此外还为经常耦合的样式属性创建类。

它与可维护 CSS 非常相似，但包含更多关于嵌套和特殊性的意见。

海外合作与交流服务

根据其构思者 Nicole Sullivan 的说法，OOCSS 的宗旨是：

• 分离结构和皮肤
• 单独的容器和内容

在谷歌搜索之前，我甚至不知道 OOCSS 为我今天在模块化 CSS 方面的努力提供了许多信息：按组件编写样式。

3 CSS 样式指南？

这是否可以为时间紧迫的开发人员提供更多阅读材料，或者更好地加强设计一致性？

我认为这取决于团队。如果公司注重设计且组织有序，这可能会非常有帮助。然而，当我第一次尝试提升我的 JS 水平以适应行业需求时，Airbnb 的 ES6 编写风格指南让我望而生畏。

4. 热门库

我更愿意引导你阅读 Huang b Kit 撰写的这篇关于流行库的精彩文章。

5. 网格和响应式网格

如果您收到了设计，您的团队可能需要就网格列和断点达成一致，否则在合并分支时事情就会变得危险。

典型的设计网格为 12 或 10 列，在小型设备上可缩小至 1-4 列。如果 CSS 库利用 flexbox 或 flexgrid，则可以无需媒体查询即可实现响应式布局。

6. 组织开发组件

我对这部分并不熟悉，但我听说过很多关于在交给其他开发人员之前使用Storybook单独测试和开发组件的好事。

问题

在理想世界中，我希望样式只需编写一次，就可以在任何地方重复使用。然后我意识到，我设想的布局方式与其他开发人员的实际工作方式之间存在一些冲突。这需要大量的沟通和协商。

我想听听你是如何在你的团队或公司中制定 CSS 策略的。你认为对于小型或大型团队来说，什么策略最有效？你发现在开发之前和开发过程中，哪些事情需要达成一致？你用 JS 编写 CSS 的经验是什么？你喜欢用 Sass 和 Less 的替代品吗？