На коммерческих проектах используются оба подхода (из моей практики). Иногда варианты реализации состояний выбирают чисто из подхода, который уже используется в проекте (даже если это не совсем правильно). Как такового каноничного решения тут нет - у каждого подхода есть свои положительные и отрицательные стороны. С появлением sealed-классов стало намного проще работать с состояниями в рамках языка (switch намного облегчает понимание кода). Но если нужно иметь какие-то общие поля в разных состояниях, или просто переносить информацию из одного в другое - придется постоянно их переписывать, либо же где-то в Блоке хранить. Генерация состояний через freezed имеет ряд недостатков, в особенности если будет одно состояние, ибо шанс не так что-то в UI написать становится гораздо больше. У freezed нет возможности делать общие поля (от родителя), да и сама генерация кода процесс не сильно быстрый, если много таких файлов. Если говорить чисто про freezed, то местами он избыточен. Помимо copyWith, там генерятся еще методы для работы с вариантами класса, и не все они используются где-то в проекте. Но и самописный copyWith - не совсем хорошая идея (t.me/fluttermiddlepodcast/321), и кодоген тут помогает.

Был пост про это в том месяце: t.me/fluttermiddlepodcast/278.

Да, но на больших классах нужно будет обязательно каждое поле указывать. Бизнес-логика имеет свойство расширяться, так что рано или поздно придется искать какое-то другое решение.

Да, какое-то время нужно потратить на оформление профиля, но с учетом того, сколько информации и примеров есть на эту тему, будет намного проще, чем самому гадать, как и что написать. Так же, рекрутеры табуном в первый месяц или два не будут приходить, на рост коннекшенов тоже нужно время. Но эффект в перспективе очень большой, особенно если нормально все сделать.

Почти) Ошибки как были одни и те же 2-3 года назад, так и сейчас есть.

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

@@fluttermiddlepodcast1220 Конечно, же ситуации бывают очень разные. Просто такой серьёзный флаг, впрочем вы же об этом и сказали. А вот по поводу "больше", мне как раз кажется, что выбрать другой проект и потом передумать - это вполне нормально. Человек полностью свободен выбирать, что ему по душе и менять этот выбор, если на то будут причины. Он же вас никак не подводил, просто выбрал другую компанию. То есть это никак его плохо не характеризует. Ну мне так видится.

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

Не сказал бы. На любом языке и на любом фреймворке можно заруинить проект с помощью плохих практик. Тут больше вопрос в том, что не все делают так, как нужно, и по каким-то непонятным причинам отходят от правильного подхода в пользу самописного решения. Знаю пару примеров, когда коммуникацию между блоками делают не с помощью виджетов из flutter_bloc, а через сторонние сервисы коммуникации. Но в таких реализациях нет стримов внутри блоков, и сами блоки все же ничего друг о друге не знают.

@@fluttermiddlepodcast1220 Да, так и есть, но все таки существуют более удобные интсрументы и менее)

и в чем трешак? по-моему, такие основные минусы дарта на данный момент: 1. Кодогенерация. Слишком много кодогенерации, приходится ждать по 1-2 минуты иногда. 2. Нет привычной многопоточки, как в других языках (например, котлин, java, c#), что является большей проблемой, как по мне. Проблему кодогенерации можно будет решить в большой степени с помощью макросов, которые выйдут в этом - начале следующего года. С многопоточкой тоже разбираются.

По поводу кодогенерации - можно настроить раннер так, чтобы он только на определенный файлы смотрел, либо же написать скрипт, который сам все необходимое (что в Гите отображается как измененное, например). Но это больше на костыль похоже (которым пользуются), чем на решение, особенно когда у тебя очень много файлов.

@@fluttermiddlepodcast1220 Да, знаю, но когда файлов много - уже не спасает))

Да, все верно.

Насколько помню, это видео писалось на Макбуке 2018 года с самой косячной яблочной клавиатурой (где часто западали клавиши). Видимо, печатать действительно было не удобно)

Да, тоже заметил. Спасибо за комментарий. Правки уже в репозитории.

@@fluttermiddlepodcast1220 круто! Да я так, просто написал)

Спасибо большое за комментарий.

По-хорошему, нужно бы сделать. Если придумаю что-нибудь с приложением, даже небольшим, и найду аккаунт в Google Play и App Store, то обязательно будет.

По поводу состояний - такой вариант тоже может быть, но он влечет за собой кучу ненужного обновления полей у состояний. Если бизнес-логика не требует отображения подробных ошибок или работы с аналитикой (когда мы трекаем каждый чих и пых в приложении), то достаточно будет обойтись состояниями только с нужными полями. Да, про трансформеры тоже нужно было рассказать. Это не совсем очевидная проблема, особенно на маленьких экранах, но она все же встречается и порой не всегда можно уловить, откуда ноги растут.

Отдельное видео про Cubit: kzbin.info/www/bejne/eabEloSAd8h1j6M. По-сути Cubit - это BLoC без событий. Есть стрим состояний, но все действия в кубитах происходят через обращение к методам, а не вызову событий как у блоков. Это разные подходы к разработке, но за счет единого базового класса у обоих вариантов - виджеты flutter_bloc работаю с ними одинаково. Кубиты проще в реализации мелкий фичей, где нет кучи событий, и нужно вызвать 1-2 метода и подписаться на обновление состояния. Кто-то (видел такие проекты) пишет все приложение на них, но у такого подхода есть ряд недостатков, начиная от риска появления непонятной связи между методами, и заканчивая сложностью отладки таких кубитов.

@@fluttermiddlepodcast1220 Спасибо большое, за ответ!

В целом примеры покрывают все вопросы по разработке. Да, они не слишком сложные, но на их основе можно было понять, какой подход и какие правила авторы хотят до нас донести. Блоку уже несколько лет, и за все это время многие вопросы уже отвечены, а ошибочные реализации разобраны авторами.

@@fluttermiddlepodcast1220 Как же тогда авторы предлагают показывать несколько ошибок друг за другом на нескольких языках? В документации есть на это пример?

Не так выразился. Общие подходы. Более специфические истории, да, не показаны как реализовывать.

@@fluttermiddlepodcast1220 Ну это самый простой пример а в документации его нету.

Чуть-чуть запутался. Где-то можно посмотреть пример такого кейса?

Риверпод просят, возможно после серии по Блоку попробую сделать аналогичное и по нему. Со всем остальным тоже в процессе возможно разберемся.

Напишите, пожалуйста, t.me/robertpugovini в Телеграме.

Видео, которые записаны год назад, актуальны. Другие роадмапы могут быть уже устаревшими, но от Зотьева и roadmap.sh еще годные.

Есть Телеграм-канал t.me/dartlang_jobs, заглядываю туда чаще, чем на HH. Там меньше описание вакансии, моментальная связь с рекрутером, но не всегда понятно, актуально ли. Ну и о компании тоже не часто информацию пишут, если это важно.

Понял, спасибо!

Да, для пагинации лучше добавить дополнительные поля. Скролл будет тригеррить событие на подгрузку новой пачки данных, ну а там уже после ответа и будет вызываться emit либо с обновленным списком, либо с добавленной ошибкой. На реальных проектах как раз так и делается. Показываем список чего-либо, и во время скролла подгружаем новые айтемы (и если есть, что грузить, показываем какой-нибудь лоадер в виде шиммера). Даже не вспомню, встречал ли требования для приложения, когда на каждую ошибку нужно все грузить заново.

Помимо Блока, есть еще и общая архитектура, деление на фичи или отдельные модули, DI, и дополнительные решения для проекта (которые могут быть уникальны только для него). Нужно будет поискать большой открытый проект, чтобы уже на его примерах рассказать об особенностях.

С вакансиями для младших разработчиков всегда было +- одинаково плохо. Года 3-4 назад их было больше, но в то же время и количество кандидатов было тоже большим. Если мы говорим про работу в офисе - то тут больше всего вакансий в столицах, если же смотреть что-то удаленное, то там в разы больше конкуренции.

Миддлам и сеньорам пишут точно, за последние несколько лет ничего не изменилось. С младшими разработчиками все намного сложнее, но можно завести страницу и следить за предложениями на рынке.

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

Да, заброшен. Авторы сейчас делают Isar, там есть очереди и другие фичи, которые в Hive отсутствуют. На многих проектах Hive до сих пор в каком-то виде присутствует, но это относится по большей части к легаси уже.

Попробую что-нибудь придумать, тема действительно мало где раскрывается.