react.js中怎么从零开始手写redux

这篇文章主要讲解了“react.js中怎么从零开始手写redux”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“react.js中怎么从零开始手写redux”吧！

成都创新互联服务项目包括太和网站建设、太和网站制作、太和网页制作以及太和网络营销策划等。多年来，我们专注于互联网行业，利用自身积累的技术优势、行业经验、深度合作伙伴关系等，向广大中小型企业、政府机构等提供互联网行业的解决方案，太和网站推广取得了明显的社会效益与经济效益。目前，我们服务的客户以成都为中心已经辐射到太和省份的部分城市，未来相信会继续扩大服务区域并继续获得客户的支持与信任！

1. Redux 是什么？

Redux 是 JavaScript 状态容器，提供可预测化的状态管理。Redux 除了和 React 一起用外，还支持其它界面库。Redux 体小精悍，仅有 2KB。这里我们需要明确一点：Redux 和 React 之间，没有强绑定的关系。本文旨在理解和实现一个 Redux，但是不会涉及 react-redux(一次深入理解一个知识点即可，react-redux 将出现在下一篇文章中)。

2. 从零开始实现一个 Redux

我们先忘记 Redux 的概念，从一个例子入手，使用 create-react-app 创建一个项目: toredux。

代码目录: myredux/to-redux 中。

将 public/index.html 中 body 修改为如下:

                前端宇宙

大家好，我是前端宇宙作者刘小夕

Blue Pink

我们要实现的功能如上图所示，在点击按钮时，能够修改整个应用的字体的颜色。

这个应用非常简单，但是它有一个问题：state 是共享状态，但是任何人都可以修改它，一旦我们随意修改了这个状态，就可以导致出错，例如，在 renderHeader 里面，设置 state = {}，容易造成难以预料的错误。

不过很多时候，我们又的确需要共享状态，因此我们可以考虑设置一些门槛，比如，我们约定，不能直接修改全局状态，必须要通过某个途经才能修改。为此我们定义一个 changeState 函数，全局状态的修改均由它负责。

我们约定只能通过 changeState 去修改状态，它接受一个参数 action,包含 type 字段的普通对象，type 字段用于识别你的操作类型(即如何修改状态)。

尽管现在我们约定了如何修改状态，但是 state 是一个全局变量，我们很容易就可以修改它，因此我们可以考虑将其变成局部变量，将其定义在一个函数内部(createStore)，但是在外部还需要使用 state，因此我们需要提供一个方法 getState()，以便我们在 createStore 获取到 state。

现在，我们可以通过 store.getState() 方法去获取状态(这里需要说明的是，state 通常是一个对象，因此这个对象在外部其实是可以被直接修改的，但是如果深拷贝 state 返回，那么在外部就一定修改不了，鉴于 redux 源码中就是直接返回了 state，此处我们也不进行深拷贝，毕竟耗费性能)。

仅仅获取状态是远远不够的，我们还需要有修改状态的方法，现在状态是私有变量，我们必须要将修改状态的方法也放到 createStore 中，并将其暴露给外部使用。

尽管，我们现在抽离了 createStore 方法，但是显然这个方法一点都不通用，state 和 changeState 方法都定义在了 createStore 中。这种情况下，其它应用无法复用此模式。

changeState 的逻辑理应在外部定义，因为每个应用修改状态的逻辑定然是不同的。我们将这部分逻辑剥离到外部，并将其重命名为 reducer (憋问为什么叫 reducer，问就是为了和 redux 保持一致)。reducer 是干嘛的呢，说白了就是根据 action 的类型，计算出新状态。因为它不是在 createStore 内部定义的，无法直接访问 state，因此我们需要将当前状态作为参数传递给它。如下:

不同应用的 state 定然是不同的，我们将 state 的值定义在 createStore 内部必然是不合理的。

大家注意 reducer 的定义，在碰到不能识别的动作时，是直接返回旧状态的，现在，我们利用这一点来返回初始状态。

要想 state 有初始状态，其实很简单，咱们将初始的 state 的初始化值作为 reducer 的参数的默认值，然后在 createStore 中派发一个 reducer 看不懂的动作就可以了。这样 getState 首次调用时，可以获取到状态的默认值。

现在这个 createStore 已经可以到处使用了, 但是你有没有觉得每次 dispatch 后，都手动 renderApp() 显得很蠢，当前应用中是调用两次，如果需要修改1000次 state 呢，难道手动调用 1000次 renderApp() ？

能不能简化一下呢？每次数据变化的时候，自动调用 renderApp()。当然我们不可能将 renderApp() 写在 createStore() 的 dispatch 中，因为其它的应用中，函数名未必叫 renderApp()，而且有可能不止要触发 renderApp()。这里可以引入发布订阅模式，当状态变化时，通知所有的订阅者。

至此，一个最为简单的 redux 已经创建好了，createStore 是 redux 的核心。我们来使用这个精简版的 redux 重写我们的代码，index.js 文件内容更新如下(to-redux/src/index.js):

如果现在我们现在希望在点击完 Pink 之后，字体色不允许修改，那么我们还可以取消订阅:

顺便说一句: reducer 是一个纯函数(纯函数的概念如果不了解的话，自行查阅资料)，它接收先前的 state 和 action，并返回新的 state。不要问为什么 action 中一定要有 type 字段，这仅仅是一个约定而已(redux 就是这么设计的)

遗留问题：为什么 reducer 一定要返回一个新的 state，而不是直接修改 state 呢。欢迎在评论区留下你的答案。

前面我们一步一步推演了 redux 的核心代码，现在我们来回顾一下 redux 的设计思想:

咱们现在已经有一个基础版本的 redux 了，但是它还不能满足我们的需求。我们平时的业务开发不会像上面所写的示例那样简单，那么就会有一个问题: reducer 函数可能会非常长，因为 action 的类型会非常多。这样肯定是不利于代码的编写和阅读的。

试想一下，你的业务中有一百种 action 需要处理，把这一百种情况编写在一个 reducer 中，不仅写得人恶心，后期维护代码的同事更是想杀人。

因此，我们最好单独编写 reducer，然后对 reducer 进行合并。有请我们的 combineReducers(和 redux 库的命名保持一致) 闪亮登场~

首先我们需要明确一点：combineReducers 只是一个工具函数，正如我们前面所说，它将多个 reducer 合并为一个 reducer。combineReducers 返回的是 reducer，也就是说它是一个高阶函数。

我们还是以一个示例来说明，尽管 redux 不是非得和 react 配合，不过鉴于其与 react 配合最为适合，此处，以 react 代码为例：

这一次除了上面的展示以外，我们新增了一个计数器功能( 使用 React 重构 ===> to-redux2):

显然，修改主题和计数器是可以分割开得，由不同的 reducer 去处理是一个更好的选择。

每个 reducer 只负责管理全局 state 中它负责的一部分。每个 reducer 的 state 参数都不同，分别对应它管理的那部分 state 数据。

appReducer 即是合并之后的 reducer，但是当 reducer 较多时，这样写也显得繁琐，因此我们编写一个工具函数来生成这样的 appReducer，我们把这个工具函数命名为 combineReducers。

子 reducer 将负责返回 state 的默认值。比如本例中，createStore 中 dispatch({type:@@redux/__INIT__${Math.random()}})，而传递给 createStore 的是 combineReducers(reducers) 返回的函数 combination。

根据 state=reducer(state,action)，newState.theme=theme(undefined, action), newState.counter=counter(undefined, action)，counter 和 theme 两个子 reducer 分别返回 newState.theme 和 newState.counter 的初始值。

我们写的 combineReducers 虽然看起来已经能够满足我们的需求，但是其有一个缺点，即每次都会返回一个新的 state 对象，这会导致在数据没有变化时进行无意义的重新渲染。因此我们可以对数据进行判断，在数据没有变化时，返回原本的 state 即可。

官方文档中，关于 applyMiddleware 的解释很清楚，下面的内容也参考了官方文档的内容:

考虑一个小小的问题，如果我们希望每次状态改变前能够在控制台中打印出 state，那么我们要怎么做呢？

当然，这种方式肯定是不可取的，如果我们代码中派发100次，我们不可能这样写一百次。既然是状态改变时打印 state，也是说是在 dispatch 之前打印 state, 那么我们可以重写 store.dispatch 方法，在派发前打印 state 即可。

假设我们不仅仅需要打印 state，还需要在派发异常出错时，打印出错误信息。

而如果我们还有其他的需求，那么就需要不停的修改 store.dispatch 方法，最后导致这个这部分代码难以维护。

我们知道，很多 middleware 都是第三方提供的，那么 store 肯定是需要作为参数传递给 middleware ，进一步改写:

现在还有一个小小的问题，exceptionMiddleware 中的 loggerMiddleware 是写死的，这肯定是不合理的，我们希望这是一个参数，这样使用起来才灵活，没道理只有 exceptionMiddleware 需要灵活，而不管 loggerMiddleware，进一步改写如下：

middleware 接收了一个 next() 的 dispatch 函数，并返回一个 dispatch 函数，返回的函数会被作为下一个 middleware 的 next()

但是有一个小小的问题，当中间件很多的时候，使用中间件的代码会变得很繁琐。为此，redux 提供了一个 applyMiddleware 的工具函数。

上面我们能够看出，其实我们最终要改变的就是 dispatch，因此我们需要重写 store，返回修改了 dispatch 方法之后的 store.

以上是一个 middleware 的情况，但是我们知道，middleware 可能是一个或者是多个，而且我们主要是要解决多个 middleware 的问题，进一步改写。

不知道大家是不是理解了上面的 middles.reduceRight，下面为大家细致说明一下：

观察上面的 middle1(middle2(middle3(store.dispatch)))，如果我们把 middle1,middle2,middle3 看成是数组的每一项，如果对数组的API比较熟悉的话，可以想到 reduce，如果你还不熟悉 reduce，可以查看MDN文档。

阅读过 redux 的源码的同学，可能知道源码中是提供了一个 compose 函数，而 compose 函数中没有使用 reduceRight，而是使用的 reduce，因而代码稍微有点不同。但是分析过程还是一样的。

关于 reduce 的写法，建议像上面的 reduceRight 一样，进行一次分析

redux 还为我们提供了 bindActionCreators 工具函数，这个工具函数代码很简单，我们很少直接在代码中使用它，react-redux 中会使用到。此处，简单说明一下:

以上代码有一个共同点，就是都是 store.dispatch 派发一个动作。因此我们可以考虑编写一个函数，将 store.dispatch 和 actionCreator 绑定起来。

感谢各位的阅读，以上就是“react.js中怎么从零开始手写redux”的内容了，经过本文的学习后，相信大家对react.js中怎么从零开始手写redux这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是创新互联，小编将为大家推送更多相关知识点的文章，欢迎关注！

重庆分公司，新征程启航

react.js中怎么从零开始手写redux

其他资讯