fix: emitting a state in a closed Cubit throws an error
ra48ad opened this issue · comments
Description
Trying to emit a state when the cubit is closed (can happen for example in async functions) leads to an Error being thrown. This behaviour may be intentional, but it is - however - different from a Bloc's behaviour the emit is called.
Steps To Reproduce
- Create a new Cubit
- Add an async function that waits for 5 seconds, then emits a new state.
- Create a new instance of this Cubit in your main method and call the function in 2) and then close the Cubit.
- You should get an Error thrown that says "Cannot emit new states after calling close"
Expected Behavior
Calling emit on a closed Cubit ignores the new state and throws no error (Just like a Bloc would)
Screenshots
Additional Context
Hi @ra48ad 👋
Thanks for opening an issue!
Are you able to share a link to a minimal reproduction sample illustrating the problem/inconsistency you're seeing? It'd be much easier to help if you could share a repro, thanks!
Hi @ra48ad 👋 Thanks for opening an issue!
Are you able to share a link to a minimal reproduction sample illustrating the problem/inconsistency you're seeing? It'd be much easier to help if you could share a repro, thanks!
Thank you for your reply!
Sure, here are two comparable samples for a Cubit and a Bloc:
Cubit
class CounterCubit extends Cubit<int> {
CounterCubit() : super(0);
// delay emit to simulate async operation
void increment() => Future.delayed(
Duration(seconds: 3),
() => emit(state + 1),
);
}
void main(List<String> args) {
final cubit = CounterCubit();
cubit.increment();
cubit.close();
// prints 0, exception [StateError] thrown (bloc_base.dart line 97)
print(cubit.state);
}
Bloc
enum CounterEvent { increment }
class CounterBloc extends Bloc<CounterEvent, int> {
CounterBloc() : super(0) {
on<CounterEvent>(_onCounterEvent);
}
Future<void> _onCounterEvent(CounterEvent event, Emitter<int> emit) async {
if (event == CounterEvent.increment) {
// delay emit to simulate async operation
return Future.delayed(
Duration(seconds: 3),
() => emit(state + 1),
);
}
}
}
void main(List<String> args) {
final bloc = CounterBloc();
bloc.add(CounterEvent.increment);
bloc.close();
// prints 0, no exception thrown because of isClosed check (bloc.dart line 202)
print(bloc.state);
}
As you can see, there is a (small) difference in behaviour of both, even though the code is very similar.
In a real world app, it could be sometimes easier to use a Cubit instead of a Bloc, but this behaviour leads to writing extra isClosed
checks in the Cubit to prevent the exception.
What do you think? is there anyway to prevent the exception without adding extra checks in the Cubit?
Why does that throw StateError
in bloc_base.dart line 97
needed? As for me the isClosed
should be handled as in Bloc
(bloc.dart line 202) and it is not interesting to know either stream closed or no. We basically know that if the bloc is initialized then its stream is active, if bloc is closed (due to widget dispose) then any new events should be just discarded and I don't want to see error.
For example, I have a case where I downlooad the image and get its size. It is a long operation which I can break. Now I get a StateError
because of widget is already disposed but emit
is still trying to send new state. To avoid this I need to add additional check on isClosed
in my code. But actually, I repeat, I am not interesting when and why the bloc was closed. I know exactly that it will be closed on widget dispose.
This behavior was introduced to be consistent with how StreamController
works in Dart. I'm open to adjusting the behavior and welcome all feedback from the community 👍
Thank you for your kind reply! @felangel
I understand this point of view and it makes sense. however, since I started using Cubits instead of Blocs in big parts of my apps, this behaviour have been a pain for me and my team. I am glad you are considering a change.
Would it be ok if I make a Pull Request with the change for you to review it?
My suggestion would be to simply return if the cubit is closed (in BlocBase
), just like Bloc
. What do you think?