Архитектура состояния и данных

Вы классифицируете данные, выберете authoritative source, cache/invalidation policy и согласование параллельных mutations.

До начала достаточно reducers, routing, Actions, async UI и внешние stores. В конце должен появиться не конспект, а карта ownership и работающий cache adapter для списка с optimistic update и conflict recovery.

Различайте local UI, form draft, URL, server state/cache, session и external realtime state. Для каждого запишите authoritative source, scope, persistence, update source и consistency. Один «global state» скрывает эти различия и создаёт неверные reset/invalidation правила.

Рабочая проверка. Заполните таблицу данных продукта до выбора библиотеки.

Типичная поломка. Положить hover, access token и server list в один persisted store.

Server data имеет удалённого владельца, stale/fetch/error semantics и может меняться без клиента. Cache хранит snapshot с key, freshness и invalidation. Копирование query result в client store создаёт второй источник и ручную синхронизацию, если нет независимого draft/workflow.

Рабочая проверка. Удалите Effect, копирующий query data в Redux/local state.

Типичная поломка. После каждого fetch dispatch полного списка в ещё один store.

Key включает все входы, влияющие на результат: resource, id, filters, tenant/user boundary. Один и тот же logical request получает один key; разные auth scopes не делят приватные данные. Объекты параметров canonicalize или формируют структурно по правилам библиотеки.

Рабочая проверка. Создайте key factory и tests для filters/tenant.

Типичная поломка. Key products для всех tenants и фильтров.

Stale time — продуктовая политика допустимой давности, не магическое ускорение. Invalidation помечает связанные entries устаревшими или обновляет cache из mutation response. Broad invalidation проста, но дорога; точечная требует знать зависимости. GC/cache time регулирует память, а не свежесть.

Рабочая проверка. Определите freshness для справочника и остатков склада отдельно.

Типичная поломка. Ставить infinite stale time динамичным данным без push/invalidation.

Перед mutation снимите затрагиваемый cache, примените optimistic patch, на failure rollback/refetch, на success согласуйте server response. Параллельные mutations требуют correlation/version. Blind rollback старого snapshot может стереть более новое успешное изменение.

Рабочая проверка. Завершите две quantity mutations в обратном порядке.

Типичная поломка. Один global previousState для всех параллельных mutations.

При edit conflict сервер возвращает version/ETag mismatch. UI не должен молча перезаписать чужое изменение или потерять draft. Покажите fresh server value, локальный draft и варианты merge/retry. Last-write-wins допустим только как осознанная доменная policy.

Рабочая проверка. Смоделируйте 409 и экран сравнения.

Типичная поломка. Автоматически повторить PUT без version после 409.

Persisted client state становится долговременным форматом. Храните минимум, добавляйте version и migration/clear policy, не сохраняйте secrets и server cache без необходимости. localStorage синхронен, доступен script и может содержать повреждённую строку — чтение начинается с unknown/try-catch.

Рабочая проверка. Мигрируйте preferences v1→v2 и обработайте invalid JSON.

Типичная поломка. Persist всего global store, включая access token и transient errors.

Сравнивайте решение по selectors, devtools, async/cache policy, SSR, bundle, ecosystem и team skill. Redux Toolkit подходит сложным client transitions/event trace; TanStack Query — server cache; Context — доставка стабильной зависимости; route loaders — navigation data. Комбинация нормальна при чётких границах.

Рабочая проверка. Напишите ADR для state stack, включая отказ от ненужных слоёв.

Типичная поломка. Выбрать один store для всего только ради единого DevTools.

Спроектируйте inventory UI: filters в URL, draft в form state, session в provider, products в server cache. Добавьте stale time, key factory, optimistic quantity update, version conflict 409 и rollback/refetch policy.

Критерий завершения: нет копий server entities в global client store без причины, cache keys детерминированы, конфликт не теряет ввод пользователя. Сначала зафиксируйте наблюдаемое поведение тестом или измерением, затем меняйте реализацию.