Он его не "завалит", а завалит. Это уже достаточно чтобы косо смотреть на эту поделку.
Серьёзно? Ваш аргумент — в том, что библиотека выдаёт ошибку, если с сервера приходят некорректные данные? В нормальной архитектуре такие ситуации предотвращаются на уровне протокола. Мы используем протокол со строгой схемой, который гарантирует типизацию и соответствие данных. Валидация выполняется ещё до того, как данные попадают в MST. Это базовая практика, и она решает проблему, которую вы драматизируете.
"Ой, думать головой это так ужасно. Это не достойно профессии программиста."
Рассуждать в таком духе — это либо токсичность, либо ЧСВ за пределами разумного. Вы действительно считаете, что "думать головой" — это изобретать велосипеды там, где уже есть проверенные решения? Программист решает задачи бизнеса. Если есть инструмент, который эти задачи решает эффективнее, зачем изобретать своё? Вы не Бог, чтобы решать, кто "достойно" работает в профессии, а кто нет.
"Typescript? Не, не слышали."
Слышали, и TypeScript используется для статической проверки типов. Но он не валидирует данные в рантайме. Если сервер нарушает контракт, TypeScript никак не защитит от некорректных данных. MST это делает. Ваш "аргумент" показывает непонимание того, что эти технологии решают совершенно разные задачи.
"Снапшоты и путешествия во времени никому не нужны."
Может быть, они не нужны вам. Но для сложных приложений, где требуется отладка, undo/redo или работа с состояниями, это полезная функция. Вы упоминаете "99.9999%", но это лишь ваше личное мнение, не подкреплённое никакими данными.
Для пользователя это так же потеря времени и интереса к сервису.
А некорректные данные — это не потеря интереса? Ваш подход — скрывать ошибки и надеяться, что всё как-нибудь заработает. Мы предпочитаем выявлять проблемы на этапе разработки, чтобы в продакшене пользователь получал стабильный продукт.
Ваши аргументы строятся на токсичности и преувеличении. Вы не предложили ни одного конструктивного решения, которое бы показало, почему ваш подход лучше. MST — это инструмент для определённых задач, и он отлично справляется с ними. Если вам не нравится MST, это ваше право, но превозносить своё мнение как истину в последней инстанции — это уже перегиб.
Вы абсолютно правы. На старте проекта в приоритете была скорость выхода MVP, чтобы проверить гипотезы и понять потребности пользователей. Осознанно приняли решение жертвовать архитектурной чистотой ради быстрого запуска. Это типичный подход: быстрее выпустить продукт, даже если потом придётся тратить ресурсы на рефакторинг.
Сейчас рефакторинг почти завершён. Осталось привести в порядок компоненты — часть из них всё ещё классовые, и мы их обновляем только при значительных изменениях функциональности.
В будущем, скорее всего, будем фокусироваться на оптимизации клиентской загрузки и масштабируемости архитектуры. При этом важно сохранять гибкость, чтобы использовать новые технологии по мере необходимости, но без лишнего "гона за хайпом".
Спасибо за интересный вопрос! Если есть идеи, как сделать проект лучше, буду рад услышать. :)
На самом деле у 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 почитали, прежде чем такую дичь морозить. Тайм-тревел работает через патчи / обратные патчи. И механизм для избегания отката действий других пользователей есть в MST — вы управляете, какие экшины помещать в стек, а какие нет и атомарностью операций.
То есть пользовательские сценарии у вас не тестируются, ясно.
С чего вы взяли? Где написано, что "юнитами все и кончилось". Бред не пишите. У нас все уровни покрыты.
MST не имеет смысла, если не нужен time travel (сайтики). Но сложно представить себе приложения, вроде google docs, mirro или figma, где time travel был бы отломан. Пользователи не поймут. Поэтому в первую очередь, выбор инструмента зависит от задачи. У меня есть опыт рефакторинга https://singularity-app.ru/, где cmd+z — must have и уже была реализована на redux.
Ощущения от MST такие:
Первые: "бля, что за черная магия вне Хогвардса?". После редакса код получался слишком простым. Ты просто пишешь логику приложения, а не все эти сраные экшин-криэйторы. Как так то? В общем, программисты ненавидят черную магию. По крайней мере, пока в ней не разберутся. Почитав исходники — стало понятно, как это все устроено. В прочем, авторы MobX и MST нифига не эстеты по коду, тут им не респект.
Вторые. Ладно, с черной магией разобрались. Что там со скоростью? Были сомнения, что на большом количестве сторов с большим объемом данных, производительность можно будет обнять и плакать. Но нет. Реальные замеры показали что у нас все ОК. И хотя MST чего-то там делает, требует каких-то накладных расходов (по сравнению с редаксом), но это все — копейки. По итогу рефакторинга, скорость только росла. Пользователи заметили. В прочем, я связываю это не с MST, а с рефакторингом селекторов и мидлварей. Запишем, что со скоростью все ОК.
Теперь о минусах. Их было три. И все они были на поверхности.
Болтливое описание типов в сторах. "Ну блин, нахрена ж вы так сделали?". Авторам нет оправдания :)) Не, я понимаю, почему они сделали именно так. Но это не круто. В идеальном мире я хочу просто перенаследовать модели с бэкэнда и сделать их обсерверными. Но MST говорит "обрыбишься".
Наследование сторов через трамбу-лямбу (композицию). Блевотка же. Этот минус следует из первого. На простых приложениях это не потребуется. Но если много actions / views — распилить стор по слоям очень захочется. MST по сути предлагает решение. Но оно не эстетичное.
Асинхронные экшины через генераторы. Вот за это хочется бить палками. Благо, таких операций у нас получилось всего 4-5 (CRUD) и их аккуратно спрятали с глаз долой в базовую модель. Но смотреть на flow(function* fetchProjects()... у меня глаз дергается. Могли бы напрячься, и починить обычные промисы/асинк/авэйт.
Что запишу в плюсы (они все спорные, но для меня — плюсы, поэтому кто не согласен — просто отвалите):
Код реально получается ОЧЕНЬ простой. Как и архитектура. И кода становится в разы меньше, чем на redux. Меньше кода — меньше багов. Разработка ускорилась.
Тестируемость. По сути, в тестах мы замокали один объект (backend-connector), передаваемый в mst через депенденси-энджекшин. И получили простые, чистые, красивые юнит-тесты на селекторы и экшины. Я — доволен.
Таймтревел и снапшоты. В нашем случае это must have. Порадовала работа с патчами.
Чем не стали пользоваться: в MST есть коннектор к Redux-стору. По сути — тупая мидлварь на два экрана. Были мыслишки, что для рефакторинга это будет удобно. По факту удобнее оказалось извлекать какю-то сущьность из редакса целиком.
Итого: если тайм тревел не нужен — вам не нужен MST. Если нужен — на чистом MobX его рехнешься писать. Ну а redux, безусловно, нужно потихоньку хоронить.
Спасибо за материал. Чувствуется глубокое погружение в тему. Почему не используете MST? Да, там болтливый синтаксис описания сторов. Но озвученная вами проблема совместного использования данных решена. До кучи — time travel и снапшоты из коробки — легко подключать API.
На setTimeout? Надеюсь нет.
Понятно, статью вы не читали.
Ну если вы не утверждаете истину, тогда спор окончен. Засчитано как слив.
Серьёзно? Ваш аргумент — в том, что библиотека выдаёт ошибку, если с сервера приходят некорректные данные? В нормальной архитектуре такие ситуации предотвращаются на уровне протокола. Мы используем протокол со строгой схемой, который гарантирует типизацию и соответствие данных. Валидация выполняется ещё до того, как данные попадают в MST. Это базовая практика, и она решает проблему, которую вы драматизируете.
Рассуждать в таком духе — это либо токсичность, либо ЧСВ за пределами разумного. Вы действительно считаете, что "думать головой" — это изобретать велосипеды там, где уже есть проверенные решения? Программист решает задачи бизнеса. Если есть инструмент, который эти задачи решает эффективнее, зачем изобретать своё? Вы не Бог, чтобы решать, кто "достойно" работает в профессии, а кто нет.
Слышали, и TypeScript используется для статической проверки типов. Но он не валидирует данные в рантайме. Если сервер нарушает контракт, TypeScript никак не защитит от некорректных данных. MST это делает. Ваш "аргумент" показывает непонимание того, что эти технологии решают совершенно разные задачи.
Может быть, они не нужны вам. Но для сложных приложений, где требуется отладка, undo/redo или работа с состояниями, это полезная функция. Вы упоминаете "99.9999%", но это лишь ваше личное мнение, не подкреплённое никакими данными.
А некорректные данные — это не потеря интереса? Ваш подход — скрывать ошибки и надеяться, что всё как-нибудь заработает. Мы предпочитаем выявлять проблемы на этапе разработки, чтобы в продакшене пользователь получал стабильный продукт.
Ваши аргументы строятся на токсичности и преувеличении. Вы не предложили ни одного конструктивного решения, которое бы показало, почему ваш подход лучше. MST — это инструмент для определённых задач, и он отлично справляется с ними. Если вам не нравится MST, это ваше право, но превозносить своё мнение как истину в последней инстанции — это уже перегиб.
У нас React :)
D&D: у нас React, за основу взят react-dnd
WYSIWYG: за основу взят Quill, дальше сами пишем плагины и форкаем некоторые части, где нужно исправить ошибки.
Добрый день. Основной расход — стейт. На старте подгружаются все проекты, созданные пользователем и все актуальные задачи с датами.
Принудительная перезагрузка страницы — не лучший вариант. Можно не угадать с моментом и потереть пользователю что-то нужное. Непростят.
Вы абсолютно правы. На старте проекта в приоритете была скорость выхода MVP, чтобы проверить гипотезы и понять потребности пользователей. Осознанно приняли решение жертвовать архитектурной чистотой ради быстрого запуска. Это типичный подход: быстрее выпустить продукт, даже если потом придётся тратить ресурсы на рефакторинг.
Сейчас рефакторинг почти завершён. Осталось привести в порядок компоненты — часть из них всё ещё классовые, и мы их обновляем только при значительных изменениях функциональности.
В будущем, скорее всего, будем фокусироваться на оптимизации клиентской загрузки и масштабируемости архитектуры. При этом важно сохранять гибкость, чтобы использовать новые технологии по мере необходимости, но без лишнего "гона за хайпом".
Спасибо за интересный вопрос! Если есть идеи, как сделать проект лучше, буду рад услышать. :)
Ну во первых, "Плевок" — странный термин
На самом деле у 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 остаётся отличным выбором, если вам нужна максимальная производительность, гибкость и контроль.
Почему?
Спасибо! Мы стараемся)
Круто!
Ещё, говорят, кто быстро ест — тот быстро работает. Тоже, наверное, внутренние психические процессы)
Фига сё, лёгкий... Это вы мой график не знаете. Но обсуждаете. Такое...
А ещё мы видим, как все превращается в saas, а людей превращают в яндекс-таксистов. Мир — он многогранный.
>> Пусть каждый, кто хочет, сам свои серваки поднимает
Сплю, и вижу...
В вообще — мир пошёл по другой дороге. Так уж получилось.
Вот меня тоже бесят подписки. Особенно когда подписался, а там БАЦ! И "Бмедиатека" или еще какой-то "+
ФПлюс".Хотя за нормальный инструмент я готов платить. И за бензин. И за электричество.
С софтом та же тема. Даже если не брать во внимание, что постоянно выпускаешь новые релизы, серваки каждый месяц денег просят.
Да
Наш техдир так же говорит. А потом на code review выкатывает такие портянки, порой — закачаешься) И все с юморком, с шуточками...
Чего это?
Вы бы сначала спеки MST почитали, прежде чем такую дичь морозить. Тайм-тревел работает через патчи / обратные патчи. И механизм для избегания отката действий других пользователей есть в MST — вы управляете, какие экшины помещать в стек, а какие нет и атомарностью операций.
С чего вы взяли? Где написано, что "юнитами все и кончилось". Бред не пишите. У нас все уровни покрыты.
MST не имеет смысла, если не нужен time travel (сайтики). Но сложно представить себе приложения, вроде google docs, mirro или figma, где time travel был бы отломан. Пользователи не поймут. Поэтому в первую очередь, выбор инструмента зависит от задачи. У меня есть опыт рефакторинга https://singularity-app.ru/, где cmd+z — must have и уже была реализована на redux.
Ощущения от MST такие:
Первые: "бля, что за черная магия вне Хогвардса?". После редакса код получался слишком простым. Ты просто пишешь логику приложения, а не все эти сраные экшин-криэйторы. Как так то? В общем, программисты ненавидят черную магию. По крайней мере, пока в ней не разберутся. Почитав исходники — стало понятно, как это все устроено. В прочем, авторы MobX и MST нифига не эстеты по коду, тут им не респект.
Вторые. Ладно, с черной магией разобрались. Что там со скоростью? Были сомнения, что на большом количестве сторов с большим объемом данных, производительность можно будет обнять и плакать. Но нет. Реальные замеры показали что у нас все ОК. И хотя MST чего-то там делает, требует каких-то накладных расходов (по сравнению с редаксом), но это все — копейки. По итогу рефакторинга, скорость только росла. Пользователи заметили. В прочем, я связываю это не с MST, а с рефакторингом селекторов и мидлварей. Запишем, что со скоростью все ОК.
Теперь о минусах. Их было три. И все они были на поверхности.
Болтливое описание типов в сторах. "Ну блин, нахрена ж вы так сделали?". Авторам нет оправдания :)) Не, я понимаю, почему они сделали именно так. Но это не круто. В идеальном мире я хочу просто перенаследовать модели с бэкэнда и сделать их обсерверными. Но MST говорит "обрыбишься".
Наследование сторов через трамбу-лямбу (композицию). Блевотка же. Этот минус следует из первого. На простых приложениях это не потребуется. Но если много actions / views — распилить стор по слоям очень захочется. MST по сути предлагает решение. Но оно не эстетичное.
Асинхронные экшины через генераторы. Вот за это хочется бить палками. Благо, таких операций у нас получилось всего 4-5 (CRUD) и их аккуратно спрятали с глаз долой в базовую модель. Но смотреть на flow(function* fetchProjects()... у меня глаз дергается. Могли бы напрячься, и починить обычные промисы/асинк/авэйт.
Что запишу в плюсы (они все спорные, но для меня — плюсы, поэтому кто не согласен — просто отвалите):
Код реально получается ОЧЕНЬ простой. Как и архитектура. И кода становится в разы меньше, чем на redux. Меньше кода — меньше багов. Разработка ускорилась.
Тестируемость. По сути, в тестах мы замокали один объект (backend-connector), передаваемый в mst через депенденси-энджекшин. И получили простые, чистые, красивые юнит-тесты на селекторы и экшины. Я — доволен.
Таймтревел и снапшоты. В нашем случае это must have. Порадовала работа с патчами.
Чем не стали пользоваться: в MST есть коннектор к Redux-стору. По сути — тупая мидлварь на два экрана. Были мыслишки, что для рефакторинга это будет удобно. По факту удобнее оказалось извлекать какю-то сущьность из редакса целиком.
Итого: если тайм тревел не нужен — вам не нужен MST. Если нужен — на чистом MobX его рехнешься писать. Ну а redux, безусловно, нужно потихоньку хоронить.
Спасибо за материал. Чувствуется глубокое погружение в тему. Почему не используете MST? Да, там болтливый синтаксис описания сторов. Но озвученная вами проблема совместного использования данных решена. До кучи — time travel и снапшоты из коробки — легко подключать API.
Спасибо! Fixed.