Что хотят услышать интервьюеры:

Ожидают не список «плохих» библиотек, а умение оценивать подходы по масштабу проекта, читаемости и тестируемости. Хороший ответ показывает, что в Flutter важнее не конкретный state management, а дисциплина границ состояния и предсказуемость обновлений. Обычно негативно относятся к решениям, которые делают состояние слишком глобальным, неявным или сильно связывают UI с бизнес-логикой.

Определение:

Не нравится тот подход к управлению состоянием, который усложняет понимание потока данных, затрудняет тестирование и приводит к лишним перерисовкам или скрытым зависимостям. В Flutter это часто проявляется, когда состояние хранится «где попало», обновляется неочевидно или доступно слишком широкому кругу виджетов без явной причины.

Практически плохим считается подход, где:

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

Пример использования:

Например, в небольшом экране с загрузкой профиля неудачно сразу тащить сложный глобальный стор на весь app, если достаточно локального setState или простого ChangeNotifier. Это усложнит код без реальной пользы.

class ProfileScreen extends StatefulWidget {
  const ProfileScreen({super.key});

  @override
  State<ProfileScreen> createState() => _ProfileScreenState();
}

class _ProfileScreenState extends State<ProfileScreen> {
  bool isLoading = false;
  String? error;
  String? name;

  Future<void> loadProfile() async {
    setState(() {
      isLoading = true;
      error = null;
    });

    try {
      // имитация запроса
      await Future.delayed(const Duration(seconds: 1));
      setState(() {
        name = 'Alex';
      });
    } catch (_) {
      setState(() {
        error = 'Не удалось загрузить профиль';
      });
    } finally {
      setState(() {
        isLoading = false;
      });
    }
  }

  @override
  void initState() {
    super.initState();
    loadProfile();
  }

  @override
  Widget build(BuildContext context) {
    if (isLoading) return const Center(child: CircularProgressIndicator());
    if (error != null) return Text(error!);
    return Text(name ?? 'Нет данных');
  }
}

Пояснение кода:

В этом примере код не требует отдельной сложной архитектуры: состояние экрана локальное и полностью принадлежит одному виджету.
Шаги такие:

isLoading отвечает за индикатор загрузки.
error хранит текст ошибки, если запрос не удался.
name содержит данные профиля после загрузки.
loadProfile() меняет состояние через setState, и UI обновляется только для этого экрана.
В build() виджет выбирает, что показать: загрузку, ошибку или данные.

Если бы это состояние вынесли в глобальный стор без необходимости, код стал бы сложнее, а цена поддержки — выше.

Ключевые моменты:

Нежелателен не сам паттерн, а его несоответствие задаче и масштабу проекта.
Плохой подход — тот, который делает состояние неявным и трудноотлаживаемым.
Для локального UI часто достаточно setState, без тяжёлой абстракции.
Для общего состояния важно явно ограничивать область видимости и зависимости.
Чем меньше магии и скрытых обновлений, тем проще тестировать и поддерживать код.

Какие подходы к управлению состоянием в архитектуре вам не нравятся и почему?