在由上下文 API 管理的状态旁边维护类中的状态是否有意义？答案

【问题标题】：Does it ever make sense to maintain state within classes alongside state managed by context API?在由上下文 API 管理的状态旁边维护类中的状态是否有意义？
【发布时间】：2019-10-23 10:59:42
【问题描述】：

我正在着手重构我的反应状态管理以利用 Context API。

我已经设置了一个基本的状态管理器，并将上下文传递到一个配置文件中，该文件进入单独的表单以避免道具钻取。

State.js

import React, {createContext, useContext, useReducer} from 'react';
export const StateContext = createContext();
export const StateProvider = ({reducer, initialState, children}) => (
  <StateContext.Provider value={useReducer(reducer, initialState)}>
    {children}
  </StateContext.Provider>
);
export const useStateValue = () => useContext(StateContext);

架构

问题

如果我在组件和上下文 API 中进行状态管理，我觉得识别每个组件的状态来自哪里会让人感到困惑，但我喜欢在每个组件中拥有状态的一件事是知道哪些状态属于那个组件。

问题

在上下文 API 旁边维护组件内管理的状态是否有意义？还是我最终应该重构所有状态以由 State.js 管理

【问题讨论】：

标签： reactjs react-context

【解决方案1】：

如果您问我，您应该尽可能在组件级别管理状态。您需要小心使用上下文 api，因为每当上下文中的单个值发生更改导致应用程序性能不佳时，您将重新渲染作为上下文使用者的每个组件。上下文 api 的文档涉及到这一点。它适用于管理用户身份验证或管理主题颜色以及不会发生太大变化但不适用于快速变化的值或复杂存储之类的事情。因此，在表单组件中管理状态，例如每次击键都会更改状态，应该在组件级别进行管理。

所有这些都说上下文 API 非常适合管理不具有高频率的小型商店。但是如果你有一个复杂的 store 连接到很多组件，那么你真的不应该使用 context api，你真的应该使用 redux 之类的东西。设置起来有点麻烦，但您不会像使用 context api 那样不断地重新渲染每个消费者组件。

【讨论】：