Хотя и с ним проблем достаточно останется. Если писать только на нативке, без библиотек, у вас либо будет чрезмерно упрощенный и не надежный код, либо собственные библиотеки. Ну либо задачи решаете очень простые, конечно.
Хотя я вот сколько мелких одностраничных лендингов / приложений не писал, все равно для хорошего UX нужно либо написать кучу кода, либо тащить тяжелые библиотеки. Мой опыт. Поэтому Reatom и пишу, пытаюсь решить основные юзкейсы за бандлсайз, который не страшно тащить даже на леднос.
Ну вы не увидели, зачем врать и обобщать мои "редкие кейсы" до "ваш проект становится сложным"? Оскорблять меня зачем? Вся публика хабра соответствующей тематики знакома с вашей агресивной идеализацией мобыкса. Ну посмотрите вы на рынок и сделайте выводы. Идите лучше на конференциях выступать, курсы делайте. А здесь в комментариях от вас только плохое настроение.
Я говорю, "редкие сложные кейсы" и привожу минимальные примеры для понимания. Посмотрите на всю статью, что вы прицепились к одной формулировке? Вам же лишь бы гнуть свою линию и грубить - это токсично и сообществу лучше не делает.
window.SENTRY.captureEvent -> import('/sentry').then({captureEvent} => ...), если быть точным, я думал это и так понятно.
Вы зачем-то чистый доменный код разбавляете системной логикой (аналитикой) или другим доменом (подсказки, например). Не надо фантазировать "ну и норм", надо попытаться проскалировать это на большие модули реальных проектов, примеры которых я не могу привезти и по этическим причинам, и из-за необходимости объяснять кучу контекста.
Можно поискать умные книжки или статьи по событийной архитектуре. Сам посоветовать что-то не могу, т.к. у меня это в голове это все от десятков проектов и летов опыта.
Буду повторять то что о чем уже писал :) Конечно, код без абстракций лучше, чем код с абстракциями и я сам с Reatom пропагандирую процедурный стиль и НЕ предлагаю писать весь код с событийном стиле. Наоборот, я ругаю тот же effector за то что там вообще все на событиях и код так выглядит сложнее и запутанее. Но, как и написано в статье, бывают "редкие, но также важные задачи", которые удобнее решать с описанием логики снаружи модуля. Редкие эти случаи, понимаете? Никто не говорит что отсутствие событийной функциональности делает инструмент неюзабельным, это просто один из факторов, который нужно учитывать.
EE - достаточно общий и часто применяемый паттерн, глупо говорить что он вообще не нужен. Как я уже отвечал в соседней ветке, в реатоме он уже встроен и работает лаконично со всей экосистемой, чем это не плюс?
В мобыксе нет встроенного EE, нужно брать сторонний или писать самому, бороться с гонками (нотификация должна быть только внутри экшена), и все равно это будет костыль сверху.
В реатоме уже есть и и работает нативно и слаженно, включая инфраструктурные тулы (логирование, мокирования для тестов). Оно просто уже есть и уже работает, в этом поинт.
Бред пишите вы, сравнивая библиотеки предлагая брать дополнительные библиотеки и выставляя это как отсутствие сложности.
Речь исключительно о синглтреде, да, лично я все же нахожусь в контексте джаваскрипта и библиотеку на пару килобайт делал под клиентское приложение. Но реактивность это очень простой и общий паттерн, а в каждом конкретном контексте ее применения могут быть свои сложности.
Уточню, в реатоме нет полноценных акторов и соотстветствующей изоляции, нет нормальной возможности из родителя перехватывать ошибку и перезапускать актор, но некоторые свойства акторов есть, например возможность извне декларировать лайфсайкл хуки: onConnect, onDisconnect, onUpdate, которые работают не только на прямые, но и косвенные связи (подписки).
Это статья не про стейт менеджемент. Вы обратили внимание на утверждение "отсутствуют примитивы для описания реактивных процессов". Пример процессов, на которые нужно реагировать я привел. Зачем вы сейчас доказываете то о чем никто не просил?
Спектр задач которые может решать реатом больше, на этом и остановимся.
Факт 1: на изменение стейта в мобыксе подписаться можно, на вызов экшена нельзя.
Факт 2: в реатоме можно подписаться и на изменение стейта и на вызов экшена
Факт 3: с ваших слов, мобыкс может работать только в паре с EventEmitter, те нужно еще где-то его взять. Первоначально вопрос был `что не может решить MobX?`, вы сами на него ответили
Диктовать бизнесу дизайн и UX, запрещая использовать текст для описания состояния загрузки - это мощно!
А current не нужно сразу менять, потому что пока идет загрузка показывается старый список, соответственно со старым индетефикатором. Что будет если лоадинг упадет - будут разные айди и список.
В реатоме тоже можно :) в некоторых случаях там вывод внутренней структуры покрасивее мола будет. Но это все еще заметно сложнее нативных структур, как можно утверждать что 100 байт читать так же просто как 10?
короткий понятный реактивный код
Только этот код с пачкой ошибок. Нет `"Loading post..."`, current должен выставляться после завершения фетчинга.
Да вариантов много. Вот есть у нас процесс оформления заказа. Отдельно пилится менее важный, но полезный модуль подсказок, который никак с критичным процессом оформления не должен быть связан. Он подгружается лениво, подписывается на событие открытия формы заказа (она может быть открыта в разных местах, в том числе в модалке) и ждет событие завершения заказа, или через 1 минуту (это я сейчас придумал), показывает нотификацию "Вам нужна помощь? Напишите нам в чат!".
На мобыксе в моделе заказа придется явно хранить статус заказа, следить за ним. А если азказ завершен нужно хранить причину завершения, от чего можно в некоторых случаях гонки поймать, ведь это не персистентное состояние, а одномоментное. На реатоме достаточно просто следить за экшенами старта и окончания процесса оформления.
Это дискуссионный вопрос, в интернетах о нем спорят. В англоязычной вики статьи по coupling и cohesion по ссылке на русский перевод обе ведут на одну и туже статью, где указаны вместе: "Зацепление, сцепление, связанность, сопряжение".
Спорят, обычно, именно о переводе "cohesion", в статье этот термин упоминается один раз на русском и дважды на английском, а во всех остальных случаях речь идет именно о сoupling и связанности, вроде бы это понятно.
А если еще чуть в сторонку посмотреть...
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 не нужно сразу менять, потому что пока идет загрузка показывается старый список, соответственно со старым индетефикатором. Что будет если лоадинг упадет - будут разные айди и список.
В реатоме тоже можно :) в некоторых случаях там вывод внутренней структуры покрасивее мола будет. Но это все еще заметно сложнее нативных структур, как можно утверждать что 100 байт читать так же просто как 10?
Только этот код с пачкой ошибок. Нет `"Loading post..."`, current должен выставляться после завершения фетчинга.
MVC - по каким признакам делить код. Реактивность - технический способ разделения кода. Одно другому не противоречит, а может и помогать.
Да вариантов много. Вот есть у нас процесс оформления заказа. Отдельно пилится менее важный, но полезный модуль подсказок, который никак с критичным процессом оформления не должен быть связан. Он подгружается лениво, подписывается на событие открытия формы заказа (она может быть открыта в разных местах, в том числе в модалке) и ждет событие завершения заказа, или через 1 минуту (это я сейчас придумал), показывает нотификацию "Вам нужна помощь? Напишите нам в чат!".
На мобыксе в моделе заказа придется явно хранить статус заказа, следить за ним. А если азказ завершен нужно хранить причину завершения, от чего можно в некоторых случаях гонки поймать, ведь это не персистентное состояние, а одномоментное. На реатоме достаточно просто следить за экшенами старта и окончания процесса оформления.
Вот еще один очень упрощенный пример:
Это дискуссионный вопрос, в интернетах о нем спорят. В англоязычной вики статьи по coupling и cohesion по ссылке на русский перевод обе ведут на одну и туже статью, где указаны вместе: "Зацепление, сцепление, связанность, сопряжение".
Спорят, обычно, именно о переводе "cohesion", в статье этот термин упоминается один раз на русском и дважды на английском, а во всех остальных случаях речь идет именно о сoupling и связанности, вроде бы это понятно.