Logic Flow專注流程圖前端可視化解決方案

LogicFlow 是由滴滴體驗(yàn)平臺(tái)技術(shù)研發(fā)的一款解決流程可視化的前端框架，提供了一系列流程圖交互、編輯所必需的功能和簡(jiǎn)單靈活的節(jié)點(diǎn)自定義、插件等拓展機(jī)制，方便我們快速在業(yè)務(wù)系統(tǒng)內(nèi)滿足類流程圖的需求。目前，LogicFlow 已經(jīng)支持了客服業(yè)務(wù)下 IVR、工單流轉(zhuǎn)、智能機(jī)器人等多個(gè)運(yùn)營(yíng)系統(tǒng)，在各系統(tǒng)不同的流程配置需求中得到了驗(yàn)證。

#為何自研 LogicFlow

首先，在幾乎支持了集團(tuán)所有事業(yè)部客服系統(tǒng)的訴求下，面對(duì)多樣性、邏輯變更快的業(yè)務(wù)場(chǎng)景，傳統(tǒng)的面向場(chǎng)景編程成本高且周期長(zhǎng)。因此我們建設(shè)了線上配置化的運(yùn)營(yíng)系統(tǒng)，讓運(yùn)營(yíng)、產(chǎn)品同學(xué)能夠通過(guò)畫(huà)流程圖的方式變更線上的業(yè)務(wù)邏輯，比如用戶電話進(jìn)線時(shí)的互動(dòng)式語(yǔ)音應(yīng)答、人工客服在處理用戶進(jìn)線時(shí)的標(biāo)準(zhǔn)作業(yè)流程等千人千面的應(yīng)用場(chǎng)景。

其次，各業(yè)務(wù)系統(tǒng)雖然都需要應(yīng)用流程可視化技術(shù)，但需求各不相同。有的對(duì)流程圖的要求比較簡(jiǎn)單，圖的數(shù)據(jù)格式也簡(jiǎn)單，而有的需要按照 BPMN 的規(guī)范來(lái)繪制流程圖，對(duì)于定制化的要求較高。我們調(diào)研了市面上相關(guān)的框架 （BPMN.js、X6、Jsplumb、G6-editor），均存在不滿足的場(chǎng)景，技術(shù)棧統(tǒng)一的成本很高。具體表現(xiàn)在：

1. BMPN.js、Jsplumb 的拓展能力不足，自定義節(jié)點(diǎn)支持成本很高；只能全量引入，各系統(tǒng)無(wú)法按需引入
2. 與后端配套的流程引擎適配，成本較高。均不支持?jǐn)?shù)據(jù)轉(zhuǎn)換、不支持流程的校驗(yàn)等業(yè)務(wù)定制需求。
3. 文檔、示例不健全。X6 的文檔不健全，示例少（2020.07 調(diào)研結(jié)論），而其他的庫(kù)都沒(méi)有可用的中文文檔

因此，我們?cè)?2020 上半年開(kāi)啟了 LogicFlow 的項(xiàng)目，支持各系統(tǒng)的流程可視化需求。

#LogicFlow 的能力和特性

LogicFlow 當(dāng)前已具備了哪些能力呢，我會(huì)分兩部分來(lái)介紹。

#快速搭建流程圖編輯器

提供了一個(gè)流程圖編輯所必需的各項(xiàng)能力，這也是 LogicFlow 的基礎(chǔ)能力：

• 圖的繪制能力。基于 SVG 來(lái)繪制形狀各異的節(jié)點(diǎn)和線，并提供了基礎(chǔ)的節(jié)點(diǎn)（矩形、圓形、多邊形等）和線（直線、折線、曲線）
• 各類交互能力，讓圖動(dòng)起來(lái)。根據(jù)節(jié)點(diǎn)、線、圖的各類鼠標(biāo)事件（hover、點(diǎn)擊、拖拽等）做出反應(yīng)。比如節(jié)點(diǎn)拖拽、拖拽創(chuàng)建連線、線的調(diào)整、雙擊節(jié)點(diǎn)編輯文本等
• 提升編輯效率的能力。提供網(wǎng)格、對(duì)齊線，上一步、下一步，鍵盤(pán)快捷鍵，圖放大縮小等配套能力，幫助用戶提升編輯效率
• 提供了豐富的 API ，宿主研發(fā)通過(guò) API 傳參調(diào)用和監(jiān)聽(tīng)事件的方式，與 LogicFlow 完成交互

通過(guò)以上能力，前端研發(fā)可以低成本、快速的搭建起流程可視化的應(yīng)用，提供流暢的產(chǎn)品交互。下面是通過(guò) LogicFlow 內(nèi)置的節(jié)點(diǎn)和配套能力，做的流程圖示例：

#基于業(yè)務(wù)場(chǎng)景拓展

當(dāng)基礎(chǔ)能力無(wú)法滿足業(yè)務(wù)需求的時(shí)候，便需要基于業(yè)務(wù)場(chǎng)景拓展。這也是 LogicFlow 能支持客服側(cè)多個(gè)系統(tǒng)的關(guān)鍵所在。

• 設(shè)置圖上所有元素的樣式，比如各種節(jié)點(diǎn)、線、錨點(diǎn)、箭頭、對(duì)齊線的大小顏色等，滿足對(duì)前端樣式調(diào)整的需求
• API 拓展。支持在 LogicFlow 上注冊(cè)自定義的方法，比如通過(guò) API 拓展提供圖片下載的方法
• 自定義節(jié)點(diǎn)、線。內(nèi)置的矩形、圓形等圖形類節(jié)點(diǎn)往往無(wú)法滿足實(shí)際的業(yè)務(wù)需求，需要定義具有業(yè)務(wù)意義的節(jié)點(diǎn)。LogicFlow 提供了 的方式讓用戶定制具有自定義圖形、業(yè)務(wù)數(shù)據(jù)的節(jié)點(diǎn)，比如流程審批場(chǎng)景中的 “審批” 節(jié)點(diǎn)
• 拓展組件。LogicFlow 在 SVG 圖層上提供了 HTML 層和一系列坐標(biāo)轉(zhuǎn)換邏輯，并支持在 HTML 層注冊(cè)組件。宿主研發(fā)可以通過(guò) LogicFlow 的 API，基于任何 View 框架開(kāi)發(fā)組件，比如節(jié)點(diǎn)的右鍵菜單、控制面板等
• 數(shù)據(jù)轉(zhuǎn)換 adapter。LogicFlow 默認(rèn)導(dǎo)出的圖數(shù)據(jù)不一定適合所有業(yè)務(wù)，此時(shí)可以通過(guò) adapter API，在圖數(shù)據(jù)從 LogicFlow 輸入、輸出的時(shí)候做自定義轉(zhuǎn)換，比如轉(zhuǎn)換成 BPMN 規(guī)范的圖數(shù)據(jù)
• 內(nèi)置部分拓展能力。基于上述拓展能力，我們還單獨(dú)提供了 extension 的包，用來(lái)存放客服業(yè)務(wù)下沉淀出的具有通用性的節(jié)點(diǎn)、組件等，比如面向 BPMN 規(guī)范的節(jié)點(diǎn)和數(shù)據(jù) adapter，默認(rèn)菜單。注意 extension 可以單獨(dú)安裝，并支持按需引入

基于上述拓展的能力，前端研發(fā)能夠根據(jù)實(shí)際業(yè)務(wù)場(chǎng)景的需求，靈活的開(kāi)發(fā)出所需的節(jié)點(diǎn)、組件等。下面有兩個(gè)基于 LogicFlow 拓展能力做出的流程圖：

BPMN： http://logic-flow.org/examples/#/extension/bpmn

審批流程：http://logic-flow.org/examples/#/extension/approve

#實(shí)現(xiàn)原理和架構(gòu)

#整體架構(gòu)圖

核心包 @logicflow/core 提供了流程圖編輯器基礎(chǔ)的能力，右邊的 @logicflow/extension 是基于 @logicflow/core 的拓展性開(kāi)發(fā)的插件。

#流程圖編輯器的設(shè)計(jì)方案

主要介紹一下實(shí)現(xiàn)流程圖編輯器重要的選型和方案設(shè)計(jì)。

#圖渲染方案

前端繪制圖形無(wú)非就是 HTML + CSS、Canvas、Svg 三種方式，我們綜合做了一下對(duì)比，列出了相應(yīng)的優(yōu)劣勢(shì)：

在流程圖的場(chǎng)景下，不需要渲染大量的節(jié)點(diǎn)（最多幾千個(gè)元素），對(duì)于動(dòng)畫(huà)的訴求也不高。Svg 基于 DOM 的特性會(huì)更適合我們，一個(gè)是學(xué)習(xí)成本和開(kāi)發(fā)成本更低，另一個(gè)是基于 DOM 可以做的拓展也更多。不過(guò) Svg 標(biāo)簽內(nèi)部并不支持插入其他比如 div 這種標(biāo)簽，所以在實(shí)現(xiàn)某些功能的時(shí)候，都需要結(jié)合其他 HTML 標(biāo)簽。

所以最終我們選擇使用 HTML + Svg 來(lái)完成圖的渲染，Svg 負(fù)責(zé)圖形、線的部分，HTML 來(lái)實(shí)現(xiàn)文本、菜單、背景等圖層。

#模塊抽象

基于上述方案，下一步我們要做的是對(duì)實(shí)現(xiàn)一張流程圖做分類和抽象。

通過(guò)上圖：

• 首先我們構(gòu)建了多個(gè)圖層來(lái)承擔(dān)不同的職責(zé)，以方便實(shí)現(xiàn)功能和能力拓展。最上層的是 Svg 圖層，所有圖形（節(jié)點(diǎn)、線、對(duì)齊線、outLine 等）均在 Svg 上渲染，也負(fù)責(zé)監(jiān)聽(tīng)圖上的各種事件。Svg 下層的分別是組件層，負(fù)責(zé)拓展 UI 組件；Grid 層，負(fù)責(zé)渲染網(wǎng)格；背景層，添加自定義的背景。
• Shape 的職責(zé)主要是基于 Svg 對(duì)圖形渲染的封裝，提供默認(rèn)樣式、把用戶傳入的屬性做轉(zhuǎn)換等，主要包含 Rect、Circle、Ellipse、Polygon、Path、PolyLine、Text 等，方便 LogicFlow 內(nèi)部復(fù)用，比如圓形節(jié)點(diǎn)和錨點(diǎn)都需要 Circle。
• 基于 Shape，還實(shí)現(xiàn)了很多小元素，比如節(jié)點(diǎn)和線需要的錨點(diǎn)，比如線上的箭頭等等。
• 而 BaseNode、BaseEdge 則是節(jié)點(diǎn)和線通用能力的封裝，聚合 shape、錨點(diǎn)、文本，還封裝了對(duì)事件和樣式的處理等。通過(guò)繼承 BaseNode，傳入 shape 我們可以得到 RectNode、CircleNode 等可渲染的節(jié)點(diǎn)。

因?yàn)榱鞒虉D是富交互或者說(shuō)是重編輯的，有了這幾個(gè)基礎(chǔ)的模塊，接下來(lái)要做的就是富交互的方案設(shè)計(jì)，即用戶在圖上做的任何操作都要給出響應(yīng)。比如我觸發(fā)一個(gè)節(jié)點(diǎn)的拖拽，那關(guān)聯(lián)的線可能需要跟著動(dòng)，還能識(shí)別出在某個(gè)水平線上有沒(méi)有其他節(jié)點(diǎn)（對(duì)齊線）。

#MVVM + Virtual DOM

首先我們考慮到整個(gè)圖編輯器具備很多狀態(tài)存儲(chǔ)，并且要實(shí)現(xiàn)編輯圖上各模塊的響應(yīng)就必須要有狀態(tài)的通信能力。第二如果要實(shí)現(xiàn)類似 redo/undo 這類功能，那整個(gè)圖就一定需要根據(jù)數(shù)據(jù)得出渲染，即 fn(state) => View ，比較好的方式就是通過(guò) Model 來(lái)驅(qū)動(dòng) View。

最終我們選擇基于 MVVM，這個(gè)廣泛被應(yīng)用于當(dāng)前前端工程中的設(shè)計(jì)模式來(lái)構(gòu)建 LogicFlow 的圖編輯器，定義圖的 View 和 Model 層，使工程代碼具備一定的解耦。與此同時(shí)，引入 Mobx 來(lái)實(shí)現(xiàn)我們的狀態(tài)管理、數(shù)據(jù)響應(yīng)的能力，一張圖基于一份 Model 做狀態(tài)的通信。此外，考慮 Mobx 的另一個(gè)原因是：只要我想，那就可以做到最細(xì)顆粒度的數(shù)據(jù)綁定（觀測(cè)），可以減少?zèng)]必要的渲染。

以下是 LogicFlow 圖編輯器的 MVVM 示意圖： 

通過(guò)上圖可以看到，View 層（圖、節(jié)點(diǎn)等）通過(guò)數(shù)據(jù)綁定，會(huì)在 Model 發(fā)生變化之后做出響應(yīng)/更新。前面我們提到了關(guān)于圖的渲染我們是基于 Svg + HTML 實(shí)現(xiàn)的，那要做 View 層的更新無(wú)非就是命令式和聲明式兩個(gè)選擇：

• 命令式。比如 jQuery 的 api，$('.rectNode').attrs({x: 1, y: 2})，像這種方式操作 DOM 代碼其實(shí)比較繁瑣，在重交互的場(chǎng)景下寫(xiě)的代碼會(huì)比較冗余。雖然我們最終找到了有一個(gè)庫(kù)能夠很方便的支持通過(guò)命令式的方式來(lái)繪圖 —— antv/g
• 聲明式。比如 React/Vue 這類 View 框架，其中一個(gè)比較核心的能力就是做到了 state => UI ，通過(guò)聲明式的方式來(lái)構(gòu)建 DOM，只要狀態(tài)發(fā)生變化，那 UI 就更新

除了考慮到命令式在操作 DOM 的場(chǎng)景下寫(xiě)代碼會(huì)比較繁瑣之外，還有一個(gè)原因就是操作 DOM 的成本問(wèn)題，在基于 State 更新 UI 的設(shè)計(jì)下，我們自然而然想到了引入 Virtual DOM 來(lái)解決某些場(chǎng)景下的更新效率，這也可以一定程度上彌補(bǔ)「基于 Svg 渲染圖形」可能造成的渲染性能問(wèn)題。

總之，選擇 MVVM 的設(shè)計(jì)模式并引入 Virtual DOM，最根本的兩個(gè)原因便是提升我們圖編輯器場(chǎng)景下的開(kāi)發(fā)效率，以及在 HTML + Svg 的圖渲染方案下，可以追求更好的性能表現(xiàn)。

#事件系統(tǒng)

介紹了在 “狀態(tài)” 和 “響應(yīng)” 我們做的設(shè)計(jì)，那要收集到用戶的各類 “操作” 并及時(shí)上報(bào)和冒泡，就需要一套事件系統(tǒng)。最主要的就是復(fù)用和統(tǒng)一上報(bào)。

復(fù)用即怎么保證所有節(jié)點(diǎn)和線都能具備默認(rèn)的事件回調(diào)，以及針對(duì)復(fù)雜事件（拖拽）的處理邏輯如何共用。

• Behavior。針對(duì)復(fù)雜事件的處理，我們做了 function 和 class 形式的封裝，比如 Drag 是通過(guò) mousemove、down、up 來(lái)模擬 h5 的 dragEnter、dragOver、dragEnd 和 drop 事件，DnD 則是通過(guò)抽象 dragsource 和 droptarget 兩個(gè)實(shí)體來(lái)實(shí)現(xiàn) drag 和 drop 的交互，比如拖拽創(chuàng)建節(jié)點(diǎn)
• 在前文模塊抽象章節(jié)提到了內(nèi)部有 BaseNode 和 BaseEdge 這樣的抽象，內(nèi)置節(jié)點(diǎn)和自定義的節(jié)點(diǎn)都通過(guò)繼承基類來(lái)獲得通用的能力，所以 LogicFlow 內(nèi)部默認(rèn)的事件回調(diào)實(shí)際是通過(guò)繼承來(lái)復(fù)用的
• EventCenter。通過(guò)事件總線做統(tǒng)一上報(bào)，把內(nèi)部捕獲到的所有用戶行為事件，按照一定的規(guī)范和格式emit(ev, args)都上報(bào)到 EventCenter，最終冒泡到 LogicFlow 類，由 LogicFlow 類統(tǒng)一跟宿主交互。此外，圖編輯器內(nèi)任何地方也都可以通過(guò) EventCenter 做事件的觸發(fā)和監(jiān)聽(tīng)

#工具中心

工具中心的定位是解決某類特定問(wèn)題的 utils，比如上面提到的 Behavior（復(fù)雜事件的封裝） 和 EventCenter。此外，在圖編輯的過(guò)程中，如果要實(shí)現(xiàn)比較好的交互效果，實(shí)際有很多復(fù)雜的計(jì)算邏輯要處理。

• 坐標(biāo)系。瀏覽器的 clientX、clientY 坐標(biāo)系，以及 Svg 圖本身的坐標(biāo)系，當(dāng)出現(xiàn)圖的縮放和平移的時(shí)候，兩個(gè)坐標(biāo)系顯然是不同的，那如何做坐標(biāo)系的轉(zhuǎn)換。

• Algorithm。是專門(mén)通過(guò)幾何、算法來(lái)處理可視化的一些問(wèn)題。比如： 當(dāng)一個(gè)節(jié)點(diǎn)在同一方向有多條折線連出的時(shí)候，如何做路徑的合并以展示起來(lái)更美觀，如下

  

  如何計(jì)算出一根線到一個(gè)圖形的切點(diǎn)，以達(dá)到線可以連接圖形非錨點(diǎn)的位置，如下圖

  

• History，主要提供 redo 和 undo 的能力。通過(guò)兩個(gè)棧來(lái)存儲(chǔ) undos 和 redos，并限制最大長(zhǎng)度，得益于 MVVM 的設(shè)計(jì)模式，能方便的做數(shù)據(jù)變化的觀測(cè)和 Model 驅(qū)動(dòng) View。

關(guān)于這幾部分的實(shí)現(xiàn)細(xì)節(jié)這里暫不展開(kāi)，后面會(huì)有專題文章來(lái)介紹。

#可擴(kuò)展性

介紹完流程圖編輯器的設(shè)計(jì)方案，現(xiàn)在來(lái)介紹 LogicFlow 的另一個(gè)重要特性，關(guān)于拓展性方面的設(shè)計(jì)。在程序世界中，小到一個(gè) function，一個(gè)服務(wù)，再到一個(gè)開(kāi)發(fā)框架 react，小程序開(kāi)發(fā)框架，大到一個(gè) Chrome 類的應(yīng)用平臺(tái)，都具備自己的可擴(kuò)展性，這也是軟件發(fā)展過(guò)程中要考慮的一種設(shè)計(jì)選擇。對(duì)于 LogicFlow，是解決某個(gè)領(lǐng)域問(wèn)題的開(kāi)發(fā)框架，首先 API 要具備可擴(kuò)展性；此外 LogicFlow 還提供了視圖層，在 View 部分應(yīng)該能夠讓用戶做二次開(kāi)發(fā)。這兩個(gè)擴(kuò)展的方向確定之后，最主要的還是結(jié)合業(yè)務(wù)需求，要能滿足當(dāng)前和未來(lái)一段時(shí)間內(nèi)預(yù)見(jiàn)的業(yè)務(wù)場(chǎng)景，但也不能過(guò)度設(shè)計(jì)。

#API 上的設(shè)計(jì)

首先，LogicFlow 在面向用戶使用這一層，完全是基于面向?qū)ο蟮脑O(shè)計(jì)模式封裝的，最大的好處是幾乎每個(gè)程序員都熟悉它的使用，使用成本低。通過(guò)下面初始化方式便可以了解。

const lf = new LogicFlow({ // 實(shí)例化 lf 對(duì)象
  container: document.querySelector('#graph'), // 獲取渲染容器
  width: 700,
  height: 600,
  background: {
    color: '#F0F0F0'
  },
  grid: {
    type: 'dot',
    size: 20,
  },
});
lf.render({ nodes: [], edges: []}); // 在界面上渲染視圖

通過(guò) class LogicFlow，用戶實(shí)例化一次便得到一個(gè)流程圖的實(shí)例，狀態(tài)也是私有的，各種使用方法通過(guò) lf 的實(shí)例調(diào)用即可。 關(guān)于 API 拓展的設(shè)計(jì)總結(jié)來(lái)看：

1. 面向?qū)ο蟮脑O(shè)計(jì)模式， LogicFlow 內(nèi)部做好封裝，用戶可以做繼承、重寫(xiě)接口/方法
2. 方法的設(shè)計(jì)。首先是要有固定類型的輸入和輸出。此外，LogicFlow 也提供了類似于 extends 的方法，通過(guò) LogicFlow.use(fn) 在原型上拓展方法
3. 通過(guò)觀察者的模式做通信，即提供 on 方法供宿主訂閱各類內(nèi)部事件
4. 圖的數(shù)據(jù)可定制。無(wú)論是一個(gè)節(jié)點(diǎn)、線有哪些自定義的業(yè)務(wù)屬性，還是流程圖要導(dǎo)出什么樣的數(shù)據(jù)，都應(yīng)該能夠定制。

#插件化

View 層的拓展性，除了用戶能夠定制展現(xiàn)方式之外，最重要的是插件化，因?yàn)樵诹鞒炭梢暬@條路上，不同的業(yè)務(wù)場(chǎng)景下需要的能力不盡相同，LogicFlow 很難做到支持所有的場(chǎng)景，所以提供好的插拔能力，讓用戶二次開(kāi)發(fā)是比較好的選擇。目前，在 UI 界面上，我們開(kāi)放了兩個(gè)能力：

1. 節(jié)點(diǎn)和線支持二次開(kāi)發(fā)，即自定義節(jié)點(diǎn)、線
2. 可開(kāi)發(fā) UI 組件注冊(cè)到 LogicFlow 的組件畫(huà)布內(nèi)

基于插件化的思路，我們已經(jīng)支持了不同的業(yè)務(wù)系統(tǒng)，并在這個(gè)過(guò)程中把一些稍微通用的能力沉淀出來(lái)，并封裝到 lf-extension 包，比如用來(lái)支持 BPMN 規(guī)范的節(jié)點(diǎn)。目前 extension 內(nèi)的拓展主要分了四類：UI 組件、自定義節(jié)點(diǎn)、API、adapter。關(guān)于插件的詳細(xì)設(shè)計(jì)和實(shí)現(xiàn)后面也會(huì)有專門(mén)的文章介紹。

#未來(lái)規(guī)劃

2021.4 發(fā)布 v1.0。目前我們對(duì) 1.0 版本的定義為：

1. API 的易用性和豐富程度。因?yàn)?LogicFlow 還是一位新同學(xué)，要想進(jìn)化為成熟好用的庫(kù)還是需要經(jīng)過(guò)大量用戶和不同類型系統(tǒng)的驗(yàn)證，以及各位開(kāi)發(fā)者的共建。具體的功能 scope 除了我們當(dāng)前的迭代計(jì)劃，還會(huì)根據(jù)用戶的需求排出優(yōu)先級(jí)后加入進(jìn)來(lái)，也希望大家多多提意見(jiàn)和需求。這個(gè)方向的基調(diào)是保持 LogicFlow 流程可視化的定位，把 core 的 API 豐富，extension 的能力增強(qiáng)
2. 更完善的文檔和示例。主要是文檔易讀、完善、提供英文版，并能夠有完整的示例和代碼，供開(kāi)發(fā)者 copy paste 代碼
3. 不僅是流程可視化庫(kù)，期望提供整套解決方案。LogicFlow 只解決了前端流程圖編輯的技術(shù)問(wèn)題，但關(guān)于圖數(shù)據(jù)的定義，流程最終如何被執(zhí)行，還需要一個(gè)配套的流程引擎。目前，關(guān)于「流程引擎」我們團(tuán)隊(duì)也有相應(yīng)的解決方案 —— turbo，后面 turbo 也會(huì)開(kāi)源，我們會(huì)把 LogicFlow 和 turbo 做成端到端的解決方案，并提供完整的應(yīng)用示例。大家拭目以待

#最后

相信你對(duì) LogicFlow 已經(jīng)有一個(gè)大概的認(rèn)識(shí)了，如果在你負(fù)責(zé)的業(yè)務(wù)中也有流程可視化的訴求，并且有較高的拓展性需求，那 LogicFlow 會(huì)是一個(gè)好的選擇。對(duì)于 LogicFlow 技術(shù)本身的實(shí)現(xiàn)細(xì)節(jié)、對(duì)于相似業(yè)務(wù)的探討也都?xì)g迎大家來(lái)交流。 對(duì)于 LogicFlow 的拓展機(jī)制、連線的計(jì)算邏輯等對(duì)于可視化的一些思考，我們后續(xù)會(huì)有更多的文章介紹，盡情期待。