79.高效的状态管理

高效的状态管理

如何更有效地在应用中组织状态？
这是我多年来一直在思考的问题，因为状态在应用开发中至关重要，但也很难掌控。

我的主要建议是：

尽量将状态向组件树的底层推进——但不要过头。

在解释为什么之前，我们需要先了解两个概念：状态距离（State Distance）和状态范围（State Scope）。
这些概念支撑了关于状态的大部分讨论，并在我们探索如何更好地结构化状态时非常有用。它们帮助我澄清了自己对“好”与“坏”的模糊直觉，不再仅仅依赖“眼见为实”，我相信它们也能帮助你。

状态的代价

有三大原因使得我们的状态难以处理：

Prop drilling（属性传递）——通过层层组件传递属性会增加耦合度，使代码更复杂。状态传递距离越远，代码越难理解。

Event frothing（事件冒泡）——这类似于属性传递，但用于事件。将事件冒泡穿过多层组件要求记住太多事情，增加了复杂性。

全局状态——由于全局状态可以在任何地方使用，修改它变得更加困难。调试时让人头疼，因为问题代码可能出现在任何地方。

在这些问题中有两个共同的因素：状态距离和状态范围。

状态距离

我们尝试为“坏状态”的模糊直觉赋予更具体的数字。

我们定义一个叫做“状态距离”的概念，类似于算法复杂度，但用于状态。虽然这不是一个可以精确计算到小数点的数字，但它可以帮助我们更好地理解状态的复杂性。

状态距离是指一个状态在你的应用中被最终使用前所经过的路径长度。