React Context API 是否适合大规模应用

如何解决React Context API 是否适合大规模应用

我计划构建一个可能包含数百个组件的大型 React 应用程序。但不确定在 Redux 和 Context API 之间使用什么状态管理系统。

Context API 内置于 React 中，不需要任何第三方库。易于实现，解决了组件不同层级共享状态的问题。

但另一方面，Redux 是行业标准，并且支持中间件来执行异步操作。

如果我选择 Context API，我们如何使用它来管理 API 调用。您还认为将上下文用于我们可能需要大量状态对象的大型应用程序是否是个好主意。

解决方法

Redux 的设计好处是操作不会实现。操作表明发生了某些事情（例如 SAVE_PROFILE_CLICKED），但该操作不执行任何操作（例如连接到 api、发送数据和保存响应状态）。您可以使用上下文 api 执行此操作，但不会强制执行那么多，并且您将没有 redux devtools。该模式称为 event store/sourcing。您可以更改 reducer 并重播事件以查看您的更改是否有效并创建一致的状态，测试更容易，扩展更容易，逻辑更好地隔离，可能还有更多好处。

该设计还将写入状态（reducer）、副作用（thunk）和读取状态（选择器）分开。这种模式（写/读分离）称为cqrs。您的 query/selector 与命令/减速器分开。这让您可以更轻松地进行测试、隔离逻辑、减少重复实现的机会，并且可能带来更多好处。

在使用 Redux 时，您仍然可以将项目弄得一团糟，并且没有完全理解它，因此使用 Redux 并不能保证任何事情。

如果我选择 Context API，我们如何使用它来管理 API 调用。

你可以随心所欲，这个问题太笼统了，无法回答。

您还认为在我们可能需要大量状态对象的大型应用程序中使用上下文是个好主意吗。

如前所述； Redux 不能保证您的项目不会一团糟。它将为您提供更轻松地实现某些模式的工具。确保你理解它和它的模式。大多数示例应用程序并没有说明为什么 Redux 如此强大，因为它们实现的问题（计数器、待办事项应用程序）还不够复杂，甚至不能保证使用它。我只能建议您编写自己熟悉并能理解的代码。