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

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

Что в этом блоке такого что не может провайдер?
Разные паттерны для разных случаев, тут я просто переписал простейший пример для понимания того, как полностью вынести логику и правильно его реализовать.
Если вы имеете в виду вот этот провайдер pub.dev/packages/provider — то этот подход (пакет) зачастую используется вместе с BLoC, когда надо передавать состояние по разным классам (экранам, виджетам). Как я понимаю, этот пакет написан поверх встроенных Inherited widgets и оказался таким удачным, что команда Flutter тоже теперь в нем участвует + рекомендует к использованию.
IMHO
Мой вопрос в том, что они оба нужны для управления состоянием, архитектуру приложения в целом на них не сделаешь. Другими словами, например мы используем клин архитектуру и в слое отвечающем за юай будет либо блок, либо блок через провайдер, либо провайдер. Вариант с чистым провайдером в разы проще и удобнее и писать в разы меньше. Поэтому и спросил что в этом блоке такого? Его везде позиционируют как что то маст хев для крупных приложений, но это совершенно не так.
Мне кажется, чтобы ответить на этот вопрос, надо взять какую-нибудь типовую проблему и написать 2 варианта решения.
И посмотреть что получается в разных вариантах.
Вы вполне можете быть правы, но вот так сразу я не готов точно сказать, так как очень много разных проблем в реальных приложениях и мне часто не хватало только провайдера.
Но это не показатель конечно.
Вот недавно столкнулся — весь код написанный на BLoC без правок переносится в web + «настольные» приложения, так как не привязан к виджетам.
С provider так не получится, придется переписывать логику.
Так что мой личный выбор BLoC + провайдер для мутаций по дереву виджетов, без логики.
awaik, если у вас логика каким-то образом оказалась связана с виджетами, то возможно, вы неверно используете провайдер.
Provider/ChangeNotifierProvider находятся в дереве виджетов, но классы, которые они создают и провайдят, висят отдельно в воздухе, ничего не знают про контекст и про UI, и занимаются только бизнес-логикой.
Если интересно, давайте я вспомню проблему, на которой это возникало и мы можем обсудить в личке варианты (примерчики накидать), а тут резюме.
На сегодняшний день, на пятом приложении, у меня выработалась вообще какая-то своя архитектура, которую тоже интересно было бы обсудить :)
vr19860507, я еще покопал эту тему. Объективное отличие одно:
— Provider+ChangeNotifier и MobX+Provider — это мутабельные архитектуры (с изменением хранилища). Преимущество — как вы справедливо заметили, гораздо меньше писанины.
— Redux (и его вариации), BLoC Library — иммутабельные архитектуры (выкидывают тебе стейты). Преимущество — ты можешь иметь историю стейтов приложения, «путешествовать во времени» (возвращаться на предыдущие стейты), можешь сохранить целиком состояние приложения. Другой вопрос, насколько это надо.
P.S. Есть еще плагин StateNotifier (от того же Реми, создателя провайдера), позволяет взять лучшее из обоих подходов, и создавать классы под провайдер с иммутабельными стейтами. Пока в версии 0.5, возможно, будет ещё значительно допиливаться, но штука перспективная.
Вот это интересно, спасибо, как раз выше написал про то, что микс у меня получился архитектур. Попробую как там что.
vr19860507 моё имхо, что не более чем вкусовщина.
В провайдер прекрасно можно выносить бизнес-логику.
Смотрел BLoC и MobX — те же яйца, только в профиль. Но в provider всё прозрачнее и значительно меньше кода.
Плюс к тому BLoC был чуть ли не единственным решением до провайдера, думаю, что многие его выучили и теперь не могут/не хотят переучиваться.
Общался в чате с одним чуваком, который всех поучает, везде топит за блок и утверждает, что «провайдер — всего лишь примитивная тулза для доступа по ссылке к объекту, а Блок — это Архитектура». Из дальнейших разговоров выяснилось, что чувак тупо не разбирается, как работает ChangeNotifier и не понимает как организовать обмен данными с провайдером, и понимать не хочет.
Кстати, подумываю тут сам написать статью про архитектуру на провайдерах на простом примере и просветить народ, а то в официальной документации он объяснен очень поверхностно, чисто синтаксис, без примеров использования.
Спасибо за статью.

Чтобы избежать утечек памяти, необходимо MyHomePage сделать StatefulWidget'ом, чтобы переопределить метод dispose с вызовом соответствующего метода объекта counterBloc.
Да, использование StatefulWidget упростит dispose и обычно так и делается. Тут я хотел показать, что при использовании BLoC мы можем полностью уйти от управления состоянием через setState методы.
Спасибо. Продолжения ждать?
Спасибо :)
Да, в течение пары недель, сейчас в проду проект на флаттере выпускаем и сил ни на что не остается.
Гуд, буду ждать. Пока для себя, по тому что узнал, блок вижу более предпочтительным (по крайней мере в сравнении с редаксом), интересно почитать, посмотреть примеры. Единственное — не понимаю в чем практический смысл не только слушать блок через стримы, но и оповещать его о событиях таким же образом.
Потому что реактивность
И? Практический смысл того что из блока данные выходят через стримы я понимаю, можно стрим билдеры использовать что довольно удобно, да и блоку не нужно на вью ссылаться для передачи данных. Но в чем смысл использовать стримы на вход в блок? Я не вижу практических преимуществ перед тем чтобы просто дергать методы блока напрямую.
Если вы программируете в реактивном стиле, то смысл правила — все входы == Streams, становится понятным.

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

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

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

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

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


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

Да, я согласен. Тут речь все таки про блок паттерн и программирование в реактивном стиле.
Если интересно, можем сделать простой пример и посмотреть как будет выглядеть код в разных стилях.
Такое ощущение, что кто-то открыл для себя react + state manager или даже angular
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.