Внешние сторы: useSyncExternalStore, подписки-селекторы и tearing

Контракт: subscribe, getSnapshot и проверка на tearing

Состояние, которым владеет React (useState, useReducer), версионируется вместе с fiber-деревом, поэтому конкурентный рендеринг никогда не увидит две версии за один проход. У состояния, живущего вне React — модульного синглтона, кеша WebSocket, navigator.onLine, — такой гарантии нет: прерываемый рендер может растянуться поверх мутации, и компоненты, отрендеренные до и после неё, разойдутся в одном закоммиченном кадре. Это tearing (разрыв — когда один рендер-кадр показывает две разные версии одних и тех же данных), и useSyncExternalStore — контракт, который его предотвращает:

const value = useSyncExternalStore(
  subscribe,    // (callback) => unsubscribe; звать callback на каждое изменение стора
  getSnapshot,  // () => текущее значение; ОБЯЗАН возвращать кеш, пока ничего не изменилось
  getServerSnapshot // опционально: значение для SSR + гидратации
);

subscribe регистрирует в вашем сторе собственный колбэк React и возвращает очистку. getSnapshot возвращает текущее значение — и обязан возвращать ту же ссылку, пока стор реально не изменился, потому что React зовёт его многократно и решает по Object.is, сдвинулось ли что-то. Верните свежий объект на каждый вызов (() => ({ ...state })) — и React увидит вечно меняющийся стор: печально известная ошибка «The result of getSnapshot should be cached» и бесконечный цикл ре-рендеров. Анти-tearing-механизм: когда обновление стора приходит во время неблокирующего рендера, React перепроверяет снапшоты и заставляет конфликтующее обновление отрендериться синхронно, жертвуя time-slicing ради согласованности. У старого хука с подпиской через useEffect был и второй изъян помимо tearing: обновления между рендером и подпиской эффекта молча терялись — uSES закрывает и эту щель.

Zustand: подписки-селекторы поверх контракта

useSyncExternalStore намеренно низкоуровневый — один стор, подписка на значение целиком. Zustand — то, как этот паттерн выглядит в виде продукта. Стор создаётся вне React как синглтон уровня модуля — без провайдера, без контекста, импортируем откуда угодно, включая не-React-код:

const useCartStore = create((set, get) => ({
  items: [],
  promo: null,
  addItem: (item) => set((s) => ({ items: [...s.items, item] })),
  total: () => get().items.reduce((sum, i) => sum + i.price, 0),
}));

// Компонент подписывается на СРЕЗ через селектор:
function CartBadge() {
  const count = useCartStore((s) => s.items.length);
  return <span>{count}</span>; // ре-рендер ТОЛЬКО при изменении items.length
}

Механизм — подписка-селектор: хук прогоняет ваш селектор по снапшоту и ре-рендерит компонент, только когда изменился вывод селектора (Object.is по умолчанию; кастомное равенство вроде shallow — по желанию). Запись промокода ре-рендерит ноль компонентов, выбравших только items.length. Сравните с контекстом: каждый потребитель ре-рендерится на любую смену идентичности значения, точка. Классическое самострельное ранение — селектор, возвращающий свежий объект: useCartStore((s) => ({ a: s.a, b: s.b })) — новая ссылка на каждый снапшот, ре-рендер на каждую запись в стор, точность молча исчезла (лечение: два селектора или shallow-равенство).

Когда внешний стор бьёт контекст — и когда состоянию надо обойти React вовсе

Прежде чем тянуться к внешнему стору, спросите: сколько потребителей ре-рендерится на запись, и как часто эти записи происходят? Это не вопрос моды; за каждой стороной механизм. Частые записи: контекст переуведомляет каждого потребителя на запись; стор уведомляет только совпавшие селекторы — при 20 записях в секунду и 50 потребителях это 1 000 рендеров компонентов в секунду против горстки. Доступ сквозь дерево: стор — это импорт модуля; обработчики событий, лоадеры роутов, аналитика и код вне иерархии провайдеров могут читать и писать его; контекст требует находиться под провайдером. Инструменты: middleware (persist, immer, devtools с историей экшенов) подключаются на границе стора. Контекст по-прежнему выигрывает для редко пишущихся, скоупо-образных значений — тема, локаль, текущий пользователь, — где иерархия провайдеров и есть фича, а зависимость — лишний вес.