我的许多同事最近通过各种方式问同一类问题：
“如果我们开始用hook后，那还有必要用Redux吗？”

“React hook不是让Redux过时了吗？那只用Hooks就可以做Redux所有能做的事了吧？”

随便搜一下Google，你就会发现人们也在互联网上问同样的问题。

简单来说，“React Hooks是否替代了Redux”这个问题的答案是：“不”。
更细致不过礼貌的答案是：“嗯，这个取决于你实际项目的类型“。
最终，我倾向于回答人们“我不确定你是否明白自己在说什么”。

“React Hooks取代了Redux”这个论点有着根本的缺陷，其原因有好几个。首先：

Redux从始至终都是可选方案

Redux的作者之一Dan Abramov曾经表达过你可能不需要Redux的建议。如果你本来就不需要某样东西，那你也就不用替换它了。

如果你正在用React，为了用起来Redux，你还得把Redux-Redux装到你的应用里。在项目中使用多个库显然会增加最终应用打包的大小，也就会增加加载应用所需的时间。因此，除非有真正的理由，你不应该使用任何库，如jQuery，Redux，MobX，甚至是React。

当人们问起来hook是否能替代Redux时，他们似乎认为得在这两者之间做出选择，但事实并非如此。如果你正开发的应用不需要存储大量状态，或者组件层次足够简单不需要深层次的prop传递，那么用整个状态管理库方案是没有意义的。无论是否使用hook，应用的状态都足够由React提供的功能进行管理了。

即便你的应用需要管理一个庞大的状态，或者应用的层次结构如古树的根一样错综复杂，你也不一定非得使用状态管理库。深层次传递prop可能很麻烦，但原生的React已经为你提供了包含在hook在内的多种状态管理的选择，他们都能帮你把状态管理的井井有条。Redux是一个轻量级的库，不过配置相对复杂，增加最终打包的体积，还需要做出各种权衡取舍。不在项目中使用Redux有许多合理的理由，所以你并不总是需要用它。

虽然如此，我们还是有许多理由使用Redux。如果你的项目本来就在用Redux，那最开始决定使用Redux应该是有一些好的理由的，比如项目的组织架构需要有一个可预测的，单一事实来源的程序状态；中间件功能；或是强大的开发调试工具。如果你曾有理由使用Redux，那hook并不会让你的这些理由失效。如果你曾需要用Redux，那你也许还得继续用它。

React hook尝试解决问题与Redux不同

Redux是一个状态管理库。Hooks是最近才加入React的新功能，它可以让函数组件支持曾经只在class组件中支持的特性。

那么，用函数组件替换class组件实现React应用会让状态管理库过时吗？答案是否定的。

关于为何开发React hook，官方文档给出了三个主要原因：

class组件的逻辑复用很困难。
生命周期方法内常包含让人困惑的无关逻辑。
class对于机器和人类来说都难以理解。

你可以注意到这些动机都跟状态管理无关。

话虽如此，React hook确实为你提供了状态管理的新选择。值得注意的是，useState，useReducer和useContext这些管理状态的新方法，一定程度上比之前React原生提供的方案更好、更有条理。但React hook没有提供超出之前React版本的新能力，也不会让状态管理库过时。

React hook不会使React应用做任何它以前做不到的事

没错，函数组件可以做到以前只有在class组件才能实现的功能，同时函数组件有更好的代码组织结构和重用能力，但函数组件做不到class组件也做不到的事。React hook的目的不是为了让应用更好，而是为了让开发体验更好。

useState和useReducer只是管理组件状态的方法，其工作方式与class组件中的this.state和this.setState工作方式的大致相同。对于深层传递prop的问题，hook也是无能为力。

人们似乎认为useContext可以把Redux打入冷宫，因为你可以使用它解决状态深层次传递的问题，但它确实不是什么新功能。context API已经存在于React一段时间了。useContext只是让你可以不通过包装组件就能使用context。虽然有些开发人员选择使用context管理整个应用的状态，但context的设计初衷不是如此。官方文档提到：

Context设计目的是为了共享那些对于一个组件树而言是“全局”的数据，例如当前认证的用户、主题或首选语言。

换句话说，放在context中的数据不应该经常更新。

文档还建议要谨慎使用context，因为“它会让代码复用变得更困难“。他们还警告开发人员，如果使用不当，context还会导致不必要的重新渲染。

我见到过一些项目成功使用React context管理整个应用的状态。理论上这确实是一种选择。但context的设计初衷并不包含状态管理，而这是Redux或是其他状态管理库的设计目的。
此外，React hook绝对不意味着Redux的灭亡，如果你瞅一眼React-Redux最近更新的文档，你会看到：

React-Redux也拥有自己的hook了

没错，React hook有助于重振React-Redux库，并移除了一些它的痛点。这与“hook会替代Redux”这个观点相去甚远。

我在另一篇文章深入介绍了React-Redux中的hook。在引入hook之前，你必须定义mapStateToProps与mapDispatchToProps函数、并用connect函数包装你的组件来创建出一个高阶组件。该高阶组件会把dispatch函数与Redux store的一部分状态通过你定义的映射函数作为props，传到被conntext包装的组件中。

我们来看个非常简单的计数器应用示例（实际上因为过于太简单不必使用Redux，但这个例子是为了表达一下信息的概述）。假设我们已经定义了Redux store，并在其他地方定义了增加和减少的动作创建方法。

真是繁琐。如果我们可以不用把组件包装在高阶组件内就能让组件访问到Redux store，不更好吗？没错，这就是hook可以发挥的地方了。hook其主要功能就是代码复用，同时消除高阶组件导致的“包装地狱”问题。

简而言之，useSelector允许你将Redux store的各个状态切片保存为组件的变量。useDispatch非常简单，你可以通过它发出动作更新Redux store。最重要的是，你不再需要实现丑陋的映射函数，并把组件包装在connect函数中了。现在，一切都很好的包含在你的组件里。这样的实现更简短，也就更具有可读性、更有条理。

React hook和Redux不是互为竞争关系的技术

显然，这两种技术可以相互补充。React hook不会“替换Redux”，它只是为你提供了更新、也许更好的方式组织你的React应用；如果你最终决定使用Redux管理应用状态，也许能写出更高内聚的组件。

所以，请不要再问"React hook是否取代了Redux？"的问题了。

相反，请问一下自己：“我在开发怎样的应用？我需要怎么样的状态管理需求？Redux是否对我来说是合理的方案，或者它对于我的需求过度复杂了？如果我决定使用Redux和React hook（或是MobX+Hook, Redux+jQuery等技术组合）我怎样才能让这些技术相互补充，和谐工作呢？”

英文原文： https://medium.com/swlh/stop-asking-if-react-hooks-replace-redux-448c54d79551

创作场景

React Hooks 是不能替代 Redux 的