記一次繪圖框架技術選型: jsPlumb VS mxGraph

公司項目須要用到繪圖框架，繪圖部分之前是另外一位同事負責，用的是 jsPlumb 框架。因爲人員流動，後來這部分我接手了。項目繪圖業務需求變得愈來愈複雜，jsPlumb 已經知足不了咱們項目，因而我將目光投到了其餘繪圖框架。本文主要說說我在使用 jsPlumb 遇到的問題，以及我爲何選擇 mxGraph。

jsPlumb

jsPlumb 有社區版跟收費版，咱們使用的是社區版，下面提到的問題在收費版不必定存在。

1. 不穩定
2. 沒有內置導航器(收費版是有這個功能的)
3. 沒有智能佈局功能
4. 沒有作圖層管理
5. 沒有集成截圖功能
6. 畫布沒有邊界自動擴充功能

• 不穩定

  主要體如今兩點

  1. 還原圖形偶爾會報一些莫名其秒的錯誤，還原失敗
  2. 鏈接線條偶爾會發生線條位置錯亂的狀況

這多是因爲我使用 jsPlumb 不當引發的，又或者是框架自己存在問題，到最後都沒法定位問題所在。但確實我在網上也看到有同窗遇到過類似不穩定的狀況。

• 沒有內置導航器

  
  (這是後來我用 mxGraph 作出來的)

  導航器爲分兩個功能：第一個是放大、縮小，第二是可拖拽改變視口的 minimap。對於放大、縮小這個功能，咱們用 css scale 來對整個畫布進行縮放。但這個方法的缺點很快就暴露了，縮放後節點位置會發生改變；至於 minimap 要實現的話無異於重複造輪子，團隊資源有限，這個功能當時擱置了。

• 智能佈局

  產品有一個需求是將用戶 Excel 表中的數據用圖形的方式展現，這就須要智能佈局功能，否則程序不知道節點應該放置在什麼地方纔美觀。實現這個功能要使用比較複雜的算法，團隊資源有限，這個功能當時也擱置了。

• 沒有作圖層管理

  jsPlumb 沒有作圖層管理，致使繪圖過程當中作不到一些想要的圖層疊加效果，要作的話只能本身用 z-index 去控制，這無疑增長了項目維護成本。並且 jsPlumb 的靶點是經過絕對定位附着在節點上的，你須要管理的不只僅是節點的 z-index 還有靶點的 z-index。

• 沒有集成截圖功能

  在用戶繪圖過程當中作了任何改變圖的外觀的操做咱們都須要對當前圖形截圖，而後同步到服務端做爲該圖形的封面。jsPlumb 沒有內置的截圖功能，咱們使用 html2canvas 將 html 轉換成 canvas 再轉換成 png，而後發送到服務端。但 html2canvas 截圖時會有1秒左右的卡頓，這下降了用戶體驗，並非咱們想要的。

• 畫布沒有邊界自動擴充功能

  因爲 jsPlumb 採用的是svg和html混排的作法，節點都是html，畫布的邊界天然是程序設定的 div 容器。節點多了或者用戶想把節點拖遠點都須要擴充畫布邊界，這又成了一個技術難題。當時咱們只好用緩兵之計把畫布寫死成 5000 * 5000。

說了這麼多 jsPlumb 的很差，我並無黑這個框架的意思。畢竟 jsPlumb 如今的 start數、npm下載量都是繪圖框架中最高的，確定有它的過人之處，只是並不適合咱們的項目。jsPlumb採用的是svg和html混排的作法，全部節點都是html，全部連線都是單獨的svg節點包裹的path元素，對於高度定製化節點樣式是很是方便的，我認爲靜態展現的圖形很是適合使用 jsPlumb 繪製。

mxGraph

基於以上說起到的種種緣由，上年年底我作起了技術調研，但願能找到一個合適咱們項目的繪圖框架。目標很是明確，我要找的框架能幫助我解決上面全部的問題。一番谷歌篩選後，發現 mxGraph 跟 GoJS 都是能解決咱們項目問題的，由於 GoJS 是閉源收費的，最後我選擇了 mxGraph。

• 穩定性

  draw.io 是一個比較知名的開源繪圖網站，就是用 mxGraph 進行開發的。這個繪圖工具我偶爾也會使用，還試過出現 BUG 的狀況。有 draw.io 當背書，我相信 mxGraph 的穩定性是靠得住的。

• 功能

  mxGraph 官方提供差很少 90 個例子，從這些例子跟 draw.io 中我能夠肯定我想要的功能 mxGraph 均可以幫助我實現。導航器、智能佈局對於 mxGraph 來講只是一個 API 調用的事。mxGraph 的畫布徹底基於 svg，自定義節點樣式，徹底經過 js 完成，比較麻煩。但這對於 mxGraph 自身作圖層管理是有好處的，對於開發都來講管理圖形層疊也只是幾個 API 的事，也不用管什麼 z-index 了。因爲畫布徹底基於 svg，不像 jsPlumb 用 html + svg 實現畫布，因此 mxGraph 能夠作到導出結構化的文檔（XML），也再也不須要使用 html2canvas 幫助截圖，只須要調用幾個接口導出當前文檔發送給服務端，而後服務端經過 Java 版 (咱們項目使用的是 Java，mxGraph 服務端環境還提供有 PHP、C#) mxGraph 將文檔轉換成圖片，這樣便解決了截圖的問題。畫布邊界擴充也的問題也不用關心，mxGraph 已經幫助咱們作了。再就是 draw.io 已經用 mxGraph 實現了複雜的繪圖功能，相信即使之後咱們的業務有更復雜的擴展這個框架也是能扛得住的。

• 社區

  mxGraph 在 stackoverflow 上有雖然有250個左右相關問題，不過大多數都是回答數比較少，這是我當時比較擔心的一點。

• 兼容性問題

  項目對瀏覽器兼容性比較寬鬆，瀏覽器兼容性問題不在考慮範圍以內。但交互上須要兼容iPad，從 mxGraph 的官方 Demo 中得知 mxGraph 對這方面有作兼容的，能夠放心使用。

• 缺點

  • 文檔不夠友好(我的認爲與GoJS文檔水平差距甚遠)，致使上手難度大
  • 沒中文文檔，英文很差的同窗用起來有點吃力
  • 相對 jsPlumb 不能使用 css 自定義節點樣式，徹底經過 js 完成，比較麻煩

通過4個月使用後，確實 mxGraph 幫忙咱們解決了上述問題。但同時也遇到的了一些問題，我會在下一篇文章《mxGraph 入門實例教程》中指出。

參考

• 精讀《12 個評估 JS 庫你須要關心的事》
• 前端可視化建模技術概覽