这是我建筑流体风格系列的一部分, 我写下设计决定、权衡和小惊喜。
我一直有的感觉是,组件框架的造型往往要求组件重新适应到旧的HTML + CSS模型中,而不是问组件是主要单元时CSS的构成应该是什么样子.
这不意味着摧毁CSS。
我喜欢CSS 而HTML + CSS模型在自己的世界中也有很多意义.
在该模型中,您会写出HTML,给出元素类名称,当嵌入部分需要造型时使用选择器.
这个模型有问题。
全球CSS可以泄露.
取名难取.
特殊性会变得痛苦 大样式表可能变得难以维护.
但基本的精神模型是容易理解的:给部分取出名字,然后取出命名部分的风格.
即使生态系统增加了SCSS,BEM,命名公约,CSS模块,以及其他工具,许多核心理念仍然很熟悉.
有标记。
诸有名相.
有选取者.
样式通过这些名称到达元素。
因为HTML和CSS是围绕着这种关系建立的。
然后组件会改变UI的形状.
组件更改“反应中的单元”和其他组件框架,我们通常不再将UI视为一个大的HTML文档。
我们认为: 这是一个巨大的改进。
一个组件拥有内部标记。
它接收道具。
其作作以子为相.
它隐藏了执行的细节。
可作打字.
可以通过工具来转化.
它可以成为设计系统的一部分.
但造型仍然必须回答一个熟悉的问题: 我该怎么处理里面的东西?
在HTML + CSS中,如果想给名片内的标题作样式,我可以写: 在一个组件世界中, 假设很多: 组件暴露出一个类 DOM 结构 保持相同的 CSS 被允许在外 CSS 系统内到达 并不孤立 类名 组件作者希望该部分 被定制 有时是好的。
我仍然在很多地方使用基于选择器的造型.
但组件边界会改变感觉.
组件拥有内部.
外部代码仍然想要定制.
这就是紧张。
我们处理的常用方法 随着时间的推移,前端代码 已经找到许多实用的方法来处理这一点。
一个常见的方法是更多的类道具: 这是明确和容易理解的。
但部分API开始围绕造型需求而增长.
每个公共部分都需要道具.
每个道具都需要一个名字.
每个名字都变成了合同 稍有条理的版本是每部分覆盖对象: 这给了消费者两个常见的逃生舱: 当他们已经拥有CSS的时候,当他们想要通过一个小的直接的覆盖时 这是方便的。
但每个公共部分仍成为合并点: 这不是奇怪的代码。
我经常写这种代码 这是实际可行的。
但是它显示了重复的形状:每个可样式的部分都需要一个名称,一个道具形状,和一个合并点.
变体是另一种常见途径:当设计案例已知时,变体是巨大的.
但当一个变体影响到许多内部时,组件开始携带一个小的样式矩阵:再次,没有错误.
有时候这是完全正确的选择。
CSS变量也有用: 它们是本地的,灵活的,它们与CSS的构思很好.
但该部分仍需要有意披露这些变量: 这是一个很好的工具,但它仍然是组件作者必须设计的公共外观。
所以我不认为这些办法是错误的。
它们是切合实际的,而且之所以存在,是因为问题确实存在。
对我来说有趣的是重复的形状: 外出风格想要到达有意义的组件部分,组件作者需要一个干净的方法来揭露这些部分而不泄露整个DOM.
这就是我想要Fluentic探索的问题。