Зачем нужен state manager, локальное и глобальное состояние
↑ 5.2 Состояние: Pinia, SSOT, Vue Query · → Следующая
Зачем это на собесе
«Когда нужен стор?» — ждут разбора видов состояния, а не «всегда Pinia».
Объяснение
Виды состояния:
| Вид | Пример | Где хранить |
|---|---|---|
| Локальное UI | открыта ли модалка, значение поля | ref в компоненте |
| Общее для поддерева | контекст формы, тема | provide/inject, composable |
| Глобальное клиентское | текущий пользователь, тема, корзина, настройки | Pinia |
| Серверное (server state) | списки, карточки с бэкенда | TanStack Query (кэш, инвалидация) |
| URL-состояние | фильтры, страница, вкладка | route.query |
| Постоянное | токен, настройки | localStorage + стор |
| Форма | значения, ошибки, dirty | библиотека форм (VeeValidate) |
Симптомы, что нужен стор: prop drilling через 3+ уровня, одно состояние читают далёкие компоненты, нужно сохранять при смене маршрутов, требуется история/отладка (DevTools).
Принципы:
- Держите состояние как можно ближе к месту использования; поднимайте по необходимости.
- Один источник правды для каждого факта (SSOT).
- Производные данные —
computed/getters, а не дублирование. - Изменения — через явные действия (actions), не разбросанные мутации.
- Не кладите в глобальный стор всё подряд и данные сервера (кэш — задача Query).
// Плохо: список заказов в сторе + ручная синхронизация с сервером
// Хорошо: заказы — useQuery, стор хранит выбранный фильтр и пользователяНюансы и подводные камни
- Глобальный стор как «мусорка» усложняет понимание зависимостей.
- Дублирование серверных данных в сторе приводит к рассинхрону.
- Состояние в модульных переменных при SSR утекает между запросами.
- Слишком гранулярные сторы порождают связанность.
Практика
- Классифицируйте состояние вашего приложения по таблице.
- Уберите из стора данные, которые стоит отдать Vue Query.
- Перенесите фильтры таблицы в query-параметры.
Вопросы с ответами
Когда нужен state manager?
Когда состояние разделяют далёкие компоненты и/или оно должно жить дольше компонента; для локальных данных достаточно
ref.
Почему server state отдельно?
У него свои задачи: кэш, инвалидация, состояния загрузки/ошибок, повторные запросы; их решает Query.