🎯 Зачем спрашивают
- Проверить кандидат просто знает названия библиотек или хорошо понимает, зачем нужен state
- Отличить поверхностный уровень («Redux решает props drilling») от глубокого понимания (архитектурная предсказуемость, единый источник правды, тестируемость, дебаг)
- Понять, умеет ли кандидат оправдать выбор инструмента контекстом задачи:
- когда state manager избыточен
- когда он даёт ценность (сложные SPA, синхронизация данных)
- Проверить способность кандидата связать конкретные технические детали с бизнес-задачами:
- ускорение онбординга (единая архитектура)
- предсказуемость изменений (меньше багов при рефакторинге)
- упрощение сопровождения и дебага
📝 Ответ
Коротко:
State manager — инструмент централизации хранения, обновления, доставки состояний приложения.
Технология решает проблему хаотичного и непредсказуемого обновления состояний.
Задачей state manager не является избавление от проблемы props drilling, Его задача — сделать изменения состояния предсказуемыми.
Избавление от props drilling — приятный бонус.
Подробнее:
Проблематика
Требования к веб-приложениям с каждым днем растут, из-за чего коду приходится управлять бóльшим количеством состояний, чем когда-либо прежде.
Под состоянием приложения можем понимать:
- локально созданные данные, которые еще не были отправлены на сервер
- состояния пользовательского интерфейса (активный маршрут, выбранные фильтры, лоудеры, состояние пагинации, темизация и т. д.)
- ответы сервера*.
Управлять постоянно меняющимся состоянием сложно. Тем более, если это состояние и логика по его изменению распылены и размазаны по всему приложению.
Представьте себе ситуацию: данные могут обновлять другие данные (они же модели), UI-компонент (он же view) может обновлять данные, что приводит к обновлению других данных, а это, в свою очередь, может привести к обновлению другого UI-компонента.
Без централизованного механизма для управления всем этим будет полная каша. Так вот, state managers призваны упростить этот вопрос.
Мотивация использования state manager
В большинстве современных фреймворков и библиотек есть механизм локального состояния. Например, в React — это state, поставляющийся вместе с базовой библиотекой.
Он неудобен тем, что такое хранилище изолировано от всего приложения в целом и имеет ограничения. К примеру, если вы хотите, чтобы разные независимые UI-компоненты реагировали на какое-либо изменение одних и тех же данных, вам придется либо передавать локальное состояние в виде props дочерним компонентам (что потенциально может привести к props drilling), либо поднимать состояние наверх до ближайшего родительского компонента.
Это может оказаться неудобным, либо этого механизма будет недостаточно. Из-за этого код усложняется — повышается зацепление, так как компоненты зависят от их вложенности, прокидывания лишних props и т. д.
State manager снимает эту проблему, так как создаёт централизованное хранилище, к которому компоненты могут подписываться и получать только нужные данные. Но это, скорее, приятный бонус, потому что основная цель state manager — не избавить вас от props drilling, а сделать изменения состояния предсказуемыми.
⚖️ Компромиссы
- Не всем приложениям нужен state manager: все зависит от задачи и контекста. Часть задач, возлагаемых на state manager, можно переложить на библиотеки для кэширования (react-query). Или, если в приложении мало состояний, можно обойтись связкой useReducer + Context API, вместо того, что тащить целую библиотеку.
- Готовые решения предоставляют функционал devtools, time-travel debugging, middleware (логирование, асинхронные экшены).
🔎 Встречные вопросы
- Чем Redux отличается от MobX?
- Когда state manager избыточен?
- Как соотносятся state managers и библиотеки для data-fetching (React Query, Apollo)? Какая разница между состоянием приложения и серверными данными?
🚩 Красные флаги
- State manager нужен для избавления от props drilling
🛠 Практика
TODO