Как оцениваешь Effector

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

Есть ли у вас собственное мнение, основанное на опыте, а не пересказ документации. Интервьюер хочет услышать, где Effector выигрывает у альтернатив и чем за это приходится платить. Почти всегда следом просят сравнить его с Redux Toolkit или Zustand и рассказать, как вы тестировали модели.

Как отвечать

Начните с устройства. Effector строит статический граф из юнитов:

• createStore: хранит состояние и обновляется только в ответ на события, мутировать значение нельзя;
• createEvent: намерение, «что произошло»;
• createEffect: побочный эффект, обычно запрос. У него есть pending, done и fail, поэтому флаги загрузки руками не заводят;
• sample: главный оператор. По триггеру берёт данные из стора, фильтрует и отправляет дальше. Старые forward и guard устарели, связи пишутся через него;
• fork и allSettled: изолированный scope для SSR и тестов, модель проверяется без рендера компонентов.

Сильные стороны: бизнес-логика живёт вне компонентов и не зависит от фреймворка, есть привязки к React, Vue и Solid, связи явные, тесты через fork пишутся легко. В React используют useUnit из effector-react. Вокруг есть экосистема: patronum с готовыми операторами, Farfetched для работы с запросами.

Слабые стороны назовите честно: высокий порог входа, непривычная декларативная модель, небольшое и в основном русскоязычное сообщество, меньше кандидатов на рынке найма. Вывод: Effector хорошо окупается на сложной бизнес-логике с множеством связей и хуже на простом CRUD.

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

Говорят «проще Redux и подходит для маленьких проектов». На маленьком проекте его декларативность как раз избыточна.

Описывают Effector терминами Redux: «диспатчу экшен в стор». Здесь нет одного стора с общим редьюсером, есть много мелких сторов и явные связи между ними.

Не знают про scope. Без fork на сервере состояние глобальных сторов протекает между запросами, а тесты начинают влиять друг на друга.