Форма состояния: решение, которое принимаешь до выбора библиотеки

Форма — это решение, а не дефолт

К концу этого урока у тебя будут три вопроса, которые делают такой баг с бейджем невозможным — ещё до того, как ты откроешь документацию по любой библиотеке.

Прежде чем тянуться к Redux, Zustand, Jotai или React Query, ты принимаешь решение потише, но важнее: что вообще является состоянием, где оно живёт и оно ли источник истины или копия другого. Угадаешь форму — и большинство «проблем управления состоянием» не появятся. Ошибёшься — и никакая библиотека не спасёт: ты просто размажешь тот же drift по более красивому API.

Форму любого значения решают три вопроса:

1. Это вообще состояние или производное? Если можно вычислить из существующего состояния прямо в рендере — это не состояние. Хранение создаёт второй источник истины, который рано или поздно разойдётся.
2. Чьё это состояние — клиента или сервера? Список заказов, полученный из API, — это серверный кэш, а не клиентское состояние. Моделировать его как клиентское — самая частая архитектурная ошибка во фронтенде.
3. Кто его читает? Этот ответ — один компонент, поддерево или всё приложение — задаёт, где значение живёт и насколько велик радиус перерендеров.

Ответь на эти три вопроса по порядку — и большинство «проблем управления состоянием» исчезают до того, как ты открыл документацию по библиотеке: выводимые значения не расходятся в принципе, серверный кэш попадает в нужный инструмент, а приватный state ререндерит только владеющее поддерево.

Ловушка производного состояния

Баг с бейджем выше — каноничный провал. count — это results.length. В тот момент, когда ты хранишь count отдельно, ты берёшь на себя инвариант, который фреймворк с радостью держал бесплатно: каждый путь кода, меняющий results, обязан менять и count. Пропусти один путь — обработчик ошибки, оптимистичное обновление, патч по websocket — и значения разойдутся. UI показывает то, что было верным в каком-то прошлом рендере и так и не исправилось.

Рефлекс сеньора: если можно вывести — выводи. Вычисляй в рендере; тянись к useMemo только когда вычисление измеримо дорогое, а не по умолчанию. Мемоизация — инструмент производительности, а не корректности: добавление useMemo не уравнивает «вывести vs хранить», потому что хранимая копия остаётся вторым источником истины даже мемоизированной.

Серверный кэш — не клиентское состояние

Самая крупная ошибка формы — загрузить серверные данные в useState/Redux и обращаться с ними так, будто они твои. Они не твои. У серверных данных есть свойства, которых у клиентского состояния не бывает: они устаревают, их можно рефетчить, их нужно дедуплицировать между компонентами, у них есть состояния загрузки и ошибки, их может инвалидировать мутация в другом месте. Когда ты моделируешь их как обычное клиентское состояние, ты вручную пишешь всё это — обычно плохо. Именно поэтому существуют React Query / TanStack Query, SWR и RTK Query: это библиотеки серверного кэша, а не состояния, и в этом различии вся суть.

Практический раздел, который проводит сеньор:

• Серверный кэш → React Query / SWR / RTK Query. С ключом по запросу, со свежестью, рефетчем, дедупом.
• Клиентское состояние → useState (локальное), Context или Zustand/Jotai (общее). То, чего сервер никогда не знал: какая вкладка открыта, черновик формы, выбор.
• URL → источник истины для всего, что шарится или кладётся в закладки: фильтры, пагинация, id открытой детали. Хранить это только в useState означает: рефреш теряет состояние, а скопированная ссылка мертва.

Колокация задаёт радиус взрыва

Состояние живёт в наименьшем общем предке всех, кто его читает, — и не выше. Поднять значение в глобальный стор «чтобы было доступно» — самая частая причина перерендер-штормов на всё приложение: каждый компонент, подписанный на стор, перерендеривается при изменении, даже те, что не читали изменившийся срез. Мысль Кента Доддса прямая: переместить состояние вниз, туда, где его используют, делает приложение быстрее, потому что React перерендеривает только владеющее поддерево.

Цена реальна на масштабе. Глобальный стор с высокочастотным состоянием (позиция мыши, живой счётчик, нажатия в форме) перерендеривает каждого подписчика на каждое изменение, если не отбирать срезы аккуратно. Atom-библиотеки (Jotai, Recoil) существуют именно чтобы сжать радиус взрыва до компонентов, читающих конкретный атом. Но самый дешёвый фикс обычно структурный: не поднимай то, чем владеет одно поддерево.

Нормализация: трейдофф для реляционного клиентского состояния

Когда ты действительно держишь реляционные данные в клиентском сторе (offline-first приложение, редактор с локальными сущностями), формируй их так, как сделала бы база: плоская мапа по id, а не вложенные массивы. { users: { byId: {...}, allIds: [...] } } вместо users, вложенных в posts, вложенных в threads.

Трейдофф конкретен. Вложенная форма делает чтение удобным (post.author.name), но обновление — кошмаром: поменяй имя одного пользователя, и придётся найти и переписать каждую копию, встроенную по всему дереву, — а пропустишь одну, снова drift, теперь на масштабе. Нормализованная форма делает обновление O(1) (запись одной записи в byId) ценой джойна при чтении (byId[post.authorId].name). Для всего, что часто мутируешь, — нормализуй. createEntityAdapter из Redux Toolkit существует, чтобы сделать это дефолтом. Для read-mostly серверных данных не парься — пусть кэш-библиотека держит сырой ответ.