前端數據驅動的陷阱

時間 2019-12-04

標籤前端數據驅動陷阱简体版

原文原文鏈接

年前一篇文章《前端數據驅動的價值》聊了一下數據驅動的一些見解。前端

其中數據驅動的核心在於整個系統中對於數據的架構，設計，維護。對於數據的處理直接決定了系統的穩定性，可維護性，可擴展性。可是這裏的數據維護也是至關複雜和難搞的一塊。react

精選評論

引用nightire在segmentfault對於《前端數據驅動的價值》的評論：
我以爲很是好因此完整複製過來git

數據驅動確定不是從 flux/redux + react 纔開始的
上者特別強調單向數據流，因此纔給人形成「由它開始」的錯覺github

單向數據流有一個前置依賴，那就是 Single Data Source，也就是你的「提線木偶」所描述的那樣數據庫

然而在你的文章裏卻把它寫成了 Data Driven 的前置依賴編程

問題來了：只有單向數據流纔算數據驅動嗎？redux

確定不是的，其實老牌的 Angular／Ember／……等等都是同樣的，無非就是對待 Data 的方式各有不一樣罷了；刨除這些細微差異，它們都是從「DOM 驅動」轉向「數據驅動」的表明做品segmentfault

只是它們並無把這個的概念提煉的深刻人心，如此說來，React 一家是功不可沒的，不可變數據＋單向數據流讓數據驅動真正成爲了「理念」，而不僅是「概念」後端

然而，單向數據流也不是十全十美的，對於 UI 編程來講，有些地方的確是雙向綁定來得更「漂亮」一些，好比：表單設計模式

因此 React 也適時的加入了雙向綁定；不過這並不妨礙數據驅動這一理念得以貫徹

Single Data Source 也不是萬能靈藥，若是 A B C 三個模塊都是各自獨立開發的，以後由於需求而要合併在一塊兒，怎麼辦？在它們之上再來一個 SDS？那這樣還算不算是 SDS 呢？（或者反過來，不是 SDS 的話難道就不行嗎？）

這個問題其實也還在發展中，這會兒我也給不出答案，只是客觀描述一番罷了。

數據驅動的陷阱

對於一個真正完美的數據驅動，就如同《前端數據驅動的價值》中的例子，全部業務所有由一個store驅動，維護好store就是維護好了整個系統。

可是對於這個一筆帶過的維護store其實技術含量很是高。

下面分業務場景和狀況描述

新項目

這種狀況是比較幸運的，開始的模型中設計好業務數據結構，設計好將來可擴展點。

固然，即便是新產品，也會遇到麻煩點，由於每個參與開發的人，必需要全局的理解整個數據結構。

看看數據難搞的地方，舉個例子：

模式A:

var store = {
    userInfo: {
        name: 'test',
        age: '20'
    },
    planNum: 2,
    plans: {
        'plan1': {
            name: 'plan1',
            price: 2.00,
            unitNum: 1,
            unit: {
                'unit1': {
                    name: 'unit1',
                    price: 1.22,
                    keywordNum: 2,
                    keyword: {
                        'keyword1': {
                            name: 'word1',
                            price: 22.00
                        },
                        'keyword2': {
                            name: 'word2',
                            price: 21.00
                        }
                    }
                }
            }
        },
        'plan2': {
            name: 'plan2',
            price: 3.00,
            unitNum: 0,
            unit: {}
        }
    }
}

上面是一種最簡單的數據結構，清晰的展示了plan、unit、keyword直接的關係，簡單直白。

可是若是當層級關係愈來愈深，這個裏面增刪改查信息就是一個麻煩點，能夠說上面結構的可擴展性不強。

那麼換下面一種結構是否更加合適：

模式B:

var store = {
    userInfo: {
        name: 'test',
        age: '20'
    },
    planNum: 2,
    plans: {
        'plan1': {
            name: 'plan1',
            price: 2.00,
            unitNum: 1,
            unit: [unit1]
        },
        'plan2': {
            name: 'plan2',
            price: 3.00,
            unitNum: 0,
            unit: []
        }
    },
    units: {
        'unit1': {
            plan: 'plan1',
            name: 'unit1',
            price: 1.22,
            keywordNum: 2,
            keyword: [keyword1]
        }
    },
    keywords: {
        'keyword1': {
            plan: 'plan1',
            unit: 'unit1',
            name: 'word1',
            price: 22.00
        },
        'keyword1': {
            plan: 'plan1',
            unit: 'unit1',
            name: 'word2',
            price: 21.00
        },
    }
}

我的感受這種模式更加適合，便於查找和更新，那麼問題來了，先拋開哪一種數據結構更合適問題，假如開發初期模式A是ok的，隨着業務的複雜，發現模式A愈來愈難維護，通過從新設計，發現轉換到模式B更加合適，能明顯提升開發和維護效率，那麼怎麼辦？

我的尚未實踐過，可是經驗上看感受是會致使大面積重構。即便重構完成，假如後期發現更好的數據模式呢？

因此能夠看出初期的數據結構決定了將來架構，看上去像不像後端開發，數據庫的設計很重要。

既然愈來愈像後端設計模式，那麼是否會模仿當時的先後端分離策略，底層數據結構和業務展示經過api實現呢？我的感受這樣有點問題過於複雜化。那麼是否能夠加一箇中間數據轉換層去處理數據呢？這樣在底層數據結構變換時，也能避免直接影響業務模塊，中間層作一個適當的解耦，展現內容和數據結構沒有什麼關聯，關聯的僅僅是數據信息。

結論一：初期的數據結構設計會是將來的不定時炸彈，早晚會面對，須要有相應策略

模塊合併

再來考慮評論中的一個問題：

Single Data Source 也不是萬能靈藥，若是 A B C 三個模塊都是各自獨立開發的，以後由於需求而要合併在一塊兒，怎麼辦？在它們之上再來一個 SDS？那這樣還算不算是 SDS 呢？（或者反過來，不是 SDS 的話難道就不行嗎？）

複雜的系統中確實會遇到這種問題，直接舉例：

模塊C，主要負責修改level:

var store = {
    moduleA: {
        'plan1': {
            name: 'plan1',
            price: 22.00
        },
        level: 2
    }
}

模塊D，主要負責修改auth:

var store = {
    moduleB: {
        'plan1': {
            name: 'plan1',
            price: 22.00
        },
        auth: 0
    }
}

如今的邏輯是假如兩個獨立開發好的模塊須要合併到一塊兒，他們都有各自模塊的內部數據結構，假如模塊C除了修改level，還修改了plan1的name會怎麼樣？爲了保證數據統一，須要去找到模塊D中的plan1信息，而且修改。假如他們都合併到上面一個例子模塊A中怎麼辦，是否還須要繼續同步修改。若是漏掉一個同步，展現上，以及後面的處理都會引起各類bug。

固然，若是不用數據驅動，可能這種模塊合併也是須要從展現層級各處同步修改信息的，也會特別麻煩。只是相比較而言，數據驅動的這種合併同步並無給咱們帶來很清晰簡單的處理方式。

結論二：數據驅動下，數據的重複和同步是一個坑，要儘可能避免