Комментарии 23
НЛО прилетело и опубликовало эту надпись здесь
Разные паттерны для разных случаев, тут я просто переписал простейший пример для понимания того, как полностью вынести логику и правильно его реализовать.
Если вы имеете в виду вот этот провайдер pub.dev/packages/provider — то этот подход (пакет) зачастую используется вместе с BLoC, когда надо передавать состояние по разным классам (экранам, виджетам). Как я понимаю, этот пакет написан поверх встроенных Inherited widgets и оказался таким удачным, что команда Flutter тоже теперь в нем участвует + рекомендует к использованию.
IMHO
Если вы имеете в виду вот этот провайдер pub.dev/packages/provider — то этот подход (пакет) зачастую используется вместе с BLoC, когда надо передавать состояние по разным классам (экранам, виджетам). Как я понимаю, этот пакет написан поверх встроенных Inherited widgets и оказался таким удачным, что команда Flutter тоже теперь в нем участвует + рекомендует к использованию.
IMHO
0
НЛО прилетело и опубликовало эту надпись здесь
Мне кажется, чтобы ответить на этот вопрос, надо взять какую-нибудь типовую проблему и написать 2 варианта решения.
И посмотреть что получается в разных вариантах.
Вы вполне можете быть правы, но вот так сразу я не готов точно сказать, так как очень много разных проблем в реальных приложениях и мне часто не хватало только провайдера.
Но это не показатель конечно.
И посмотреть что получается в разных вариантах.
Вы вполне можете быть правы, но вот так сразу я не готов точно сказать, так как очень много разных проблем в реальных приложениях и мне часто не хватало только провайдера.
Но это не показатель конечно.
0
Вот недавно столкнулся — весь код написанный на BLoC без правок переносится в web + «настольные» приложения, так как не привязан к виджетам.
С provider так не получится, придется переписывать логику.
Так что мой личный выбор BLoC + провайдер для мутаций по дереву виджетов, без логики.
С provider так не получится, придется переписывать логику.
Так что мой личный выбор BLoC + провайдер для мутаций по дереву виджетов, без логики.
0
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Спасибо за статью.
Чтобы избежать утечек памяти, необходимо MyHomePage сделать StatefulWidget'ом, чтобы переопределить метод dispose с вызовом соответствующего метода объекта counterBloc.
Чтобы избежать утечек памяти, необходимо MyHomePage сделать StatefulWidget'ом, чтобы переопределить метод dispose с вызовом соответствующего метода объекта counterBloc.
+1
Спасибо. Продолжения ждать?
+1
Спасибо :)
Да, в течение пары недель, сейчас в проду проект на флаттере выпускаем и сил ни на что не остается.
Да, в течение пары недель, сейчас в проду проект на флаттере выпускаем и сил ни на что не остается.
0
Гуд, буду ждать. Пока для себя, по тому что узнал, блок вижу более предпочтительным (по крайней мере в сравнении с редаксом), интересно почитать, посмотреть примеры. Единственное — не понимаю в чем практический смысл не только слушать блок через стримы, но и оповещать его о событиях таким же образом.
0
НЛО прилетело и опубликовало эту надпись здесь
И? Практический смысл того что из блока данные выходят через стримы я понимаю, можно стрим билдеры использовать что довольно удобно, да и блоку не нужно на вью ссылаться для передачи данных. Но в чем смысл использовать стримы на вход в блок? Я не вижу практических преимуществ перед тем чтобы просто дергать методы блока напрямую.
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
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
BLoC паттерн на простом примере