为什么 React 项目仍然使用 Redux

最近有很多讨论，为什么 Redux 不再是状态管理的好选择，以及为什么我们应该使用 hooks 和 React Context API。

作为一名 Redux 用户，我想解决 Context API 和 Redux 之间的战争。那就让我们战斗开始吧！⚔️

为什么使用 Redux

Redux 流行的原因如下：

• 易于测试
• 单向数据流使其具有确定性
• 状态为只读
• 使用纯函数进行更改
• 庞大的生态系统

Redux 想要解决的问题是可预测的状态更新。了解状态变化的位置和原因，并拥有“单一事实来源”可能是一个优势。

我个人认为最大的优点是可测试性。

大型应用程序是建立在大量测试之上的。🤓

当应用程序超过一定规模时，很明显没有工程师会确切知道所有模块和小部件的作用。

这就是测试发挥作用的地方。测试是优秀软件的基础。而 Redux 代码非常容易测试。 

Redux 在大型 React 应用中久经考验。这些应用将会长期存在并继续使用它。几乎一半的 React 应用都在使用 Redux（根据民意调查和开发者调查）——所以你大概就能理解它为何如此受欢迎，又为何如此不受欢迎了。

Redux 生态系统

Redux 拥有庞大的工具生态系统，可以帮助开发者完成状态管理以外的其他工作。以下是简短的列表，更详尽的列表请见此处。

调试

• redux 开发者工具
• redux-logger

副作用

• redux thunk - 用于异步状态处理
• redux saga - 基于 ES6 生成器，非常适合复杂的异步流程
• redux observable - 基于 RxJS 的 Redux 中间件
• redux persist - 正如其名称所述 - 持久化存储，因此您无需在用户下次刷新应用程序时再次加载所有内容 - 使其成为离线优先的应用程序

集成

• redux socket.io - 使用流行的 socket.io 实时通信库
• redux react firebase - firebase 集成

还有很多很多……

如果使用 Redux 需要考虑什么

警惕反模式：

🐛 将本应为本地状态的状态变为全局状态

例如，将表单数据设置为全局变量——这太愚蠢了。表单数据提交到服务器后就没有任何价值了。

🐛 服务器状态 - 想象一下，如果你存储的只是服务器状态，而不是全局应用程序状态，在这种情况下，可以考虑使用react-query或swr 之类的解决方案。这些工具内置了自动缓存 + 重新获取等功能。

🐛 状态重复 - 这是一个常见的状态管理问题。应尽可能避免状态重复，并在需要时获取状态。

🐛 在 Reducer 之外进行状态更新
不要这样做：

const initialState = {

  complexObjectArray: []

}


const badPracticeReducer = (state = initialState, action) => {

  switch(action.type) {

    case "UPDATE": return {...state, ...action.payload}

<span class="nl">default</span><span class="p">:</span> <span class="k">return</span> <span class="nx">state</span><span class="p">;</span>



    

    




}

}


const nextState = badPracticeReducer(initialState, {

  type: "UPDATE",

  payload: someArray.map(createComplexObject)

})

学习最佳实践

您可以在此处找到 Redux 最佳实践和应避免事项的详尽列表- 由 Redux 维护人员编制。

2020 年你应该学习 Redux 吗？

是的- 如果您想获得一份 React 工作，那么您去的公司使用 Redux 作为其产品的可能性是 50%。

但不仅仅是因为这一点 - Redux 流行的概念 - 单向数据流、纯函数、不可变状态更新仍然值得学习，并将使您成为更好的软件工程师。🌟

那么 Context API 怎么样？

虽然我也提倡在新应用程序中使用 Context API，但我没有这样做，因为我不喜欢 Redux 或者我不承认使用 Redux 的好处。

我只是提倡对新开发者来说复杂性更低的解决方案。使用 Context API 比 Redux 更容易，因为它总是能与你已经熟悉的 hooks（例如useState或）配合使用useReducer。

Redux 给我们的应用程序增加了一层额外的复杂性，我们需要仔细权衡。

结论

我认为Redux非常适合高复杂度的应用。而且，当 Redux 生态系统中的库能够发挥作用时（例如，如果 Sagas 能够更轻松地推理复杂的异步流程），Redux 也是一个很好的选择。

当与 React 生态系统的新手一起工作并且你并不真正需要 Redux 生态系统中的东西时，我会使用Context API。