20000，可见大家对其的热情程度，究竟是什么魔力让大家为之疯狂呢？让我们上车，亲自体验一波试试~~本文章偏向于讲解redux流程。

宅印前端基于 react + redux 的模式开发，我们指定了一套分工明确的并行开发流程。下面通过一个 “苹果篮子” 实例，来看看整个应用开发流程。

(摘苹果的过程模拟请求网络，体现一个异步动作，所以响应看起来有些延迟)

更优雅的方式：如果你想更优雅地使用 react + redux ，欢迎查看我的最新系列文章 。

首先，我们来看看这个实例的原型：

看到这个水果篮子的样子，大家应该可以明白它的功能：你可以做两件事 -- 摘苹果和吃苹果。当你摘苹果时，应用会向后台发送ajax请求索取苹果，每个苹果有两个属性：编号和重量。当你吃苹果掉时，不用告诉后台，在前端偷偷吃掉就好啦~ 同时苹果篮子会显示当前的苹果量和已经吃掉的苹果量。好！那下面我们来开工！

下面先来总体了解一下 redux 应用的基本原理，一图胜千言：

可见整个redux流程的逻辑非常清晰，数据流是单向循环的，就像一个生产的流水线：

这一点对精细化分工协作很有好处。

我们来看看这三个概念：

• store 是应用的状态管理中心，保存着是应用的状态（state），当收到状态的更新时，会触发视觉组件进行更新。
• container 是视觉组件的容器，负责把传入的状态变量渲染成视觉组件，在浏览器显示出来。
• reducer 是动作(action)的处理中心， 负责处理各种动作并产生新的状态（state），返回给store。

NOTE：从对象的包含关系上讲，reducer 是store的一部分，但在逻辑上我们把它分出来，这样会比较容易理解整个redux流程。

我们可以做个形象的比喻，把 js 比喻成巴士，把 store, container, reducer 比喻为三个车站，再把 state 和 action 比喻成两种乘客。这是一趟环路巴士：

redux 只是定义了应用的数据流程，只解决了 “数据层”（model layer） 的问题，一般还会使用 react， angular 等作为“显示层” （UI layer） 来一起使用，我们项目采用 react 作为显示框架。

在开始之前，这里先提供一些介绍react和redux的参考资料，如果在下文遇到哪些点不理解，可以来这里翻看参考资料：

下文的展示的js代码，会用到少量简单的 语法，可以在遇到时参考这里，或自己查找资料：

• / ：es6代码模块化模式

我们会使用 babel 编译器把es6语法编译成es5, 所以大家不必担心浏览器兼容性问题，可以大胆使用es6。

应用的基础配置工作由前端开发主管负责，大家不必详细理解。

按照开发的内容，我们把前端团队分为两个小组： “布局组” 和 “逻辑组”，每个小组有2种任务，一共4种任务。

• 任务2：动态布局 - 使用 JSX 语法对静态布局做动态渲染处理

布局组 要求对 HTML + CSS 布局比较熟悉，只需要会简单的 js 即可， 不需要完整地理解redux流程。
逻辑组 要求对 js 比较熟悉，最好可以比较完整地理解redux流程， 但基本不需要涉及HTML + CSS布局工作。

接下来，先给出我们教程相关的 src 目录。这里大家可以先一扫而过，大概了解即可

- src 源码文件夹：包含项目源码，我们基本都在这个文件夹下做开发
 - containers 容器文件夹：存放容器组件，比如 “苹果篮子”
 - components 组件文件夹：存放普通显示组件，比如 “苹果”
 - services 服务文件夹：存放经过封装的服务，如 ajax服务, 模拟数据服务
 - images 图片文件夹：存放图片资源
 - apis 开发接口文件夹：存放开发接口文档

下面正式开始啦，先从布局组开始。

• 能力要求：只需要会使用 HTML + CSS （SASS）进行布局即可

同时静态布局开发人员还要负责书写样式，宅印的样式使用sass 书写， 下面是的例子是ponent {

我们对比一下之前的写法：

可以发现使用新的方式使代码简洁了很多！

但是，这对于有对象属性提示功能编辑器来说，这种方式会使编辑器无法分析对象属性：

这时，需要一边看actions文件对该actions对象的定义，一边在目标位置填入action，不过这也不是很麻烦。而且对于使用没有对象属性提示的编辑器的开发者来说，这个 drawback 根本就不存在。我们相对推荐使用这种经过dispatch封装的action, 但不要求，大家根据自己的情况使用即可。

对于普通显示组件的actions传递方式，我们统一使用actions属性传递，如下：

普通显示组件使用统一actions属性接受父级的action，可以在组件内部建立mockActions, 这个mockActions 既有文档功能，也有测试功能，非常实用：

* 开关这行代码，用于切换装入的state和actions来源。(为了开关的方便，请把两句代码合成一行) * 在开发阶段打开，使用内部 state 和 action, 开发完成后请注释关闭

点击 “摘苹果” 和 “吃掉” 按钮，我们看看控制台，已经可以发出我们想要的action啦：

好啦，actions 开发的内容就介绍到这里。我们来总结一下我们对action所做的封装：

开发内容： reducer的其实就是action的处理器。其开发的内容很明确清晰，就是开发一类函数，接受action 和 当前的state，返回新的state。

技术要求：要求对js比较熟悉，需要会使用 immutable.js 这个数据静态化库。

下面是reducer功能的图解：

我们先看看我们苹果板块的state的数据结构，非常简单，这里是某个时刻的状态：

• isPicking ：表示是否正在摘苹果，我们在上面已经知道，摘苹果其实是发送一个ajax请求，向后台摘一个苹果，这个请求在进行时我们会把 isPicking 设置为ture, 表明正在摘苹果，同时禁止在完成前再发送摘苹果请求
• apples：是苹果列表数组，存放着苹果对象，苹果对象的结构在apples数组里有给出实例。

我们上面提及actions分为广义的action和狭义的普通action。其实，非普通action, 如thunk，一般会以发起普通action结束。我们reducer只需要处理狭义上的普通action,。在我们摘苹果应用里，总共有这4个普通action:

//通知store应用开始摘苹果

我们可以看到，reducer是一个函数，接受state和action两个参数，在函数内部，根据 action.type 来确定要做哪些操作，并且每种操作都要返回state（或者是新的，或者是原来的）。

我们以 apple/EAT_APPLE动作为例，讲解如何书写reducer。EAT_APPLE 动作的含义是吃苹果，我们可以非常简单地处理这个动作：直接把对应苹果对象的 isEaten 属性设为true即可。

按照一般的思维，我们会这样处理：

但是，这种方法在 redux 应用里看不到作用，因为这种写法不会使store触发react进行重新渲染，为什么呢？因为 newState == oldState ! 下面我们来做一些解释：

首先，要先从js对象的相等判断运算说起，我们看下面的代码

redux 是根据返回的state是否改变来决定是否通知 react 更新的。根据这种情况所，可能有人会这样改进刚才的reducer：

这样一来，点击 “吃掉”按钮，看到了有效果了，苹果不见了！但是，这种写法只是迎合了redux更新视觉组件的触发条件，还具有很大的局限性，不是我们redux规定的reducer。下面我们来看看正确的reducer：

首先，reducer有这样的重要约束：在reducer里，不可以修改原来的state，需要保持使每个版本的state不变。

这种保持数据不变（）的方式在函数式编程（）非常常见。在我们的redux应用里，其意义在于：

1. 调试意义：保持每个版本的state的不变性，使得我们可以跟踪每个时刻的state, 跟踪应用的“发展史”，这个特性为调试带来了很大的方便。

2. 性能意义：保持state不变这个约束引导我们使用局部更新对象的方法，这样会可以非常有效地提高react或其他显示框架的渲染效率。我们先来看看为了保持数据不变性，要怎么对state做更新，以我们的苹果篮子state为例：

为了保证每个版本的state不变性，我们有两种实现方式：“深复制”，“浅复制”。我们来看两种模式的内部原理：

深复制方式：有人会这样想：“保持state的不变性很容易，只需要深复制一个state, 让后在新的state要怎么修改就怎么修改，不ok了吗？”，如下就是深复制

这种方式是一种很低级保持不变性的方式：

1. 没有为渲染环节提供提高渲染效率的铺垫

它只是简单迎合保持数据不变性的约束，虽然有一定调试意义，但是，不但没有提高程序的性能，反而降低了程序的总体性能！没有实践意义。

浅复制方式：浅复制模式只对内部数据发生变化的引用做更新，如下

“state” 对象的内部数据发生变化，所以创建新的state引用；而apples array 内部数据不发生变化，所以就不对该引用做更新！在这个操作中，这种浅复制的方法运行效率比较高，而且其简单地实现了数据不变性，为调试带来方便，同时，也是更重要的，这种浅复制的方式极大地提高了视觉组件渲染阶段的运行效率！我们来对比一下：当用户点击摘苹果时，如果使用“深复制”，渲染程序需要重新遍历整个state对象树来做视觉更新，而使用浅复制来实现数据不变性时，渲染程序只需要遍历state对象的一级子节点即可，而不需要对apples array 做遍历，性能大大地提高。尤其是当苹果很多的时候，两种方式的性能差距是非常明显的。

备注：在react组件里面，要开启条件更新这个生命周期函数 shouldComponentUpdate， 才会对把这个性能提高点释放出来，类似这样：

下面我们再给出 “吃苹果” reducer 进行浅复制的例子：

现在大家应该理解了用浅复制实现数据不变性的原理和意义了，下面我们来看具体的代码实现。

我们的代码用 es6 编写，这里要用到 es6 两个非常方便的特性：

1. 方法，该方法用于产生新的对象

大家可以稍微看一下文档，或者看我下面的例子就知道其用法了：

大家会发现这种浅复制操作在开发的过程会复杂一点，于是就有了 这个专门处理不变性数据的库(也是facebook出品)，它可以使用类似赋值的方式生成浅复制的不变性数据，下面来看看它怎么简化我们的开发：

用了immutable.js后，轻松一行代码搞定！如果团队约定 state 都用 immutable 内部的数据类型，就可以连 fromJS 和 toJS 的转化都省了，超级方便！

到这里， reducer 任务的介绍就结束啦~

至此，我们四个任务都介绍完了，大家应该对redux流程有一定概念了，我们来回顾一下我们的4个任务：

这样子，我们通过流程化把 react + redux 的主要流程都定义好了，这种模式的可构建性很高，可以构建非常复杂的单页面应用，不会因为应用的业务复杂性增加而增加开发复杂性。

并且在这种分工里面，布局组对专注于写样式布局，大多是基本的HTML+CSS 工作；逻辑组专注于开发应用逻辑，基本都是JS工作，分工得到非常明确的规划，人们可以更好地做精自己负责的工作，各个部件的耦合性很低，人员安排灵活性比较大。

这就是我们用苹果篮子实例讲解的react+redux开发流程，大家形成redux流程基本的概念就好，具体的理解还是要在实践中慢慢参透。

一些依赖的JS库没有在这里给大家介绍，大家可以在后面的相关js库中查看。

(摘苹果的过程模拟请求网络，体现一个异步动作，所以响应看起来有些延迟)

• ： js开发环境和打包器
• ： 当下非常火的显示框架
• ： 与react搭配的前端路由器
• ： web应用的状态容器（定义了一套非常清晰的数据传递 流程）
• : js 持久化数据框架
• ： 用于产生模拟后台数据的框架
• : 在项目中，我们仅使用它的非常通行的 ajax 功能

感谢您的阅读，希望这篇文章对大家有帮助，欢迎回复和讨论。

传智播客是一家覆盖全国17所城市,成立超过1...| 总评分0.0| | 浏览量 0