Flutter Question posted in
The official Flutter documentation can be found here.

Concurrency in Flutter Bloc: why is the state not propagating through multiple subsequent async functions?

I’m using Flutter with flutter_bloc, and I’m in front of the following scenario.

Scenario

I have a Cubit with two methods beings loadFoo and loadBar:


class UserCubit extends Cubit<UserState> {
  UserCubit() : super(UserState());

  Future loadFoo() async {
    emit(state.copyWith(
      foo: await fancyApiService.loadFoo()
    ));
  }

  Future loadBar() async {
    emit(state.copyWith(
      bar: await fancyApiService.loadBar()
    ));
  }
}

Then, in a StatefulWidget I have the following:

@override
void initState() {
  context.read<UserCubit>()..loadFoo()..loadBar();
  super.initState();
}

What happens

loadFoo is the first method to complete its execution and emit a new state.

In executing loadBar, this.state doesn’t contain the value provided by loadFoo.

A possible solution

I noticed that by rewriting the methods code this way, it works properly. But shouldn’t it give the same results as the code mentioned above?
I guess this has something to do with the way Dart works behind the scenes (?).

  Future loadFoo() async {
    final foo = await fancyApiService.loadFoo();
    emit(state.copyWith(
      foo: foo
    ));
  }

  Future loadBar() async {
    final bar = await fancyApiService.loadBar();
    emit(state.copyWith(
      bar: bar
    ));
  }
Tags:

2

Answers


  1. 0

    This code:

    context.read<UserCubit>()..loadFoo()..loadBar();

    is equivalent to:

    final cubit = context.read<UserCubit>();
cubit.loadFoo();
cubit.loadBar();

    Just to be clear, you have two unawaited async calls.

    In the first version loadFoo and loadBar will read the same state because An async function runs synchronously until the first await keyword and the await calls that will suspend the functions happen after reading the state. The execution flow will look like this:

    • cubit.loadFoo()
    • read state in loadFoo
    • suspend loadFoo at await fancyApiService.loadFoo()
    • cubit.loadBar()
    • read state in loadBar
    • suspend loadBar at await fancyApiService.loadBar()

    At this point fancyApiService.loadFoo() and fancyApiService.loadBar() are both scheduled and execution flow will depend on which one completes first but the emit in cubit.loadFoo or cubit.loadBar will use the same state in either case.

    In your second version of loadFoo and loadBar the await happens before reading the state so once again, fancyApiService.loadFoo() and fancyApiService.loadBar() are both scheduled and the execution flow will continue depending on which call completes first. The difference is that now the state is read after the async call so one of cubit.loadFoo and cubit.loadBar will get a chance to emit before the other reads the state.

    If your intention is to call loadBar after loadFoo completes you should at least await loadBar().

    Login or Signup to reply.
  2. 0

    Here are the methods, theoretically it’s supposed to work, just try:

    These methods are asynchronous methods, but they don’t return any thing just void. so it’s unnecessary to await on their call, actually it may produce an error because await can only be used when the return type is Future<AnyThing>

      void loadFoo() async {
    final foo = await fancyApiService.loadFoo();
    emit(state.copyWith(
      foo: foo
    ));
  }

  void loadBar() async {
    final bar = await fancyApiService.loadBar();
    emit(state.copyWith(
      bar: bar
    ));
  }

    and, Here’s the initState method, no need to await:

    @override
void initState() {
  context.read<UserCubit>()..loadFoo()..loadBar();
  super.initState();
}
    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search