浅谈使用hook实现React中的应用状态管理

状态管理可以说是所有应用中最难处理的一部分。这也是为什么当下存在这么多的状态管理工具，并且仍然层出不穷（有一些工具甚至建立在另一些之上，npm 中有大量 “简单版的 redux“）。然而，我认为正是由于我们经常过度设计，才导致这个问题这么难处理。

我们通常把 React 组件看做乐高积木，用它们来搭建应用。我觉着听到这个说法的人，通常会隐隐地觉得这个说法遗漏了和状态相关的那一部分。我自己使用的方法的“秘密”就是：对待状态管理问题时，想想怎么把应用的状态映射到应用的树状结构上面去。

redux 大获成功的原因之一就是它解决了Prop Drilling问题。通过把组件传给一些神奇的 connect 函数就可以让数据共享到应用树的任意地方的做法确实很棒。对 reducers/action creator 的使用也不错，但我仍然坚信 redux 的被普遍使用的原因是它为开发者解决了 prop drilling 所带来的痛苦。

我经常看到开发者把他们所有的状态（state）都放到 redux 中。包括全局状态和本地状态。这会导致非常多的问题，其中最重要的一个是，当你在维护任何状态交互时，都将会涉及到 reducer 、action creator / types 和 dispatch 调用的交互，这最终导致我们必须打开一大堆文件，并在大脑中追溯代码实现，才能弄明白当下发生了什么，以及它对代码库的其它部分产生了什么样的影响。

澄清一下，这样对于全局状态来说是没问题的，但是对于简单的状态（比如一个弹窗是否打开，或者表单中填写的值）来说就会是很大的问题。更糟糕的是，这样基本没法扩展。你的应用越大，这个问题就越难处理。当然，用不一样的 reducer 去管理应用中的不同部分是没问题的，但是通过这些 action creators 和 reducer 来间接处理的方式并不是最好的。

就算没有使用 redux ，把应用中的所有状态全放在一个对象上还是会导致其他问题。当 React <Context.Provider> 获取到一个新的值，所有消费它的组件都会被更新且必须被渲染，哪怕它是一个只关心其中部分数据的函数组件。这就会带来潜在的性能问题（React-Redux v6 尝试使用这个办法，然后发现它不能和 hook 一起工作，这导致他们在 v7 中需要用其他办法来处理）。我的重点在于，如果把状态从逻辑上分隔开并且放在 React 树上对应合适的位置，那你就不用担心这些问题了。