共计 3207 个字符，预计需要花费 9 分钟才能阅读完成。
1 引言
「可视化搭建零碎」——从设计到架构，摸索前端的畛域和意义 这篇文章次要剖析了现阶段可视化搭建的几种表现形式和实现原理，并重点介绍了基于富文本的可视化搭建思路，让人耳目一新。
基于富文本的可视化搭建看似很新鲜，但其实早就被宽泛应用了，任何一个富文本编辑器简直都有插入表格性能，这就是一个典型插入自定义组件的场景。
应用过 语雀 的同学应该晓得，这个产品的富文本编辑器能够插入各种各样自定义区块，是“最像搭建”的富文本编辑器。
那么积木式搭建和富文本搭建存在哪些差别，除了富文本更偏向于记录动态内容外，还有哪些差别，两者是否能够联合？本文将围绕这两点进行探讨。
2 精读
还是先顺着原文谈谈对可视化搭建的了解：
可视化搭建是通过可视化形式代替开发。 前端代码开发次要围绕的是 html + js + css，那么无论是 markdown 语法，还是创立另一套模版语言亦或 JSON 形成的 DSL， 都是用一种 dsl + 组件 + css 的形式代替 html + js + css，可视化搭建则更进一步，用 ui 代替了 dsl + 组件， 即精简为 ui 操作 + css。
能够看到，这种转换的推演过程存在肯定瑕疵，因为每次转换都有局部损耗：
用 dsl + 组件 代替 html + js。
如果 dsl 拓展得足够好，实践上能够达到 html 的程度，尤其在垂直业务场景是不须要那么多非凡 html 标签的。
但用组件代替 js 就有点奇怪了，首先并不是所有 js 逻辑都积淀在组件里，肯定有组件间的联动逻辑是无奈通过一个组件 js 实现的，另一方面如果将 js 逻辑寄托在组件代码里，实质上是没有提效的，用源码开发我的项目与开发搭建平台的组件都是 pro code，更极其一点来说，无论是组件间联动还是整个利用都能够用一个组件来写，那搭建平台就无事可做了，这个组件也成了整个利用，game over。
为了补救这块缺憾，低代码能力的呼声越来越高，而低代码能力的外围在于设计是否正当，比方裸露哪些 API 能够笼罩大部分需要？写多少代码适合，如何以最小 API 透出最大补救组件间缺失的 js 能力？目前来看，以状态数据驱动的低代码是绝对优雅的。
用 ui 操作 代替 dsl + 组件。
UI 操作并不是规范的，相比间接操作模版或者 JSON DSL，UI 化后就仁者见仁智者见智了，但 UI 化带来的效率晋升是微小的，因为所见即所得是生产力的源泉，从直观的 UI 布局来看，就比保护代码更轻松。但 UI 化也存在两个问题，一个是可能有人感觉不如 markdown 效率高，另一个是性能有失落。
对于第一点 UI 操作效率不如 markdown 高，可能很多程序员都崇尚用 markdown 保护文档而不是富文本，起因是感觉程序员保护代码的效率反而比所见即所得高，但那可能是错觉，起因是还没有遇到好用的富文本编辑器，体验过语雀富文本编辑器后，置信大部分程序员都不会再想回头写 markdown。当然语雀富文本战败 markdown 的起因有很多，我感觉次要两点是排汇并兼容了 markdown 操作习惯，与反对了更多仅 UI 能做到的拓展能力，对 markdown 造成降维打击。
第二点性能失落很好了解，markdown 有一套规范语法和解析器能够验证，但 UI 操作并没有标准化，也没有独立验证零碎，如果无奈回退到源码模式，UI 没有实现的性能就做不到。
回到富文本搭建上，其实富文本搭建和一般网页构建并没有本质区别。html 是超文本标记语言，富文本是跨平台文档格局，从逻辑上这两个格局是能够互转的，只有富文本规定作出足够多的拓展，就能够大抵笼罩 html 的能力。
但富文本搭建有着显著的特色，就是光标。
积木式搭建和富文本搭建的区别
富文本以文本为核心，因而编辑文字的光标会常驻，编辑的外围逻辑是排版文字，并思考如何在文字四周增加一些自定义区块。
有了光标后，圈选也十分重要，因为大家编辑文字时有一种很天然的想法是，任何文字圈选后复制，能够粘贴到任何中央，那么所有插入到富文本中的自定义组件也要反对被圈选，被复制。
实际上富文本内插入自定义区块也能够转换为积木式搭建计划解决，比方上面的场景：
文本 A
图表 B
文本 C咱们在文本 A 与 文本 C 之间插入图表 B，也能够了解为拖拽了三个组件：文本组件 A + 图表组件 B + 文本组件 C，而后别离编辑这三个组件，微调款式后能够达到与富文本一样的编辑成果，甚至加上自在布局后，在布局能力上会超过富文本。
尽管性能层面上富文本略有输给积木式搭建，但富文本在编辑体验上是胜出的，对于文字较多的场景，咱们还是会抉择富文本形式编辑而不是积木式搭建拖拽 N 个文本组件。
所以微软 OneNote 也汲取了这个教训，毕竟笔记本次要还是记录文字，因而还是采纳富文本的编辑模式，但创造性的退出了一个个独立区块，点击任何区域都会发明一个区块，整个文档能够由一个区块形成，也能够是多个区块组合而成，这样对于连贯性的文字场景能够采纳一个富文本区块，对于自定义区块较多，比方大部分是图片和表格的，还能够回到积木式搭建的体验。因为 OneNote 采纳相对定位模仿流式布局的思路，当区块重叠时还能够主动挤压底部区块，因而多区块模式下编辑体验还是绝对顺畅的。
能够看进去这是一种联合的尝试，从前端角度来看，富文本实质上是对一个 div 进行 contenteditable 申明，那么一个利用能够整体是 contenteditable 的，也能够部分几个区块是，这种代码层面的自由度体现在搭建上就是积木式搭建能够与富文本搭建自在联合。
积木式搭建与富文本搭建如何联合
对于积木式搭建来说，富文本只是其中一个组件，在不思考有富文本组件时是齐全没有富文本能力的。比方一个搭建平台只提供了几个图表和根底控件，你是不可能在其根底上应用富文本能力的，甚至连写动态文本都做不到。
所以富文本只是搭建中一个组件，就像 contenteditable 也只能依附于一个标签，整个网页还是由标签组成的。但对于一个提供了富文本组件的积木式搭建零碎来说，文字与控件混排又是一个痛点，毕竟要以一个个区块组件的形式去拖拽文本节点，老本比富文本模式大得多。
所以现实状况是富文本与整个搭建零碎应用同一套 DSL 形容构造，富文本只是在布局上有所简化，简化为简略的平铺模式即可，但因为 DSL 形容买通，富文本也能够形容应用搭建提供的任意组件嵌套在内，所以只有用户违心，能够将富文本组件拉到最大，整个页面都基于富文本模式去搭建，这就变成了富文本搭建，也能够将富文本放大，将一般控件以积木形式拖拽到画布中，走积木式搭建路线。
用代码形式形容积木式搭建：
<bar-chart /><div> <p>header</p> <line-chart /> <p>footer</p></div> 上述模式须要拖拽 bar-chart、div、p、line-chart、p 共 5 个组件。富文本模式则相似上面的构造：
<bar-chart /><div contenteditable> <p>header</p> <line-chart /> <p>footer</p></div> 只有拖拽 bar-chart、div 两个组件即可，div 外部的文字通过光标输出，line-chart 通过富文本某个按钮或者键盘快捷键增加。
能够看到尽管操作形式不同，但实质上形容协定并没有本质区别，咱们实践上能够将任何容器标签切换为富文本模式。
3 总结
富文本是一种重要的交互模式，能够基于富文本模式做搭建，也能够在搭建零碎中嵌入富文本组件，甚至还能够谋求搭建与富文本的联合。
富文本组件既能够是搭建零碎中一个组件，又能够在外部承载搭建零碎的所有组件，做到这一步才算是真正施展出富文本的后劲。
探讨地址是：精读《可视化搭建思考 – 富文本搭建》· Issue #262 · dt-fe/weekly
如果你想参加探讨，请 点击这里，每周都有新的主题，周末或周一公布。前端精读 – 帮你筛选靠谱的内容。
关注 前端精读微信公众号
版权申明：自在转载 - 非商用 - 非衍生 - 放弃署名（创意共享 3.0 许可证）
