앞선 글에서 Future로 서버 요청을 하고 Stream으로 데이터베이스 변화를 받는 법을 봤다. 이제 그 값을 화면에 보여줄 차례다. Future를 돌려주는 함수를 위젯에 그대로 넣어보자.

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

  @override
  Widget build(BuildContext context) {
    return Text(fetchUser(1).name); // 여기서 에러남
  }
}

에디터에 빨간 줄이 뜬다.

The getter 'name' isn't defined for the type 'Future<User>'.

fetchUser(1)은 User가 아니라 "나중에 User가 도착한다"는 약속(Future<User>)이라서 아직 name이 없다. 비동기 글에서 본 그 상자다. 그렇다고 await를 쓸 수도 없다. build는 async가 될 수 없고, 기다리는 동안 화면에는 뭔가를 보여줘야 하기 때문이다.

원인: 화면은 기다리는 동안과 도착한 뒤를 모두 그려야 한다

서버 응답을 기다리는 화면은 최소한 세 가지 모습이 필요하다. 기다리는 중(로딩 표시), 도착함(데이터), 실패함(에러 문구). 지난 글들에서 이걸 isLoading, error, data 필드로 흩어두면 모순된 상태가 가능하다고 했다. Flutter는 이 세 상태를 알아서 나눠주는 위젯을 준다.

해결 1: FutureBuilder - Future 하나를 화면에 연결한다

FutureBuilder<User>(
  future: fetchUser(1),
  builder: (context, snapshot) {
    if (snapshot.connectionState == ConnectionState.waiting) {
      return const CircularProgressIndicator();
    }
    if (snapshot.hasError) {
      return Text('에러: ${snapshot.error}');
    }
    return Text('안녕, ${snapshot.data!.name}');
  },
)

• future: 기다릴 Future다
• builder의 snapshot: 지금 Future가 어떤 상태인지를 담은 객체다
• snapshot.connectionState: 아직 기다리는 중이면 waiting이다
• snapshot.hasError, snapshot.error: 실패했는지와 그 내용이다
• snapshot.data: 도착한 값이다. 도착 전에는 null이라서 타입이 User?이고, 위 코드는 앞에서 에러를 걸러낸 뒤라 !로 단언했다. 확실하지 않으면 snapshot.hasData를 먼저 확인한다

builder는 상태가 바뀔 때마다 다시 실행된다. 처음엔 waiting으로 로딩 표시가 뜨고, 응답이 오면 데이터 화면으로 바뀐다. StatelessWidget 안에서 쓸 수 있고 setState가 필요 없다.

삽질 포인트: 화면이 그려질 때마다 서버 요청이 반복된다

위 코드의 future: fetchUser(1)은 build가 실행될 때마다 요청을 새로 보낸다. build는 setState, 화면 회전, 키보드 올라옴 같은 일로 자주 다시 실행되는데, 그때마다 fetchUser(1)이 다시 불려서 요청이 반복되고 로딩 표시가 깜빡인다.

해결은 Future를 한 번만 만들어서 State에 보관하는 것이다. 첫 글에서 본 late final과 initState가 정확히 이 자리에 쓰인다.

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

  @override
  State<UserView> createState() => _UserViewState();
}

class _UserViewState extends State<UserView> {
  late final Future<User> _future;

  @override
  void initState() {
    super.initState();
    _future = fetchUser(1); // 한 번만 요청
  }

  @override
  Widget build(BuildContext context) {
    return FutureBuilder<User>(
      future: _future, // 매번 새로 만들지 않고 보관해둔 걸 넘김
      builder: (context, snapshot) {
        // 위와 같은 분기
      },
    );
  }
}

initState는 build보다 먼저, 그리고 한 번만 실행되니, 채우는 코드가 읽는 코드보다 먼저 실행되는 순서가 보장된다. FutureBuilder를 쓸 때는 Future를 만드는 코드를 build 안에 두지 않는다는 규칙을 기억해 둔다.

해결 2: StreamBuilder - 값이 여러 번 오는 경우

Future는 값이 한 번 오고, Stream은 여러 번 온다. 지난 글에서 만든 drift의 watchAll()이 Stream이었다. 같은 모양의 StreamBuilder로 연결한다.

StreamBuilder<List<Todo>>(
  stream: db.watchAll(),
  builder: (context, snapshot) {
    if (snapshot.hasError) {
      return Text('에러: ${snapshot.error}');
    }
    if (!snapshot.hasData) {
      return const CircularProgressIndicator();
    }
    final todos = snapshot.data!;
    return ListView.builder(
      itemCount: todos.length,
      itemBuilder: (context, index) => ListTile(title: Text(todos[index].title)),
    );
  },
)

구조는 FutureBuilder와 거의 같고 future 대신 stream을 넘긴다. 차이는 새 값이 올 때마다 builder가 다시 실행된다는 점이다. 데이터베이스에 항목을 추가하면 watchAll()이 새 목록을 흘려보내고, 화면이 setState 없이 저절로 갱신된다. Stream도 build 안에서 새로 만들면 구독이 반복되므로, FutureBuilder와 똑같이 한 번만 만들어서 쓴다.

해결 3: Riverpod의 AsyncValue - 세 상태를 한 객체로

Riverpod 글에서 서버 값은 FutureProvider를 쓴다고 했다. 이걸 화면에서 읽으면 Future가 아니라 AsyncValue 가 나온다. 로딩, 데이터, 에러 세 상태를 하나의 객체에 담은 것으로, Bloc 글에서 sealed class로 직접 묶은 상태와 같은 발상이다.

final userProvider = FutureProvider<User>((ref) async {
  final response = await dio.get('/users/1');
  return User.fromJson(response.data as Map<String, dynamic>);
});

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

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final user = ref.watch(userProvider);

    return user.when(
      data: (user) => Text('안녕, ${user.name}'),
      loading: () => const CircularProgressIndicator(),
      error: (error, stack) => Text('에러: $error'),
    );
  }
}

• ref.watch(userProvider): AsyncValue<User>를 돌려준다
• .when(data:, loading:, error:): 세 상태 모두의 화면을 반드시 적게 한다. 하나라도 빼면 에러가 나서, FutureBuilder처럼 에러 분기를 깜빡하는 실수가 없다
• FutureProvider는 Riverpod이 요청을 한 번만 실행하고 결과를 보관한다. FutureBuilder처럼 future를 State에 따로 둘 필요가 없다

다시 불러오고 싶을 때는 provider를 무효화한다.

ElevatedButton(
  onPressed: () => ref.invalidate(userProvider), // 다시 요청
  child: const Text('다시 불러오기'),
)

ref.invalidate가 호출되면 다음에 이 값을 읽을 때 다시 요청을 보낸다. 3.0부터는 실패한 provider를 자동으로 재시도하기도 해서, 실패 후 에러 화면을 보여주기까지 시간이 걸릴 수 있다는 점은 알아두자.

세 방법, 언제 뭘 쓰나

• FutureBuilder, StreamBuilder: 별도 패키지 없이 한 화면에서 한 번 읽을 때. 상태 관리 패키지를 쓰지 않는 간단한 화면에 알맞다
• AsyncValue(Riverpod): 이미 Riverpod을 쓰고 있을 때. 여러 화면이 같은 요청 결과를 공유하고, 다시 불러오기와 재시도를 한 곳에서 다루기 편하다
• Cubit과 BlocBuilder: Bloc을 쓴다면 sealed class 상태를 BlocBuilder에서 switch로 나눈다

Compose, SwiftUI와 비교하면

// Compose - collectAsState + when
val state by viewModel.state.collectAsState()
when (val s = state) {
    is UiState.Loading -> CircularProgressIndicator()
    is UiState.Success -> Text("안녕, ${s.user.name}")
    is UiState.Error -> Text("에러: ${s.message}")
}

// SwiftUI - .task + enum 상태
@State private var state: LoadState = .loading

var body: some View {
    switch state {
    case .loading: ProgressView()
    case .loaded(let user): Text("안녕, \(user.name)")
    case .error(let message): Text("에러: \(message)")
    }
}
.task { await load() }

• 상태를 세 모습으로 나누기: Flutter AsyncValue.when / Compose sealed interface UiState와 when / SwiftUI enum과 switch
• 요청 시작 시점: Flutter는 initState나 FutureProvider / Compose는 ViewModel 생성 때 / SwiftUI는 .task
• 값이 여러 번 올 때: Flutter StreamBuilder / Compose Flow를 collectAsState / SwiftUI는 AsyncSequence를 .task에서 순회

Compose에서 UiState를 when으로 나누는 구조와 Flutter의 AsyncValue.when이 가장 닮았다. 다만 Compose는 상태를 직접 sealed interface로 만들어야 하는 반면, Riverpod은 로딩, 데이터, 에러를 AsyncValue가 이미 가지고 있다.

정리

• Future는 아직 값이 아니라서 위젯에 바로 못 넣고, FutureBuilder로 기다리는 중, 도착, 실패를 나눠 그린다
• FutureBuilder의 future를 build 안에서 만들면 화면이 다시 그려질 때마다 요청이 반복되므로, initState에서 late final로 한 번만 만들어 보관한다
• 값이 여러 번 오는 Stream은 StreamBuilder로 연결하고, 새 값이 올 때마다 builder가 다시 실행된다
• Riverpod의 AsyncValue는 로딩, 데이터, 에러를 한 객체에 담고, .when에서 세 화면을 모두 적도록 강제한다
• 다시 불러오기는 ref.invalidate(provider)로 한다
• 간단한 화면은 FutureBuilder, Riverpod을 쓰고 있다면 AsyncValue, Bloc을 쓴다면 BlocBuilder로 나눈다

다음 글에서는 로딩, 에러, 빈 목록 같은 상태를 화면에서 어떻게 보여줄지, 에러 처리와 로딩 상태 UI를 다뤄보겠다.