我仍然在Reaction项目中使用Redux进行全局状态管理

在我参与的每个绿地反应项目的开始，都会出现一个问题：我们如何管理全球状态？我们总是争论使用Redux与使用Reaction上下文和钩子滚动我们自己的全局状态管理解决方案的优点。我们最终为每个项目选择了Redux，原因如下。

(这篇文章专门通过Reaction上下文将Redux与自定义状态管理进行了比较。您还应该检查一下其他状态管理解决方案，如RECOIL、MobX和Apollo。)。

我仍然使用Redux的主要原因是它被Reaction社区广泛采用。Redux已经存在了大约五年，因此有很多资源可以帮助指导我们的实施决策。Redux官方网站上有很多信息可以帮助您开始或维护使用Redux的项目。

自从Redux被广泛采用以来，已经有大量的库来扩展Redux。当我可以使用Thunks或Sagas时，为什么要使用我自己的异步操作解决方案呢？当我可以使用redux-undo或undox时，为什么要实现一种撤消操作的方法？Redux社区已经解决了很多问题。

在决定Redux和自定义解决方案之间的关系时，Redux DevTools本身可以用作参数。查看操作的调度顺序和每个操作之间的状态差异对Reducer开发来说是一件好事。在撰写本文时，我还没有找到一个广泛采用的调试工具，可以与useReducer相媲美。

归根结底，自定义状态管理解决方案看起来与Redux非常相似，那么我为什么不使用Redux呢？

话虽如此，Redux并不总是解决问题的办法。每个软件问题都是不同的。一些项目将不需要全球状态管理。其他的可以在没有Redux提供的所有额外功能的情况下工作得很好。归根结底，你应该根据手头的问题做出决定。