Е
Евгений Паромов
@cleanfrontend3.8K подп.
6.4Kпросмотров
15 июня 2025 г.
Score: 7.1K
Вот, что мне не нравится в effector Я долго не касался темы effector в контенте, так как не было достаточного опыта взаимодействия с ним. Но недавно столкнулся со средней кодовой базой, которая активно переписывалась на effector последний год. И разобравшись в ней, я смог сформулировать, что мне не нравится в effector Но начну с хорошего: В эффекторе есть идея, которая мне очень нравится – эвенты выделены, как сущности Это позволяет строить инверсию зависимостей (управления). И по этой причине на effector просто писать по fsd. // Эвент определяется в месте где его вызвают export const buttonClicked = createEvent(); export const Button = () => <button onClick={() => buttonClicked()}>text</button> // В любом месте можно на него подписаться &#036;counter.on(buttonClicked , (count) => count + 1); В остальном, это мог бы быть обычный стейт менеджер с интересной особенностью. Но мы приходим к тому, что мне больше всего не нравится в effector. Effector своей философией пытается всё "поджать" под себя. Ну то есть. Из-за обилия инверсии (эвент, стор и реакция на эвент – это всегда разные сущности) Писать правильно на effector очень сложно. Поэтому написание на effector требует следованию жесткого гайдлайна. Иначе будет дикая лапша, в которой невозможно разобраться. И насколько я понимаю, это признают даже самые ярые поклонники эффектора. А как раз этот гайдлайн максимально "категоричный" В речи фаната effector вы обязательно услышите утверждения: 1. Нужно отделить модель от отображения. Иначе говнокод 2. Бизнес логики не должно быть в ui 3. Ты должен писать бизнес логику так, чтобы можно было убрать react и заменить на условную консоль 4. В хуках не может быть никакой бизнес логики, так как это view слой 5. Бизнес логика – это любая работа с данными, которая не завязана на отображение 6. Effector – идеальный инструмент для описания сложной логики. На хуках только кнопки красить Я с этими тезисами не согласен. Но на выражение моего мнения потребуется сильно больше одного поста. В результате этих утверждений получается следующее: 1. Все hook first библиотеки в топку. Так как это привязывает логику к отображению. Мы должны всё перевести на effector 2. Запросы на хуках в топку – это бизнес логика 3. Локальное состояние в топку – это тоже бизнес логика. А бизнес логика должна быть вне компонентов Результат: 1. Всё становится глобальным состоянием. Сложно переиспользовать код. Нужно писать фабрики, а это ещё сложнее, чем чистый эффектор 2. Effector заполняет собой всё пространство и вытесняет всю React инфраструктуру, заменяя ее effector инфраструктурой. А что нет в effector, приходится писать велосипеды из хлебного мякиша 3. Всё в effector – инверсия зависимостей. Так как по версии effector вся работа с данными это бизнес логика - всё приложение должно быть на effector. Теперь даже самые простые компоненты становятся сложными. 4. Да, сложный асинхронный флоу можно описать красиво. Но обычно сложного в приложениях не так много. В результате, код написанный по всем канонам effector мне читать и модифицировать сложнее, чем 3000строчные компоненты вчерашнего джуна. (В этом же проекте есть не отрефакторенные места) Зафиксируем мое мнение на этом моменте. Мне еще предстоит долго работать с этой кодовой базой. И я не стесняюсь переобуваться. Поживем увидим 🤌🏼 И забавное наблюдение напоследок. За последний год я встречаю уже не первую историю, как один человек затащил effector, а потом всем он не нравится. Но выпилить либо слишком долго, либо сложно 🫠
6.4K
просмотров
3515
символов
Да
эмодзи
Нет
медиа

Другие посты @cleanfrontend

Все посты канала →