前端數據驅動的價值

時間 2019-11-08

標籤前端數據驅動價值简体版

原文原文鏈接

數據驅動應該是從flux/redux + react這種模式開始流行的。 react

他的背後不只僅是數據驅動這麼簡單，在複雜的系統中，我以爲它解決了一個很關鍵的問題就是模塊間的交互/通訊。有不少文章拿他和mvc/mvvm去比較，我我的以爲沒有特別的可比性，由於解決的問題不一樣。git

以往處理模式

一個稍微複雜點的例子： github

假若有這麼一個頁面，咱們按照以往模式開發，首先模塊化開發，拆分紅A，B，C 三個模塊，而後每一個模塊有本身的子模塊。 redux

若是需求簡單還比較好解決，每一個模塊中本身解決本身的邏輯，解耦的很是清晰。父子之間的關係也很是明確。微信

例如銷燬C模塊，會自動銷燬它的子模塊C1和C101。數據結構
模塊間的關係也很清晰，B1不會和B2有直接關係，他們之間須要經過B模塊去傳遞。同理，B模塊和A模塊也沒有直接關係，他們都須要經過外層頁面去處理關係。mvc

可是假若有這麼一個需求，A2的顯示和B2（用戶交互）以及C101（用戶交互）相關怎麼辦。mvvm

按照這種模式，它的解決方案是：模塊化

B2若是發生改變，通知B模塊，B模塊在通知頁面，頁面調用A模塊和C模塊，C模塊調用C1，C1調用C101獲取C101的數據處理，頁面調用A模塊，A模塊再調用A2，再結合一下從C101獲取的數據，改變它的展現。 spa

是否是看着很繞，從圖上看是這麼個關係：

圖中僅僅顯示了其中一個複雜交互，假如咱們再多兩個模塊間關聯的邏輯：

B1和B2模塊影響A2模塊(圖中黃線)
C1影響B1模塊(圖中白線)

以下圖：

3個複雜一點的交互，整個模塊間的通訊已經變成蜘蛛網了，重要的是，每一條關係線都須要開發者維護的，不只影響開發效率，並且很差維護，容易引起bug，假如後期加新需求或者調整需求，開發成本都是比較高的。

可見，對於複雜的交互，或者模塊間關係複雜時，這種依賴父子關係的通訊，是一個很大的障礙。

可是咱們怎麼辦，拒絕模塊化開發嗎？那樣頁面設計起來耦合度更大，更加不可維護。

首先一點，模塊化開發是一個不可逆的趨勢，然而在這種趨勢下，解決模塊化通訊是一個很是重要的點。

模塊間通訊其餘方案

在那個時候，我考慮最多的就是如何去解決模塊之間的通訊，如何讓模塊之間交互更加輕鬆，模塊之間更加獨立。

方案一：

當時考慮的一個方案是使用一個全局的event（全局的on和fire）。這樣模塊之間就不用依賴父子關係了。模塊和模塊間是能夠之間交互的。

可是這樣會有一些弊端：

事件名稱如何定義，保證不重名
事件是否會重複的on
模塊和模塊之間會由於事件產生一些耦合
當交互特別複雜時，也會比較麻煩，仍是上面的例子，B2通知C2改變後，C2還須要通知C101獲取一次數據，來確認改變

總體來看：

優點：擺脫了模塊間父子層級關係，能夠簡單的跨模塊通訊

劣勢：依然須要維護複雜的模塊間關係，只是能夠繞過父子依賴

方案二:

全局共享一個model + component模式。這種其實已經很是趨向與數據驅動了。每一個模塊都是共享全局的model，而後每一個component均可以被全局獲取到到，裏面的功能屬性能夠直接被使用。

其實這種模式已經比較理想，頁面上面的任何component均可以被直接調用到而且使用。

我的以爲缺點就是：
多了一個全局可調用component的功能。若是砍掉他能夠實現完成數據驅動，若是模塊調用時，使用多了直接獲取component的功能，仍是須要在模塊間維護好和其餘模塊間的交互邏輯。

數據驅動

先看一個圖，我感受能夠很好的體現數據驅動

提線木偶：他的特色就是每一個動做都是，頭，手臂，腳，金箍棒都是由操做的人手決定的，頭和手臂直接沒有任何關係。

數據驅動也能夠這麼理解，頁面上面因此的展現都是由數據決定的，和頁面其餘地方沒有任何關係。

再來看看上面那個例子若是加上數據驅動的設計思想。

頁面之間每一個模塊，不用關心父子模塊之間的關係，每一個獨立的模塊都是由一個全局的model決定。

回到上面那個麻煩的場景。當B2改變時，它會修改model中對應的數據（效驗C101數據，結合B2的改變，修改A2的數據），而後A2的業務模塊跟進A2的數據改變。

這種設計的核心是每個模塊的改變，所有都交給model處理。

而後model裏面會和個個模塊一一對應，每一個模塊無需關注其餘模塊的變化，只須要關注model裏面對應本身數據的變化便可。因此模塊間關係鏈條會顯得很是簡單。

重點在於，當交互邏輯不斷增長時，這個關係鏈條依然不會增長，由於模塊只和model裏面對於的數據相關聯。

固然，這種模式也沒法去省略複雜的業務邏輯，只是業務邏輯所有都會彙集在model中。能夠理解爲頁面上全部的操做都是對數據的操做。而後每一個模塊只須要監聽關注的數據改變便可，這個監聽關係就是圖中惟一的一條關係線。

換一個理解，咱們將直接的模塊和模塊直接的耦合關係所有轉移到了數據中去體現。而數據的維護是遠遠比模塊更好維護的。

Model如何對應View

仍是上面頁面爲例子：

model

var page = {
    a: {
        isShow: true,
        children: [{
            a1: {
                isShow: true
            }
        },
        {
            a2: {
                isShow: true
            }
        }]
    },
    b: {
        isShow: true,
        children: [{
            b1: {
                isShow: true
            }
        },
        {
            b2: {
                isShow: true
            }
        }]
    },
    c: {
        isShow: true,
        children: [{
            c1: {
                isShow: true,
                children: [{
                    c101: {
                        isShow: true
                    }
                }]
            }
        }]
    }
}

isShow 表示展現的意思。這個狀態對應文章第一個圖片。

當數據改變時，例如model發生變化以下：

var page = {
    a: {
        isShow: true,
        children: [{
            a1: {
                isShow: true
            }
        },
        {
            a2: {
                isShow: false
            }
        }]
    },
    b: {
        isShow: true,
        children: [{
            b1: {
                isShow: true
            }
        },
        {
            b2: {
                isShow: false
            }
        }]
    },
    c: {
        isShow: true,
        children: [{
            c1: {
                isShow: false,
                children: [{
                    c101: {
                        isShow: true
                    }
                }]
            }
        }]
    }
}

對應下面這樣：