지난 글까지 Provider와 Riverpod으로 상태를 공유해봤다. 이번엔 세 번째 선택지인 Bloc 라이브러리(flutter_bloc)를 보고, 마지막에 "그래서 뭘 써야 하나"를 정리한다. 먼저 Bloc이 왜 나왔는지부터 보자. 서버에서 사용자 이름을 불러오는 모델을 지난 글의 ChangeNotifier로 만들어본다.

class UserModel extends ChangeNotifier {
  bool isLoading = false;
  String? error;
  String? name;

  Future<void> load() async {
    isLoading = true;
    notifyListeners();

    try {
      await Future.delayed(const Duration(seconds: 1)); // 서버 요청이라고 가정
      name = '홍길동';
      isLoading = false;
    } catch (e) {
      error = '불러오지 못했어요';
      isLoading = false;
    }
    notifyListeners();
  }
}

에러는 나지 않는다. 그런데 처음 요청이 실패해서 error에 문구가 들어간 뒤, 다시 시도해서 성공하면 이상한 일이 생긴다. name에는 '홍길동'이 들어가는데 error는 지워지지 않아서, 화면이 "에러 문구"와 "홍길동"을 동시에 보여준다.

원인: 상태가 필드 세 개로 흩어져 있어서 말이 안 되는 조합이 가능하다

isLoading, error, name 세 필드는 따로 움직인다. 조합은 여덟 가지인데 의미가 있는 건 "로딩 중", "성공", "실패", "시작 전" 네 가지뿐이다. isLoading이 true인데 error도 있는 상태처럼 모순된 조합을 코드가 막아주지 않는다. 값을 바꿀 때마다 세 필드를 다 챙겨야 하고, 하나만 빼먹으면 이런 버그가 생긴다.

해결: 상태를 하나의 객체로 묶는다

Dart 3의 sealed class로 가능한 상태를 네 가지로 못박는다.

sealed class UserState {}

class UserInitial extends UserState {}

class UserLoading extends UserState {}

class UserLoaded extends UserState {
  final String name;
  UserLoaded(this.name);
}

class UserError extends UserState {
  final String message;
  UserError(this.message);
}

이제 상태는 네 가지 중 정확히 하나다. UserLoaded에는 error가 아예 없고 UserError에는 name이 없어서, 에러와 이름이 동시에 존재할 수 없다. 이 상태를 관리하는 게 Cubit이다.

Cubit: 상태 하나를 들고 emit으로 바꾼다

설치부터 한다.

flutter pub add flutter_bloc

import 'package:flutter_bloc/flutter_bloc.dart';

class UserCubit extends Cubit<UserState> {
  UserCubit() : super(UserInitial()); // 처음 상태

  Future<void> load() async {
    emit(UserLoading());
    try {
      await Future.delayed(const Duration(seconds: 1)); // 서버 요청이라고 가정
      emit(UserLoaded('홍길동'));
    } catch (e) {
      emit(UserError('불러오지 못했어요'));
    }
  }
}

• Cubit<UserState>: 상태의 타입이 UserState인 관리자다
• : super(UserInitial()): 생성자 글에서 본 initializer list로 처음 상태를 부모에게 넘긴다
• emit(새 상태): 상태를 통째로 갈아끼우고 구독자에게 알린다. notifyListeners()가 필요 없다
• state: 지금 상태다. 밖에서는 읽기만 되고 바꿀 수 없다. 바꾸는 길은 emit뿐이다

ChangeNotifier는 필드를 하나씩 고치다 마지막에 알림을 보냈다. Cubit은 완성된 상태를 한 번에 emit한다. 중간에 어정쩡한 상태가 화면에 보일 일이 없다.

화면에 연결하기

void main() {
  runApp(
    BlocProvider(
      create: (context) => UserCubit()..load(), // 만들면서 바로 불러오기
      child: const MyApp(),
    ),
  );
}

class UserView extends StatelessWidget {
  const UserView({super.key});

  @override
  Widget build(BuildContext context) {
    return BlocBuilder<UserCubit, UserState>(
      builder: (context, state) {
        return switch (state) {
          UserInitial() => const Text('시작 전'),
          UserLoading() => const CircularProgressIndicator(),
          UserLoaded(:final name) => Text('안녕, $name'),
          UserError(:final message) => Text('에러: $message'),
        };
      },
    );
  }
}

• BlocProvider: Cubit을 트리에 걸어둔다. Provider의 ChangeNotifierProvider와 같은 자리다
• BlocBuilder<UserCubit, UserState>: 상태가 바뀔 때마다 builder를 다시 실행한다. watch와 비슷한 역할이다
• UserCubit()..load(): ..는 앞의 객체를 돌려주면서 메서드를 호출하는 문법이다. Cubit을 만들자마자 load()를 부른다
• switch에 sealed class를 넣으면 네 가지를 빠짐없이 처리했는지 컴파일러가 확인한다. 상태를 하나 추가하고 switch에서 빼먹으면 빨간 줄이 뜬다

버튼에서 Cubit의 함수를 부를 땐 지난 글들과 똑같이 context.read를 쓴다.

ElevatedButton(
  onPressed: () => context.read<UserCubit>().load(),
  child: const Text('다시 불러오기'),
)

삽질 포인트 1: 리스트를 고쳐서 emit하면 화면이 안 바뀐다

class TodoCubit extends Cubit<List<String>> {
  TodoCubit() : super([]);

  void add(String item) {
    state.add(item); // 기존 리스트에 직접 추가
    emit(state);     // 같은 리스트를 다시 emit
  }
}

항목은 추가되는데 화면은 그대로다. Cubit은 새 상태가 현재 상태와 같으면 무시한다. 같은 리스트 객체를 emit하면 "바뀐 게 없다"고 판단한다. 새 리스트를 만들어서 넘겨야 한다.

void add(String item) {
  emit([...state, item]); // 새 리스트를 만들어서 emit
}

[...state, item]은 기존 항목을 펼치고 하나를 더한 새 리스트다. 컬렉션 글에서 본 .toList() 습관과 이어진다. Cubit에서는 상태를 직접 고치지 않고 새로 만든다가 규칙이다.

삽질 포인트 2: BlocProvider를 걸어둔 곳에서 바로 읽으면 못 찾는다

BlocProvider를 만드는 같은 build에서 context.read<UserCubit>()를 부르면 BlocProvider를 찾지 못했다는 에러가 난다. InheritedWidget, Provider에서 본 것과 같은 이유다. context가 BlocProvider보다 위에 있어서 위로 올라가도 없다. 읽는 쪽을 별도 위젯이나 BlocBuilder, Builder로 분리한다.

Cubit과 Bloc의 차이

flutter_bloc에는 두 가지가 있다. 지금까지 쓴 건 Cubit이다. Bloc은 한 단계 더 나아가서, 함수를 직접 부르는 대신 이벤트 객체를 보낸다.

sealed class CounterEvent {}

class Incremented extends CounterEvent {}

class CounterBloc extends Bloc<CounterEvent, int> {
  CounterBloc() : super(0) {
    on<Incremented>((event, emit) => emit(state + 1));
  }
}

// 사용
context.read<CounterBloc>().add(Incremented());

• Cubit: increment() 같은 함수를 호출하면 상태가 바뀐다. 코드가 짧다
• Bloc: add(이벤트)를 보내면 on<이벤트>가 받아서 상태를 바꾼다. 코드가 길지만, 어떤 이벤트 때문에 상태가 바뀌었는지 기록으로 남는다

처음에는 Cubit으로 시작하고, 이벤트 기록이나 이벤트 변환(검색어 입력 지연 처리 등)이 필요해질 때 Bloc으로 올리는 게 보통이다.

그래서 뭘 써야 하나: 선택 기준

정답은 없다. 지금까지 본 네 가지를 기준별로 놓고 보면 이렇다.

• setState: 한 위젯 안에서만 쓰는 값(입력 중인 글자, 펼침 여부). 별도 패키지가 필요 없다
• Provider: 구조가 단순해서 가장 빨리 익힌다. 작은 앱이나 학습용에 알맞다. 다만 값을 타입으로 찾기 때문에 실행 중에야 에러가 드러난다
• Riverpod: 컴파일 때 에러를 잡고 context 없이 읽는다. 값끼리 서로 의존하는 구조와 테스트에 유리해서, 새로 시작하는 프로젝트에서 많이 고른다
• Bloc/Cubit: 상태와 이벤트를 엄격한 틀에 가둔다. 코드는 늘어나지만 여러 사람이 같은 구조로 쓰게 강제하기 좋아서, 팀이 크고 규칙이 중요한 프로젝트에서 많이 쓴다

고를 때는 세 가지를 본다.

• 프로젝트 규모: 화면 두세 개면 Provider로 충분하고, 커질수록 Riverpod이나 Bloc의 규칙이 도움이 된다
• 팀 경험: 이미 익숙한 사람이 많은 쪽이 낫다. 라이브러리 성능 차이보다 팀이 같은 방식으로 쓰는 게 더 크다
• 테스트 용이성: 상태를 만드는 곳이 위젯과 분리돼 있을수록 테스트가 쉽다. 세 가지 모두 가능하지만 Riverpod과 Bloc이 틀이 더 분명하다

혼자 앱을 만드는 입장이라면 Riverpod 하나로 시작하는 게 무난하다. 다만 어느 쪽을 골라도 오늘 본 "상태를 하나의 객체로 묶는다"는 원칙은 그대로 쓸 수 있다.

Compose, SwiftUI와 비교하면

// Compose - ViewModel + sealed interface UiState
sealed interface UserUiState {
    data object Loading : UserUiState
    data class Loaded(val name: String) : UserUiState
    data class Error(val message: String) : UserUiState
}

class UserViewModel : ViewModel() {
    private val _state = MutableStateFlow<UserUiState>(UserUiState.Loading)
    val state = _state.asStateFlow()
}

// 화면
when (val s = state) {
    is UserUiState.Loading -> CircularProgressIndicator()
    is UserUiState.Loaded -> Text("안녕, ${s.name}")
    is UserUiState.Error -> Text(s.message)
}

// SwiftUI - enum으로 상태 묶기
enum UserState {
    case loading
    case loaded(name: String)
    case error(message: String)
}

switch state {
case .loading: ProgressView()
case .loaded(let name): Text("안녕, \(name)")
case .error(let message): Text(message)
}

• 상태를 묶는 방법: Flutter sealed class / Compose sealed interface UiState / SwiftUI enum(연관값)
• 상태를 들고 있는 곳: Flutter Cubit / Compose ViewModel + StateFlow / SwiftUI ObservableObject나 @Observable
• 상태 바꾸기: Flutter emit(새 상태) / Compose _state.value = 새 상태 / SwiftUI 프로퍼티 대입
• 화면에서 분기: 세 쪽 모두 switch/when으로 빠짐없이 처리

Compose의 ViewModel + sealed interface UiState 구조와 거의 같다. Cubit이 ViewModel, BlocBuilder가 collectAsState 뒤의 when 분기에 해당한다.

정리

• 상태를 isLoading, error, name 같은 필드로 흩어두면 모순된 조합이 가능하고, 하나만 빼먹어도 버그가 생긴다
• sealed class로 가능한 상태를 정해두고 Cubit<상태>가 emit으로 통째로 갈아끼우면, 말이 되는 상태만 존재한다
• 화면에서는 BlocProvider로 걸어두고 BlocBuilder로 상태별 화면을 switch로 나눈다. sealed class라서 빠뜨린 상태는 컴파일러가 알려준다
• Cubit은 새 상태가 현재 상태와 같으면 무시하므로, 리스트 같은 값은 직접 고치지 말고 새로 만들어서 emit한다
• 함수를 부르는 Cubit으로 시작하고, 이벤트 기록이 필요하면 Bloc을 쓴다
• 프로젝트 규모, 팀 경험, 테스트 용이성을 보고 고르되, 혼자 시작한다면 Riverpod이 무난하다

다음 글부터는 4단계로 넘어가서, 여러 화면을 오가는 화면 이동(Navigator와 go_router)을 다뤄보겠다.