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
));
}
7
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
stateinloadFoo - suspend
loadFooatawait fancyApiService.loadFoo() cubit.loadBar()- read
stateinloadBar - suspend
loadBaratawait 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 loadFoo().
There are more ways to do this. One technique is wrapping the logic in an async function which then will be called without awaiting it (aka fire and forget), but will allow you to use await:
@override
void initState() {
super.initState();
// Wrap unawaited async calls to explicitly show the intention
unawaited(init());
}
Future<void> init() async {
final cubit = context.read<UserCubit>();
await cubit.loadFoo();
await cubit.loadBar();
}
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();
}
2