Atomic Class 的设计初衷？

1、更好地帮助组件代码模块化

1.1、为实现自动化打基础：

为了设计工具的 Node-Tree 和组件 DSL、代码能够做到互相转换或映射变更，组件侧的视觉、逻辑、布局等都需要尽可能地结构化、模块化。

2019年时参加 QCon 当时 @asnowwolf 提出了逻辑抽离组件的一种方式 ui-model ，那么视觉是否也可以这样做到这样模块化管理呢？

https://github.com/design-to-release/atomic-class/issues/12 进行了更详细的阐述。

1.2、增强代码的可读性： 几乎很多鼎鼎大名的组件库，其组件实现的源码可读性都很差，越完备的组件库提供了越多的功能和样式可选项，再加上接口-默认样式实现，样式的运算，视觉相关部分阅读起来都令人叹为观止。

比如 ant-design/button 、 semi-design/avatar 混在script 中的样式运算；smelte 中为了支持更多的ui可能性，提供了较多的 props，但这些 props 的入参和 default class、event 产生的 class 如何 merge 并生效，俨然成为一门科学。

2、解决原子样式的实践困扰：

实践 TailwindCSS 编写组件库带来最多的问题就是样式打散后聚合阶段的问题，比如以何种粒度或逻辑聚合？聚合和聚合之间如果产生优先级冲突，如何解决？

如文本的颜色为 text-black hover:text-orange，现希望暗黑模式下文字色反白，所以添加 dark:text-white。鼠标hover后， dark:text-white 与 hover:text-orange 优先级冲突，后者可能失效，需要再度补充 dark:hover:text-orange。如果还有新的变体加入，几乎所有的原子样式都要指数级组合并描述一遍，而如果用户一不小心引入一个 custom selector ，可能会迷失在变体森林。

而对于这个节点在一个特定的状态下，token 如何生效成为难题。所以开发 Atomic Class 的初衷是设计师和研发如果能很清楚地描述需要的效果，那么直接表达出来即可。

我们暂且称之这种高度耦合业务实现的组合形式为逻辑性聚合，对比场景聚合（Dark、Hover）、功能性聚合（Button、Text），他们之间的是存在一定区别的：

场景聚合（设计语言构建阶段）：
- 抽象出一些场景，对于一个样式属性，可能存在2种或以上值对应不同场景（如明暗夜色、媒体查询、设备）；在设计语言侧仍然体现为一种聚合token，而实现阶段是做一种值选择
- 实现方式一：变体，采取的方法是分别描述，但缺点是
- 需要提前定制变体前缀，新增前缀产出样式会成倍
- 如 hover:text-active hover:bg-red，脚本无法轻易靠添加.hover 或其他简易方法使两者生效，故而需要css运算
- 实现方式二：通过切换容器场景或者修改var，影响 token-var 的映射结果，但这样做的前提是设计语言里的 token 对应多个值（text-base-color: #000/#fff/#333）
功能性聚合（组件库建设阶段）：
- 一般是出于对某种功能元素样式的复用目的而形成的聚合，如Button { @apply text-xs, bg-gray, text-white}
- 是提前梳理实现的
逻辑性聚合（具体业务编码阶段）：
- 一般是出于动态元素的状态切换，而产生的聚合

更多可以阅读 https://github.com/design-to-release/atomic-class/issues/11

3、样式的可扩展性：

如上述基于 Atomic-Class 的实现组件，可以做到编译后剥离样式，同时生成 Node-Sate-Token Tree，结合设计工具、可视化工具、VS Code扩展，可以再度生成新的样式，并通过 AOT 和 JIT 方式生效，使得组件样式可以自由扩展。

同时，对于一般使用者，如果有不复杂的组件样式定制化需求，可以直接通过 CSS代码补全方式实现，而不用查阅 API 或烦恼组件开发者没有提供相应的样式修改接口，如下：

以下是可能的实现子组件样式配置的 Spec 和 Feature ，欢迎讨论：

e.g. 1： Custom Styles

<script>
   import { Button } from "@atomic-class/playground/svelte-components";
</script>
<Button id="btn"></Button>
<style>
#btn .icon { // 此处有代码补全帮助 selector和默认内容填充
 .disabled { @apply text-red bg-gray-100; }
  .active { @apply text-orange; }
}
</style>

e.g. 2： Custom Inlined Styles

<script>
   import { Button } from "@atomic-class/playground/svelte-components";
</script>
<Button ac-style={icon: {disabled: "text-red bg-gray-100",  active: "text-orange"}}></Button>

e.g. 3: Custom Inlined Classes

<Button ac-class="icon-disabled-text-red icon-disabled-bg-gray-100 icon-active-text-orange"></Button>

e.g. 4：Custom Styles With Button.prefab.js

import { Button, Styles } from "@atomic-class/playground/svelte-components";
Styles.icon.disabled = "text-red bg-gray-100";
export  { Button, Styles }

<script>
   import { OldButton } from "@atomic-class/playground/svelte-components";
   import { NewButton } from "./Button.prefab";
</script>
<OldButton ></OldButton>
<NewButton ></NewButton>

e.g. 5：Custom Styles in Button.prefab.json

{
  "compontents": "@atomic-class/playground/svelte-components",
  "version": "0.1.0",
  "styles": { "icon": { "disabled" : "text-red bg-gray-100"} }
}

design-to-release / atomic-class

Atomic Class 的设计初衷？ #13