Привет, нет, но есть много статей у Дмитрия Карловского (автора $mol), который очень активно сравнивал его инструмент с другими, соответствено и c mobx и с другими реактивными штуковинами
Устал терпеть это и перешёл в спотифай, и оказывается начал осознавать что моя волна все время сувала мне одинаковые песни, которые либо есть в моих лайках, либо я уже слушал на этой неделе. Спотифай в итоге мне прижился, песни новые, все исполнители есть
Очень нравится ангуляр и его флоу работы с данными , слоем представления и кодом в целом, но у меня очень горький опыт с RxJS и нечитабельным кодом, который он порождает
Логично будет спросить - а где тогда хранить бизнес логику ? Ответ, я уверен, все прекрасно знают - бизнес логику нужно хранить отдельно от слоя представления в инструментах, поддерживающих реактивность данных, то есть в стейт менеджерах, но не тех стейт менеджерах, которые не способны существовать без реакта.
Стоит подметить один неприятный момент , да wrapper hell , HOC это не очень хорошо, но есть ещё такой момент – hook hell , где у тебя каша из react хуков и вся бизнес логика, вынуждено живёт в слое представления, что не есть хорошо э
Абсолютно с вами согласен, оставляя существующий проект на съедение вайбкодингу, без какого либо рефакторинга и контроля того, что пишет ИИ — учесть проекта сведётся к нечитабельному коду, дубликатам и хаосу, ну и ещё ИИ все равно будет труднее понимать такой проект. Увы руководство и менеджеры вышестоящие над разработчиками не всегда это понимают и больше заставляют забывать о качестве и выдавать количество (функционала)
Не могу сказать что безответственных очень много, потому что сам недавно, к сожалению, попал в такую историю, что исправлять баги нам запретили, потому что основной фокус нужно тратить на фичи.
В итоге я , как и несколько других разработчиков, видят очень много багов, их заводят, но ничего с ними не делают (хоть я лично и хочу, чтобы наша система была идеальной)
В общем это я к тому что баги хоть и создают разработчики, но не чинят их не потому что они их не хотят починить, а просто потому что им не дают времени на это
Отброшенный рендер - актуально только для сценария без ViewModelStore, что не основной кейс. С ViewModelStore viewModels.attach() просто инкрементит ref-count, что безопасно. Без стора действительно есть ограничение при работе с Suspense - это описано в доке. Перенос mount() в Layout Effect решил бы его, но требует нетривиального рефакторинга - синхронный mount в рендере нужен для SSR и совместимости с mobx-react observer.
StrictMode - работает корректно. В проде useRef сохраняет экземпляр через unmount/remount, lastAttachedInstanceRef предотвращает повторный attach. В дев режиме useMemo может пересоздать экземпляр при remount, но пуллинг по id в сторе не даст дублирования, а без стора очистка отработает корректно. При этом лично я StrictMode не использую - на мой взгляд, инструмент, который меняет поведение в дев и не идентичен поведению в продакшне, применять нельзя.
В общем утечек памяти в самом observer я с уверенностью могу сказать что нет, потому что у нас вкладка с фронтом (два фронта: главное приложение + iframe приложение внутри) после работы GC занимает память 84-86 МB
Важный момент: мы не используем React хуки вовсе в слое представления для БЛ (кроме юайных хуков вроде useTable), поэтому прокси не отправляются в массив зависимостей в хуках, как и не используются в замыканиях в хуках. Это может быть связано с утечками
В данный момент мы разрабатываем чисто CSR апку, но на гитхабе у меня можно найти пример работы MobX в режиме SSR (GOZON), а также да, как вы упомянули, можно использовать mobx-tanstack-query + написать некий стор который имеет базовое состояние-слепок стейта
Отсюда это все кажется костыльненько, потом ещё и приклеили компайлер который оборачивает в хуки блоки кода
Как в реакте 19 задетектить что файбер реакта не будет отвергнут ДО рендера ?
Пример
Есть проблема с suspense + lazy что реакт может делать файберы в каком то смысле “впустую” отсюда и строгий режим.
Зачем рядовому вайбкодеру знать какие то nodejs typescript?
Привет, нет, но есть много статей у Дмитрия Карловского (автора $mol), который очень активно сравнивал его инструмент с другими, соответствено и c mobx и с другими реактивными штуковинами
Приветствую next адепта!
Ого, спасибо! Тема интересная и достаточно новая!
Устал терпеть это и перешёл в спотифай, и оказывается начал осознавать что моя волна все время сувала мне одинаковые песни, которые либо есть в моих лайках, либо я уже слушал на этой неделе. Спотифай в итоге мне прижился, песни новые, все исполнители есть
Красиво и практично!
Успехов вам в продвижении
Очень нравится ангуляр и его флоу работы с данными , слоем представления и кодом в целом, но у меня очень горький опыт с RxJS и нечитабельным кодом, который он порождает
Логично будет спросить - а где тогда хранить бизнес логику ?
Ответ, я уверен, все прекрасно знают - бизнес логику нужно хранить отдельно от слоя представления в инструментах, поддерживающих реактивность данных, то есть в стейт менеджерах, но не тех стейт менеджерах, которые не способны существовать без реакта.
Стоит подметить один неприятный момент , да wrapper hell , HOC это не очень хорошо, но есть ещё такой момент – hook hell , где у тебя каша из react хуков и вся бизнес логика, вынуждено живёт в слое представления, что не есть хорошо э
Абсолютно с вами согласен, оставляя существующий проект на съедение вайбкодингу, без какого либо рефакторинга и контроля того, что пишет ИИ — учесть проекта сведётся к нечитабельному коду, дубликатам и хаосу, ну и ещё ИИ все равно будет труднее понимать такой проект. Увы руководство и менеджеры вышестоящие над разработчиками не всегда это понимают и больше заставляют забывать о качестве и выдавать количество (функционала)
Да, так в основном и строятся крепкие веб приложения сейчас. Мы вместо rxjs используем mobx только
Не могу сказать что безответственных очень много, потому что сам недавно, к сожалению, попал в такую историю, что исправлять баги нам запретили, потому что основной фокус нужно тратить на фичи.
В итоге я , как и несколько других разработчиков, видят очень много багов, их заводят, но ничего с ними не делают (хоть я лично и хочу, чтобы наша система была идеальной)
В общем это я к тому что баги хоть и создают разработчики, но не чинят их не потому что они их не хотят починить, а просто потому что им не дают времени на это
Спасибо за комментарий! По пунктам:
Порядок рендера - не проблема. useValue в проде использует useRef-паттерн ленивой инициализации, экземпляр привязан к конкретному хуку, а не к порядку вызовов. С ViewModelStore дополнительно работает пуллинг по id - повторного создания не будет.
Отброшенный рендер - актуально только для сценария без ViewModelStore, что не основной кейс. С ViewModelStore viewModels.attach() просто инкрементит ref-count, что безопасно. Без стора действительно есть ограничение при работе с Suspense - это описано в доке. Перенос mount() в Layout Effect решил бы его, но требует нетривиального рефакторинга - синхронный mount в рендере нужен для SSR и совместимости с mobx-react observer.
StrictMode - работает корректно. В проде useRef сохраняет экземпляр через unmount/remount, lastAttachedInstanceRef предотвращает повторный attach. В дев режиме useMemo может пересоздать экземпляр при remount, но пуллинг по id в сторе не даст дублирования, а без стора очистка отработает корректно. При этом лично я StrictMode не использую - на мой взгляд, инструмент, который меняет поведение в дев и не идентичен поведению в продакшне, применять нельзя.
Насколько я знаю лишнего рендера не будет, потому что 18+ реакт будет автоматически батчить такие апдейты, но mobx реакции вызовутся два раза да
Привет, все зависит от того как писать !
У нас тоже были утечки памяти, но они были связаны с тем, что в некоторые reaction не были прикинуты сигналы на удаление
В общем утечек памяти в самом observer я с уверенностью могу сказать что нет, потому что у нас вкладка с фронтом (два фронта: главное приложение + iframe приложение внутри) после работы GC занимает память 84-86 МB
Важный момент: мы не используем React хуки вовсе в слое представления для БЛ (кроме юайных хуков вроде useTable), поэтому прокси не отправляются в массив зависимостей в хуках, как и не используются в замыканиях в хуках. Это может быть связано с утечками
Да, спасибо за внимательность, допишу об этом моменте в статье!
Этот варнинг убирается через настройку
Привет!
В данный момент мы разрабатываем чисто CSR апку, но на гитхабе у меня можно найти пример работы MobX в режиме SSR (GOZON), а также да, как вы упомянули, можно использовать mobx-tanstack-query + написать некий стор который имеет базовое состояние-слепок стейта
Что то кнопка зарегистрироваться не работает