React中store、action和reducer之间的关系

参考链接：别人写的不错的文章，可以进行参考借鉴一下
知乎：理解 React，但不理解 Redux，该如何通俗易懂的理解 Redux？

简书：redux 终于搞明白store reducer action之间的关系
React 实践心得：react-redux 之 connect 方法详解

React中的props和 state

React有props和state: props意味着父级分发下来的属性，state意味着组件内部可以自行管理的状态，并且整个React没有数据向上回溯的能力，也就是说数据只能单向向下分发，或者自行内部消化

在react中组件之间的数据交流

问题：组件之间数据交流的问题

般构建的React组件内部可能是一个完整的应用，它自己工作良好，你可以通过属性作为API控制它。但是更多的时候发现React根本无法让两个组件互相交流，使用对方的数据。然后这时候不通过DOM沟通（也就是React体制内）解决的唯一办法就是提升state，将state放到共有的父组件中来管理，再作为props分发回子组件。

子组件改变父组件state的办法只能是通过onClick触发父组件声明好的回调，也就是父组件提前声明好函数或方法作为契约描述自己的state将如何变化，再将它同样作为属性交给子组件使用。这样就出现了一个模式：数据总是单向从顶层向下分发的，但是只有子组件回调在概念上可以回到state顶层影响数据。这样state一定程度上是响应式的。

解决办法：把所有state集中放到所有组件顶层

解决办法 ：</font

为了面临所有可能的扩展问题，最容易想到的办法就是把所有state集中放到所有组件顶层，然后分发给所有组件。

为了有更好的state管理，就需要一个库来作为更专业的顶层state分发给所有React应用 ，这就是Redux。让我们回来看看重现上面结构的需求：
a. 需要回调通知state (等同于回调参数) -> action
b. 需要根据回调处理 (等同于父级方法) -> reducer
c. 需要state (等同于总状态) -> store
对Redux来说只有这三个要素：

a. action是纯声明式的数据结构，只提供事件的所有要素，不提供逻辑。
b. reducer是一个匹配函数，action的发送是全局的：所有的reducer都可以捕捉到并匹配与自己相关与否，相关就拿走action中 的要素进行逻辑处理，修改store中的状态，不相关就不对state做处理原样返回。
c. store负责存储状态并可以被react api回调，发布action.

react-redux的使用

当然一般不会直接把两个库（react和redux）拿来用，还有一个binding叫react-redux, 提供一个Provider和connect。

provider组件

rovider是一个普通组件，可以作为顶层app的分发点，它只需要store属性就可以了。它会将state分发给所有被connect的组件，不管它在哪里，被嵌套多少层。

connect函数

它是一个科里化函数，意思是先接受两个参数（数据绑定mapStateToProps和事件绑定mapDispatchToProps），再接受一个参数（将要绑定的组件本身）：

connect的第一个参数 mapStateToProps：
mapStateToProps：构建好Redux系统的时候，它会被自动初始化，但是你的React组件并不知道它的存在，因此你需要分拣出你需要的Redux状态，所以你需要绑定一个函数，它的参数是state，简单返回你关心的几个值。

connect的第二个参数：mapDispatchToProps：

声明好的action作为回调，也可以被注入到组件里，就是通过这个函数，它的参数是dispatch，通过redux的辅助方法bindActionCreator绑定所有action以及参数的dispatch，就可以作为属性在组件里面作为函数简单使用了，不需要手动dispatch。这个mapDispatchToProps是可选的，如果不传这个参数redux会简单把dispatch作为属性注入给组件，可以手动当做store.dispatch使用。这也是为什么要科里化的原因。

为什么会出现redux

在数据为王的网络世界中，数据永远都是页面的核心，那么对于数据管理的模式，react采用的是单向数据流模式

，单向也就是数据只能从一个方向流向另外一个方向而不能反过来

如果把dom想象成一颗树，单向数据流就是将数据自上向下的流动，为了让数据流到尽可能多的dom中，肯定要把数据尽可能放的高一点。这里的数据可以简单理解为state，而对于流到下面的数据，dom通过props接收。这样模式就很显而易见了，尽可能高的组件对state进行更新，子组件的props也会随即更新，数据单向流动，

这时候如果想通过子组件来反向更新state，就要通过上层组件传递一个函数，在函数中通过setState等方法来达到反向数据的更新。
其实到这已经可以应付一些简单的应用了，但是对于复杂的应用，组件之间的数据通信有可能是交叉而又错综复杂的，这时候就希望通过一种统一的方式将数据好好管理起来，那么出现了redux。

redux的三剑客

store ----->物流仓库中心

store，把它想象成一个物流仓库中心，数据(state)就是一个个包裹

action ---->包裹的包装 store.dispatch(action)

为了便于对包裹的管理，需要给它们进行包装store.dispatch(action)，比如打上标签action.type，标明这是联邦快递，还是申通快递，你是要寄快递还是退快递，要发到江浙沪，还是发到偏远地带…那对于一个新来的包裹，首先要做的第一步就是包装，这一步由action完成，

reducer---->根据包裹的标签做针对性的处理 reducer(state,action)

圆通的快递员处理圆通快递，申通的快递员处理申通的快递，这一步，由reducer完成，他根据action.type做针对性的处理。如果我想向物流仓库中心发一个快递，就通过store的dispatch方法，先给包裹包装，然后丢到物流中心由一个个快递员(reducer)进行处理。

现实世界和物流中心的管道 connect(react组件和redux的对接)

connect(
	mapStateToProps,
	mapDispathcToProps,
)(App)

connect:作为现实世界和物流中心的管道,他能实时得知任何一个包裹的物流进度，这个包裹是在揽件，还是因为某20停在一个神奇的地方，这些信息connect通过一个函数mapStateToProps()作为参数，在这个函数中有一个state的参数，这个参数就存放着整个物流中心包裹实时物流情况，绝对宝贵，传说只要谁掌握了它，谁就能成为王的男人…那么就可以对这个信息做各种处理mapDispathcToProps，比如某人发了一个圆通快递，从上海发往北京，那mapStateToProps()就可以针对这个包裹的state进行实时更新，他的每一次更新，都可以通过单向数据流的方式传递给那个发快递的人(子组件)。

案例分析

1. 比如有这样一个需求，北京想要得知整个中国的天天快递物流情况，该怎么办？
2. 很简单，通过redux进行统一管理:

   整个中国每一个人发包裹都要通过唯一的物流中心store，这个物流中心暴露一个dispatch方法store.dispatch(action)，用于发快递，比如你要寄天天快递去北京，你就要这样dispatch(tiantian({target:"beijing",msg:'神秘大礼包'}))，将快递丢到物流中心，物流中心的天天快递员(reducer)便会对其进行处理。

3.那么作为掌握第一手宝贵信息的connect，会实时得知来了一个快递，mapStateToProps()通过对state进行分析发现。哎嘿，是天天快递，于是更新了天天快递的物流信息mapDispathcToProps，最后组件通过props的方式传递给北京，于是北京就能实时掌握全国的天天快递物流信息了