Контекст, идентичность value и шторм ререндеров

Механизм: одна проверка идентичности, затем broadcast

Распространение контекста брутально просто. Когда провайдер перерисовывается, React сравнивает новый prop value с предыдущим через Object.is. Если он отличается, React обходит поддерево, находит каждый компонент, читающий этот контекст — через useContext или use, — и планирует каждому ререндер. Два свойства этого обхода определяют каждый контекстный баг, который вы встретите. Первое: доставка обходит bailout-ы memo. React.memo и поверхностно равные props могут остановить спуск родительских ререндеров, но обновление контекста доставляется подписанным потомкам сквозь мемоизированных предков — сами предки остаются пропущенными, а потребитель под ними всё равно перерисовывается. Это by design: потребитель попросил значение, значит, обязан получить новое. Второе: селекторов нет — потребитель не может подписаться только на value.theme. Любая смена идентичности целого value перерисовывает каждого потребителя, изменился читаемый им срез или нет.

Теперь шторм из Hook следует механически. value={{ user, theme, permissions, setTheme }} — объектный литерал в рендере провайдера, свежая идентичность на каждом рендере. Значит, ререндер провайдера по любой причине (нажатие клавиши в несвязанном состоянии, обновление родителя) означает: Object.is(prev, next) — false, все 38 потребителей перерисовываются, их поддеревья — тоже. Содержимое не изменилось; изменилась идентичность обёртки, а идентичность — единственное, что проверяет React.

// ❌ широковещательный шторм: новая идентичность value на каждом рендере каркаса
function AppShell() {
  const [query, setQuery] = useState("");
  return (
    <AppContext.Provider value={{ user, theme, permissions, setTheme }}>
      <SearchInput value={query} onChange={setQuery} />
      <Routes />
    </AppContext.Provider>
  );
}

// ✅ лечение 1: стабильная идентичность — вещание только при смене содержимого
const appValue = useMemo(
  () => ({ user, theme, permissions, setTheme }),
  [user, theme, permissions] // setTheme из useState и так стабилен
);

// ✅ лечение 0 (часто лучше): опустить несвязанное состояние ВНИЗ —
// поле поиска владеет своим query; провайдер вообще не рендерится на нажатия.

Разделение контекстов: state отдельно от dispatch

У самой жестокой детали из Hook — потребители setTheme, перерисовывающиеся при каждом изменении данных, — есть структурное лечение. Функции-обновители состояния имеют стабильные идентичности (setState из useState и dispatch из useReducer гарантированно стабильны), поэтому компонентам, которые только запускают изменения, не нужно перерисовываться при смене данных. Положите данные и обновители в два отдельных контекста:

const StateContext = createContext(null);
const DispatchContext = createContext(null);

function AppProvider({ children }) {
  const [state, dispatch] = useReducer(reducer, initialState);
  return (
    <StateContext.Provider value={state}>
      <DispatchContext.Provider value={dispatch}>
        {children}
      </DispatchContext.Provider>
    </StateContext.Provider>
  );
}

Теперь кнопка тулбара, вызывающая dispatch, подписана только на DispatchContext, чьё value никогда не меняет идентичность, — она перерисовывается ровно ноль раз при обновлениях состояния. Компоненты с интенсивным чтением подписаны на StateContext и перерисовываются, когда состояние действительно изменилось (редьюсер возвращает новый объект, только если что-то поменялось). Два уточнения, на которых держатся реальные приложения: разделяйте и по доменам — ThemeContext отдельно от AuthContext отдельно от PermissionsContext, — чтобы обновление авторизации не перерисовывало каждую темизированную кнопку; и паттерн {children} выше — сам по себе оптимизация: children создаются вызывающим AppProvider, поэтому при изменении собственного состояния AppProvider идентичность элемента children не меняется, и React может пропустить ререндер этого поддерева целиком — провайдер перерисовывается, статичное дерево под ним нет.

Выбор канала: props, контекст или внешний стор

Три механизма доставки — три честных критерия выбора. Прокидывание props — явный поток данных: каждый прыжок виден, рефакторинг прослеживаем, скрытых подписок нет. На 2–3 уровня это просто правильно, а композиция компонентов (передача JSX как children) убирает большую часть «боли прокидывания» вообще без контекста. Его цена — церемония через много уровней и ререндеры вдоль цепочки без мемоизации. Контекст создан для значений с низкой частотой и широким веером: тема, локаль, текущий пользователь, положение роутера, фиче-флаги — то, что меняется несколько раз за сессию и что читают десятки компонентов. Его жёсткие пределы: нет селекторов (каждый потребитель перерисовывается при любой смене идентичности value), и цена обновления пропорциональна числу потребителей. Внешние сторы (Zustand, Redux, Jotai — все построены на useSyncExternalStore) держат состояние вне React и дают каждому компоненту подписку с селектором: ререндер только когда selector(state) вернул значение, отличное от прошлого. Это и есть гранулярность подписки — то, чего контекст дать не может, — и именно она делает высокочастотное состояние (фильтры на уровне нажатий, websocket-тикеры, позиции перетаскивания) жизнеспособным в масштабе. Хук стора сравнивает выбранный срез, а не весь объект состояния, поэтому трейдинговая таблица перерисовывает только строки, чей тикер сдвинулся.

Когда тянешься к контексту, спроси: как часто меняется это значение и скольким компонентам оно нужно? Решение за один проход: меняется редко, читается широко → контекст. Меняется постоянно, или разным потребителям нужны разные срезы → внешний стор с селекторами. Видимые 2–3 прыжка → просто передайте props; тянитесь к машинерии, лишь когда явная версия измеримо болит. Типовой продакшен-провал — обратное: состояние приложения любой частоты свалено в один контекст «чтобы не тащить Redux», что заново выводит шторм из Hook, — а затем внутри провайдера вырастает самодельная система подписок, то есть внешний стор, написанный плохо, без гарантий useSyncExternalStore от tearing.