Руки бы поотрывать тем, кто пытается делать откат действий через снепшоты.
Вы бы сначала спеки 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.
Пишем на Flutter полтора года. В целом — довольны, получилось очень не плохо. Но есть минусы. МИНУСЫ:
1. Сырой API. Могут поменять спецификацию «На лету».
2. Не работают некоторые нативные вещи, которые должны работать из коробки. Например, до сих пор есть глюки в текстовых полях на некоторых моделях телефонов (задваивается текст). Решается костылями. А очень неприятно решать костылями то, что ожидаемо должно правильно работать из коробки.
3. Нет НОРМАЛЬНОГО WYSIWYG-редактора (проект зефир скорее мертв чем жив).
4. Виджеты. Пришлось писать на нативе. В итоге довольно сложная архитектура, т.к. виджет должен работать в паре с основным приложением, а поднимать дартовское приложение в фоне для виджета — это сразу большой расход памяти (напомню, у виджетов например на айфонах есть ограничение в 24 мегабайта). Выкрутиться можно, но архитектура получается довольно дремучая. ПЛЮСЫ:
Мне понравился и язык, и типизация, и портабельность и скорость работы. Мы делали десктоп и PWA-версию на React (не Native, но все же...) и мобильную разработку на Dart. (Не сочтите за рекламу, потыкать можно тут singularity-app.com). Код мобильной версии получился в разы проще (в основном конечно не из-за языка, а, из-за того, что не нужно было делать типовые десктопные штуки, типа обработку хоткеев и всякие прелести, типа CMD+Z). Плюс паттерн BLOc, который проповедуют в мире Flutter, в итоге дает более понятный код и меньше слоев абстракции, чем Redux (тут очень спорно и холиварно, и все зависит от задачи, но в нашем случае это оказалось так; впрочем никто не мешает его использовать MOBx но в больших приложениях есть риск утонуть в отладке обзерверов).
Итог такой, что лично я доволен Flutter. А минусы — везде есть )
Спасибо! Мы стараемся)
Круто!
Ещё, говорят, кто быстро ест — тот быстро работает. Тоже, наверное, внутренние психические процессы)
Фига сё, лёгкий... Это вы мой график не знаете. Но обсуждаете. Такое...
А ещё мы видим, как все превращается в 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.
squircley.app
МИНУСЫ:
1. Сырой API. Могут поменять спецификацию «На лету».
2. Не работают некоторые нативные вещи, которые должны работать из коробки. Например, до сих пор есть глюки в текстовых полях на некоторых моделях телефонов (задваивается текст). Решается костылями. А очень неприятно решать костылями то, что ожидаемо должно правильно работать из коробки.
3. Нет НОРМАЛЬНОГО WYSIWYG-редактора (проект зефир скорее мертв чем жив).
4. Виджеты. Пришлось писать на нативе. В итоге довольно сложная архитектура, т.к. виджет должен работать в паре с основным приложением, а поднимать дартовское приложение в фоне для виджета — это сразу большой расход памяти (напомню, у виджетов например на айфонах есть ограничение в 24 мегабайта). Выкрутиться можно, но архитектура получается довольно дремучая.
ПЛЮСЫ:
Мне понравился и язык, и типизация, и портабельность и скорость работы. Мы делали десктоп и PWA-версию на React (не Native, но все же...) и мобильную разработку на Dart. (Не сочтите за рекламу, потыкать можно тут singularity-app.com). Код мобильной версии получился в разы проще (в основном конечно не из-за языка, а, из-за того, что не нужно было делать типовые десктопные штуки, типа обработку хоткеев и всякие прелести, типа CMD+Z). Плюс паттерн BLOc, который проповедуют в мире Flutter, в итоге дает более понятный код и меньше слоев абстракции, чем Redux (тут очень спорно и холиварно, и все зависит от задачи, но в нашем случае это оказалось так; впрочем никто не мешает его использовать MOBx но в больших приложениях есть риск утонуть в отладке обзерверов).
Итог такой, что лично я доволен Flutter. А минусы — везде есть )