前端数据驱动的陷阱

年前一篇文章《前端数据驱动的价值》聊了一下数据驱动的一些见解。

其中数据驱动的核心在于整个系统中对于数据的架构，设计，维护。对于数据的处理直接决定了系统的稳定性，可维护性，可扩展性。可是这里的数据维护也是至关复杂和难搞的一块。

精选评论

引用nightire在segmentfault对于《前端数据驱动的价值》的评论：
我以为很是好因此完整复制过来

数据驱动确定不是从 flux/redux + react 才开始的
上者特别强调单向数据流，因此才给人形成“由它开始”的错觉

单向数据流有一个前置依赖，那就是 Single Data Source，也就是你的“提线木偶”所描述的那样

然而在你的文章里却把它写成了 Data Driven 的前置依赖

问题来了：只有单向数据流才算数据驱动吗？

确定不是的，其实老牌的 Angular／Ember／……等等都是同样的，无非就是对待 Data 的方式各有不一样罢了；刨除这些细微差异，它们都是从 “DOM 驱动” 转向 “数据驱动” 的表明做品

只是它们并无把这个的概念提炼的深刻人心，如此说来，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。

固然，若是不用数据驱动，可能这种模块合并也是须要从展现层级各处同步修改信息的，也会特别麻烦。只是相比较而言，数据驱动的这种合并同步并无给咱们带来很清晰简单的处理方式。

结论二：数据驱动下，数据的重复和同步是一个坑，要尽可能避免

不适合的场景

然而，单向数据流也不是十全十美的，对于 UI 编程来讲，有些地方的确是双向绑定来得更“漂亮”一些，好比：表单

评论里面提到的这部分应该是单向数据流的一个痛点，若是模块里面严格执行单向数据流，对于这种表单验证来讲，是很是痛苦的。

例如：

var form = {
    value: 2.00
}

对应一个输入框，输入框只能限制输入1-100的2位小数。整个验证过程单向数据驱动就会特别麻烦。

一个简单的例子，在使用react实现表单验证就比较麻烦。

结论三:对于某些具体的模块，单向数据流不是万灵药，总体架构单向数据驱动，具体模块能够根据场景选择最合适的

总结

我的感受数据驱动对于开发人员的要求其实有一些增长，开发是须要更多的全局观，对于业务须要更加的了解。这个其实算是缺点，由于从工程化的角度，这种模式提升了开发成本，提升了开发人员的学习成本。

那么优势呢，应该是系统的稳定性，可维护性，健壮性会更好。

总之没有银弹，每种模式都有适合的场景。以上就是对于数据驱动的一点点见解。仅供参考。

微信公众号

我的博客

http://tangguangyao.github.io/