Я поэтому и решил написать о нем, пару дней потыкался в код, как-то ничего для меня явного на ум не пришло. Думал, будут полные комменты людей, кто предложат векторы атаки, но пока пусто)
Да, для чувствительных тем сам так и делаю. Благо, даже за последний год достаточно легких моделей стало сильно больше и они порядком прокачались.
Я рассматриваю сервисы, подобные Confer, как альтернативу для людей без технического бекграунда. Потому что, согласитесь, процесс локального подъема ллм пока далек от масс адопшена.
Что не очень нравится в perplexity и ему подобных им поисковиков, они не "взвешивают" источники. В соседних абзацах инфа из научных статей, реддита и vc ru.
У меня нет особо мудрых мыслей, как это решить. Но лично мне это часто стреляет в ногу, приходится внимательно смотреть, откуда инфа.
На самом деле, заметил, что навык управления командой существенно повысился с того момента, как начал активно использовать агенты. Так тренажёр получается)
Меня вообще чутка смущает эта ситуация с агентами. Выглядит так, как будто лет через 5 чтобы быть конкурентоспособным программистом нужно тратить нормальные такие деньги на токены. Потому что иначе сильно отстанешь в скорости и проиграешь тем, кто агенты активно юзает.
Мне кажется, это что-то типо локального вида спорта у js комьюнити - плодить либы по поводу и без.
Если серьезно, то по сути реальная разница есть между либами, которые мутируют объекты (mobx, valtio, ...) и теми, кто идёт по пути реакта и объекты не мутирует.
А в рамках одной группы разница не так велика. Я, наверное, соберу ещё хейта за такие мысли, но разница буквально в предпочтительных паттернах и синтаксисе.
Если прям интересно, очень рекомендую книгу "Micro state Management react hooks". Читается за день, даёт ответы на большинство вопросов связанных с см в контексте react приложений.
Думаю, мое мнение сложилось исходя из сложностей, с которыми пришлось столкнуться при знакомстве с технологией (это был легаси, сменивший много команд, у каждой из которых было свое виденье того, как стейт должен выглядеть).
Все стейт менеджеры хороши, и холивар тут как бы нет причин начинать. речь в статье именно о эджкейсах, т.е. исключениях, а не правилах.
Сложно сравнить хорошие продукты, которыми являются и mobX и его конкуренты, поэтому я и говорю о крайних случаях, где одни чуть лучче других, по моему опыту.
Это на самом деле очень хороший комментарий, спасибо за информацию!
Могу только сказать, что я не хотел выставить mobX в плохом свете или вроде того. Мой опыт с ним был в жестком легаси, где команды сменяли команды и легко там быть определенно не может.
Я о том, что более структурированный и декларативный redux, по моему опыту, в случае подобного легаси был бы предпочтительнее, потому что "распутать" состояние в его случае как будто проще.
Ваш довод про "если он перерендерился - значит нужно" прекрасно работает, если разработчики, как изначально пишущие менеджмент состояния, так и после поддерживающие проект, знали, что они делают. Если это условие не соблюдается, как и было в моем случае, как раз и происходит описываемая проблема. У других стейт менеджеров она бы тоже имела место, но, по моему мнению, не в этом масштабе.
Приведенный вами пример действительно не вызовет мучений, вне зависимости от выбранной технологии стейт менеджмента. Я столкнулся с проблемой на проекте с большими объектами в сторе, к тому же, довольно плохо реализованном.
Фраза про "мучения" не должна быть воспринята буквально. То есть, все стейт менеджеры из статьи это решения, доказавшие свою эффективность на огромном числе проектов, redux и mobx особенно.
Тут речь больше про "защиту от дурака". Тот же zustand, который, я, к слову, очень люблю, такой тоже не обладает, по моему опыту. Так что его использование как основного стейт менеджера в больших аппках может быть рисковано.
При использовании реактивного mobx в декларативном реакте существует, на мой взгляд, больше возможностей создать себе проблемы.
Опытная команда, уверен, избежит этого, но таких, как мы видим, меньшинство.
Больше возможностей интеграции с ОСями, чем в пва + он пошустрее, на моем опыте.
Насколько я понял, у них уже был веб на tailwind и им нужна была унификация с ним.
Классный разбор! Очень большой труд, спасибо вам. В ру сегменте найти качественные defi разборы - редкость
Я поэтому и решил написать о нем, пару дней потыкался в код, как-то ничего для меня явного на ум не пришло. Думал, будут полные комменты людей, кто предложат векторы атаки, но пока пусто)
Да, для чувствительных тем сам так и делаю. Благо, даже за последний год достаточно легких моделей стало сильно больше и они порядком прокачались.
Я рассматриваю сервисы, подобные 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 в декларативном реакте существует, на мой взгляд, больше возможностей создать себе проблемы.
Опытная команда, уверен, избежит этого, но таких, как мы видим, меньшинство.