「前端架构」使用React进行应用程序状态管理( 三 ) React是管理应用程序状态所需的

)}function UserPage({username}) { return ( )}function UserSettings() { // this would be the associated hook for the AuthenticationProvider const {user} = useAuthenticatedUser()}
请注意，每个页面都可以有自己的提供程序，其中包含其下组件所需的数据。代码拆分对这种东西也“管用” 。如何将数据导入每个提供程序取决于这些提供程序使用的钩子以及如何在应用程序中检索数据，但您知道从何处开始查找（在提供程序中）如何工作。
关于为什么这个托管是有益的，请查看我的“State colosition will make your React app faster”和“colocation”博客文章。有关上下文的更多信息，请阅读如何有效地使用React context
服务器缓存与UI状态最后我想补充一点。状态有多种类型，但每种类型的状态都可以分为两种类型：

服务器缓存—实际存储在服务器上的状态，我们将其存储在客户机中以便快速访问（如用户数据）。
UI状态—仅在UI中用于控制应用程序交互部分的状态（如模态isOpen状态）。

当我们把两者结合在一起时，我们犯了一个错误。服务器缓存与UI状态有着本质上不同的问题，因此需要进行不同的管理。如果你接受这样一个事实：你所拥有的根本不是状态，而是一个状态缓存，那么你就可以开始正确地思考它，从而正确地管理它。
当然，您可以使用自己的useState或useReducer在这里和那里使用正确的useContext来管理它。但请允许我帮你直截了当地说，缓存是一个非常困难的问题（有人说它是计算机科学中最难的问题之一），在这个问题上站在巨人的肩膀上是明智的。
这就是为什么我对这种状态使用并推荐react query 。我知道我知道，我告诉过你不需要状态管理库，但我并不认为react query是状态管理库。我认为这是个藏匿处。这真是个好主意。看看！坦纳·林斯利是个聪明的小甜饼。
性能怎么样？当你遵循上面的建议时，性能就很少是个问题了。尤其是当你遵循有关托管的建议时。但是，在某些用例中，性能可能会有问题。当您遇到与状态相关的性能问题时，首先要检查的是有多少组件由于状态更改而被重新呈现，并确定这些组件是否真的需要由于状态更改而重新呈现。如果是这样，那么perf问题不在管理状态的机制中，而是在渲染速度上，在这种情况下，需要加快渲染速度。
但是，如果您注意到有许多组件在没有DOM更新或需要的副作用的情况下进行渲染，那么这些组件将不必要地进行渲染。在React中，这种情况一直都会发生，而且它本身通常不是问题（您应该首先集中精力快速进行不必要的重新渲染），但是如果这真的是瓶颈，那么以下是一些在React上下文中使用state解决性能问题的方法：

将你的状态划分为不同的逻辑部分，而不是在一个大的存储区中，这样对状态的任何部分进行一次更新都不会触发对应用程序中每个组件的更新。
优化上下文提供程序
把 jotai带进来

这又是一个库的建议。的确，有些用例React的内置状态管理抽象不太适合。在所有可用的抽象中， jotai对于这些用例是最有前途的。如果您想知道这些用例是什么，那么jotai很好地解决的问题类型实际上在 Recoil: State Management for Today's React - Dave McCabe aka @mcc_abe at @ReactEurope 2020一书中得到了很好的描述。 Recoil和jotai非常相似（并且解决了相同类型的问题）。但根据我和他们的（有限）经验，我更喜欢jotai 。
无论如何，大多数应用程序都不需要像recoil或jotai这样的原子状态管理工具。
结论同样，这是你可以用类组件来做的事情（你不必使用钩子）。钩子使这变得容易得多，但是您可以用React 15来实现这一理念。尽可能保持状态的本地性，并且只有在支柱钻井成为问题时才使用上下文。这样做会使您更容易维护状态交互。
【「前端架构」使用React进行应用程序状态管理】全网同号，欢迎关注。本文：
（此处已添加圈子卡片，请到今日头条客户端查看）