前端技术栈(二)：从Flux到Redux

最新推荐文章于 2024-08-06 14:07:25 发布

TurkeyCock

最新推荐文章于 2024-08-06 14:07:25 发布

阅读量821

点赞数

分类专栏：前端技术文章标签：前端技术栈 Flux Redux react-redux reducer

本文链接：https://blog.csdn.net/TurkeyCock/article/details/88373541

版权

本文分析了Flux的不足，包括多Store数据依赖和状态修改非纯函数的问题。接着介绍了Redux的出现，它使用全局唯一Store和纯函数修改状态以支持时间旅行调试。Redux的基本概念包括Store、Reducer、Action、Action Creator、状态读取和订阅以及Middleware。文中还探讨了如何使用react-redux配合React进行更高效的状态管理。

摘要由CSDN通过智能技术生成

上一篇分析了Flux出现的背景和原理，最核心的思想就是“组件化+单向数据流”。

但是，Flux在设计上并非完美，具体来说主要存在以下2个不足：

1. 多Store数据依赖

由于Flux采用多Store设计，各个Store之间可能存在数据依赖。以flux-chat为例：在这个聊天软件里，可能会有多个人给你发消息，比如Dave给你发了3条，Brian给你发了2条，当你点开某个人给你发的消息后，界面需要刷新，显示你目前还有几个人的未读消息没有查看：
在这里插入图片描述
为了解决这个需求，创建了3个Store：

ThreadStore用来存储消息组状态
MessageStore用来存储每个组里的消息的状态
UnreadThreadStore用来计算目前还有几个消息组没有查看

当你点开某个消息组时，显然你需要先更新ThreadStore和MessageStore，然后再更新UnreadThreadStore。由于Store的注册顺序是不确定的，为了应付这种依赖，Flux提供了waitFor()机制，每个Store在注册之后都会生成一个令牌（dispatchToken），通过等待令牌的方式确保其他Store被优先更新。

因此UnreadThreadStore的代码会写成下面这个样子：

Dispatcher.waitFor([
  ThreadStore.dispatchToken,
  MessageStore.dispatchToken
]);

switch (action.type) {
  case ActionTypes.CLICK_THREAD:
    UnreadThreadStore.emitChange();
    break;
  ...
}

虽然可以工作，但是总觉得不是很优雅，在一个Store中需要显示地包含其他Store的调用。当然你会说，干脆把这3个Store的代码糅到一起，搞成一个Store不就行了？但是这样又会导致代码结构不够清晰，不利于多模块分工协作。

为了兼顾这两个方面，Redux使用全局唯一Store，外部可以使用多个reducer来修改Store的不同部分，最后会把所有reducer的修改再组合成一个新的Store状态。

2.状态修改不是纯函数

所谓纯函数，是指输出只和输入相关，相同的输入一定会得到相同的输出。用专业一点的术语来说，纯函数没有“副作用”。我们先来看看Flux中是怎么修改状态的：

Dispatcher.register(action => {
  switch(action.type) {
    case ActionTypes.CLICK_THREAD:
      _currentID = action.threadID;
      ThreadStore.emitChange();
      break;
    ...
}

可以看到，是直接修改变量值，然后显式发送一个change事件来通知View。

我们再来看看Redux中是怎么修改状态的：

export default function threadReducer(state = {}, action) {
  switch (action.type) {
    case ActionTypes.CLICK_THREAD: {
      return { ...state, _currentID: action.threadID };
    ...
}

细心的人可能已经看出来了，主要有3点区别：