и сложно "подменить" реализацию фичи в проекте

замена на блок это = класс с самописной бизнес логикой

было бы очень круто, если бы в следующей статье попровали "выпилить" мобх и оценить clean насколько пришлось глубоко залезть

и спасибо за статью 🙃

Я попробую:)

Спасибо.
Еще раз спасибо за статью, по итогу стало только немного жалко что такой пример маленький для демонстрации был выбран, т.к. доменная логика и usecase совсем не раскрыты.
Планируются ли еще статьи по flutter?

Пример был маленьким как раз для того, чтобы не отвлекать от основной идеи. Что касается ещё статей - есть несколько задумок, но пока не знаю, когда возьмусь за них.

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

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

Ссылки на родительские что? Виджеты? Я такого не видела😁 блоки? Такую идею вроде предлагал сам создатель блок пакета.

Я к сожалению видел. Я видел, когда в build методе виджета идет получение данных из bloc, который размещен в контексте, и это называли переносимым решением.

Для меня это сложная тема. Я не очень люблю инхеритед виджеты поэтому (решения не очень переносимые получается, если инхеритед не тема или локаль), но это инструмент, который даёт флаттер и комьюнити его активно использует. Все презентации по стейт менеджмент решениям начинались раньше со слов: ну неужели вы будете передавать это все в конструктор снова и снова. Так что в каких-то случаях это наверное и ок. Смотря как делить на компоненты и что именно хотеть переносить

Я считаю,что если есть логически отдельный компонент , то его обращение к данным из контекста - хреновое решение. Да ему нужно передать все в конструкторе, а дальше внутри должен быть свой блок, который занимается внутренней логикой и дает какое то апи для получения результатов этого компонента (контроллер, stream, future)

Да, согласна

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

Вторая часть, кмк, не менее важная чем первая.
Если по итогу статьи поставить вопрос: а как модифицировать приложение таким образом, чтобы пользователь не мог делать запрос информации более 3 раз в день, думаю вариантов реализаций будет предложено очень много)

я разделяю компоненты на умные и глупые.

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

Тогда он не переносим.

Имхо с redux так не получится...

у умных компонентов нет такой цели, это просто темплейты для верстки

Ну  тут вопрос терминологии. Компонент - атом. Все что состоит из компонентов - композиция( в моем словаре)