Comments 23
UFO just landed and posted this here
Разные паттерны для разных случаев, тут я просто переписал простейший пример для понимания того, как полностью вынести логику и правильно его реализовать.
Если вы имеете в виду вот этот провайдер pub.dev/packages/provider — то этот подход (пакет) зачастую используется вместе с BLoC, когда надо передавать состояние по разным классам (экранам, виджетам). Как я понимаю, этот пакет написан поверх встроенных Inherited widgets и оказался таким удачным, что команда Flutter тоже теперь в нем участвует + рекомендует к использованию.
IMHO
Если вы имеете в виду вот этот провайдер pub.dev/packages/provider — то этот подход (пакет) зачастую используется вместе с BLoC, когда надо передавать состояние по разным классам (экранам, виджетам). Как я понимаю, этот пакет написан поверх встроенных Inherited widgets и оказался таким удачным, что команда Flutter тоже теперь в нем участвует + рекомендует к использованию.
IMHO
0
UFO just landed and posted this here
Мне кажется, чтобы ответить на этот вопрос, надо взять какую-нибудь типовую проблему и написать 2 варианта решения.
И посмотреть что получается в разных вариантах.
Вы вполне можете быть правы, но вот так сразу я не готов точно сказать, так как очень много разных проблем в реальных приложениях и мне часто не хватало только провайдера.
Но это не показатель конечно.
И посмотреть что получается в разных вариантах.
Вы вполне можете быть правы, но вот так сразу я не готов точно сказать, так как очень много разных проблем в реальных приложениях и мне часто не хватало только провайдера.
Но это не показатель конечно.
0
Вот недавно столкнулся — весь код написанный на BLoC без правок переносится в web + «настольные» приложения, так как не привязан к виджетам.
С provider так не получится, придется переписывать логику.
Так что мой личный выбор BLoC + провайдер для мутаций по дереву виджетов, без логики.
С provider так не получится, придется переписывать логику.
Так что мой личный выбор BLoC + провайдер для мутаций по дереву виджетов, без логики.
0
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Спасибо за статью.
Чтобы избежать утечек памяти, необходимо MyHomePage сделать StatefulWidget'ом, чтобы переопределить метод dispose с вызовом соответствующего метода объекта counterBloc.
Чтобы избежать утечек памяти, необходимо MyHomePage сделать StatefulWidget'ом, чтобы переопределить метод dispose с вызовом соответствующего метода объекта counterBloc.
+1
Спасибо. Продолжения ждать?
+1
Спасибо :)
Да, в течение пары недель, сейчас в проду проект на флаттере выпускаем и сил ни на что не остается.
Да, в течение пары недель, сейчас в проду проект на флаттере выпускаем и сил ни на что не остается.
0
Гуд, буду ждать. Пока для себя, по тому что узнал, блок вижу более предпочтительным (по крайней мере в сравнении с редаксом), интересно почитать, посмотреть примеры. Единственное — не понимаю в чем практический смысл не только слушать блок через стримы, но и оповещать его о событиях таким же образом.
0
UFO just landed and posted this here
И? Практический смысл того что из блока данные выходят через стримы я понимаю, можно стрим билдеры использовать что довольно удобно, да и блоку не нужно на вью ссылаться для передачи данных. Но в чем смысл использовать стримы на вход в блок? Я не вижу практических преимуществ перед тем чтобы просто дергать методы блока напрямую.
0
Если вы программируете в реактивном стиле, то смысл правила — все входы == Streams, становится понятным.
Например, если реализовать Debounce оператор, для постановки лайков в приложении, то передача любого нажатия напрямую в блок сделает код кривоватым и трудно масштабируемым.
А если через Streams, то все будет очень красиво и логично.
Сам оператор вот тут reactivex.io/documentation/operators/debounce.html
(я очень надеюсь скоро опубликовать package для instagram подобных сториз и там как раз все это становится очень понятно)
Например, если реализовать Debounce оператор, для постановки лайков в приложении, то передача любого нажатия напрямую в блок сделает код кривоватым и трудно масштабируемым.
А если через Streams, то все будет очень красиво и логично.
Сам оператор вот тут reactivex.io/documentation/operators/debounce.html
(я очень надеюсь скоро опубликовать package для instagram подобных сториз и там как раз все это становится очень понятно)
0
Хм, действительно, выглядит применение вполне логично, спасибо.
0
Не очень понимаю, почему код будет кривоватым?
debounce / throttle декораторы для функций известны ещё со времён underscore, если не раньше
0
Продолжение тут habr.com/ru/post/485002
+1
Такое ощущение, что кто-то открыл для себя react + state manager или даже angular
0
Sign up to leave a comment.
BLoC паттерн на простом примере