Я поэтому и решил написать о нем, пару дней потыкался в код, как-то ничего для меня явного на ум не пришло. Думал, будут полные комменты людей, кто предложат векторы атаки, но пока пусто)
Да, для чувствительных тем сам так и делаю. Благо, даже за последний год достаточно легких моделей стало сильно больше и они порядком прокачались.
Я рассматриваю сервисы, подобные Confer, как альтернативу для людей без технического бекграунда. Потому что, согласитесь, процесс локального подъема ллм пока далек от масс адопшена.
Что не очень нравится в perplexity и ему подобных им поисковиков, они не "взвешивают" источники. В соседних абзацах инфа из научных статей, реддита и vc ru.
У меня нет особо мудрых мыслей, как это решить. Но лично мне это часто стреляет в ногу, приходится внимательно смотреть, откуда инфа.
На самом деле, заметил, что навык управления командой существенно повысился с того момента, как начал активно использовать агенты. Так тренажёр получается)
Меня вообще чутка смущает эта ситуация с агентами. Выглядит так, как будто лет через 5 чтобы быть конкурентоспособным программистом нужно тратить нормальные такие деньги на токены. Потому что иначе сильно отстанешь в скорости и проиграешь тем, кто агенты активно юзает.
Мне кажется, это что-то типо локального вида спорта у js комьюнити - плодить либы по поводу и без.
Если серьезно, то по сути реальная разница есть между либами, которые мутируют объекты (mobx, valtio, ...) и теми, кто идёт по пути реакта и объекты не мутирует.
А в рамках одной группы разница не так велика. Я, наверное, соберу ещё хейта за такие мысли, но разница буквально в предпочтительных паттернах и синтаксисе.
Если прям интересно, очень рекомендую книгу "Micro state Management react hooks". Читается за день, даёт ответы на большинство вопросов связанных с см в контексте react приложений.
Думаю, мое мнение сложилось исходя из сложностей, с которыми пришлось столкнуться при знакомстве с технологией (это был легаси, сменивший много команд, у каждой из которых было свое виденье того, как стейт должен выглядеть).
Все стейт менеджеры хороши, и холивар тут как бы нет причин начинать. речь в статье именно о эджкейсах, т.е. исключениях, а не правилах.
Сложно сравнить хорошие продукты, которыми являются и mobX и его конкуренты, поэтому я и говорю о крайних случаях, где одни чуть лучче других, по моему опыту.
Это на самом деле очень хороший комментарий, спасибо за информацию!
Могу только сказать, что я не хотел выставить mobX в плохом свете или вроде того. Мой опыт с ним был в жестком легаси, где команды сменяли команды и легко там быть определенно не может.
Я о том, что более структурированный и декларативный redux, по моему опыту, в случае подобного легаси был бы предпочтительнее, потому что "распутать" состояние в его случае как будто проще.
Ваш довод про "если он перерендерился - значит нужно" прекрасно работает, если разработчики, как изначально пишущие менеджмент состояния, так и после поддерживающие проект, знали, что они делают. Если это условие не соблюдается, как и было в моем случае, как раз и происходит описываемая проблема. У других стейт менеджеров она бы тоже имела место, но, по моему мнению, не в этом масштабе.
Приведенный вами пример действительно не вызовет мучений, вне зависимости от выбранной технологии стейт менеджмента. Я столкнулся с проблемой на проекте с большими объектами в сторе, к тому же, довольно плохо реализованном.
Фраза про "мучения" не должна быть воспринята буквально. То есть, все стейт менеджеры из статьи это решения, доказавшие свою эффективность на огромном числе проектов, redux и mobx особенно.
Тут речь больше про "защиту от дурака". Тот же zustand, который, я, к слову, очень люблю, такой тоже не обладает, по моему опыту. Так что его использование как основного стейт менеджера в больших аппках может быть рисковано.
При использовании реактивного mobx в декларативном реакте существует, на мой взгляд, больше возможностей создать себе проблемы.
Опытная команда, уверен, избежит этого, но таких, как мы видим, меньшинство.
Хм, я, наоборот, меньше всего симпатизирую MobX из всего списка. Был не самый лучший опыт с большим проектом, где местами сложно понять, почему компонент перерендерился, так как зависимости отслеживаются автоматически.
В Redux/Zustand перерисовка явно связана с вызовом setState или dispatch, что с ростом масштаба кратно упрощает дебаг. Плюс DevTools у Redux (с логом действий и diffами состояния) гораздо мощнее, чем у MobX.
MobX очень гибок, у него этого не отнять. Но есть ощущение, что часто эта гибкость стреляет в ногу с ростом масштаба.
Безусловно, я далек от экспертности в контексте таких эджкейсов MobX. Если у вас есть опыт, как такое реашется, поделитесь, пожалуйста.
Я поэтому и решил написать о нем, пару дней потыкался в код, как-то ничего для меня явного на ум не пришло. Думал, будут полные комменты людей, кто предложат векторы атаки, но пока пусто)
Да, для чувствительных тем сам так и делаю. Благо, даже за последний год достаточно легких моделей стало сильно больше и они порядком прокачались.
Я рассматриваю сервисы, подобные Confer, как альтернативу для людей без технического бекграунда. Потому что, согласитесь, процесс локального подъема ллм пока далек от масс адопшена.
Но это скорее придирка, в целом, для ежедневного поиска использую именно perplexity
Что не очень нравится в perplexity и ему подобных им поисковиков, они не "взвешивают" источники. В соседних абзацах инфа из научных статей, реддита и vc ru.
У меня нет особо мудрых мыслей, как это решить. Но лично мне это часто стреляет в ногу, приходится внимательно смотреть, откуда инфа.
Приятно видеть, как вырос RN. Писал с expo 4 года назад и эта прям боль. Очень большой скачек сделала экосистема.
Интересно было бы услышать человека, кто имеет опыт и на RN, и на Flutter, как оно, сократилась ли пропасть в developer experience.
На самом деле, заметил, что навык управления командой существенно повысился с того момента, как начал активно использовать агенты. Так тренажёр получается)
У Antigravity есть бесплатный доступ с довольно лояльным лимитом по токенам.
Очень рекомендую попробовать. Не утверждаю, что что-то будет 100% лучше или хуже, но попробовать точно стоит
Меня вообще чутка смущает эта ситуация с агентами. Выглядит так, как будто лет через 5 чтобы быть конкурентоспособным программистом нужно тратить нормальные такие деньги на токены. Потому что иначе сильно отстанешь в скорости и проиграешь тем, кто агенты активно юзает.
Он хорош, сам пользовался долго, но условному Claude Code и Antigravity сильно проигрывает, как по скорости, так и по контексту. Ну, мой опыт такой.
А чем хуже? По вашему мнению. Я с ними не работал, экспертизы тут не имею
Мне кажется, это что-то типо локального вида спорта у js комьюнити - плодить либы по поводу и без.
Если серьезно, то по сути реальная разница есть между либами, которые мутируют объекты (mobx, valtio, ...) и теми, кто идёт по пути реакта и объекты не мутирует.
А в рамках одной группы разница не так велика. Я, наверное, соберу ещё хейта за такие мысли, но разница буквально в предпочтительных паттернах и синтаксисе.
Если прям интересно, очень рекомендую книгу "Micro state Management react hooks". Читается за день, даёт ответы на большинство вопросов связанных с см в контексте react приложений.
Делаю, что могу)))
Знал, на что я шел
А тут все просто, не использовал их еще)
Думаю, мое мнение сложилось исходя из сложностей, с которыми пришлось столкнуться при знакомстве с технологией (это был легаси, сменивший много команд, у каждой из которых было свое виденье того, как стейт должен выглядеть).
Все стейт менеджеры хороши, и холивар тут как бы нет причин начинать. речь в статье именно о эджкейсах, т.е. исключениях, а не правилах.
Сложно сравнить хорошие продукты, которыми являются и mobX и его конкуренты, поэтому я и говорю о крайних случаях, где одни чуть лучче других, по моему опыту.
Это на самом деле очень хороший комментарий, спасибо за информацию!
Могу только сказать, что я не хотел выставить mobX в плохом свете или вроде того. Мой опыт с ним был в жестком легаси, где команды сменяли команды и легко там быть определенно не может.
Я о том, что более структурированный и декларативный redux, по моему опыту, в случае подобного легаси был бы предпочтительнее, потому что "распутать" состояние в его случае как будто проще.
Ваш довод про "если он перерендерился - значит нужно" прекрасно работает, если разработчики, как изначально пишущие менеджмент состояния, так и после поддерживающие проект, знали, что они делают. Если это условие не соблюдается, как и было в моем случае, как раз и происходит описываемая проблема. У других стейт менеджеров она бы тоже имела место, но, по моему мнению, не в этом масштабе.
Ответил выше)
Интересно ваше мнение
Приведенный вами пример действительно не вызовет мучений, вне зависимости от выбранной технологии стейт менеджмента. Я столкнулся с проблемой на проекте с большими объектами в сторе, к тому же, довольно плохо реализованном.
Фраза про "мучения" не должна быть воспринята буквально. То есть, все стейт менеджеры из статьи это решения, доказавшие свою эффективность на огромном числе проектов, redux и mobx особенно.
Тут речь больше про "защиту от дурака". Тот же zustand, который, я, к слову, очень люблю, такой тоже не обладает, по моему опыту. Так что его использование как основного стейт менеджера в больших аппках может быть рисковано.
При использовании реактивного mobx в декларативном реакте существует, на мой взгляд, больше возможностей создать себе проблемы.
Опытная команда, уверен, избежит этого, но таких, как мы видим, меньшинство.
Что забавно, MobX - единственный из списка, с кем реально пришлось помучаться)
Хм, я, наоборот, меньше всего симпатизирую MobX из всего списка. Был не самый лучший опыт с большим проектом, где местами сложно понять, почему компонент перерендерился, так как зависимости отслеживаются автоматически.
В Redux/Zustand перерисовка явно связана с вызовом
setStateилиdispatch, что с ростом масштаба кратно упрощает дебаг. Плюс DevTools у Redux (с логом действий и diffами состояния) гораздо мощнее, чем у MobX.MobX очень гибок, у него этого не отнять. Но есть ощущение, что часто эта гибкость стреляет в ногу с ростом масштаба.
Безусловно, я далек от экспертности в контексте таких эджкейсов MobX. Если у вас есть опыт, как такое реашется, поделитесь, пожалуйста.