Урок 90. Архитектуры - BLoC. Введение.

Пожертвования - boosty.to/lazyloadflutter
Канал с анонсами в телеграм - t.me/lazyload_flutter
Группа в телеграм - t.me/learnDartFlutter
Группа в вк - club203125105
Код урока для подписчиков boosty - github.com/JonFir/lazyload_fl...
Заметка про блок - telegra.ph/Paru-slov-o-BLoC-0...

[@Raimkhodzhanov]

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

[@stanlygetz9616]

Спасибо большое! Ждал объяснение BLOC именно от Вас, Евгений, так как Вы лучше всех рассказываете про Flutter!

[@dan.gorbunov]

Как же я люблю твои уроки

[@sovrinfo]

Евгений, большое спасибо за ваш труд!!! Коммент в поддержку!

[@overlord2k4]

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

[@RubicsGuide]

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

[@SviatoslavMoskva]

Большое спасибо! Очень ждал урока про bloc

[@SciNotes]

Огромное спасибо вам за то , что вы делаете !!!

[@artischock]

премного благодарен за данный видеоматериал

[@ravshan349]

good lesson!

[@svetlanaia7900]

огромное спасибо за ваш труд! лучшие уроки!!

[@KBOOMSKA]

Прекрасный урок, спасибо Вам огромное!

[@SpacePC.]

Спасибо за урок!

[@diyorjonnasriddinov]

thank you for lessons you are number one blogger on youtube

[@GO-JS]

Супер респект за уроки.

[@GO-JS]

Поддержал подпиской, главное чтобы хватало времени после 2 работ)

[@nazarsorokin5665]

Спасибо за качественный контент)

[@abibor]

Спасибо за уроки!

[@user-od5pm7ou1f]

Топ!!! Спасибо, ты лучший учитель.

[@user-wj6il8xo6l]

Спасибо за контент!

[@IgorN1234]

Спасибо большое!

[@TarasShevchenkoStep]

Здорово - ждем блок и кубит )

[@mishakalyna]

Thanks a lot!

[@serezhka4920]

Спасибо за урок! Для меня на данном этапе овладения флаттером, такой блок как-то проще выглядит, чем мввм. Вот блок, вот в нем всё, а в мввм куча классов дополнительных была.

[@n000x]

Большое спасибо

[@user-yo3so7ep8v]

отличное видео

[@user-ho4cn9yp9x]

Спасибо!

[@user-ok6nz2mo7v]

👍

[@peekors8829]

хороший урок, запишите плз Riverpod+Hooks

[@yell3137]

+ за хуки

[@unknownunknown17]

Если я правильно понял, то всё в мобильной разработке на Flutter в основе завязано на Инхеритах? Только разные методы их реализации

[@LearnDartFlutter]

практически да

[@ChorumTheDevourer]

А у меня такой вопрос. Вы принципиально не пользуетесь пакетами типа freezed и json_annotation для кодогенерации или это чисто для разжевывания материалов для зрителей? С тем же блоком от Ангелова работать с помощью фризд одно удовольствие, отвлекаясь на блок с copyWith только в случае, если нужно менять маленькую часть большого стейта. Уроки отличные, просто порой некоторый оверинжиниринг вызывает недоумение.

[@LearnDartFlutter]

Не принципиально, в целом фризед использовать можно

[@_Sergey_E_]

Евгений, если в коде используется Provider, то не проще добавить StreamProvider, чтобы не использовать StreamBuilder. Нужно только описать UserBloc как singleton класс. Вроде при StreamProvider не нужен широковещательный стрим, достаточно обычного.

[@LearnDartFlutter]

Мне очень нравится идея добавлять синглтоны в этом месте

[@konstantinkist]

О библиотеке bloc жду. А о библиотеке flutter_bloc вы снимите видео?

[@user-qn6rd8yv9n]

почему внутри синхронного кода вызывается асинхронный _initialize еще и без await? значит ли это, что код _initialize будет выполнен всё равно, но мы просто не ждем ответ ?

[@khurshidddbek]

44:49

[@murodaliismailov2503]

Просто комментарии!

[@user-mk8ol7di7g]

А где можно взять сыллку на код а то гит не открывает 404 ошибка !

[@LearnDartFlutter]

Она только для тех кто донатит на бусти

[@Raimkhodzhanov]

А ссылку на статью про bloc забыл кинуть

[@LearnDartFlutter]

точно telegra.ph/Paru-slov-o-BLoC-08-18

[@TraubenfeldGANG]

Евгений, мне кажется вы ошибаетесь на 16:55. Ведь сам Ангелов в разделе архитектуры говорит: - Поскольку блоки предоставляют потоки, может возникнуть соблазн создать блок, который слушает другой блок. Вы не должны этого делать. - Как правило, родственных зависимостей между двумя сущностями на одном архитектурном уровне следует избегать любой ценой, поскольку они создают тесную связь, которую трудно поддерживать. Поскольку блоки находятся на архитектурном уровне бизнес-логики, ни один блок не должен знать о каком-либо другом блоке. - Блок должен получать информацию только через события и из внедренных репозиториев.

[@sergeyzhukov1370]

Вы правы. Но часто бывает необходимость в связях между сущностями и фичами за которые отвечают блоки. И в доках описаны 2 способа взаимодействия между блоками. Один из них через прослушку на слое презентации используя листенеры . Не очень подход потому что бизнес логика (а я считаю что взаимодействие между фичами это часть бизнес логики) мешается с ui логикой. Второй через репозиторий на доменном слое. Там же в примере с todos описан второй подход про который вы написали. И вот мне лично он тоже не нравится. Там в репозитории создается стрим. Блоки на него подписываются и записывают данные себе в стейты. Спрашивается а зачем нам нужны блоки если мы можем слушать стримы напрямую с репозитория и дергать там же методы? Да и большая часть бизнес логики происходит именно в репозитории. Тоесть блок тут становится каким то лишним слегка непонятно за что он впринципе отвечает. Плюс у нас теперь список todos не только в стейтах но еще и в репозитории. Хотя там какбы и утверждается что типа мы нарушаем single source of truth и нам пофик. Но самая большая проблема блока в том что если ты захочешь сменить архитектуру на другую тебе придестя идти по всем виджетам крупным и мелким и выковыривать оттуда все эти билдеры провайдеры и листенеры и это очень муторно. Особенно когда в ide нет такой кнопочки(remove builder). В идеале не хотелось бы сильно чего то менять на ui уровне при изменениях в бизнес логике или в архитектуре . Но тогда придется билдеры переместить куда то выше откуда их будет проще выковыривать (например обернуть им виджет который отвечает за экран целиком) и назвать это все view model) Но это уже может бить по перфомансу. Вообщем неоднозначный стейт менеджер однако альтернативы не сильно лучше.

[@alexnik4187]

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

[@konstantinkist]

Кажется даже строк меньше стало...