[proposal] feat(bloc): cancelable async operations
**Description** As a developer, I want to be able to await asynchronous operations within a bloc/cubit which are automatically canceled if the instance is closed while the async operation is pending. An example use-case is when using a cubit to fetch some data asynchronously from a screen in which a user can go back. ```dart static Route<MyScreen> route() { return MaterialPageRoute( builder: (context) => BlocProvider( create: (context) => MyCubit()..load(), child: const MyScreen(), ), ); } enum MyState { idle, loading } class MyCubit extends Cubit<MyState> { MyCubit() : super(MyState.idle); Future<void> load() async { emit(MyState.loading); await Future<void>.delayed(const Duration(seconds: 3)); emit(MyState.idle); } } ``` In this scenario, as soon as `MyScreen` is pushed onto the navigation stack, the `load()` method is called on a newly created instance of `MyCubit`. It's possible that the user might get tired of waiting and press the back button before `load()` has completed. In this case, the Future will still complete after the `MyCubit` has been closed and the subsequent `emit(MyState.idle)` will be evaluated which will result in a `StateError`: `Unhandled Exception: Bad state: Cannot emit new states after calling close` **Desired Solution** It would be nice if we had a `cancelable` (open to naming suggestions) API which allowed developers to await asynchronous operations which would automatically be canceled if the bl
Posted by felangel on Dec 16, 2021, 4:23 AM
Tags
Related issues
- [Meta] Feedback on granular control over Copilot changes
- unexpected status 401 Unauthorized issue
- [MODEL] Measurable quality regression in Claude generation 5 (Fable 5 / Opus 5 / Sonnet 5): worse nonsense detection, ~2x verbosity, under-disclosed model fallb
- [CRITICAL] Subagent spawning and subagent pattern bugs trigger infinite recursion, infinite token usage, grossly inefficient token usage, and lost accumulated s
- Video stops playing after some minutes
- [MODEL] Claude verbose code comments by default — ignores instructions to stop.
Raise real-world problems, find people facing the same issue, and discuss solutions.3,000 issues0 comments
github (Software)
[Meta] Feedback on granular control over Copilot changes
unexpected status 401 Unauthorized issue
[MODEL] Measurable quality regression in Claude generation 5 (Fable 5 / Opus 5 / Sonnet 5): worse nonsense detection, ~2x verbosity, under-disclosed model fallb
[CRITICAL] Subagent spawning and subagent pattern bugs trigger infinite recursion, infinite token usage, grossly inefficient token usage, and lost accumulated s
Video stops playing after some minutes
[MODEL] Claude verbose code comments by default — ignores instructions to stop.
Scope Codex VS Code chats to the current workspace/project
Update on "Co-authored-by: Copilot" in commit messages
[proposal] feat(bloc): cancelable async operations
**Description** As a developer, I want to be able to await asynchronous operations within a bloc/cubit which are automatically canceled if the instance is closed while the async operation is pending. An example use-case is when using a cubit to fetch some data asynchronously from a screen in which a user can go back. ```dart static Route<MyScreen> route() { return MaterialPageRoute( builder: (context) => BlocProvider( create: (context) => MyCubit()..load(), child: const MyScreen(), ), ); } enum MyState { idle, loading } class MyCubit extends Cubit<MyState> { MyCubit() : super(MyState.idle); Future<void> load() async { emit(MyState.loading); await Future<void>.delayed(const Duration(seconds: 3)); emit(MyState.idle); } } ``` In this scenario, as soon as `MyScreen` is pushed onto the navigation stack, the `load()` method is called on a newly created instance of `MyCubit`. It's possible that the user might get tired of waiting and press the back button before `load()` has completed. In this case, the Future will still complete after the `MyCubit` has been closed and the subsequent `emit(MyState.idle)` will be evaluated which will result in a `StateError`: `Unhandled Exception: Bad state: Cannot emit new states after calling close` **Desired Solution** It would be nice if we had a `cancelable` (open to naming suggestions) API which allowed developers to await asynchronous operations which would automatically be canceled if the bl
Comments (0)
No comments yet. Start the discussion.