怎么看待Redux

怎么看待Redux

以下均出于个人理解，查证可能不足，欢迎读者指正。

可以说Redux是流行框架React不折不扣的最佳伴侣。React管理显示，贤内助Redux管理数据。除了优雅的设计和高逼格的理论概念，易于上手和为数据管理提供的便利（其实并不一定）深深吸引了前端儿们。

很多技术文章会将Redux的能力吹的神乎其神，但在我的眼中它并没有那么神奇。它就是在Web API基础上创造的一件亲民的艺术品，一件包装精美的工具。

为什么这么说呢？让我们从它提出的几个主要概念开始看起。

State

State直译为状态。它在Redux里就是数据模型，或者说是当前的某一部分数据。

这些数据是用于应用的显示，所以可以说这些数据就代表了应用的状态。

比如最简单的Todo list，每一个todo包含了todo内容、状态（完成、未完成）。这里每个todo可以称为todo state，而这个包含todo顺序的列表又可以称为todo list state。

再如稍微复杂一些的个人博客，假设这个博客没有用户概念，只有博客文章和文章的分类。那就可以想象这里可以有：

• 分类列表 state
• 每个分类的博客list state
• 博客内容 state

Store

Store的官方解释：

The Store is the object that brings them together. The store has the following responsibilities:

• Holds application state;
• Allows access to state via getState();
• Allows state to be updated via dispatch(action);
• Registers listeners via subscribe(listener);
• Handles unregistering of listeners via the function returned by subscribe(listener).

从这里可以看出，Store就是整个应用的数据仓库，它是State的集合，也是连接Action、Reducer、State这几个主要构成的桥梁。

Action

Action的官方解释：

Actions are payloads of information that send data from your application to your store. They are the onlysource of information for the store. You send them to the store using store.dispatch().

这里可以看出Action其实是store.dispatch 方法传递的指令和相关参数、数据。

也就是说store.dispatch 会将Action指令发送给所有挂载在Store上的Reducer，让Reducer根据指令和“Action”提供的相关数据处理更新现有的State。

简单来说，Action只是用来告诉Reducer发生了什么，这些是你可能需要用的数据。然后它就啥都不管了。

由于Redux作者给出的关于Action的实例通常如下：

store.dispatch({
    type: TODO.COMPLETE_TODO
    data: 'xxx'
});

我们也就习惯了默认将Action认为是一个包含type属性的对象。实际上，只需要跟Reducer约定好处理的方式，action可以是任何类型，任何内容，没有限制。

看到这里，是不是感觉这跟"发布/订阅"模式有些神似？

store.dispatch(action)即是Redux里的”发布者“，而Reducer即是“订阅者”。

Reducer

Reducers specify how the application’s state changes in response to actions sent to the store. Remember that actions only describe what happened, but don’t describe how the application’s state changes.

如Action一节中所说，Reducer负责接收store.dispatch(action)发送过来的指令和相关数据，并且对现有State进行处理，并返回处理过后的State，更新我们的Store。

注意上一节中我将Reducer比做发布/订阅模式里的订阅者。但它们并不相同。

不论dispatch了什么Action，所有挂载在Store上的Reducer都能依次接收到，并且可以对State进行处理，全看你代码怎么写。自由度很大。

除此之外

除此之外，实际应用当中我们还引入了其他一些概念。

比如Selector。Selector是用来从Store中选出显示或者做其他处理通常所需要的一些数据，并做一定的整理。

其实就是客户端数据库？

说到这里，有没有感觉Redux其实就是包装了一个"客户端数据库"出来？

Store => 数据库

State => 数据表

Action => 查询指令

Reducer => 存储过程、数据锁等

Selector => 数据库视图

不过这个“数据库”只把数据存在了浏览器内存里。当然也可以借助一些中间件，存到localStorage或者IndexDb，与真正的DB更近一步。

最后

思考到这里，只是想感叹一下，万变不离其宗。世间的很多东西，其实都是在混乱上制定了一些规则，理顺了整个过程，从而达到了神奇的效果。这点在编程中尤其明显。