You build a login screen. When authentication fails, your state container emits an error. You catch it in your UI and show a SnackBar. Everything works—until the user rotates their phone, pulls down the notification shade, or types on the virtual keyboard.
Suddenly, the widget tree rebuilds. The state container is still holding AuthErrorState("Invalid password"). The UI listener fires again. And a duplicate snackbar appears out of nowhere.
In this article, we’ll explore why domain state machines struggle with transient UI events, how the classic BLoC community worked around this with package:blocpresentation, and how BlocSignal lets you handle one-shot side effects cleanly with zero additional package dependencies. The Root Problem: Persistent State vs. Ephemeral Actions
State management in Flutter is designed to model persistent truth over time: Is the user logged in? AuthState.authenticated(user) Is data loading? TodoState.loading What is the cart total? $49.99
In contrast, UI presentation actions are ephemeral pulses: Show a brief SnackBar toast. Pop up an alert confirmation dialog. Push a new route on the Navigator stack. Vibrate the haptic motor.
These actions answer: "What just happened that requires a one-time reaction?" The Legacy Workarounds (And Their Hidden Costs)
Historically in package:bloc and package:flutterbloc, developers used one of three approaches:
Downside: Causes two separate microtask queue ticks and multiple widget rebuild cycles just to reset a transient flag.
Downside: Clutters state classes with imperative UI tracking flags that violate domain purity.
Workaround C: package:blocpresentation LeanCode created package:blocpresentation, adding a separate secondary StreamController.broadcast() to Blocs so developers could call emitPresentation(MyEvent()) independently of emit(state).
While blocpresentation solved the problem well for classic BLoC, maintaining third-party wrapper packages in your monorepo introduces versioning churn, boilerplate, and dependency overhead. The BlocSignal Advantage: 0ms Synchronous Guarantees
Unlike classic BLoC which queues updates asynchronously on microtask-queue Streams, calling emit(newState) in BlocSignal updates the underlying reactive signal and settles dependencies immediately in the exact same frame.
Because state updates are synchronous, you often don't need any presentation streams at all!
When an action is initiated by a user interaction (like tapping a button), the simplest and cleanest pattern is handling the reaction right in the button's onPressed callback:
Why this works so well in BlocSignal: Zero Race Conditions: The moment cubit.signIn(...) finishes, cubit.stateValue is 100% up to date. Zero Duplicate Triggers: Screen rotations or unrelated rebuilds will never re-execute the button handler. Zero Extra Code: No special listeners, no extra streams, no consumable wrapper classes. The Zero-Dependency PresentationMixin Recipe
What if your domain state machine triggers side-effects autonomously (for example, an incoming WebSocket disconnects, a background sync finishes, or you are migrating an existing codebase from blocpresentation)?
You can drop in a 100% compatible presentation architecture in ~25 lines of pure Dart without adding any 3rd-party dependencies.
Step 2: The Flutter Listener (BlocSignalPresentationListener) Putting It Together: A Real-World Example