数据驱动模式借助react的实践探索

以前谈到过不少次数据驱动的理解，此次经过实际项目检验了一下本身的想法。

相关文件

《前端数据驱动的价值》

《前端数据驱动的陷阱》

项目详设

详设的重要性

对于复杂一点的项目，作一个详细设计很是重要。有人会疑惑，前端还须要详设吗？
根据个人经验，详设很是重要，很是体现能力。
对于一个新人，详设可以给开发作一些提早准备。
对于一个老手，详设能够提早预见一些隐藏的坑。
对于一个高手，详设须要达到随便给一个有点经验的人，都能直接写代码。

在某种程度上，开发者详设在整个开发周期中占得比重越大，能力就越强。
新人可能只占5%，高手肯能占到50%以上（架构彻底想清楚了，而后剩下用代码去实践设计）。

react详设的步骤

1. 吃透业务，这个无论用什么选型都很重要

2. 顶层数据结构，model必须梳理清晰，model须要可以完整的覆盖业务

3. 业务React Component中每个的props，state布局，props，state中每一项的用处，计算方式，与顶层数据结构的映射函数

4. 业务React Component中每个的Action对于的model改变

5. model上面添加和后端的关联

基本上上面梳理清楚了，后面就能够直接写代码了。

道和术

网上看到不少讲解redux+react的实践思路，设计模型。感受都是实践方式上面的讲解。

比较经典的一张图：

今天我这边想换一种思路去解释他。

数据驱动+react实践的一个前提

相信react的性能！
相信react的性能！
相信react的性能！

快照概念

model能力超级强大，请记住，每一个model都必须可以对应一种页面状态（可以像恢复快照同样）。model和页面状态存在一种一一对应的关系。

以下图：

每个M都和下面的页面对应，用M1能够render出第一个页面，M2能够render第二个页面。

当用户有交互行为时，经过action改变M1到M2，这时你们注意了

慢动做：

用户对M1的页面一作了一个操做（action）让M1产生了改变M',这时M1变成了M2,对应的页面也由页面一刷新成了M2对应的页面二。同理，M2经过交互变成了M3,页面也会刷新成M3对应的页面三。

注意我强调了刷新两个字。

核心就是页面的行为使得数据改变，数据渲染出数据改变后相应的页面。

这个就是我所理解的数据驱动。

为了达到上面目的，其实咱们有意忽略了性能问题。就是用户每次操做都会从新渲染数据，生成对应的新页面。

那么性能问题如何解决，这时react就出场了，性能上，咱们须要借助react的虚拟dom，去比较每一次页面修改的最小diff，而后从新渲染diff部分。因此我上面提到，你须要相信react的性能。

说实话，若是没有这种最小diff的处理能力，这种彻底的数据驱动性能问题很是大。

从上面看，代码其实能够分为两大部分：

1. render: 根据model写渲染逻辑，这部分就交给react,你们仔细看看react的生命周期，都是围绕render的

2. change model: 根据用户的action，修改model的数据，这部分交给redux的模式

数据驱动副产物

单元测试

某种程度上，前端是很是难去写单侧的，由于涉及到dom，哪怕是时间容许，单侧的使用度也不是很高。
对于数据驱动这种模式，至少从数据层，能够规避dom，作一层数据变化的效验（这个和写服务端单侧差很少）。而后有精力和时间，能够加一层model-to-dom逻辑的测试。

用户行为回放

回答上面那个图片，经过model能够记录一个页面的快照，那么若是对于单个用户，单个终端，按照时间轴记录一连串的model，咱们就能够回放用户的操做行为。
以及利用大数据去批量分析用户行为数据。

数据驱动的思考

这种模式某种程度上，是为了提升开发效率，减小页面的复杂度（参考《前端数据驱动的价值》），减小开发的复杂度。

想一想5-6年前，仍是多页面时代，每一个模块都是一个页面，数据都由后端去套模板。而后用户每一个操做基本上都会触发一些刷新。数据驱动和有点相似，只是借用react在单页面上实现了。前端也承担了更多的数据处理工做。

博客地址

http://tangguangyao.github.io/

微信公众号