Где хранить состояние в React
Что проверяют
Есть ли у вас правило выбора места, а не привычка класть всё в глобальное хранилище.
Как отвечать
Правило одно: держать состояние как можно ближе к месту использования и поднимать только по необходимости. Дальше лестница от узкого к широкому.
1. Не хранить вовсе. Если значение выводится из других (отфильтрованный список, признак пустоты, итоговая сумма), его считают при рендере. Хранение производного это гарантированный рассинхрон.
2. Локально, useState или useReducer. Нужно одному компоненту, значит там и живёт. useReducer когда переходов много и они связаны.
3. Поднять до общего предка. Нужно двум соседям, значит поднимаем ровно на один уровень выше, а не в корень.
4. В URL. Фильтры, номер страницы, активная вкладка, идентификатор открытого элемента. Такое состояние переживает перезагрузку, работает с кнопкой «назад» и передаётся ссылкой. Это самое недооценённое место.
5. В кэше серверных данных. Всё пришедшее с сервера это кэш, а не состояние приложения. TanStack Query или RTK Query дают загрузку, ошибку, устаревание, повтор и дедупликацию запросов бесплатно. Самая частая архитектурная ошибка это перекладывать ответы API в Redux руками.
6. В контексте. Редко меняющееся сквозное: тема, язык, текущий пользователь. Помня, что изменение значения перерисовывает всех потребителей.
7. В глобальном хранилище. Redux Toolkit или Zustand, когда есть настоящее общее клиентское состояние со сложными переходами: корзина, редактор, черновик формы через несколько шагов.
8. В хранилище браузера. localStorage для черновиков и предпочтений, с оглядкой на серверный рендер: читать его надо после монтирования, иначе разъедется разметка.
Где спотыкаются
Кладут серверные данные в глобальное хранилище и пишут загрузку и ошибки вручную.
Хранят производные значения и синхронизируют их эффектами.
Держат фильтры в состоянии компонента, из-за чего ссылку нельзя передать.
Поднимают состояние в корень «на будущее» и перерисовывают всё приложение.