Как стать автором
Обновить

Комментарии 12

Ну не знаю, как по мне MobX делает тоже, но более читабельно.

Ну, а по мне stacked удобнее и нет лишних прослоек, но чемто похож на Elementary

В Stacked у виджета остается доступ к контексту. В Elementary вся работа с контекстом вынесена в WM это позволяет лучше тестировать приложение. Концепции будут похожи так как MVVM взят за основу у обоих.

На недавнем DartUp был доклад о том, что в случае Flutter mvvm - это антипаттерн, так как эта архитектура создана, чтобы решать проблему, которой нет во Flutter.

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

Прокомментируйте, пожалуйста.

Спасибо!

О каком конкретно докладе идет речь?

Не совсем понял, какой пакет уже менялся кардинально?

По поводу проблемы, которой нет во flutter. Разве то, что слой представления так или иначе содержит бизнес-логику не выглядит как проблема? Плюс такое разделение позволяет протестировать отдельно Model, WidgetModel и сам виджет.

Речь о последнем докладе второго дня в англоязычном потоке от Кирилла Бубочкина.
Ваш пакет Elementary, который вы продвигаете, наследует MWWM. Это просто переименование или всё же обратно несовместимые пакеты?
Правильно ли я понимаю ваш тезис о тестировании, как главный и единственный аргумент за предлагаемый подход?
Если так, то пишете ли вы сами UI-тесты в таком объёме, чтобы оправдать сопутствующие издержки?
Могут ли golden-тесты с использованием презентера позволить тестировать виджеты не хуже предлагаемого вами подхода?

Здравствуйте, я как автор библиотеки тоже немного подключусь к обсуждению. Скоро выйдет статья в которой я многие из этих проблем расскажу и опишу подробнее, но пока что вкратце постараюсь ответить.

На недавнем DartUp был доклад о том, что в случае Flutter mvvm - это антипаттерн, так как эта архитектура создана, чтобы решать проблему, которой нет во Flutter.

А какой конкретно проблемы нет во Flutter? Нет необходимости иметь презентационную логику, или презентационное состояние? Есть. Иначе зачем было бы разработчикам добавлять например StatefulWidget? Как раз для того что есть такая необходимость, стейт просто берет этот момент на себя. И для небольших приложений вам вообще ничего не нужно, ни стейтмашины отдельные, ни либы которые вам позволят имплементировать конкретные паттерны.

Касаемо самого MVVM - он хорош удобен и полезен, когда у нас есть возможность реагировать на изменение свойств в отображении и у Flutter эта возможность есть.

Правильно ли я понимаю ваш тезис о тестировании, как главный и единственный аргумент за предлагаемый подход?

Нет не едиснтвенный - разделение отвтетственностей делает код чище, проще, в том числе и проще для тестирования. Ну и естественно за это приходится платить тем что нужно написать чуть больше сущностей. Это решаемая проблема - как темплейтами, так и мы уже провели работу над этим и добавили плагины которые генерируют бойлерплейт код, разработчику нужно лишь писать действительно ценное содержание.

Ваш пакет Elementary, который вы продвигаете, наследует MWWM. Это просто переименование или всё же обратно несовместимые пакеты?

Это разные пакеты, но в Elementary я постарался забрать удобные вещи из mwwm на основе опыта личного использования и избежать болей которые могли возникать при его использовании. Не смотря на то что это разные пакеты, миграция проходит довольно легко, @vlkonoshenko может это подтвердить, у него есть такой опыт.

Если так, то пишете ли вы сами UI-тесты в таком объёме, чтобы оправдать сопутствующие издержки?

Да мы активно пишем как юнит тесты, так и виджет/голден. Чуть реже используется e2e тестирование, но в данном случае не разработчиками а qa отделом. А издержки не такие большие от многословности, как вам кажется, а с учетом автоматизаций они становятся еще меньше. При этом Elementary изначально проектировался с таким учетом, чтобы тесты было писать просто, быстро и это лишь подталкивало к тому чтобы это делать еще полнее и качественнее на проектах.

Михаил, благодарю за развёрнытый ответ! Жду вашу статью!

Наверное, мне не стоит пересказывать доклад Кирилла и эту ветвь дискуссии не стоит развивать, если и вы не посмотрите его. Не хотел бы переврать тезисы.

Ваши доклады я тоже смотрел и вполглаза следил за эволюцией MWWM -> Elementary, потому и задал вопрос о такой зависимости.

Вероятно, мне следовало сразу обозначить свою боль, породившую изначальный вопрос. Попробую кратко изложить, полагая, что я не один такой.
Я не противник MVVM и не сомневаюсь в его сильных сторонах.
Flutter представляется фреймворком, позволяющим быстрее и проще создавать приложения. Он предлагает подход "всё есть виджет", но не обязывает ему следовать. Можно обнаружить огромное разнообразие библиотек, большая часть которых реализует технологии, пришедшие из других языков и платформ (redux, rx и т.п.) и выглядят чужеродными. В то же время есть примеры библиотек (Provider, graphql_flutter), следующие парадигме "всё есть виджет". Они предлагают несколько иной подход, который выглядит компактнее. Это позволяет надеяться, что быстро написанный MVP не придётся выбрасывать, а можно продолжать развивать, не боясь породить неподдерживаемого монстра.

Возможно, это лишь путь смелых продуктовых компаний, а тем, кто рисковать не готов надёжнее полагаться на проверенные подходы. Но рисковать хотелось бы зная, что кто-то прошёл этой дорогой и не пожалел. Однако, мне не попадались развёрнутые доклады на эту тему. В докладах Surf лишь кратко упоминалась причина разработки MWWM (BLoC не понравился?), если я ничего не упустил.

Да, стейт менеджер не обязательно определяет архитектуру проекта, но всё же влияет на удобство реализаций той или иной. Приходят ли вам на ум статьи, где вы сравниваете Elementary с другими пакетами? Например, с Clean Dart и чем-то попроще? Возможно, это будет в новой статье?

Спасибо!

Спасибо за фидбкек!

Наверное, мне не стоит пересказывать доклад Кирилла и эту ветвь дискуссии не стоит развивать, если и вы не посмотрите его. Не хотел бы переврать тезисы.

В любом случае заинтересовали и теперь в список докладов, которые не успел посмотреть сразу на DartUP и посмотрю позже добавился доклад Кирилла.

Касаемо моего решения, 1 из важных моментов было чтобы Elementary не просто следовал MVVM, а еще и укладывался в том числе в логику работы Flutter. В статье я как раз про это буду рассказывать. Ну и собственно если посмотрите исходники - он укладывается, используется для представления интерфейса виджет, источником правды для которого является сущность с презентационным состоянием и презентационной логикой. И живет она вместе с Element-ом. Вобщем реализация настолько близка к Flutter (к Stateful виджету если быть точнее) что местами они как два брата близнеца.

В докладах Surf лишь кратко упоминалась причина разработки MWWM

Ну мы кстати довольно много про это говорили в различных выступлениях. Не было блока когда отдел создавался. Да и если бы был скорее всего ничего бы не поменялось. 1ое чисто наша история - нужна была легкая конверсия разработчиков из андроида и потенциальная назад если ничего не получится. 2 - блок это часть бизнес логики, стейт машина по конкретному кейсу. Стейтмашина это только часть вашей архитектуры. А учитывая что мобилки это в большинстве тонкие клиенты - порой тот же блок на мой взгляд в огромном количестве кейсов просто избыточен. Есть кейсы когда он жизненно необходим, но это не запросы которые мы по сети делаем. В случае что MWWM что Elementary это более широкие вопросы чем просто организация стейтмашины, к слову я вообще туда не стал тянуть ее. Как мне кажется разработчик достаточно самостоятелен чтоб ему не диктовали сверху как ему писать бизнес логику в конкретной ситуации.

Приходят ли вам на ум статьи, где вы сравниваете Elementary с другими пакетами?

Вот тут вряд ли) мне это чужеродно, даже если я буду делать это объективно, это не будет выглядеть таковым. При этом я не люблю искать сор в чужом глазу, поэтому тыкать в проблемы каких то решений ну как-то не по мне. У любого решения есть сильные и слабые стороны. Если вам говорят что оно идеально, save some ram и в 9 раз быстрее всего остального, есть большая вероятность что вас обманывают. Поэтому я могу лишь честно анализировать свое решение. В нем есть слабая сторона - многословность. Поэтому мы создали тулинг чтобы уменьшить действие этой слабости. Опять же Elementary это инструмент, которым надо понять как пользоваться.

Михаил, благодарю за развёрнутый ответ!
Полагаю, анонсированная статья будет действиткельно полезна.
В вопросе о сравнении Elementary с другими я не подразумевал поиск сора в чужом глазу. Мне очень понравился доклад архитектора из Гугл, сделавшего таблицу по нескольким менеджерам состояния, чтобы можно было выбирать исходя из конкретных условий. Он её делал для себя, но сделал для всех.
Полагаю, есть смысл объективно сравнить разные подходы, чтобы сделать доступнее процесс выбора архитектуры, подходящей конкретному проекту.
Вероятно, это лучше делать не самим авторам, хотя и такой вариант возможен.

Доклад Кирилла, на который я ссылался выше, появился в текстовом виде https://habr.com/ru/post/596503/

Cпасибо, выглядит интересно

Ссылка на LiveTemplate не рабочая

Зарегистрируйтесь на Хабре , чтобы оставить комментарий