Каким боком @effectorjs помогает выстроить архитектуру приложений? Очень просто: он является языком описания бизнес-логики. А еще и помогает связать логику с представлением.
К чему мы привыкли? Встраиваем управление состоянием внутрь React. И после этого продолжаем называть REACT библиотекой, хотя он уже давно ФРЕЙМВОРК.
Мне не нравится такое положение. Из-за возраста React нам приходится очень долго ждать ConcurrentMode, терпеть издевательства StrictMode и наглости memo.
Чего я хочу от библиотеки рендеринга? Простого разделения ответственности, изящной интеграции СТМ, не сложного SSR, зависимости от состояния.
Да. Я хочу, чтобы вьюха зависела от бизнес-логики и подчинялась её законам. Чтобы не приходилось вымучивать интеграцию, и не пытаться адаптировать БЛ под Реакт. Бесит!
Помните нас «ублажали», что Реакт это «функция от состояния»? Мол, передали пропсы сверху в корневой компонент и получили всегда одинаковое состояние?
Ага. Только если не используем хуки и классовые компоненты. Очевидно, что нужно иметь способ управлять состоянием приложения снаружи.
Взять даже пресловутый SSR. Посмотрите на костыли NextJs, для того, чтобы запустить релевантные функции загрузки данных.
Просто вдумайтесь: чтобы сделать SSR, пришлось построить огромный ФРЕЙМВОРК поверх реакта и новую экосистему! Экосистему, Карл!
Чем дольше я пишу на реакте и чем больше создаю веб-приложений, тем больше убеждаюсь, что вьюха должна строиться вокруг бизнес-логики. Написал модель — прицепил вьюху.
То, что делает Redux, RxJs и MobX так это встраивание БЛ внутрь жизненного цикла слоя представления. А это сразу же накладывает кучу тупых ограничений:
БЛ-процесс запускается из вьюхи, а значит на сервере ждет проблема в виде необходимости вытащить этот запуск из вьюхи, либо рендерить несколько раз, чтобы запустилось точно всё.
А в браузере нужно дождаться рендера компонента, чтобы запустить логику. Вместо того, чтобы запустить логику сразу, а рендерить уже компоненты по актуальным данным
Нельзя просто так запустить логику вне компонента. Ведь СТМ лежит в контексте и извлечь наружу весьма проблемно. Придется создать служебный компонент и иже с ним...
...логику использования этого служебного компонента(привет reatom), потерю семантичности jsx разметки. Притом, что у нас и так слишком много всяких служебных Provider, которые не про вьюху, а про какие-то данные
Если нужно, чтобы БЛ работала по своему особенному жизненному циклу не связанному с ЖЦ реакт компонента, то извините, придумывайте костыли.
Я крайне не понимаю людей, которые рекомендуют не брать СТМ и писать на чистом реакте. Это же билет в один конец — станция метро «Наследие».
Очень легко писать WriteOnly код. А как потом разбираться в куче memo и неизвестных причин рендера/ремаунта, которые запускают логику повторно?
