Хотя и с ним проблем достаточно останется. Если писать только на нативке, без библиотек, у вас либо будет чрезмерно упрощенный и не надежный код, либо собственные библиотеки. Ну либо задачи решаете очень простые, конечно.
Хотя я вот сколько мелких одностраничных лендингов / приложений не писал, все равно для хорошего UX нужно либо написать кучу кода, либо тащить тяжелые библиотеки. Мой опыт. Поэтому Reatom и пишу, пытаюсь решить основные юзкейсы за бандлсайз, который не страшно тащить даже на леднос.
Ну вы не увидели, зачем врать и обобщать мои "редкие кейсы" до "ваш проект становится сложным"? Оскорблять меня зачем? Вся публика хабра соответствующей тематики знакома с вашей агресивной идеализацией мобыкса. Ну посмотрите вы на рынок и сделайте выводы. Идите лучше на конференциях выступать, курсы делайте. А здесь в комментариях от вас только плохое настроение.
Я говорю, "редкие сложные кейсы" и привожу минимальные примеры для понимания. Посмотрите на всю статью, что вы прицепились к одной формулировке? Вам же лишь бы гнуть свою линию и грубить - это токсично и сообществу лучше не делает.
window.SENTRY.captureEvent -> import('/sentry').then({captureEvent} => ...), если быть точным, я думал это и так понятно.
Вы зачем-то чистый доменный код разбавляете системной логикой (аналитикой) или другим доменом (подсказки, например). Не надо фантазировать "ну и норм", надо попытаться проскалировать это на большие модули реальных проектов, примеры которых я не могу привезти и по этическим причинам, и из-за необходимости объяснять кучу контекста.
Можно поискать умные книжки или статьи по событийной архитектуре. Сам посоветовать что-то не могу, т.к. у меня это в голове это все от десятков проектов и летов опыта.
Буду повторять то что о чем уже писал :) Конечно, код без абстракций лучше, чем код с абстракциями и я сам с Reatom пропагандирую процедурный стиль и НЕ предлагаю писать весь код с событийном стиле. Наоборот, я ругаю тот же effector за то что там вообще все на событиях и код так выглядит сложнее и запутанее. Но, как и написано в статье, бывают "редкие, но также важные задачи", которые удобнее решать с описанием логики снаружи модуля. Редкие эти случаи, понимаете? Никто не говорит что отсутствие событийной функциональности делает инструмент неюзабельным, это просто один из факторов, который нужно учитывать.
EE - достаточно общий и часто применяемый паттерн, глупо говорить что он вообще не нужен. Как я уже отвечал в соседней ветке, в реатоме он уже встроен и работает лаконично со всей экосистемой, чем это не плюс?
В мобыксе нет встроенного EE, нужно брать сторонний или писать самому, бороться с гонками (нотификация должна быть только внутри экшена), и все равно это будет костыль сверху.
В реатоме уже есть и и работает нативно и слаженно, включая инфраструктурные тулы (логирование, мокирования для тестов). Оно просто уже есть и уже работает, в этом поинт.
Бред пишите вы, сравнивая библиотеки предлагая брать дополнительные библиотеки и выставляя это как отсутствие сложности.
Речь исключительно о синглтреде, да, лично я все же нахожусь в контексте джаваскрипта и библиотеку на пару килобайт делал под клиентское приложение. Но реактивность это очень простой и общий паттерн, а в каждом конкретном контексте ее применения могут быть свои сложности.
Уточню, в реатоме нет полноценных акторов и соотстветствующей изоляции, нет нормальной возможности из родителя перехватывать ошибку и перезапускать актор, но некоторые свойства акторов есть, например возможность извне декларировать лайфсайкл хуки: onConnect, onDisconnect, onUpdate, которые работают не только на прямые, но и косвенные связи (подписки).
Это статья не про стейт менеджемент. Вы обратили внимание на утверждение "отсутствуют примитивы для описания реактивных процессов". Пример процессов, на которые нужно реагировать я привел. Зачем вы сейчас доказываете то о чем никто не просил?
Спектр задач которые может решать реатом больше, на этом и остановимся.
Факт 1: на изменение стейта в мобыксе подписаться можно, на вызов экшена нельзя.
Факт 2: в реатоме можно подписаться и на изменение стейта и на вызов экшена
Факт 3: с ваших слов, мобыкс может работать только в паре с EventEmitter, те нужно еще где-то его взять. Первоначально вопрос был `что не может решить MobX?`, вы сами на него ответили
Диктовать бизнесу дизайн и UX, запрещая использовать текст для описания состояния загрузки - это мощно!
А current не нужно сразу менять, потому что пока идет загрузка показывается старый список, соответственно со старым индетефикатором. Что будет если лоадинг упадет - будут разные айди и список.
Это какое-то чудо, вы просто повторяете уже разобранные аргументы и примеры кода. Не знаю что вам ответить.
Я вижу все комментарии и не отвечаю на те, которые уже зашли в тупик, потому что кто-то ходит по кругу и не слышит ответов которые ему уже давали :)
Да конечно. Еще вот очень рекомендую для личного ознакомления: https://habr.com/ru/companies/ruvds/articles/737114/
Писал подчти о том же еще в конце 2022, но тлг каналы не гуглятся. Видимо, надо переезжать на сайт...
https://t.me/artalog/568
А если еще чуть в сторонку посмотреть...
https://github.com/artalar/RTK-entities-basic-example/pull/1/files
Пока нативного AsyncContext нет - все так :)
Хотя и с ним проблем достаточно останется. Если писать только на нативке, без библиотек, у вас либо будет чрезмерно упрощенный и не надежный код, либо собственные библиотеки. Ну либо задачи решаете очень простые, конечно.
Хотя я вот сколько мелких одностраничных лендингов / приложений не писал, все равно для хорошего UX нужно либо написать кучу кода, либо тащить тяжелые библиотеки. Мой опыт. Поэтому Reatom и пишу, пытаюсь решить основные юзкейсы за бандлсайз, который не страшно тащить даже на леднос.
Было бы интересно сравнение с https://www.reatom.dev/package/async/ :)
Ну вы не увидели, зачем врать и обобщать мои "редкие кейсы" до "ваш проект становится сложным"? Оскорблять меня зачем? Вся публика хабра соответствующей тематики знакома с вашей агресивной идеализацией мобыкса. Ну посмотрите вы на рынок и сделайте выводы. Идите лучше на конференциях выступать, курсы делайте. А здесь в комментариях от вас только плохое настроение.
Я говорю, "редкие сложные кейсы" и привожу минимальные примеры для понимания. Посмотрите на всю статью, что вы прицепились к одной формулировке? Вам же лишь бы гнуть свою линию и грубить - это токсично и сообществу лучше не делает.
window.SENTRY.captureEvent->import('/sentry').then({captureEvent} => ...), если быть точным, я думал это и так понятно.Вы зачем-то чистый доменный код разбавляете системной логикой (аналитикой) или другим доменом (подсказки, например). Не надо фантазировать "ну и норм", надо попытаться проскалировать это на большие модули реальных проектов, примеры которых я не могу привезти и по этическим причинам, и из-за необходимости объяснять кучу контекста.
Можно поискать умные книжки или статьи по событийной архитектуре. Сам посоветовать что-то не могу, т.к. у меня это в голове это все от десятков проектов и летов опыта.
Буду повторять то что о чем уже писал :)
Конечно, код без абстракций лучше, чем код с абстракциями и я сам с Reatom пропагандирую процедурный стиль и НЕ предлагаю писать весь код с событийном стиле. Наоборот, я ругаю тот же effector за то что там вообще все на событиях и код так выглядит сложнее и запутанее. Но, как и написано в статье, бывают "редкие, но также важные задачи", которые удобнее решать с описанием логики снаружи модуля. Редкие эти случаи, понимаете? Никто не говорит что отсутствие событийной функциональности делает инструмент неюзабельным, это просто один из факторов, который нужно учитывать.
EE - достаточно общий и часто применяемый паттерн, глупо говорить что он вообще не нужен. Как я уже отвечал в соседней ветке, в реатоме он уже встроен и работает лаконично со всей экосистемой, чем это не плюс?
В мобыксе нет встроенного EE, нужно брать сторонний или писать самому, бороться с гонками (нотификация должна быть только внутри экшена), и все равно это будет костыль сверху.
В реатоме уже есть и и работает нативно и слаженно, включая инфраструктурные тулы (логирование, мокирования для тестов). Оно просто уже есть и уже работает, в этом поинт.
Бред пишите вы, сравнивая библиотеки предлагая брать дополнительные библиотеки и выставляя это как отсутствие сложности.
Тут подробно описал https://t.me/artalog/846
Иметь разные очереди батчинга - так себе идея.
Зачем раздувать этого тормознутого монстра ещё больше :)
Лично моя нелюбовь к мобыксу обусловлена ещё и неприятием использования прокси - слишком много проблем с ними.
Речь исключительно о синглтреде, да, лично я все же нахожусь в контексте джаваскрипта и библиотеку на пару килобайт делал под клиентское приложение. Но реактивность это очень простой и общий паттерн, а в каждом конкретном контексте ее применения могут быть свои сложности.
Уточню, в реатоме нет полноценных акторов и соотстветствующей изоляции, нет нормальной возможности из родителя перехватывать ошибку и перезапускать актор, но некоторые свойства акторов есть, например возможность извне декларировать лайфсайкл хуки: onConnect, onDisconnect, onUpdate, которые работают не только на прямые, но и косвенные связи (подписки).
Это интересно :)
Только стоит отменить, что транзакции в реатоме уже есть: https://www.reatom.dev/core#ctxschedule
Это статья не про стейт менеджемент. Вы обратили внимание на утверждение "отсутствуют примитивы для описания реактивных процессов". Пример процессов, на которые нужно реагировать я привел. Зачем вы сейчас доказываете то о чем никто не просил?
Спектр задач которые может решать реатом больше, на этом и остановимся.
Факт 1: на изменение стейта в мобыксе подписаться можно, на вызов экшена нельзя.
Факт 2: в реатоме можно подписаться и на изменение стейта и на вызов экшена
Факт 3: с ваших слов, мобыкс может работать только в паре с EventEmitter, те нужно еще где-то его взять. Первоначально вопрос был `что не может решить MobX?`, вы сами на него ответили
Диктовать бизнесу дизайн и UX, запрещая использовать текст для описания состояния загрузки - это мощно!
А current не нужно сразу менять, потому что пока идет загрузка показывается старый список, соответственно со старым индетефикатором. Что будет если лоадинг упадет - будут разные айди и список.