我正计划构建一个可能包含数百个组件的大型 React 应用程序。但不确定在 Redux 和 Context API 之间使用什么状态管理系统。
Context API 是内置在 React 中的，不需要任何第三方库。易于实现，解决了组件不同层级共享状态的问题。
但另一方面，Redux 是行业标准，并且支持中间件执行异步操作。
如果我选择上下文 API，我们如何使用它来管理 API 调用。您还认为在我们可能需要大量状态对象的大型应用程序中使用上下文是一个好主意吗？
【问题讨论】：
标签： reactjs react-redux react-hooks react-context redux-observable
Redux 的设计优势在于操作没有实现。动作表示发生了某事（例如 SAVE_PROFILE_CLICKED），但该动作不执行任何操作（例如连接到 api、发送数据和保存状态响应）。您可以使用上下文 api 执行此操作，但不会强制执行分离，并且您不会拥有 redux 开发工具。该模式称为event store/sourcing。您可以更改 reducer 并重放事件以查看您的更改是否有效并创建一致的状态，测试更容易，扩展更容易，逻辑更好地隔离，可能还有更多好处。
该设计还将状态写入（reducer）、副作用（thunk）和读取状态（选择器）分开。这种模式（写/读分离）称为cqrs。您的 query/selector 与命令/减速器分开。这使您可以更轻松地进行测试、隔离逻辑、减少重复实现的机会，并且可能会带来更多好处。
你仍然可以在使用 Redux 时把你的项目弄得一团糟，并且没有完全理解它，所以使用 Redux 并不能保证任何事情。
如果我选择 Context API，我们如何使用它来管理 API 调用。
你可以随心所欲，这个问题太笼统了，无法回答。
您还认为在我们可能需要大量状态对象的大型应用程序中使用上下文是个好主意吗？
如前所述； Redux 不能保证你的项目不会一团糟。它将为您提供更轻松地实现某些模式的工具。确保你理解它和它的模式。大多数示例应用程序没有说明为什么 Redux 如此强大，因为它们实现的问题（计数器、待办事项应用程序）不够复杂，甚至不足以保证使用它。我只能建议您编写自己熟悉且可以理解的代码。
【讨论】：