Будет ли использоваться state management во Flutter и почему выбрать bloc или cubit

Что проверяют

Понимаете ли вы, какое состояние вообще требует отдельного решения, и можете ли обосновать выбор между Cubit и Bloc, а не просто назвать пакет. Раз специальность Android, часто просят сравнить с привычным: ViewModel со StateFlow и MVI. Следом спрашивают про тесты и лишние перестроения экрана.

Как отвечать

Управление состоянием будет в любом случае, вопрос только в уровне. Локальное эфемерное состояние (раскрыт ли блок, какая вкладка выбрана) спокойно живёт в setState. Состояние, которое делят экраны или которое зависит от сети и базы, выносят в отдельный слой.

• Cubit: класс с методами, которые вызывают emit(newState). По смыслу это ViewModel с MutableStateFlow: вызвали метод, получили новое состояние;
• Bloc: на вход приходят события, обработчики регистрируются через on<Event>. Это ближе к MVI с intent и reducer. Есть трансформеры событий из bloc_concurrency (droppable, restartable, sequential) для поиска с отменой прошлого запроса или защиты от двойного нажатия, а onTransition показывает, какое событие привело к какому состоянию;
• общее: оба наследуют BlocBase и отдают Stream состояний, оба подключаются через BlocProvider, BlocBuilder, BlocListener, BlocSelector и тестируются через blocTest из пакета bloc_test.

Разумное правило: начинать с Cubit и переводить экран на Bloc, когда появляется сложная работа с потоком событий или нужен аудит переходов. Состояния делают неизменяемыми и сравнимыми через Equatable или freezed.

Где спотыкаются

Мутируют список в текущем состоянии и отдают тот же объект в emit. Для библиотеки это то же самое состояние, emit его пропускает, и интерфейс не обновляется.

Утверждают, что Cubit работает без стримов. Стрим у него есть, нет только событий на входе.

Создают блок прямо в build или передают через BlocProvider.value там, где нужен create. В первом случае он пересоздаётся на каждое перестроение, во втором его никто не закроет.