Flutter Developer Learn #3 - Реализация состояний в BLoC
HTML-код
- Опубликовано: 6 сен 2024
- Продолжаем знакомство с пакетом flutter_bloc и концепциями BLoC. В этом видео поговорим про варианты реализации состояний для блоков, преимуществах и недостатках каждого их описанных подходов.
Материалы из видео: t.me/fluttermi...
Telegram: t.me/fluttermi...
Apple Podcasts: podcasts.apple...
Яндекс Музыка: music.yandex.r...
Обратная связь: fluttermiddlepodcast@gmail.com
Music from #Uppbeat (free for Creators!):
uppbeat.io/t/p...
License code: MYBBMY0E0J9VYTZM
#flutter #bloc #flutterbloc #флаттер #блок #флаттерблок #программирование #программированиедляначинающих #программированиеснуля #fluttertutorial #flutterwidgets #blocstate #state #состояниеблока
Продолжай в том же духе бро
Можешь ли рассказать про архитектуру в продакшн проектах?
Какая она, какие есть и примеры?
(Нормальные примеры, с кодом, а не два три слова)
Был бы очень благодарен
Видос топ
Помимо Блока, есть еще и общая архитектура, деление на фичи или отдельные модули, DI, и дополнительные решения для проекта (которые могут быть уникальны только для него). Нужно будет поискать большой открытый проект, чтобы уже на его примерах рассказать об особенностях.
Приветствую!!
Спасибо за видео.
Подскажи пожалуйста на 14:12, я правильно понимаю:
Представим у нас с юзеров 100+ (уже после нескольких пагинаций) загруженные айтемы уже в ListView уже = всё ок.
И в моменте следующей пагинации интернет отваливается и мы показываем error. То на 14:12 наш Стейт отдаст error, но также потеряет юзеров?
После отображения ошибки и при след. успешной пагинации вниз потеряем старых юзеров? Будем снова по новой юзеров загружать?
Почему не сделать внутри sealed класса - users - error - isLoading и также пользоваться стейтами отдельными ??🧐🧐
Интересует твоё мнение и как на реальном проекте при таком требовании: «не терять юзеров» и «показывать алертом - error».
Как бы ты написал код ?)
Спасибо за ответ, заранее!😉
Да, для пагинации лучше добавить дополнительные поля. Скролл будет тригеррить событие на подгрузку новой пачки данных, ну а там уже после ответа и будет вызываться emit либо с обновленным списком, либо с добавленной ошибкой.
На реальных проектах как раз так и делается. Показываем список чего-либо, и во время скролла подгружаем новые айтемы (и если есть, что грузить, показываем какой-нибудь лоадер в виде шиммера). Даже не вспомню, встречал ли требования для приложения, когда на каждую ошибку нужно все грузить заново.
На продакшене что из этих 2-х подходов чаще используется. Подход с несколькими состояниями или с одним но с copyWith?
И является ли freezed хорошей практикой в продакшене?
На коммерческих проектах используются оба подхода (из моей практики). Иногда варианты реализации состояний выбирают чисто из подхода, который уже используется в проекте (даже если это не совсем правильно).
Как такового каноничного решения тут нет - у каждого подхода есть свои положительные и отрицательные стороны. С появлением sealed-классов стало намного проще работать с состояниями в рамках языка (switch намного облегчает понимание кода). Но если нужно иметь какие-то общие поля в разных состояниях, или просто переносить информацию из одного в другое - придется постоянно их переписывать, либо же где-то в Блоке хранить.
Генерация состояний через freezed имеет ряд недостатков, в особенности если будет одно состояние, ибо шанс не так что-то в UI написать становится гораздо больше. У freezed нет возможности делать общие поля (от родителя), да и сама генерация кода процесс не сильно быстрый, если много таких файлов.
Если говорить чисто про freezed, то местами он избыточен. Помимо copyWith, там генерятся еще методы для работы с вариантами класса, и не все они используются где-то в проекте. Но и самописный copyWith - не совсем хорошая идея (t.me/fluttermiddlepodcast/321), и кодоген тут помогает.