基於vue的簡單流程圖開發

EER發表於2017-10-18
Vue流程圖

嚴重拖延症，一方面這專案模組純屬個人娛樂。另一方面，流程圖這塊涉及的東西還是蠻多的，這次也只是介紹一些簡單的部分。拖了這麼久，現在終於要開始硬著頭皮寫一篇基於vue+svg的流程圖"偽教程"文章了。初次獻醜，還請輕噴。

模組簡介

專案地址

圖片預覽
圖片預覽

出於學習vue而非相容的目的，本專案僅考慮現代瀏覽器( 谷歌 )，部分相容問題還請見諒。

本模組的開發源於對流程圖的簡單需求( 純UI實現，暫不存在業務邏輯 )，這裡不贅訴vue-cli生成的目錄結構(可以參考這篇或自行谷歌)。

專案實際用到的技術棧：SVG + vue + vuex

功能介紹：

  • 畫布縮放
  • 節點( 開始,基礎,判斷等 )新增，刪除
  • 節點間連線( 直線/折線 )
  • 文字新增
  • 外部匯入SVG圖形
  • 撤銷與重做

畫布縮放

考慮到畫布縮放後佈局需保持一致，這裡通過修改transform: scale(); transform-origin: ; 來實現,節點則相對父層定位。

TODO: SVG最優縮放解決方案?

節點相關

下面我簡單說一下思路：

由於不存在業務邏輯，我把流程圖簡化為 開始 基礎 判斷 3個基礎元件( 基於SVG )。

如:

<template>
    <!-- 開始 -->
    <ellipse v-bind="style"></ellipse>
    <!-- 基礎 -->
    <rect v-bind="style"></rect>
    <!-- 判斷 -->
    <path v-bind="style"></path>
</template>複製程式碼

這裡說一下判斷這個元件( 後期可能出現複雜形狀均以path實現 )，一般由AI軟體直接匯出相關形狀。

左邊工具欄跟畫布中的相同圖形源於同個元件，故設有兩個樣式，即 defaultStyle 和 drawStyle。之前有考慮過，如果流程圖的圖形複雜多變的話，那這種模式豈不是每一個元件都得人為定義。同樣，採用匯入SVG也有類似問題。因為如果圖形大小都不確定的話，除了支援圖形修改大小，否者將導致畫布出現大小不一的圖形。( 非常遺憾這方面沒有做出突破，不過這將成為未來改進的方向。)

最開始採用的解決方案是以scale的方式，也就是統一讓工具欄中的圖形跟拖入畫布中的圖形成等比縮放關係。不過該方式會造成stroke也同比縮放，並非我們想要的。

所以目前暫時採用寫死的方式。

注意: 在svg中 ellipse 定位相對於中心點，而rect定位是相對於左上角。

TODO是否有辦法將各元件定位源點設定為元件中心點。

節點渲染

節點渲染方面，由於之前是將圖形作為元件，於是採用 component + is 的方式來渲染圖形。同時也是以資料驅動的方式來渲染，即資料決定檢視。

 <component v-for="(item,index) in nodeData" :is="item.type" :id="item.id" v-node inDraw></component>複製程式碼

拖動節點涉及映象節點時：

<component :is="selNodeId" :transform="selNodeInfo.transform" v-if="isDragging" inDraw></component>複製程式碼

程式碼直通車

新增節點

drag drop 的形式。採用該方式的好處是不需要模擬拖拽事件。也就是映象什麼的不需要自己做。( 畫布內節點拖拽則使用原生模擬 )

程式碼直通車

對節點的操作均以指令( directives )的形式( 直接操作DOM )。這引發了我對該類專案是否適合用vue類框架來做的疑問，從開發效率方面，還是首選vue，但是從效能方面，由於沒有深入研究，並沒有發言權。

TODO 場景模擬，假設我們需要移動畫布內節點，通過directives的el來獲取節點，然後通過el.onmousemove來修改data中對應的translate來實現位置的更改。這裡修改data來驅動檢視是我們常用的方式，但是我想不通的就是el.onmousemove來修改data實現的雙向資料繫結所帶來的效能在這裡是否有體現。

我所設想的是，是否涉及多依賴的時候，diff帶來的效能提升才有價值。舉個例子，我有一個列表，存在於data中的listData，然後在view中有多處關聯listData。那此時操作listData比直接操作DOM來得更好些。

看過相關vitrualDOM的介紹，通過diff可以只操作變化的DOM。

獲取SVG大小

獲取節點大小使用 getBoundingClientRect ，同時由於前面做了縮放功能，這裡獲取節點大小時需要除以縮放比例來獲取正確值。

let obj = el.getElementsByTagName('g')[0]
let w = obj.getBoundingClientRect().width / _this.drawStyle.zoomRate
let h = obj.getBoundingClientRect().height / _this.drawStyle.zoomRate
let wh = {
    width: w,
    height: h
}複製程式碼

程式碼直通車

節點操作總結

由於節點的顯示是基於NodeData，所以增刪其實就是對NodeData的增刪。

主要程式碼

連線相關

連線其實也只是用到了svg的line和polyline，這裡跟節點類似，均以元件的形式存在，並以lineData驅動連線檢視。所以最終連線的增刪也是對資料的操作。

連線點的顯示

基於vue的簡單流程圖開發

首先是連結點的位置( 綠色遠點位置 )，之前基於jquery做的流程圖是用div佈局，現在用svg增加了難度，由於svg不能使用position，所以無法基於當前元素定位。採用的是土辦法，即用圖形大小+padding動態獲取4個點的位置。期間，由於4個連線節點與圖形節點有空隙，當mouseover不處於圖形或節點時，事件無法觸發。在此是模擬一個區域來解決的。由於個人經驗問題，這部分程式碼完全就是命令式的風格。勿噴

程式碼直通車
程式碼直通車2

連線處理

節點間連線做了兩種情況：（這裡不講訴從mousedown至mouseup具體細節，可以看這裡）

其實很多人說，演算法可以解決很多垃圾程式碼。可惜我還沒掌握它的真諦，比如之前的圖形元件，以及接下來的不同線條。其實都可以通過一定的演算法得出來。我這裡只講講最笨的方法，待我成長到能用演算法來說話的時候，在回來好好理下這篇文章。

  • line直線

直線無外乎就是兩個點座標，通過svg中的line來顯示。這時候就得看專案的需求，我們假設最簡單的情況，就是上面講到過的4個連線點最為連線的起始或結束點。
下面是計算圖形中4個點的座標位置


computeLine(direction, obj) { // low不止一點點
    let { top, left, width, height } = obj
    let w = width / 2
    let h = height / 2
    switch (direction) {
    case 't':
        top = top - h
        break
    case 'b':
        top = top + h
        break
    case 'l':
        left = left - w
        break
    case 'r':
        left = left + w
        break
    default:
        break
    }
    return { top, left }
}複製程式碼
  • polyline折線

折線考慮的情況相對比較多一點，這邊由於使用的是polyline，它的點位設定長這樣子points="125,96 183.5,96 183.5,399 242,399"

這個時候一般會把字元轉化為較為好操作的陣列或物件。折線涉及的開始點跟結束點跟上面介紹直線的點位一樣，不同的是中間線的位置，如果不考慮複雜的情況，

一般可以分為兩種，上下，左右。通過獲取開始與結束點的中點位置來確定中線即可以得到想要的折線。程式碼如下：（都是用簡單粗暴的方式。）

computePolyLine(start, end, direction) {
    let startPoint = {
    x: +(start.split(',')[0]),
    y: +(start.split(',')[1])
    }
    let endPoint = {
    x: +(end.split(',')[0]),
    y: +(end.split(',')[1])
    }
    let m1, m2
    switch (direction) {
    case 't':
    case 'b':
        let mY = startPoint.y + (endPoint.y - startPoint.y) / 2
        m1 = {
        x: startPoint.x,
        y: mY
        }
        m2 = {
        x: endPoint.x,
        y: mY
        }
        break
    case 'l':
    case 'r':
        let mX = startPoint.x + (endPoint.x - startPoint.x) / 2
        m1 = {
        x: mX,
        y: startPoint.y
        }
        m2 = {
        x: mX,
        y: endPoint.y
        }
        break
    default:
        break
    }
    return `${startPoint.x},${startPoint.y} ${m1.x},${m1.y} ${m2.x},${m2.y} ${endPoint.x},${endPoint.y}`
}複製程式碼

連線總結

節點跟連線在渲染以及操作的處理上大同小異，這裡不確定是否為最佳實踐的有兩個地方，一是採用component+is的形式來渲染元件，二是採用 diretives的方式來操作DOM。連線的計算形式也略顯簡單，這確實是需要一定時間來成長的。扯偏了，在這簡單總結一下，無論是哪種連線方式，我們需要做的就是正確獲取對應點的位置，然後修改資料來驅動檢視。不過能在各種複雜的情況下總結出演算法，也是一種跨越，加油吧。

節點及連線的文字新增

節點及連線的文字新增原理都一樣，這裡採用的是設定 contenteditable 當contenteditable為true時，html結構自動新增文字節點並且可編輯。更多細節可以參考張鑫旭的這篇

順道講一下pointer-events本模組有兩個地方用到該css屬性。一個是文字新增這塊，以及頭部工具欄部分。

CSS屬性pointer-events允許作者控制特定的圖形元素在何時成為滑鼠事件的target。當未指定該屬性時，SVG內容表現如同visiblePainted。

除了指定元素不成為滑鼠事件的目標，none值還指示滑鼠事件穿過該元素，並指向位於元素下面的元素。

更多細節關於pointer-events

張鑫旭
MDN

TODO 文字編輯雖已實現功能，但這塊BUG較多，還未完善。

外部匯入SVG

這邊也是用到了HTML5的Drop功能，顯示則是用到了svg的images。拖拽實現比較簡單：

dropHandle (e) {
    let reader = new FileReader()
    let file = e.dataTransfer.files[0]
    reader.onload = (e) => {
        this.userImages.push(e.target.result)
    }
    reader.readAsDataURL(file)
},
dragoverHandle () {
},
dragstart (imgSrc) {
    event.dataTransfer.setData('URL', imgSrc)
}複製程式碼

這邊需要注意的是@drop.stop.prevent="dropHandle" @dragover.stop.prevent="dragoverHandle"要阻止冒泡以及阻止瀏覽器預設行為。

還有一個要注意的是dataTransfer.getData()在dragover,dragenter,dragleave中無法獲取資料的問題

根據W3C標準，drag data store有三種模式，Read/write mode, Read-only mode跟Protected mode。細節

Read/write mode
讀/寫模式，在dragstart事件中使用，可以新增新資料到drag data store中。

Read-only mode
只讀模式，在drop事件中使用，可以讀取被拖拽資料，不可新增新資料。

Protected mode
保護模式，在所有其他的事件中使用，資料的列表可以被列舉，但是資料本身不可用且不能新增新資料。

深入

撤銷與重做

這一功能本質上是沒有完成的，因為採用了一種偷懶的方式，vuex 生成 State 快照，生產環境不建議使用。

基本原理就是通過vuex提交更高（mutation）來觸發回撥。以此來記錄state 快照

程式碼直通車

總結

本專案屬於入門級的vue+vuex,但是並沒有講如何使用vue或者vuex，因為這些在官方文件其實都已經講的非常清楚了。該專案也只是簡單使用瞭如vue的自定義指令，MiXin等常用方法。諸如vue Render函式元件，不在本文談論範圍，這裡簡單講下使用體驗，render元件比較適合高自定義的元件（變化邏輯比較複雜）。因為一些簡單元件其實更適合用tempalte的形式，雖然使用Render可以提高一定的效能( 減少了從tempalte到render這一步 )，但是很多現有的如sync，是render元件所不具備的（ 需自己實現 ）。vuex的使用，則需要注意的是object引用地址的問題。也就是說，要避免資料間的潛在影響。（雖然vuex自身也有規避這個問題）可以瞭解一下immutable 。

本教程主要講述一個基於vue如何實現一個簡單的流程圖，更多引發的思考是，什麼專案更適合使用這種MVVM模式的框架，以及如何發揮VitrualDOM的價值。其實上面幾個章節的點隨便拿個出來都可以深入探討出很多技術問題，以後有機會再陸續深入。

相關文章