谈真正分离代码与设计

[tuoxiansp]

告别界面代码 - 真正分离代码与设计

这篇文章并不是谈如何分离界面代码和逻辑代码，而是彻彻底底告别使用代码书写界面的方式 — 设计师交付界面给工程师写代码逻辑。工程师不写哪怕一行界面代码，完全不关注界面绘制。

如何做？

首先，组件化是一切的基础。

然后在组件化的基础上，让设计师能够使用组件拼装出界面。

设计师最终交付的其实就是一段界面数据。这段数据可以轻易在代码里被实例化为界面，并展示在用户眼前。

只不过我们最好是对工程师隐藏这一细节，对工程师来说，他就是在代码里引入了一个界面，并能够通过 id 获取某一个组件句柄，然后进一步写代码给组件赋值，把真实数据交由组件渲染成界面并最终展示给用户。

---

说到这里，你一定发现了：上述的思路，一点都不新鲜。

我自己也有见过和曾经用过。

这些已有的方案的具体细节我也忘记了。同时我很懒，不太情愿去翻已有的方案做对比。把我的方案说出来就好。

我的方案

要实现告别界面代码（广义上工程师不再关注界面代码），我认为很关键的一点（也是至今未见实现的）就是界面要被彻底数据化，不带任何逻辑。

正因为不带任何逻辑，才能被设计师制作并交付。

为了让工程师不写界面代码，设计师必须交付完整的界面，不遗漏任何需要工程师后续写界面代码填补的交互细节。

为了实现这一点，我们需要解决一个可视化界面编辑中极为常见的问题：

界面通常是有逻辑的。我们很难摆脱逻辑来描述一个界面。

举个例子：我有⚡️和🌧两个基础的组件，现在需要根据今天的天气，来决定展示⚡️还是🌧。

可能有人会粗略一想：简单啊！写个天气组件把这俩组件集成一下不就行了。

isLightening => isLightening ? ⚡️：🌧

仔细想想，会发现事情并没有那么简单。

这种带一丢丢逻辑的组件，给我一天，能想出一万个。比如根据雷电天气的强度，我想展示 ⚡️、⚡️⚡️ 和 ⚡️⚡️⚡️ 怎么办？

我们不可能事先准备好所有可能用到的组件，只能给出最最基础的展示元素，交给设计师们自由发挥。
那么问题还在这里：

类似 isLightening => isLightening ? ⚡️：🌧 这样的组件，要如何在设计中表达呢？

我给出的办法是：使用集合。

设计师需列出组件的所有状态，所有这些状态的集合，便构成了这个组件。

于是，上述例子我们可以给出的解便是：

[⚡️, 🌧] 和 [⚡️, ⚡️⚡️, ⚡️⚡️⚡️]

而把这样的数据导入到程序里，我们可以轻松地使用代码来控制最终的展示。

伪代码如下

() => {
    const isLightening = getIsLightening()
    return isLighting ? 0 : 1  //0 和 1 对应集合中的 [⚡️, 🌧]
}

命名

最后，我把按照上述方案，以所有状态的集合来描述界面的方法称为界面的有限表述。

相对应的，只按照当前显示的内容描述界面的方法，称之为界面的单一表述。