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 許可證）