精讀《可視化搭建思考 - 富文本搭建》

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