应用数据流状态管理框架Redux简介、设计思想、核心概念及工作流

tip：有问题或者需要大厂内推的+我脉脉哦：丛培森 ٩( ‘ω’ )و

【本文源址：http://blog.csdn.net/q1056843325/article/details/54784109 转载请添加该地址】

前几天给大家谈了谈React
不过它只是一个侧重于UI的框架
只能算作是MVC中的V（View视图）
而且只是DOM的一个抽象层，不是Web应用完整解决方案
如果仅仅用它构建大型项目
你会非常的吃力
#简介

14年，Facebook提出Flux架构意图解决这个问题
15年，Dan Abramov将 Flux 与函数式编程相结合，创造了Redux，由于简单易学就开始流行起来
16年，Dan Abramov被facebook挖走了

Redux体积很小，如果删掉源码的空行和注释，连500行代码都不到
别看它小（压缩版7KB），却非常有用

#优点
使用它构建web应用有如下优点：

• 预测
  始终有一个准确的数据源，就是store, 对于如何将actions以及应用的其他部分和当前的状态同步可以做到绝不混乱。
• 维护
  具备可预测结果的性质和严格的组织结构让代码更容易维护。
• 组织
  对代码应该如何组织更加严苛，这使代码更加一致，对团队协作更加容易。
• 测试
  编写可测试代码的首要准则就是编写可以仅做一件事并且独立的小函数。Redux的代码几乎全部都是这样的函数：短小、纯粹、分离。
• 服务端渲染
  可以带来更好的用户体验并且有助于搜索引擎优化，尤其是对于首次渲染。仅仅是把服务端创建的store传递给客户端就可以。
• 开发者工具
  开发者可以实时跟踪在应用中正在发生的一切，从actions到状态的改变。
• 社区与生态圈
  存在很多支持Redux的社区，使它能够吸引更多的人来使用。

可能有同学会说，这不是和百度百科一样么
这应该不能算抄吧，其实百度百科redux的词条是我建的o(￣▽￣)d
不过编辑的蛮差劲的，希望各位有时间的时候能补充词条让更多人了解

#使用场景
还要强调的一点就是，不是任何时候都需要用它
如果我们用React遇到瓶颈了，或许我们才需要用到Redux
一般情况它都是配合React使用的（因为React用state描述界面，Redux控制state，配合天衣无缝）
不过也可以配合其他框架（甚至原生JavaScript）

阮大神在这方面总结的很详细
这些情况不需要用Redux

• 用户的使用方式非常简单
• 用户之间没有协作
• 不需要与服务器大量交互，也没有使用 WebSocket
• 视图层（View）只从单一来源获取数据

下列情况建议使用Redux

• 用户的使用方式复杂
• 不同身份的用户有不同的使用方式（比如普通用户和管理员）
• 多个用户之间可以协作
• 与服务器大量交互，或者使用了WebSocket
• View要从多个来源获取数据

组件角度考虑的话，Redux的使用场景

• 某个组件的状态，需要共享
• 某个状态需要在任何地方都可以拿到
• 一个组件需要改变全局状态
• 一个组件需要改变另一个组件的状态

#设计原理
学Redux的时候就觉得很亲切，但不知道亲切在哪儿
后来知道了，这不就是命令模式么
而这个命令command对象就是store

命令模式的应用场景就是：有时需要向某些对象发送请求