控件即是块编辑器的「块」

近期时不时地会想「反混沌前端工程」当前比较重要且优先的两块事情：控件（UI 组件）体系 Petals 和通用块编辑器。

大部分人不会认为这两者之间有什么联系，然而在我眼中关系可大了去了——它们的「本质」可以近似看作是一个东西。

控件可以认为是当下 GUI 开发的重要基础设施和基本单元，而在块编辑器体系中则是「块」，理论上「块」就是控件，是被注入特殊状态的控件——好比一个被施了法术的人成为提线木偶一般。

那么，直觉告诉我 Petals 可以跟块编辑器打通，将更为抽象的「块」作为基础设施；这里的「块」不是块编辑器中的「块」，还是用「block」做区分吧。

回顾并总结这十多年的 GUI 开发经验来看，GUI 中最基本的元素就是占据整行的「block」和与文本类内容实际宽度相匹配的区域这两种，后者我就叫它「text」吧。

在网页开发中，前者叫「块级元素」，后者则叫「内联元素」或「行内元素」。

假设有分别代表平面中水平和垂直方向的 x、y 轴，再加上垂直于它们所构成平面（屏幕）的 z 轴，在元素的堆叠方式上也有两种：

1. 沿 y 轴从上往下堆叠，这时「block」如上面所说默认占据整行，与「block」重叠的元素可以视为是在其内部，就像中间挖了个槽；
2. 沿 z 轴自底向顶堆叠，这时「block」与「text」没太大分别，都是差不多的矩形，与它们重叠的元素就是像摞衣服一样一层压着一层。

第一种堆叠方式就是很常见的 GUI 渲染方式，也是块编辑器中的布局方式；第二种则多用于画布类可以自由排列组合的场景。

这两种方式并不是非此即彼，它们经常一起使用，只不过是以其中一种为主。

说了这么多，打通 Petals 与块编辑器的关键点就在于——

用「block」和「text」作为基本单元构建起 Petals 这个控件体系，并且它们的行为是可被注入的，为被外部「操控」留下口子：

interface IInjectableElement {}

// Block-level element
interface IBlock extends InjectableElement {}

// Inline-level element
interface IText extends InjectableElement {}

function createInjectableElement<E extends IInjectableElement = IInjectableElement>(): E {}

没被注入时，默认行为就跟常规控件一样；而被注入后，控件就成了提线木偶被外部库或框架所控制，比如变成了块编辑器中的「块」。

---

本文其他阅读地址：个人网站｜微信公众号