Как оцениваешь библиотеку Zustand

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

Понимаете ли вы, как Zustand устроен внутри и откуда берутся лишние перерисовки, или просто пользовались create по туториалу. Следом обычно просят сравнить его с Redux Toolkit и Context и спрашивают, как вы работаете с ним при SSR.

Как отвечать

Суть: стор это обычный объект вне React, компоненты подписываются на него хуком с селектором. Под капотом useSyncExternalStore, провайдер не нужен.

• create((set, get) => ({...})): состояние и действия описываются вместе, set по умолчанию сливает новое значение с текущим на верхнем уровне;
• селекторы: useStore((s) => s.user) перерисует компонент только при изменении user. Без селектора компонент подписан на весь стор;
• useShallow: нужен, когда селектор возвращает новый объект или массив. В v5 такой селектор без него уводит компонент в бесконечный цикл обновлений;
• middleware: persist для localStorage, devtools для Redux DevTools, immer для мутирующего синтаксиса, subscribeWithSelector для подписок вне React;
• createStore из zustand/vanilla: стор без React, его можно использовать в сервисах и тестах.

Оценка: маленький API, почти нет шаблонного кода, легко начать и легко вынести логику из компонентов. Минусы: нет встроенных правил структуры, поэтому в большой команде стор без договорённостей расползается; нет кэша запросов, для серверных данных лучше TanStack Query. В Next.js модульный стор на сервере общий для всех запросов, поэтому стор создают на каждый запрос и передают через контекст.

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

Говорят, что Zustand работает на прокси. Это про Valtio и MobX, а Zustand хранит неизменяемое состояние и сравнивает результат селектора по ссылке.

Достают весь стор деструктуризацией const { a, b } = useStore(). Тогда изменение любого поля перерисует компонент.

Кладут в Zustand ответы API и заново пишут загрузку, ошибки и инвалидацию, которые уже решены в TanStack Query.