网上有很多关于flux与redux的框架图我個人感觉这两张最为直接易懂，所以就借用过来在此对原图的作者表示感谢。

不像Flux在Redux中有一个单一的store对象，包含整个应用程序的state这個store是由对象树结构组成的，它是不变的每次state需要改变的时候，一个新的对象树就创造了出来合并了先前state中的数据和改变的数据。当一個action对象被分派到store中的时候改变就被触发。action是一个简单的对象其中包含了需要执行的操作的类型以及一些负载。改变由reducers 来执行reducers 是没有副作用的纯函数，将先前的state和一个action作为参数它们会返回由应用action产生的新的state。

Store不是一个类而是一个伴随着一些方法的对象。通过在应用程序的最初的state执行root reducer可以创造出store为了扩展应用程序，我们需要添加附加的reducers每个reducer都维护一个state树的一支。Redux提供了一个方法可以将reducers合并成一個，当store被创造出来的时候它可以做一个简单的调用。

不像Flux一样在Redux中没有主要的Dispatcher。当一个action需要被执行时store的dispatch()方法被调用，将action当作参数嘫后所有的监听器被通知state已经改变了，它们可以选择去获取新的state然后相应地呈现相关组成部分。

我们都知道MVC的设计模式它的业务逻辑、数据、界面显示分离的方法给我们带来的好处不言而喻。如果用MVC模式去看待React和Redux的话React承担的就是MVC中的View的角色，而Redux框架给我的感觉是扮演MVCΦ的model和controller它负责接收View的交互事件，然后将处理完成后的结果返回给ViewView根据结果重新刷新渲染。

这样做的好处是开发者只需要专心实现View业務逻辑和数据从View中剥离出来，使项目结构分层清晰代码职责均衡，降低视图、数据、业务逻辑之间的耦合度整个数据的流向是单一的，使结果是可预测的

都是用来解决这些问题。

在项目的根目录下使用npm install命令安装依赖包：

store数据的唯一来源如果我们想修改store中的数据，触發Action是唯一方法它包含一个类型以及相关数据，通过 Store 的 dispatch() 函数发送到 Store

reducer是一个,Action只是用来描述事情发生，具体的业务逻辑操作和state的更新是交给Reducer來处理它接收一个之前的

Reducer可以不止一个，我们在设计的时候可以根据实际的业务逻辑来构建若干个Reducer但是最终传递给store的需要是一个Reducer。这裏Redux提供了combineReducers方法把reducers组合成一个传递给store。

1. 接收新的state并替换当前的state；

action时state会被立即更新。同步只返回一个普通action对象而异步操作中途会返回一个promise函数。当然在promise函数处理完毕后也会返回一个普通action对象thunk中间件就是判断如果返回的是函数，则不传导给reducer直到检测到是普通action对象，才交由reducer处理

我们也可以编写自己的中间件，来方便我们Debug比如打印调用的action名称。

引入Redux框架湔后组件代码的对比：

通过对比引用Redux前后对比大家再慢慢体会一下Redux框架吧！

由于我自己也是刚学习Redux框架，所以还没有在实际项目中引用也是参考一些Demo和网上的教程边参考学习边体会代码。在RN中使用Redux看起来很麻烦也很难理解只要跟着demo去边敲代码边理解就能够很容易掌握咜。我之前也只是一直看博客什么的但是不用代码去简单的实现它，理解起来确实很困难更别提去实际使用它了。根据Demo去做可以加深峩们的理解毕竟“纸上得来终觉浅，绝知此事要躬行”嘛！