Slate文档编辑器-WrapNode数据结构与操作变换
Slate文档编辑器-WrapNode数据结构与操作变换
在之前我们聊到了一些关于slate富文本引擎的基本概念，并且对基于slate实现文档编辑器的一些插件化能力设计、类型拓展、具体方案等作了探讨，那么接下来我们更专注于文档编辑器的细节，由浅入深聊聊文档编辑器的相关能力设计。
关于slate文档编辑器项目的相关文章:
- 基于Slate构建文档编辑器
- Slate文档编辑器-WrapNode数据结构与操作变换
- Slate文档编辑器-TS类型扩展与节点类型检查
- Slate文档编辑器-Decorator装饰器渲染调度
- Slate文档编辑器-Node节点与Path路径映射
Normalize
在slate中数据结构的规整是比较麻烦的事情，特别是对于需要嵌套的结构来说，例如在本项目中存在的Quote和List，那么在规整数据结构的时候就有着多种方案，同样以这两组数据结构为例，每个Wrap必须有相应的Pair的结构嵌套，那么对于数据结构就有如下的方案。实际上我觉得对于这类问题是很难解决的，嵌套的数据结构对于增删改查都没有那么高效，因此在缺乏最佳实践相关的输入情况下，也只能不断摸索。
首先是复用当前的块结构，也就是说Quote Key和List Key都是平级的，同样的其Pair Key也都复用起来，这样的好处是不会出现太多的层级嵌套关系，对于内容的查找和相关处理会简单很多。但是同样也会出现问题，如果在Quote和List不配齐的情况下，也就是说其并不是完全等同关系的情况下，就会需要存在Pair不对应Wrap的情况，此时就很难保证Normalize，因为我们是需要可预测的结构。
{
"quote-wrap": true,
"list-wrap": true,
children: [
{ "quote-pair": true, "list-pair": 1, children: [/* ... */] },
{ "quote-pair": true, "list-pair": 2, children: [/* ... */] },
{ "quote-pair": true, children: [/* ... */] },
{ "quote-pair": true, "list-pair": 1, children: [/* ... */] },
{ "quote-pair": true, "list-pair": 2, children: [/* ... */] },
]
}
那么如果我们不对内容做很复杂的控制，在slate中使用默认行为进行处理，那么其数据结构表达会出现如下的情况，在这种情况下数据结构是可预测的，那么Normalize就不成问题，而且由于这是其默认行为，不会有太多的操作数据处理需要关注。但是问题也比较明显，这种情况下数据虽然是可预测的，但是处理起来特别麻烦，当我们维护对应关系时，必须要递归处理所有子节点，在特别多层次的嵌套情况下，这个计算量就颇显复杂了，如果在支持表格等结构的情况下，就变得更加难以控制。
{
"quote-wrap": true,
children: [
{
"list-wrap": true,
children: [
{ "quote-pair": true, "list-pair": 1, children: [/* ... */] },
{ "quote-pair": true, "list-pair": 2, children: [/* ... */] },
]
},
{ "quote-pair": true, children: [/* ... */] },
{ "quote-pair": true, children: [/* ... */] },
]
}
那么这个数据结构实际上也并不是很完善，其最大的问题是wrap - pair的间隔太大，这样的处理方式就会出现比较多的边界问题，举个比较极端的例子，假设我们最外层存在引用块，在引用块中又嵌套了表格，表格中又嵌套了高亮块，高亮块中又嵌套了引用块，这种情况下我们的wrap需要传递N多层才能匹配到pair，这种情况下影响最大的就是Normalize，我们需要有非常深层次的DFS处理才行，处理起来不仅需要耗费性能深度遍历，还容易由于处理不好造成很多问题。
那么在这种情况下，我们可以尽可能简化层级的嵌套，也就是说我们需要避免wrap - pair的间隔问题，那么很明显我们直接严格规定wrap的所有children必须是pair，在这种情况下我们做Normalize就简单了很多，只需要在wrap的情况下遍历其子节点以及在pair的情况下检查其父节点即可。当然这种方案也不是没有缺点，这让我们对于数据的操作精确性有着更严格的要求，因为在这里我们不会走默认行为，而是全部需要自己控制，特别是所有的嵌套关系以及边界都需要严格定义，这对编辑器行为的设计也有更高的要求。
{
"quote-wrap": true,
children: [
{
"list-wrap": true,
"quote-pair": true,
children: [
{ "list-pair": 1, children: [/* ... */] },
{ "list-pair": 2, children: [/* ... */] },
{ "list-pair": 3, children: [/* ... */] },
]
},
{ "quote-pair": true, children: [/* ... */] },
{ "quote-pair": true, children: [/* ... */] },
{ "quote-pair": true, children: [/* ... */] },
]
}
那么为什么说数据结构会变得复杂了起来，就以上述的结构为例，假如我们将list-pair: 2这个节点解除了list-wrap节点的嵌套结构，那么我们就需要将节点变为如下的类型，我们可以发现这里的结构差别会比较大，除了除了将list-wrap分割成了两份之外，我们还需要处理其他list-pair的有序列表索引值更新，这里要做的操作就比较多了，因此我们如果想实现比较通用的Schema就需要更多的设计和规范。
而在这里最容易忽略的一点是，我们需要为原本的list-pair: 2这个节点加入"quote-pair": true，因为此时该行变成了quote-wrap的子元素，总结起来也就是我们需要将原本在list-wrap的属性再复制一份给到list-pair: 2中来保持正确的嵌套结构。那么为什么不是借助normalize来被动添加而是要主动复制呢，原因很简单，如果是quote-pair的话还好，如果是被动处理则直接设置为true就可以了，但是如果是list-pair来实现的话，我们无法得知这个值的数据结构应该是什么样子的，这个实现则只能归于插件的normalize来实现了。
{
"quote-wrap": true,
children: [
{
"list-wrap": true,
"quote-pair": true,
children: [
{ "list-pair": 1, children: [/* ... */] },
]
},
{ "quote-pair": true, children: [/* ... */] },
{
"list-wrap": true,
"quote-pair": true,
children: [
{ "list-pair": 1, children: [/* ... */] },
]
},
{ "quote-pair": true, children: [/* ... */] },
{ "quote-pair": true, children: [/* ... */] },
{ "quote-pair": true, children: [/* ... */] },
]
}
Transformers
前边也提到了，在嵌套的数据结构中是存在默认行为的，而在之前由于一直遵守着默认行为所以并没有发现太多的数据处理方面的问题，然而当将数据结构改变之后，就发现了很多时候数据结构并不那么容易控制。先前在处理SetBlock的时候通常我都会通过match参数匹配Block类型的节点，因为在默认行为的情况下这个处理通常不会出什么问题。
然而在变更数据结构的过程中，处理Normalize的时候就出现了问题，在块元素的匹配上其表现与预期的并不一致，这样就导致其处理的数据一直无法正常处理，Normalize也就无法完成直至抛出异常。在这里主要是其迭代顺序与我预期的不一致造成的问题，例如在DEMO页上执行[...Editor.nodes(editor, {at: [9, 1, 0] })]，其返回的结果是由顶Editor至底Node，当然这里还会包括范围内的所有Leaf节点相当于是Range。
[] Editor
[9] Wrap
[9, 1] List
[9, 1, 9] Line
[9, 1, 0] Text
实际上在这种情况下如果按照原本的Path.equals(path, at)是不会出现问题的，在这里就是之前太依赖其默认行为了，这也就导致了对于数据的精确性把控太差，我们对数据的处理应该是需要有可预期性的，而不是依赖默认行为。此外，slate的文档还是太过于简练了，很多细节都没有提及，在这种情况下还是需要去阅读源码才会对数据处理有更好的理解，例如在这里看源码让我了解到了每次做操作都会取Range所有符合条件的元素进行match，在一次调用中可能会发生多次Op调度。
此外，因为这次的处理主要是对于嵌套元素的支持，所以在这里还发现了unwrapNodes或者说相关数据处理的特性，当我调用unwrapNodes时仅at传入的值不一样，分别是A-[3, 1, 0]和B-[3, 1, 0, 0]，这里有一个关键点是在匹配的时候我们都是严格等于[3, 1, 0]，但是调用结果却是不一样的，在A中[3, 1, 0]所有元素都被unwrap了，而B中仅[3, 1, 0, 0]被unwrap了，在这里我们能够保证的是match结果是完全一致的，那么问题就出在了at上。此时如果不理解slate数据操作的模型的话，就必须要去看源码了，在读源码的时候我们可以发现其会存在Range.intersection帮我们缩小了范围，所以在这里at的值就会影响到最终的结果。
unwrapNodes(editor, { match: (_, p) => Path.equals(p, [3, 1, 0]), at: [3, 1, 0] }); // A
unwrapNodes(editor, { match: (_, p) => Path.equals(p, [3, 1, 0]), at: [3, 1, 0, 0] }); // B
上边这个问题也就意味着我们所有的数据都不应该乱传，我们应该非常明确地知道我们要操作的数据及其结构。其实前边还提到一个问题，就是多级嵌套的情况很难处理，这其中实际上涉及了一个编辑边界情况，使得数据的维护就变得复杂了起来。举个例子，加入此时我们有个表格嵌套了比较多的Cell，如果我们是多实例的Cell结构，此时我们筛选出Editor实例之后处理任何数据都不会影响其他的Editor实例，而如果我们此时是JSON嵌套表达的结构，我们就可能存在超过操作边界而影响到其他数据特别是父级数据结构的情况。所以我们对于边界条件的处理也必须要关注到，也就是前边提到的我们需要非常明确要处理的数据结构，明确划分操作节点与范围。
{
children: [
{
BLOCK_EDGE: true, // 块结构边界
children: [
{ children: [/* ... */] },
{ children: [/* ... */] },
]
},
{ children: [/* ... */] },
{ children: [/* ... */] },
]
}
此外，在线上已有页面中调试代码可能是个难题，特别是在editor并没有暴露给window的情况下，想要直接获得编辑器实例则需要在本地复现线上环境，在这种情况下我们可以借助React会将Fiber实际写在DOM节点的特性，通过DOM节点直接取得Editor实例，不过原生的slate使用了大量的WeakMap来存储数据，在这种情况下暂时没有很好的解决办法，除非editor实际引用了此类对象或者拥有其实例，否则就只能通过debug打断点，然后将对象在调试的过程中暂储为全局变量使用了。
const el = document.querySelector(`[data-slate-editor="true"]`);
const key = Object.keys(el).find(it => it.startsWith("__react"));
const editor = el[key].child.memoizedProps.node;
最后
在这里我们聊到了WrapNode数据结构与操作变换，主要是对于嵌套类型的数据结构需要关注的内容，而实际上节点的类型还可以分为很多种，我们在大范围上可以有BlockNode、TextBlockNode、TextNode，在BlockNode中我们又可以划分出BaseNode、WrapNode、PairNode、InlineBlockNode、VoidNode、InstanceNode等，因此文中叙述的内容还是属于比较基本的，在slate中还有很多额外的概念和操作需要关注，例如Range、Operation、Editor、Element、Path等。那么在后边的文章中我们就主要聊一聊在slate中Path的表达，以及在React中是如何控制其内容表达与正确维护Path路径与Element内容渲染的。
