Каждый автор СТМ пишет свои бенчи и именно его библиотека в них всегда выигрывает. А запускать миллионы апдейтов в бенчах и кричать, что там кто-то самый медленный это лицемерие. Тот же effector, который самый медленный, спокойно может рендерить в canvas в 60fps и выше. Что опять же доказывает, что бенчи тупо не показательны. А это все попытка хайпожорить.
Другой момент — удобство разработки. Тот же MobX оказывается довольно удобен на практике и не очень важно сколько он весит и как долго запускается приложение при старте. Но вот будет ли кто-то писать на $mol или Reatom, когда у них около нуля документации, столько же реальных пользователей и сообщества, и это я еще не пишу про синтаксис. Достаточно открыть примеры кода на $mol, чтобы убедиться, что кто-то в здравом уме не будет это использовать.
Сообщество frontend разработчиков придумывает десятки способов изоляции кода, потому что иначе поддержка в большой команде это адский ад, но господин Карловский считает, что весь мир — это идиоты, и надо позволять переопределять КАЖДЫЙ кусочек любого компонента, чтобы в дальнейшем компонент не подлежал дальнейшей разработке. И конечно же отказаться от любого вида модульности в JavaScript (CommonJS, ESModules). Все должны использовать глобальные имена в модулях, ведь импорт нужного имени в локальный скоуп модуля это гораздо сложнее, чем писать каждый раз при использовании полный путь вида $mol_plot_ruler_vert.
А еще, не стоит оценивать бенчмарки по красивым картиночкам и результатам, которые сам автор интерпретирует как ему удобно. Я вижу, что бенчмаркинг это сложнейшая сфера, в которой очень много особенностей, которые нельзя просто так замерить через прогон пару сотен раз и вычисление среднего времени этих прогонов. Именно поэтому я не пишу бенчмарки, скорее всего я сделаю их не правильно и буду обманывать читателя.
Если интересно, почему я пишу этот комментарий, то это потому, что автор пытается замерять одну часть в каждом СТМ и в effector. Но вот незадача в том, что effector это НЕ стейт-менеджер, это штука гораздо более полная. В сообществе его называют data flow manager, и СТМ это лишь часть его. К счастью, инструменты выбирают не только из-за скорости, а еще и благодаря DX, благодаря качественной реализации которого, мы можем получить длительную поддержку проектов.
Назвать Preact, SolidJS и effector стейт-менеджерами это конечно очень смешно. Никакой из инструментов перечисленных выше не пытается быть серебрянной пулей. Все решают определенный скоуп задач для определенной аудитории. А ставить в один ряд очень разные инструменты это конечно бред.
Предлагаю снова думать своей головой. Спасибо, за прочтение!
На мой взгляд здесь слишком много кода. Цель любой архитектуры уменьшить количество ошибок и облегчить разработку большой команде.
Но чем больше кода и элементов в системе, тем сложнее её разрабатывать и поддерживать, ведь появляется всё больше мест для совершения ошибок.
Через 5 лет мучений на разных СТМ и подходах с реактом я пришел к Effector, и три года искал способы писать код в большой команде. Оказалось, что его модели можно класть рядом с VM-компонентом не обременяя себя проблемами огромной кодовой базы. Каждый разработчик у нас в команде думает лишь о двух вещах: как реализовать UI без привязки к логике и как реализовать логику не думая о UI. При этом никто не хочет думать об особенностях CleanArchitecture, мы лишь думаем о данных и событиях, грубо говоря о потоках данных.
Можем пообщаться в Telegram и обсудить подходы, которые мы используем в production. Мне несколько неловко писать огромные статьи на хабр.
Как потом эти бизнес слои связывать вместе используя Flux?
Как это дебажить без вменяемых dev-tools?
redux-symbiote был призван решить только одну проблему: убрать бойлерплейт вокруг экшенов и редюссеров, ни больше, ни меньше.
symbiote — чисто апдейтеры стора, thunk/execute — бизнес-логика, components — отображение данных. Всё тоже самое разделение на слои, только более простое.
Разделять приложение между командами нужно полноценно разделяя приложение на micro-frontends, а не работать всем вместе в огромном монолите.
А вот по поводу качественного разделения: я постепенно перехожу на effector. Где есть и полноценный дебаг и статическое вычисление зависимых сторов, и красивое API, и отстутствие проблемы ромбовидных зависимостей.
Спасибо за вопрос. `createSymbiote` имеет третий параметр namespace/options, с помощью которого можно задать префикс для всех экшен-типов сразу. github.com/sergeysova/redux-symbiote#options
В вашем комментарии скрыта огромная проблема — неопытность в проектировании больших проектов. Ни один человек в здравом уме не будет менять функцию/метод настолько, чтобы потребовалась асинхронщина.
В данном случае правильнее будет написать новую асинхронную фукцию, чтобы как раз, не ломать совместимость с предыдущим кодом. Введение этого «движка» в проект только ухудшит поддержку кода, по нескольким причинам:
— Новый слой абстракции. Это всегда проблема, когда этот слой не нужен.
— Неизвестная технология. Как новичкам, так и старичкам в проекте придется разбираться в работе этого модуля, придется исследовать баги, ждать пока Вы их поправите, или же править их самому.
— Не стандарт. Этого нет в ECMAScript
Каждый автор СТМ пишет свои бенчи и именно его библиотека в них всегда выигрывает. А запускать миллионы апдейтов в бенчах и кричать, что там кто-то самый медленный это лицемерие.
Тот же effector, который самый медленный, спокойно может рендерить в canvas в 60fps и выше. Что опять же доказывает, что бенчи тупо не показательны. А это все попытка хайпожорить.
Другой момент — удобство разработки. Тот же MobX оказывается довольно удобен на практике и не очень важно сколько он весит и как долго запускается приложение при старте. Но вот будет ли кто-то писать на $mol или Reatom, когда у них около нуля документации, столько же реальных пользователей и сообщества, и это я еще не пишу про синтаксис. Достаточно открыть примеры кода на $mol, чтобы убедиться, что кто-то в здравом уме не будет это использовать.
Сообщество frontend разработчиков придумывает десятки способов изоляции кода, потому что иначе поддержка в большой команде это адский ад, но господин Карловский считает, что весь мир — это идиоты, и надо позволять переопределять КАЖДЫЙ кусочек любого компонента, чтобы в дальнейшем компонент не подлежал дальнейшей разработке. И конечно же отказаться от любого вида модульности в JavaScript (CommonJS, ESModules). Все должны использовать глобальные имена в модулях, ведь импорт нужного имени в локальный скоуп модуля это гораздо сложнее, чем писать каждый раз при использовании полный путь вида $mol_plot_ruler_vert.
Прежде чем принимать на веру хоть слово из этой статьи рекомендую изучить "ауру" которая сложилась вокруг автора и результатов его трудов. Как пример, нужно обязательно переопределить base64 encode, но не написать реализацию. https://github.com/hyoo-ru/mam_mol/blob/d190555a186c4936a43d914864c5e58850ca0e92/base64/encode/encode.ts
Вот референс https://mol.hyoo.ru/
А еще, не стоит оценивать бенчмарки по красивым картиночкам и результатам, которые сам автор интерпретирует как ему удобно. Я вижу, что бенчмаркинг это сложнейшая сфера, в которой очень много особенностей, которые нельзя просто так замерить через прогон пару сотен раз и вычисление среднего времени этих прогонов. Именно поэтому я не пишу бенчмарки, скорее всего я сделаю их не правильно и буду обманывать читателя.
Если интересно, почему я пишу этот комментарий, то это потому, что автор пытается замерять одну часть в каждом СТМ и в effector. Но вот незадача в том, что effector это НЕ стейт-менеджер, это штука гораздо более полная. В сообществе его называют data flow manager, и СТМ это лишь часть его. К счастью, инструменты выбирают не только из-за скорости, а еще и благодаря DX, благодаря качественной реализации которого, мы можем получить длительную поддержку проектов.
Назвать Preact, SolidJS и effector стейт-менеджерами это конечно очень смешно.
Никакой из инструментов перечисленных выше не пытается быть серебрянной пулей. Все решают определенный скоуп задач для определенной аудитории. А ставить в один ряд очень разные инструменты это конечно бред.
Предлагаю снова думать своей головой. Спасибо, за прочтение!
Но чем больше кода и элементов в системе, тем сложнее её разрабатывать и поддерживать, ведь появляется всё больше мест для совершения ошибок.
Через 5 лет мучений на разных СТМ и подходах с реактом я пришел к Effector, и три года искал способы писать код в большой команде. Оказалось, что его модели можно класть рядом с VM-компонентом не обременяя себя проблемами огромной кодовой базы. Каждый разработчик у нас в команде думает лишь о двух вещах: как реализовать UI без привязки к логике и как реализовать логику не думая о UI. При этом никто не хочет думать об особенностях CleanArchitecture, мы лишь думаем о данных и событиях, грубо говоря о потоках данных.
Можем пообщаться в Telegram и обсудить подходы, которые мы используем в production. Мне несколько неловко писать огромные статьи на хабр.
Можно использовать аналог render-props Реакта. Но при этом можно навешивать обработчики на элемент, внутри которого этот render-props используется.
Объявлено два props first, second. По месту их вызова появится всё, что будет передано в эти коллбеки.
При этом значения от spec смешиваются. Таким образом можно примешивать нужную функицональность, не прокидывая огромный список пропс.
Таким образом можно убрать из material-ui/button многие пропсы под вызов spec(). Код будет чище, API компонента проще
Как это дебажить без вменяемых dev-tools?
redux-symbiote был призван решить только одну проблему: убрать бойлерплейт вокруг экшенов и редюссеров, ни больше, ни меньше.
symbiote — чисто апдейтеры стора, thunk/execute — бизнес-логика, components — отображение данных. Всё тоже самое разделение на слои, только более простое.
Разделять приложение между командами нужно полноценно разделяя приложение на micro-frontends, а не работать всем вместе в огромном монолите.
А вот по поводу качественного разделения: я постепенно перехожу на effector. Где есть и полноценный дебаг и статическое вычисление зависимых сторов, и красивое API, и отстутствие проблемы ромбовидных зависимостей.
Мб потом статью о нём напишу.
github.com/sergeysova/redux-symbiote#options
Некоторые примеры использования symbiote можно посмотреть здесь: github.com/howtocards/frontend/tree/dev/src/features/cards/symbiotes
В данном случае правильнее будет написать новую асинхронную фукцию, чтобы как раз, не ломать совместимость с предыдущим кодом. Введение этого «движка» в проект только ухудшит поддержку кода, по нескольким причинам:
— Новый слой абстракции. Это всегда проблема, когда этот слой не нужен.
— Неизвестная технология. Как новичкам, так и старичкам в проекте придется разбираться в работе этого модуля, придется исследовать баги, ждать пока Вы их поправите, или же править их самому.
— Не стандарт. Этого нет в ECMAScript