避坑指南：如何在基于组件的应用中使用 CSS 架构

CSS 架构是一个常被开发人员忽视的复杂问题。为简化开发人员的工作，可对每个组件封装（Encapsulate）CSS，由此避免许多 CSS 相关的坑，但这种“变通”做法是以降低可重用性和可扩展性为代价的。

一旦开发人员定义了一个 CSS 类，该类将自动作用于整个应用的范围之内，会修改所有相关元素及其子元素。对于那些结果可预测的简单应用，这种做法非常适用。但是随着应用和团队规模的增长，该做法立刻会出现问题，将导致一些不可预料的问题。

上述问题的最初解决方案是 BEM（Block Element Modifier） 规范。作为一种方法和命名规范，BEM 为开发人员清晰标识了每个类的行为，有助于避免产生冲突。例如，form__submit–disabled 指示开发人员正在表单内设置一个提交按钮的状态为禁用。

但作为命名规范，难以强制开发人员去遵守 BEM。此后，JavaScript 推出了一些更易于实现的解决方案，包括 CSS Modules 和 Styled Components ，并得到了开发人员的采纳。这些方法采用不同的技术路线，在单个组件中添加 CSS，同样解决了许多 BEM 所针对的问题。

解决组件化设计中缺少跨应用架构的问题，涉及三个独立的方面：

1. UI：包括主题和一般应用行为。
2. 布局组件（Layout Components）：也常被称为“容器”或“智能组件”。布局组件确定指定组件在特定场景中的行为，通常是不可重用的。
3. 展示组件（Presentational Components）：是增强应用功能的可重用代码片段。为增加展示组件的多样性，其中应尽可能避免包含逻辑。

UI

UI 会定义在作用于整个应用的全局 CSS 文件中。主要包括两个方面：

1. 常量类（Constant）：开发人员过去会使用所有主流浏览器都支持的 自定义 CSS 属性 ，最近可使用 SCSS 或 LESS 变量，

CSS 自定义属性主要有两方面优点。第一，可在运行时做修改。对于转换主题或支持夜景模式，这是一种很好的解决方案。第二，支持在布局组件中修改，开发人员更易于实现小范围内的设计调整。

1. UI 状态（State）定义通常可分解为三方面：
   1. 修饰符（Modifier）状态：确定各元素的规格（大 / 小）、设计（主 / 次）等的变化。
   2. 行为（Behavioral）状态：包括整个应用范围的状态。例如，在线 / 离线、正在加载等。
   3. 伪（Pseudo）状态：启用 / 禁用等临时状态，以及:hover 和:focus 等 CSS 状态。

布局组件

布局组件会按指定方式在页面上组织可重用的组件。布局组件的功能可分解为两个方面，一是以设定属性和设计对可重用组件做初始化，二是使用 CSS Grid、Flexbox 等功能将其所控制区域设定为特定的布局。

可重用组件

可重用组件中几乎不包含逻辑。它们从布局组件接收数据，当布局组件执行操作时会触发相关事件（或回调）。

为确保组件的可重用性，开发人员应尽量避免在组件中添加逻辑和设计。具体而言，通常应避免添加显示、宽度、留白等属性。

这并非易事，因为可重用组件常常需要处理比其最初设计更多的场景，例如，支持多行文本的按钮，支持显示更多文本内容的标题等。但可重用组件确保了组件真正的可重用性，无需在应用下次使用时进行重写。

原文链接：

CSS Architecture for Component-Based Applications