通俗易懂地理解Redux-CSDN博客

通俗易懂的理解Redux

最近在学习React在学习到有关Redux的状态管理的时候真的是看了很久但还是不能说了解的很透彻，经过看了很多篇文章才逐渐对Redux做到了有所了解，希望可以通过这篇文章让更多不懂Redux的同学能够理解它，也算是有所作用了，可会被说标题党了吧。（逃

虽然我们可以通过Redux的官方文档可以得知，它是一个JavaScript状态容器，所以他并不是只能和React配合使用，但我们还是要先了解React—这个它最常被使用到的场景。

官方文档内容:

Redux 是 JavaScript 状态容器，提供可预测化的状态管理。

可以让你构建一致化的应用，运行于不同的环境（客户端、服务器、原生应用），并且易于测试。不仅于此，它还提供超爽的开发体验.

Redux 除了和 React 一起用外，还支持其它界面库。它体小精悍（只有2kB，包括依赖）。

了解需求

第一步，我们先去探索Redux是在什么情况下被编写出来解决什么问题的，知己知彼，方能百战不殆。首先我们先来看下React的特点:

React 中有两个重要的特性: props和state, props 是父级向下分发的属性，而 state 则是组件内部自己管理的状态，并且 React 的数据流是自项而下的,它不存在向上传递数据的能力，因为这个特性， React 的数据只能够单向地向下分发或者内部消化。

举个例子来说的话：React 的数据源是一条河的源头，它(数据)汇聚成河流向下游地区流动，每个地区用水（数据）时只能得到上游流下来的水（props）以及自己通过水库存的水（state），而上游却不能让河流逆流来得到下游的水资源。
通常地，我们构建的一个 React 组件即实现了某种功能，可以称作完整的应用，它有良好的父子关系，数据在这种良好的关系中有秩序的单向流动，但当我们想让两个同级的组件相互交流时，我们发现他们无法直接进行交互。BTW，我们可以通过 DOM 来解决这个问题，可这就违背了我们使用 React 的期望（尽量地减少直接对 DOM 的操作），我们可以通过提升State来解决这个问题，我们将两个组件要用的数据放在他们的共同父组件中，然后通过这个父组件 props 分发给两个组件。
此时子组件想要改变父组件的 state 就需要通过 onClick, onChange 等来触发父组件声明好得回调，所以相当于父组件要提前声明好方法来确定如何改变state, 然后将改变好的state作为属性交付给子组件使用，这样就完成了一次组件间的交互。（概念上的响应）

可能听了上面的说明，你还是云里雾里的，那么下面我通过一个例子来讲解这个概念：

我们假设一个完整的 React 应用是一所学校，一个学生（组件）想向他的同桌（同级组件）说下一节是上物理课，但是他不能直接告诉他（不可以同级组件直接交互），他必须先向他们的班主任（共同的父组件）说：“下一节上物理课”，老师记在了自己的笔记本（state）上，然后老师向每一位同学发放一张纸（props），上面写着 ”下一节上物理课“，此时他的同桌就知道了，”哦，原来下一节是物理课。“

可是有时也有可能是一个班的同学想向另一个班的同学传达某个信息，或者一个班的同学想向另一个班的老师传达某个信息，这个时候我们找谁呢？哦，我们想到了学校的掌管者——校长（顶级父组件），此时，一个同学向校长反应了一个情况，校长向全校的师生每人发了一个文件，上面写着这个情况，这个同学想传递信息的另一个同学或者老师就获取到了这个信息。

Redux的出现

为了更好地管理state，我们需要一个库来作为专业的顶层 state 分发给所所有的组件， Rudex 出现了。

先来介绍以下 Redux 的主要内容：

action：回调向state发起通知 => 回调的参数

action 是一个纯的声明，它只提供事件的参数，但不提供任何的逻辑。
reducer：根据回调进行处理state => 相当于之前在父级中提前声明好的方法

reducer 是一个匹配函数， action 在发送时是发向全局的，所以所有的reducer都会接受到这个action，之后他会判断这个 action 是否与自己相关，相关就拿走 action 中提供的参数进行逻辑处理来修改 store；若不相关，就什么也不做。
store：就是顶层父级的 state => 所有组件的总状态

负责存储状态，相当于大脑，它可以被 React api 回调，通过dispatch方法发布 action。

我们接着那个学校的例子讲：

但校长平常就有很多事情要处理，若每天大大小小的事情都要校长亲自处理，肯定是要忙不过来的，于是校长请了一位专业的人员来管理——教导主任（Redux）。教导主任上任便进行了改革：首先，不在把所有的东西都存在校长那里了，先解放了校长的劳累，而是存在教导主任的信息库（store）里。其次，确立了公文格式，不论谁向教导主任汇报信息，都要按格式发公文（action）来确保统一性。再者，成立了很多部门（reducer），管理不同的事务，教导主任接到公文（action）会向所有的部门发送，有关部门看到这个事情是自己管的就去处理，然后向教导主任处的信息库进行数据修改，不是则什么也不做，等待其他通知。

果不其然，自从教导主任接手后，学校的管理更加的有秩序有效率，校长也有空去处理更大的事务，整个学校（React 应用）井然有序地运行着。

优化的应用 react-redux

在我们的日常应用中，我们一般不会直接使用两个库，而是使用一个 Redux 提供的 React 绑定库 —— react-redux。

react-redux 向我们提供了两个东西：

Provider 是react-redux向我们提供的用来作为顶层组件的普通组件。它只需要一个属性——store,用来存放我们的顶层 state 然后将它分发给所有 connect 的组件，不论它在哪儿。
connect 是一个柯里化（Currying）的函数，它先要接受两个参数：（数据绑定mapStateToProps 和事件绑定 mapDispatchToProps），再接收一个参数，就是要绑定的组件本身。

柯里化：它是把接收的多个参数的函数转换成接收单一参数的函数的操作。它返回接收余下的参数并且返回结果的新函数。

更多有关柯里化的内容可以看这篇文章，这里就不做细致的论述了。

[翻译]JavaScript中的柯里化（Currying in JavaScript）
- mapStateToProps 当我们构建好 Redux 的应用时，它会自动初始化，可是我们的 React 组件不知道它的存在，此时我们分拣出我们需要的 Redux 状态中的内容，我们通过绑定一个函数（参数为state来返回我们需要的几个值）
- mapDispatchToProps 我们可以用已经声明过的 action 作为回调，之后注入到组件里，它的参数是 dispatch ，通过 redux 的辅助方法bindActionCreator绑定所有的 action 以及参数的 dispatch，就可以在组件里面作为函数简单使用，就不需要手动 dispatch。这个参数是可选的，如果不传 redux 就会简单的把 dispatch 作为属性诸如给组件，手动当 store.dispatch 使用。

接着学校的例子讲：

在高度信息化的今天，教导主任提议，我们也应该响应信息化（react-redux），于是在校长的支持下，学校接入了信息化管理平台（Provider），在这个平台上存储有所有之前在教导主任处存储的信息（store），然后他会向每一个连上网络（connect）的教职工发放信息（state）。如果没有连上网络（connect），教职工是无法访问到信息平台的，也就不能获取平台发布的信息。但是由于有些人同学每天要看教育信息，而有的管理人员要看政务信息，如果都一股脑的把所有信息发给这些人就会很麻烦，所以教导主任决定，学生们连入学生网，管理人员接入政务网，学生网设置他只获取信息库中的教育信息（mapStateToProps），而政务网设置他只获取信息库中的政务信息（mapStateToProps）。信息管理平台为了更加有秩序的管理教职工的公文发布（action），所以它提前设置了几种提事务的类型为教材事务申报、维修事务申报、学籍事务申报等（mapDispatchToProps），提哪种事务就会直接自动提交到有关部门，不需要部门人员一个一个去看是不是和自己部门相关的了，从教职工到有关部门的工作人员的办事效率都提高了，全校师生不禁赞叹：信息化真好。

虽然这个例子可能不是很合适，但我尽可能的用通俗易懂的方式讲解了redux的逻辑与内容，相信不懂的你能够有所感悟，而已经懂了的你会有更深一步的认识。：）