精读《可视化搭建思考 - 富文本搭建》
ascoders opened this issue · 4 comments
由于笔者一直在数据中台做搭建，所以总会看看业界搭建理解新文章，本周就读 「可视化搭建系统」——从设计到架构，探索前端的领域和意义 这篇吧，基于富文本思路做搭建，有一定新意，我会把思考总结成篇。
对于第一点 UI 操作效率不如 markdown 高，可能很多程序员都崇尚用 markdown 维护文档而不是富文本，原因是觉得程序员维护代码的效率反而比所见即所得高，但那可能是错觉，原因是还没有遇到好用的富文本编辑器，体验过语雀富文本编辑器后，相信大部分程序员都不会再想回头写 markdown。当然语雀富文本战胜 markdown 的原因有很多，我觉得主要两点是吸收并兼容了 markdown 操作习惯，与支持了更多仅 UI 能做到的拓展能力，对 markdown 形成降维打击。
关于这一点我并不是很认同，包括 Notion、语雀、纯 Markdown（Typora、VS Code）工具都有使用过。我并没有感觉到语雀比其他的形式组织起来更让人舒适。富文本适应的场景是写产品文档，对结构化信息要求低，对操作人员对代码的要求低，对插入多种类型的块要求高，这些场景下是很合适的。但涉及到项目自身代码的文档，个人知识的组织，富文本并不是一个灵丹妙药。
wordpress 的 gutenberg 也是把面向流的文本编辑，改成了面向区块了。这个看起来是富文本编辑器的扩圈之路。“电子纸” 这个隐喻是个挺好的东西。能不能把工具做成纸张那样，感觉不到存在呢?
wordpress 的 gutenberg 也是把面向流的文本编辑，改成了面向区块了。这个看起来是富文本编辑器的扩圈之路。“电子纸” 这个隐喻是个挺好的东西。能不能把工具做成纸张那样，感觉不到存在呢?
纸张感觉不到存在的前提是不施加复杂需求，只写字。如果你想画表格，一样会遇到困难。我感觉维持一定复杂性是不可避免的，即使复杂如 word 面对一些不常见的排版需求都会感到使用很不舒服。
只要引擎把数据流和渲染器解耦，理论上可以在任何可以呈现 ui 的地方渲染 dsl，不影响联动取数等等。富文本只是其中一种场景了。我倒觉得富文本的 dsl 和积木搭建的 dsl 不用打通，在富文本组件插入区块的地方有一个映射关系告诉富文本我需要从外部数据流中拿一个容器组件，容器组件内部的逻辑又可以由外部数据流接管了。包括渲染 children、拖拽。