Comments 19
MST (MobX State Tree)
Это плевок в лицо MobX'a. Уж тогда лучше оставались бы с редаксом или заменили на любую другую дичь, раз вы не рассматриваете человеческие варианты.
Почему?
Почему?
Ну во первых MobX это максимально нативный код:
Чего не скажешь о MST:
Во вторых MobX не рушит тебе приложение, когда его можно не рушить, т.к. в нем нет проверок в рантайме на "модель" .
Самый типичный пример:
Приложение в проде, с бэка пришла цента вместо number => string или наоборот, вместо string => number. А мы в карточке товара просто выводим эту цену. Так вот, в случае с MobX все будет ок, а в случае с MST все приложение просто упадет.
Да, это ошибка с точки зрения нарушения контракта бэком, но ошибка ошибке рознь, в данном случае она не критичная и по большому счету ни на что не влияет и не является поводом чтобы завалить прод.
Вот код:
https://stackblitz.com/edit/vitejs-vite-we3busph?file=src%2Fmain.ts&terminal=dev
И результат, кода что выше
В третьих MobX работает быстрее и потребляет меньше оперативной памяти.
В четвертых, он позволяет делать максимально удобный, гибкие и красивые вещи, т.к. вообще не связывает руки.
Ну во первых, "Плевок" — странный термин
На самом деле у MobX и MST один и тот же создатель — Михель Вестстрат. MST не "плевок" в сторону MobX, а шаг решить задачи, которые в MobX требуют создания собственной архитектуры. Ну либо Михель плюнул сам в себя. Не надо быть столь категоричным.
Я не очень хочу защищать MST, т.к. у меня к нему есть вопросы, и вы правы — синтаксис MobX — лучший. Тем не менее, как я писал в статье — оба фреймворка отлично работают в паре. И в официальной документации MST прямо указывается, что он создан как надстройка над MobX. Его цель — добавить структуру и инструменты, такие как типизация, модели и снапшоты, чтобы решить задачи, для которых MobX "из коробки" не предназначен. Если вам нужно больше гибкости — никто не мешает использовать MobX и MST совместно.
Во вторых, то что MobX быстрее и ест меньше памяти — прямо указано в статье. С замерами и скриншотами.
В третьих — строгая проверка данных. Да, MST может "завалить" приложение, если с бэка приходит некорректный тип данных. Но это скорее фича, чем баг: такие ошибки важно ловить на этапе разработки. Для продакшена всегда можно добавить гибкую обработку ошибок.
Да, всё это можно сделать и на чистом MobX, но в таком случае вы рискуете создать собственный "велосипед", который, по сути, будет выполнять ту же работу, что и MST. MST позволяет избежать дублирования усилий и использовать готовое решение.
Типизация и структура. MST предоставляет строгие модели и проверку типов, что особенно полезно в крупных командах для поддержания согласованности данных. Подробнее об этом можно узнать в статье на Dev.to.
Снапшоты и путешествия во времени. MST позволяет легко сохранять и восстанавливать состояние приложения с помощью снапшотов, что упрощает отладку и тестирование. Эта функция подробно описана в официальной документации.
Строгая проверка данных. MST обеспечивает проверку типов во время выполнения, предотвращая некорректные изменения состояния и повышая надежность приложения. Об этом говорится в статье на Dev.to.
MobX остаётся отличным выбором, если вам нужна максимальная производительность, гибкость и контроль.
Да, MST может "завалить" приложение, если с бэка приходит некорректный тип данных
Он его не "завалит", а завалит. Это уже достаточно чтобы косо смотреть на эту поделку. Плюс сам по себе код и подход так себе, по сравнению с MobX.
На самом деле у MobX и MST один и тот же создатель — Михель Вестстрат
И что? Мне сам по себе создатель не внушает никакого уважения и доверия, можно посмотреть на код как он пишет и ужаснуться. Плюс многие примеры в документации ужасны. И пользоваться MobX'ом так, как показано в примерах так себе затея, можно гораздо лучше.
MST не "плевок" в сторону MobX, а шаг решить задачи, которые в MobX требуют создания собственной архитектуры.
Ой, думать головой это так ужасно. Это не достойно профессии программиста. Толи дело когда какой-то Вася Пупкин уже "решил" за тебя задачу. Пускай криво/косо, но зато самому не надо извилинами шевелить.
Но это скорее фича, чем баг: такие ошибки важно ловить на этапе разработки. Для продакшена всегда можно добавить гибкую обработку ошибок.
Да, а теперь возвращаемся в реальный мир, и это прям сверх распространенная ситуация когда бэк тебе может прислать вместо '' скажем null или вообще не прислать это поле. А у тебя логика на фронте простая,
{item.price && <div className={styles.price}>{item.price}</div>}В нормальном мире все отработает без проблем, а мире MST просто закрашится.
Или же ты в модели прописал поле, допустим думал что оно будет использоваться, но реально оно не использовалось никогда, а потом его просто убрали как ненужное, а в модели оно осталось и все, опять бабах и прощай приложение с MST. Вместо того, чтобы технология упрощала тебе жизнь, она начинает ее усложнять плюс ещё и бомбы замедленного действия закладывает в приложение.
Да, всё это можно сделать и на чистом MobX, но в таком случае вы рискуете создать собственный "велосипед"
Ага, т.е. программист который пишет ту или иную логику, сам создает те или иные решения это велосипедист и вообще это зашквар, таким не место в профессии. Ясно, понятно. У меня вот есть полно собственных решений шикарных, и что, я теперь тупой, ущербный и не вправе их применять?
MST предоставляет строгие модели и проверку типов, что особенно полезно в крупных командах для поддержания согласованности данных.
Typescript? Не, не слышали.
Снапшоты и путешествия во времени
Такой же "аргумент" всегда приводился в "пользу" redux. И он максимально абсурден и смешон. Ибо в реальности в 99.9999% не нужен никому, а в остальных случаях все равно из коробки работает не так, как тебе именно надо. Потому что тебе нужны совершенно конкретные вещи запоминать для undo/redo, а для этого супер легко и супер быстро пишется логика, и если для вас это целая проблема, то что тут можно теперь поделать.
Строгая проверка данных MST обеспечивает проверку типов во время выполнения, предотвращая некорректные изменения состояния и повышая надежность приложения.
Да, очень сомнительно и очень с натяжкой повышает надежность, но расплата за это - краши приложения там, где они не должны быть. А это потеря репутации для бизнеса, потеря денег, потеря времени и т.п. Для пользователя это так же потеря времени и интереса к сервису.
Он его не "завалит", а завалит. Это уже достаточно чтобы косо смотреть на эту поделку.
Серьёзно? Ваш аргумент — в том, что библиотека выдаёт ошибку, если с сервера приходят некорректные данные? В нормальной архитектуре такие ситуации предотвращаются на уровне протокола. Мы используем протокол со строгой схемой, который гарантирует типизацию и соответствие данных. Валидация выполняется ещё до того, как данные попадают в MST. Это базовая практика, и она решает проблему, которую вы драматизируете.
"Ой, думать головой это так ужасно. Это не достойно профессии программиста."
Рассуждать в таком духе — это либо токсичность, либо ЧСВ за пределами разумного. Вы действительно считаете, что "думать головой" — это изобретать велосипеды там, где уже есть проверенные решения? Программист решает задачи бизнеса. Если есть инструмент, который эти задачи решает эффективнее, зачем изобретать своё? Вы не Бог, чтобы решать, кто "достойно" работает в профессии, а кто нет.
"Typescript? Не, не слышали."
Слышали, и TypeScript используется для статической проверки типов. Но он не валидирует данные в рантайме. Если сервер нарушает контракт, TypeScript никак не защитит от некорректных данных. MST это делает. Ваш "аргумент" показывает непонимание того, что эти технологии решают совершенно разные задачи.
"Снапшоты и путешествия во времени никому не нужны."
Может быть, они не нужны вам. Но для сложных приложений, где требуется отладка, undo/redo или работа с состояниями, это полезная функция. Вы упоминаете "99.9999%", но это лишь ваше личное мнение, не подкреплённое никакими данными.
Для пользователя это так же потеря времени и интереса к сервису.
А некорректные данные — это не потеря интереса? Ваш подход — скрывать ошибки и надеяться, что всё как-нибудь заработает. Мы предпочитаем выявлять проблемы на этапе разработки, чтобы в продакшене пользователь получал стабильный продукт.
Ваши аргументы строятся на токсичности и преувеличении. Вы не предложили ни одного конструктивного решения, которое бы показало, почему ваш подход лучше. MST — это инструмент для определённых задач, и он отлично справляется с ними. Если вам не нравится MST, это ваше право, но превозносить своё мнение как истину в последней инстанции — это уже перегиб.
Рассуждать в таком духе — это либо токсичность, либо ЧСВ за пределами разумного
Вы говорите - писать "велосипеды" плохо. А я говорю что нет. Если я имею своё мнение, то я токсичный и ЧСВшник? Ясно. Более того, прикрываются "велосипедами" в 99% случаях плохие программисты, и снимают с себя ответственность за то или иное решения, спихивая всё на: "ну это библиотека плохая, а не я" или "Я не могу это сделать, потому что в этой библиотеке это не предусмотрено" или "мы не сможем это сделать, потому что я не нашел библиотеки никакой" и т.д. и т.п.
И как раз самая ярая защитная реакция у таких "программистов" это высмеивание "велосипедов". Например, меня не устраивает ни одно решение из готовых для работы с формами и валидацией. Вон ни одно. И что мне делать? Терпеть и взять готовое?
Ну нет, я то как раз программист, и я сделал свое решение и подход(пользуюсь им больше 6ти лет) которое меня более чем устраивает и гораздо удобнее и гибче в использовании, чем ваши "проверенные решения".
Вы действительно считаете, что "думать головой" — это изобретать велосипеды там, где уже есть проверенные решения?
Думать головой — это в том числе изобретать "велосипеды", там где есть решения которые не во всем тебя устраивают.
Думать головой — это иметь критическое мышление, и думать своей головой, а не прятаться за "авторитетными" мнениями.
Вы не Бог, чтобы решать, кто "достойно" работает в профессии, а кто нет.
Если вы не заметили, то фраза "Ой, думать головой это так ужасно. Это не достойно профессии программиста." это сарказм, описывающий ваше мнение, просто более открытой форме, а не моё.
Если вам не нравится MST, это ваше право, но превозносить своё мнение как истину в последней инстанции — это уже перегиб.
Где хоть одно упоминания что я говорю истину? Я говорю своё мнение и свои аргументы. Встретили человека который имеет своё мнение, а не молча кивает вам в ответ головой — в ступоре оказались?
Конечно же классическая защитная реакция это завуалированно сказать оппоненту что он сумасшедший и не ведает что несет.
Ведь ни у кого не может быть мнения отличного от вашего. И выбор который делаете вы всегда правильный, без вариантов.
Но для сложных приложений, где требуется отладка, undo/redo или работа с состояниями, это полезная функция
Ну и классическая вишенка на торте это то, что именно у вас "сложные" приложения и только вы по настоящему большие и сложные вещи делаете, и вот им то кровь из носа нужна та или иная шелуха, а вот все остальные никогда ничего сложного не делали, поэтому у них все так просто. Мы сами не можем сделать undo/redo, сами знаете почему, ведь у нас сложные задачи, а undo/redo это ещё сложнее, это ж надо целых пару часов убить чтобы реализовать. Но это не наш путь, мы будем искать только готовые и "проверенные решения", пускай кривые косые, медленные и выжирающие всю память, но зато их написал кто-то другой, а он то точно лучше знает что нам надо, мы то не знаем.
Программист решает задачи бизнеса
А Evan You кто? Черепашка? Ну уж явно не программист, ведь он велосипеды пишет. Написал какой-то Vue когда есть реакт, ангуляр и т.п. Написал какой-то Vite когда есть webpack, rollup и т.п. Ну точно черепашка, ибо нормальный человек такое делать никогда не будет, да?
Ну нет, я то как раз программист, и я сделал свое решение и подход
На setTimeout? Надеюсь нет.
это ж надо целых пару часов убить чтобы реализовать
Понятно, статью вы не читали.
Где хоть одно упоминания что я говорю истину?
Ну если вы не утверждаете истину, тогда спор окончен. Засчитано как слив.
На setTimeout? Надеюсь нет.
Какое отношение setTimeout имеет к работе с данными форм? А что за жалкая попытка высмеять setTimeout? Типо ха-ха-ха он знает, как все устроено и с помощью него может решить проблему которая может помешать писать удобный код..
Понятно, статью вы не читали.
Нюансы которые у вас описаны не относятся к реализации принципа undo/redo, а относятся к конкретно вашу приложению и его особенностям. Поэтому написать решение самим все равно придется и никакие undo/redo из коробки в библиотеках никогда не канают в реальной жизни.
Ну если вы не утверждаете истину, тогда спор окончен. Засчитано как слив.
Классика. Найти любой предлог чтобы избежать неудобства любого уровня. Мама попросила помыть посуду, и вдруг опа, сразу ты "захотел" кушать, или вдруг книжку "решил" почитать и т.п. Учитель попросил после уроков помочь убраться в классе, а у тебя тут как тут "живот заболел". Только вот незадача, вы уже вроде как взрослый человек, а приемы все те же.
У меня, как у человека, у которого не было опыта разработки настолько крупных проектов, возник сразу вопрос: правильно ли я понимаю, что на самом старте всего проекта в угоду скорости появления первой минимально рабочей версии продукта (с целью определения потребности в нём пользователей и объема спроса) архитектурно изначально при полном понимании недостатков этого подхода всё равно был допущен большой оверхед, но затем после того как продукт выстрелил, то уже существенная часть усилий ушла на избавление от него (переход с Redux на MST в целях облегчения и оптимизации как пример этого)? То есть, альтернативный подход, когда тщательно прорабатывалась бы архитектура без существенного оверхеда, но продукт запустился бы гораздо позже (и усилия могли не оправдаться впоследствии) не рассматривался именно по этой причине? (то есть, как бы, осознанно приняли решение выбрать минимальное зло из всех прочих зол) Если да, то будет любопытно узнать какие планы в будущем для избавления от оставшегося оверхеда могут быть реализованы? Какие-либо замены технологий/подходов/фреймворков?
Вы абсолютно правы. На старте проекта в приоритете была скорость выхода MVP, чтобы проверить гипотезы и понять потребности пользователей. Осознанно приняли решение жертвовать архитектурной чистотой ради быстрого запуска. Это типичный подход: быстрее выпустить продукт, даже если потом придётся тратить ресурсы на рефакторинг.
Сейчас рефакторинг почти завершён. Осталось привести в порядок компоненты — часть из них всё ещё классовые, и мы их обновляем только при значительных изменениях функциональности.
В будущем, скорее всего, будем фокусироваться на оптимизации клиентской загрузки и масштабируемости архитектуры. При этом важно сохранять гибкость, чтобы использовать новые технологии по мере необходимости, но без лишнего "гона за хайпом".
Спасибо за интересный вопрос! Если есть идеи, как сделать проект лучше, буду рад услышать. :)
Какую библиотеку используете для VUE D&D (drag-and-drop) ? чет в ходу актуальных не нашел, а популярные более 2 лет уже не обновляются.
Тот же вопрос про WYSIWYG, каккую библиотеку для vue использует? вы написали про родмэп создание своего, но сейчас используете взятый готовый?
Спасибо за то, что делитесь опытом. Буду рад ответам.
Пусть окно Electron весит в оперативке 200mb. А сколько всего кушает оперативки ваше приложение в начале работы? И на что уходит память? На dom или реактивность, или держите много данных в рантайме?
Ещё вопрос. Я тоже замечаю, что при длительной работе с вкладкой (не важно хромиум это или лиса) размер оперативки, которая привязана к конкретной вкладке/страницы постепенно увеличивается. Рассматривали ли вы такое решение этой проблемы как принудительная перезагрузка страницы, чтобы высвободить ненужные ресурсы? Это непростое решение, потому что это нужно делать тогда, когда пользователь не работает со страницей и так, чтобы стейт страницы полностью восстановился. Но способ вроде бы рабочий. И будет производится мгновенно, потому что приложение локальное.
Лучше даже было не писать такую причину "почему не Vue". Ибо когда технический анализ анализ проводится только по популярности, хочется плакать. И нет от перехода меджу 2 и 3 компании не развалились, зато остальные бизнес-метрики отличные у vue: скорость вхождения в проект, скорость изучения, перфоманс, легкость и скорость написания проектов выше чем у React. Но это я так, на подумать, действительно ли "популярность" единственный фактор.
PS. Насчет 2 и 3: уроки учтены, огромная работа была проведена для того чтобы не допустить этого вновь. Так что... аргумент для новых проектов теперь этот на уровне "ну что-то там когда-то произошло"
Круто! Молодцы!
Могу судить о проделанной работе на основе своего пэт проекта (https://github.com/budarin/my-tasks, который пока не смог завершить)
Большое спасибо за то , что поделились своим опытом!
Как пользователь, скажу "Спасибо!" за классное приложение. Важной фичей для меня является возможность писать заметки с форматированием в задачах - люблю думать текстом и иногда целые статьи получаются 🙂
Что думаете насчёт несовместимости MobX и грядущего React Compiler?
Что думаете насчёт несовместимости MobX и грядущего React Compiler?
Игнор версий в которых не работает MobX, ибо реакт без MobX это гадкий утенок. Все равно в связке с MobX нет разницы какой версии реакт, v16, v17, v18, v100500. Свою главную задачу он уже давным давно выполняет и его новые "фичи" как собаке пятая нога.
Переход на Preact
React Compiler вообще никакой погоды не сделает, по этому что с ним, что без него разницы не будет в реальной жизни и на реальных приложениях.
Todo-лист на максималках: разбираем архитектуру крупного приложения