BLoC паттерн на простом примере

[@awaik]

Разные паттерны для разных случаев, тут я просто переписал простейший пример для понимания того, как полностью вынести логику и правильно его реализовать.
Если вы имеете в виду вот этот провайдер pub.dev/packages/provider — то этот подход (пакет) зачастую используется вместе с BLoC, когда надо передавать состояние по разным классам (экранам, виджетам). Как я понимаю, этот пакет написан поверх встроенных Inherited widgets и оказался таким удачным, что команда Flutter тоже теперь в нем участвует + рекомендует к использованию.
IMHO

[@awaik]

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

[@awaik]

Вот недавно столкнулся — весь код написанный на BLoC без правок переносится в web + «настольные» приложения, так как не привязан к виджетам.
С provider так не получится, придется переписывать логику.
Так что мой личный выбор BLoC + провайдер для мутаций по дереву виджетов, без логики.

[@awaik]

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

[@awaik]

Вот это интересно, спасибо, как раз выше написал про то, что микс у меня получился архитектур. Попробую как там что.

[@rchese]

Спасибо за статью.

Чтобы избежать утечек памяти, необходимо MyHomePage сделать StatefulWidget'ом, чтобы переопределить метод dispose с вызовом соответствующего метода объекта counterBloc.

[@awaik]

Да, использование StatefulWidget упростит dispose и обычно так и делается. Тут я хотел показать, что при использовании BLoC мы можем полностью уйти от управления состоянием через setState методы.

[@Neikist]

Спасибо. Продолжения ждать?

[@awaik]

Спасибо :)
Да, в течение пары недель, сейчас в проду проект на флаттере выпускаем и сил ни на что не остается.

[@Neikist]

Гуд, буду ждать. Пока для себя, по тому что узнал, блок вижу более предпочтительным (по крайней мере в сравнении с редаксом), интересно почитать, посмотреть примеры. Единственное — не понимаю в чем практический смысл не только слушать блок через стримы, но и оповещать его о событиях таким же образом.

[@Neikist]

И? Практический смысл того что из блока данные выходят через стримы я понимаю, можно стрим билдеры использовать что довольно удобно, да и блоку не нужно на вью ссылаться для передачи данных. Но в чем смысл использовать стримы на вход в блок? Я не вижу практических преимуществ перед тем чтобы просто дергать методы блока напрямую.

[@awaik]

Если вы программируете в реактивном стиле, то смысл правила — все входы == Streams, становится понятным.

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

А если через Streams, то все будет очень красиво и логично.

Сам оператор вот тут reactivex.io/documentation/operators/debounce.html

(я очень надеюсь скоро опубликовать package для instagram подобных сториз и там как раз все это становится очень понятно)

[@Neikist]

Хм, действительно, выглядит применение вполне логично, спасибо.

[@unel]

Не очень понимаю, почему код будет кривоватым?

debounce / throttle декораторы для функций известны ещё со времён underscore, если не раньше

[@awaik]

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

[@awaik]

Продолжение тут habr.com/ru/post/485002

[@SmartDiver]

Такое ощущение, что кто-то открыл для себя react + state manager или даже angular