Pull to refresh
166
0
Владимир Завертайлов @zevvssibirix

Главный бармалей в Сибирикс и SingularityApp

Send message

Руки бы поотрывать тем, кто пытается делать откат действий через снепшоты.

Вы бы сначала спеки 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, а с рефакторингом селекторов и мидлварей. Запишем, что со скоростью все ОК.

Теперь о минусах. Их было три. И все они были на поверхности.

  1. Болтливое описание типов в сторах. "Ну блин, нахрена ж вы так сделали?". Авторам нет оправдания :)) Не, я понимаю, почему они сделали именно так. Но это не круто. В идеальном мире я хочу просто перенаследовать модели с бэкэнда и сделать их обсерверными. Но MST говорит "обрыбишься".

  2. Наследование сторов через трамбу-лямбу (композицию). Блевотка же. Этот минус следует из первого. На простых приложениях это не потребуется. Но если много actions / views — распилить стор по слоям очень захочется. MST по сути предлагает решение. Но оно не эстетичное.

  3. Асинхронные экшины через генераторы. Вот за это хочется бить палками. Благо, таких операций у нас получилось всего 4-5 (CRUD) и их аккуратно спрятали с глаз долой в базовую модель. Но смотреть на flow(function* fetchProjects()... у меня глаз дергается. Могли бы напрячься, и починить обычные промисы/асинк/авэйт.

Что запишу в плюсы (они все спорные, но для меня — плюсы, поэтому кто не согласен — просто отвалите):

  1. Код реально получается ОЧЕНЬ простой. Как и архитектура. И кода становится в разы меньше, чем на redux. Меньше кода — меньше багов. Разработка ускорилась.

  2. Тестируемость. По сути, в тестах мы замокали один объект (backend-connector), передаваемый в mst через депенденси-энджекшин. И получили простые, чистые, красивые юнит-тесты на селекторы и экшины. Я — доволен.

  3. Таймтревел и снапшоты. В нашем случае это must have. Порадовала работа с патчами.

Чем не стали пользоваться: в MST есть коннектор к Redux-стору. По сути — тупая мидлварь на два экрана. Были мыслишки, что для рефакторинга это будет удобно. По факту удобнее оказалось извлекать какю-то сущьность из редакса целиком.

Итого: если тайм тревел не нужен — вам не нужен MST. Если нужен — на чистом MobX его рехнешься писать. Ну а redux, безусловно, нужно потихоньку хоронить.

Спасибо за материал. Чувствуется глубокое погружение в тему. Почему не используете MST? Да, там болтливый синтаксис описания сторов. Но озвученная вами проблема совместного использования данных решена. До кучи — time travel и снапшоты из коробки — легко подключать API.

Привет. Пока inprogress. Готово процентов 60.
Мне нравится )
Пишем на Flutter полтора года. В целом — довольны, получилось очень не плохо. Но есть минусы.
МИНУСЫ:
1. Сырой API. Могут поменять спецификацию «На лету».
2. Не работают некоторые нативные вещи, которые должны работать из коробки. Например, до сих пор есть глюки в текстовых полях на некоторых моделях телефонов (задваивается текст). Решается костылями. А очень неприятно решать костылями то, что ожидаемо должно правильно работать из коробки.
3. Нет НОРМАЛЬНОГО WYSIWYG-редактора (проект зефир скорее мертв чем жив).
4. Виджеты. Пришлось писать на нативе. В итоге довольно сложная архитектура, т.к. виджет должен работать в паре с основным приложением, а поднимать дартовское приложение в фоне для виджета — это сразу большой расход памяти (напомню, у виджетов например на айфонах есть ограничение в 24 мегабайта). Выкрутиться можно, но архитектура получается довольно дремучая.
ПЛЮСЫ:
Мне понравился и язык, и типизация, и портабельность и скорость работы. Мы делали десктоп и PWA-версию на React (не Native, но все же...) и мобильную разработку на Dart. (Не сочтите за рекламу, потыкать можно тут singularity-app.com). Код мобильной версии получился в разы проще (в основном конечно не из-за языка, а, из-за того, что не нужно было делать типовые десктопные штуки, типа обработку хоткеев и всякие прелести, типа CMD+Z). Плюс паттерн BLOc, который проповедуют в мире Flutter, в итоге дает более понятный код и меньше слоев абстракции, чем Redux (тут очень спорно и холиварно, и все зависит от задачи, но в нашем случае это оказалось так; впрочем никто не мешает его использовать MOBx но в больших приложениях есть риск утонуть в отладке обзерверов).
Итог такой, что лично я доволен Flutter. А минусы — везде есть )
Да. Но это больше похоже на багфикс чужого кода. Чем на аппрув пул-реквестов :)
Да. Есть стимул стараться.
Предусмотреть вообще всё, увы, невозможно :)
При всём при этом макеты в фотошопе пока окончательно не исчезли, а плохие макеты в фотошопе — тем более
Думаете, прям тратят время на изучение Фотошопа? Да его просто давно все знают и по привычке используют, скорее. Вопрос в том, что у кого-то даже привычки-то работать в нём грамотно не сформировалось:)
Автор только что пришел с тренировки по боксу, и у него синяк на среднем пальце. Автор понимает все риски. И в основном исходит из песни Шнура про ЗОЖ. Вернее, из её припева :)
Да, но это другая проблема. По-моему инженерного решения не имеет.
Сможет ли человек интерпретировать код, или будет дрюкаться между парой мониторов (с штормом и браузером), надалбывая CTRL+R, в надежде, что очередной кусок копипасты заработает как надо :) В прочем, ctrl+r многие уже автоматизировали…
Да, вы правы. Особенно с отечественным заказчиком (.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity