Серверное против клиентского состояния: кто владеет какой истиной

Два вида состояния с противоположной физикой

Прежде чем писать следующий useEffect для фетча, спросите себя: кто реально владеет этой истиной? Инструментарий useState/useReducer/стор из предыдущих уроков управляет клиентским состоянием: истиной, рождающейся в UI — какая вкладка активна, открыта ли модалка, ширина сайдбара. Источник истины — вы; оно синхронно, всегда корректно и умирает вместе с сессией. Серверное состояние — другая субстанция, которая лишь протекает через те же хуки, если ей позволить: список проектов, профиль пользователя, цены. Этой истиной владеет сервер. Ваша копия — кеш чужих данных: асинхронный, общий с другими пользователями, которые их мутируют, и устаревший в момент прибытия. У кешей есть жизненный цикл, которого у клиентского состояния нет: фетч и рефетч, дедупликация параллельных запросов, инвалидация после мутаций, фоновая ревалидация, сборка мусора неиспользуемых записей. Query-библиотека (TanStack Query, SWR, RTK Query) — не «библиотека для фетчинга» (фетч — одна строка). Это менеджер кеша: записи по ключам запросов, отслеживание устаревания, дедуп, ревалидация по фокусу и интервалу, инвалидация от мутаций. Этот жизненный цикл и есть настоящая работа, и его ручная сборка покомпонентно — то, как рождается призрак переименования.

Класс багов: копирование серверных данных в useState

Анти-паттерн выглядит безобидно и прекрасно компилируется:

// АНТИ-ПАТТЕРН: форк серверной истины в локальное состояние
function ProjectList() {
  const [projects, setProjects] = useState([]);
  useEffect(() => {
    fetchProjects().then(setProjects); // приватная копия, замороженная на момент фетча
  }, []);
  // ...
}

// Под управлением кеша: одна общая запись, инвалидируемая мутациями
function ProjectListFixed() {
  const { data: projects } = useQuery({
    queryKey: ["projects"],
    queryFn: fetchProjects,
  });
  // переименование где-то ещё: queryClient.invalidateQueries({ queryKey: ["projects"] })
}

Механизм бага: в момент, когда серверные данные попадают в useState, они форкаются. Компонент владеет снапшотом без ключа, говорящего, копией чего он является, — поэтому никакая мутация не может его найти и инвалидировать; два компонента, фетчащие один ресурс, держат независимые форки, расходящиеся после любой записи; рефетч гоняется с мутацией, и более медленный ответ побеждает, воскрешая старые данные. Каждая «починка» — шины событий, прокинутые колбэки refresh, ручной refetchAll() — это самописная, баг-в-баг, реимплементация инвалидации кеша. Производный вариант коварнее и переживает ревью: useState(props.user.name) «для инициализации» — инициализатор выполняется один раз при маунте, поэтому когда запрос рефетчится и пропсы обновляются, состояние хранит протухший форк. Нужно преобразованное представление серверных данных — выводите его при рендере (const sorted = useMemo(...)): деривация пересчитывается от свежей истины, копия замораживает мёртвую.

Состояние формы: третий вид — намеренный форк

Формы выглядят противоречием: форма редактирования обязана копировать серверные данные в локальное состояние — пользователь печатает в черновик. Разрешение противоречия: черновик — форк нарочно, с явным коммитом. Расхождение с сервером — это фича (пользователь редактирует); submit — точка коммита, отправляющая черновик назад и инвалидирующая кеш. Дисциплина, делающая намеренные форки безопасными: черновик инициализируется из серверных данных один раз на сессию редактирования и никогда молча не пересинхронизируется посреди правки (представьте фоновый рефетч, переписывающий полунабранное поле), а компонент перемонтируется при смене субъекта — key={project.id} на форме, чтобы редактирование другого проекта получало свежий черновик, а не протухший. Библиотеки форм (react-hook-form, формы с actions) — эта дисциплина как продукт: dirty-трекинг, reset-on-success, валидация черновика.

Таблица решений