Как используются менеджеры состояния во Vue

Что проверяют

Знаете ли вы актуальный стек Vue 3 или рассказываете про Vuex времён Vue 2. И умеете ли отличить состояние, которому место в глобальном сторе, от локального и серверного. Следом часто спрашивают, почему нельзя просто деструктурировать стор.

Как отвечать

Официальный менеджер состояния для Vue 3 это Pinia. Vuex переведён в режим поддержки, новые проекты на нём не начинают, а при миграции главное отличие в том, что мутаций больше нет.

• defineStore: стор объявляется в стиле Options (state, getters, actions) или setup-функцией, где ref становится состоянием, computed геттером, а обычные функции экшенами;
• экшены: синхронные и асинхронные пишутся одинаково, состояние меняется прямо в них или через $patch для пачки полей;
• модульность: вместо вложенных модулей Vuex отдельные сторы, которые импортируют друг друга по мере надобности, а сборщик разносит их по чанкам;
• storeToRefs: достаёт поля состояния и геттеры как ref, сохраняя реактивность при деструктуризации;
• инструменты: интеграция с Vue Devtools, плагины (например, сохранение в localStorage), типизация TypeScript, SSR в Nuxt.

Затем покажите, что не всё состояние глобальное. Форма или открытая модалка живут в компоненте, на пару уровней вниз хватает props и provide/inject, общую логику удобно выносить в композаблы. Данные с сервера (списки, кеш, повторные запросы) лучше отдать TanStack Query для Vue: он сам следит за устареванием и перезагрузкой. Стор остаётся для клиентского состояния: текущий пользователь, корзина, настройки интерфейса.

Где спотыкаются

Пишут const { count } = useCounterStore() и удивляются, что значение не обновляется. Деструктуризация отрывает поле от реактивного объекта, нужен storeToRefs, а экшены берутся прямо со стора.

Описывают Vuex с мутациями как современную норму. Для вакансии на Vue 3 это сигнал, что опыт устарел, стоит знать хотя бы отличия Pinia.

Делают стор через reactive на уровне модуля и используют его в SSR. Такой объект один на весь процесс сервера, и данные одного запроса утекают в ответ другому. В SSR на каждый запрос нужен свой экземпляр createPinia(), Nuxt делает это сам.