DEV Community: Randal L. Schwartz

How We Achieved Full BLoC API & Protocol Parity in BlocSignal 0.2.0

Randal L. Schwartz — Tue, 21 Jul 2026 14:04:54 +0000

The BLoC (Business Logic Component) pattern is one of the most reliable and trusted state management architectures in the Flutter ecosystem. By separating event inputs from state outputs, it provides outstanding predictability, trace-ability, and testability.

However, classic BLoC is built entirely on asynchronous Dart Streams. While powerful, streams run on the microtask queue, which introduces frame-level delays and can lead to transient UI glitches or coordination issues when chaining multiple reactive nodes.

Enter BlocSignal—a state management library that bridges the structural discipline of BLoC with the synchronous, glitch-free, fine-grained rebuild performance of reactive signals.

In the 0.2.0 release, we set out to achieve complete class and protocol parity with classic BLoC (package:bloc and package:flutter_bloc), making it seamless to migrate or pair-program using familiar paradigms.

Here is how we did it, including how we solved complex element-caching leaks and the few necessary exceptions we made due to the nature of signals.

1. Core Observability: Changes, Transitions, and Observers

Classic BLoC provides a robust global BlocObserver that tracks the lifecycle, events, transitions, and errors of every bloc in the app. In BlocSignal 0.2.0, we implemented the exact same observability protocol:

// The Change class tracks state mutations (used by both Blocs and Cubits)
final change = Change(currentState: oldState, nextState: newState);

// The Transition class tracks event-triggered updates (used by Blocs)
final transition = Transition(
  currentState: oldState,
  event: IncrementEvent(),
  nextState: newState,
);

Global Interception

You can now subclass BlocSignalObserver and hook into every lifecycle phase across your application:

class MyObserver extends BlocSignalObserver {
  @override
  void onCreate(BlocSignalBase bloc) {
    print('Created: ${bloc.runtimeType}');
  }

  @override
  void onChange(BlocSignalBase bloc, Change change) {
    print('Change in ${bloc.runtimeType}: $change');
  }

  @override
  void onTransition(BlocSignalBase bloc, Object? event, Object? state) {
    // Legacy support
  }

  @override
  void onClose(BlocSignalBase bloc) {
    print('Closed: ${bloc.runtimeType}');
  }
}

Local Overrides

We also aligned subclass method signatures so you can override onChange(Change) and onTransition(Transition) directly in your custom blocs to execute local side-effects, logging, or analysis:

class CounterBloc extends BlocSignal<CounterEvent, int> {
  CounterBloc() : super(initialState: 0);

  @override
  void onChange(Change<int> change) {
    super.onChange(change); // Keep observer updated
    print('Local change detected: $change');
  }
}

2. Flutter Bindings Parity

To bring bloc_signals_flutter to full parity, we overhauled the widget lifecycle behaviors to match flutter_bloc 1:1.

Lazy Provider Initialization

In previous versions, BlocSignalProvider eagerly created the BLoC on mount. In 0.2.0, we aligned with classic BLoC by defaulting to lazy: true. The BLoC's create factory is deferred until the first time a descendant widget looks up the bloc (via context.read(), context.watch(), or builders).

BlocSignalProvider(
  create: (context) => HeavyLoadingBloc(),
  lazy: true, // Deferred until accessed
  child: const MyWidget(),
)

Conditional Listening (`listenWhen`)

We added the listenWhen filter parameter to BlocSignalListener and BlocSignalConsumer. This allows developers to conditionally filter listener triggers based on the previous and current states:

BlocSignalListener<CounterBloc, int>(
  listenWhen: (previous, current) => current.isEven,
  listener: (context, state) {
    // Only runs when the count changes to an even number
    showCelebrationDialog(context);
  },
  child: const CounterView(),
)

We also implemented MultiBlocSignalListener, letting you chain multiple independent listeners linearly to keep your widget trees flat and readable.

3. Solving the `context.select` Memory Leak (Under the Hood)

Implementing context.select<T, R>(selector) with reactive signals was our greatest technical challenge.

In classic BLoC, context.select listens to a stream and rebuilds the calling widget element only when the selected sub-state changes. With signals, we wanted to use a Computed signal to wrap the selector callback and rebuild the calling Element whenever the computed signal value changed.

To make this O(1), we used an Expando keyed on the calling Element to store and reuse _SelectSubscription objects across builds.

The Bug: Strong Reference Cycle Leak

An Expando uses weak keys, meaning entries are automatically garbage-collected when the key (Element) is no longer referenced.

However, our initial implementation of the effect callback captured a strong reference to the Element to trigger element.markNeedsBuild(). Because the effect was reachable from the subscription stored in the Expando, this created a strong reference cycle:
Element (Key) -> SelectorState -> Subscription -> Effect -> Element (Key).

This cycle prevented the Element key from ever being garbage-collected, creating a massive memory leak!

The Fix: `WeakReference` to the Rescue

To break this cycle, we wrapped the Element in a WeakReference inside our subscription model:

class _SelectSubscription<T extends BlocSignalBase<dynamic>, R> {
  _SelectSubscription({
    required T bloc,
    required R Function(T) selector,
    required Element element,
  })  : _bloc = bloc,
        _selector = selector,
        _elementRef = WeakReference(element) {
    _computed = computed(() => _selector(_bloc));
    _selectedValue = _computed.value;

    _dispose = effect(() {
      final newValue = _computed.value;
      if (newValue != _selectedValue) {
        _selectedValue = newValue;
        final el = _elementRef.target;
        if (el != null && el.mounted) {
          el.markNeedsBuild();
        }
      }
    });
  }
  // ...
}

Now, the closure only holds a weak reference to the element. Once the widget unmounts, the Element key is naturally garbage-collected, which automatically evicts the subscription from the Expando and cleans up the reactive effect!

4. Necessary Exceptions (Because of Streams)

While we achieved API parity, there are a few features from classic BLoC that cannot be replicated directly due to the underlying shift from Streams to Signals.

Here is what is missing, and how to achieve the same result using signals:

1. Custom `EventTransformer`s

Classic BLoC lets you supply custom event transformers (like concurrent, sequential, or restartable from package:bloc_concurrency) to control how events queue up. Because BlocSignal executes event handlers synchronously upon dispatch, there is no event queue stream.

droppable (Throttle) Equivalent: If you want to drop events while an async action is running, check your loading state synchronously:

  on<FetchPage>((event, emit) async {
    if (stateValue is PageLoadInProgress) return; // Drop event
    emit(PageLoadInProgress());
    // ...
  });

restartable (SwitchMap) Equivalent: If you want to cancel the current request when a new event arrives, track a CancelableOperation and cancel it:

  class DetailBloc extends BlocSignal<DetailEvent, DetailState> {
    CancelableOperation<Data>? _activeOperation;

    on<FetchDetails>((event, emit) async {
      await _activeOperation?.cancel(); // Cancel active operation
      emit(DetailLoadInProgress());

      final op = CancelableOperation.fromFuture(api.fetch(event.id));
      _activeOperation = op;

      final data = await op.value;
      if (!op.isCanceled) emit(DetailLoadSuccess(data));
    });
  }

2. Debouncing Events

In classic BLoC, you might debounce event dispatching (e.g. search box text entry). In BlocSignal, you can achieve this by managing a simple Timer in your bloc:

class SearchBloc extends BlocSignal<SearchEvent, SearchState> {
  Timer? _debounceTimer;

  @override
  Future<void> onEvent(SearchEvent event) async {
    await super.onEvent(event);
    if (event is SearchTextChanged) {
      _debounceTimer?.cancel();
      _debounceTimer = Timer(const Duration(milliseconds: 300), () {
        _performSearch(event.query);
      });
    }
  }
}

Bonus: Automated Migrations with AI Coding Skills

We know that refactoring state management across a large codebase can be daunting. To solve this, the bloc_signals repository exposes a built-in AI Coding Skill under skills/bloc-signals/migration.md.

This markdown document is structured specifically for LLMs and AI coding assistants (like Google Antigravity, Cursor, or Copilot). By pointing your AI agent to this skill, it can automatically rewrite and migrate your legacy stream-based BLoC widgets and state classes to reactive signals with high precision, eliminating almost all of the manual migration friction!

Conclusion

With BlocSignal 0.2.0, you no longer have to choose between the architectural predictability of BLoC and the raw performance of reactive signals. By achieving class and protocol parity, you get the best of both worlds: O(1) state selections, synchronous propagation, full observer tracing, and zero frame-level rebuild delays.

Check out the packages today on pub.dev:
👉 bloc_signals

👉 bloc_signals_flutter

BLoC meets Signals: How to Pitch BlocSignal to Your Dev Leads

Randal L. Schwartz — Mon, 20 Jul 2026 16:12:04 +0000

Flutter state management is a battleground. Every few seasons, a new paradigm emerges, claiming to solve all our development woes. We’ve seen standard setState, scoped model, Provider, BLoC, MobX, and Riverpod.

Recently, Signals (derived from the Preact architecture) has taken the frontend world by storm. It offers synchronous, fine-grained, and glitch-free reactivity. But raw signals can feel too chaotic for large teams, leading developers to modify state directly from the UI without any structure.

Enter BlocSignal—a framework that bridges the architectural discipline of the BLoC pattern (Events in, States out) with the extreme performance and synchronous reactivity of Signals.

But when you bring a new library to an architectural review board, you will face pushback. Here is how to pitch BlocSignal and answer the 5 toughest questions your dev leads and reviewers will throw at you.

Objection 1: "It's brand new! Why should we adopt an untested library?"

The Critic

"We can't afford to run our production apps on a brand-new, untested state-management library. What if it gets abandoned or introduces critical bugs?"

The Response

BlocSignal is a thin, architectural bridge linking two of the most mature, popular, and battle-tested paradigms in Dart and Flutter:

The BLoC Pattern: Originally designed by Google and popularized by Felix Angelov, the BLoC model (Events, States, Cubits, and standard unidirectional data flow) has been the gold standard for enterprise Flutter for years. Developers use the exact same mental models they already know.
Preact-style Signals: The reactivity engine is powered by Rody Davis's signals library (version 7). Signals are the industry-standard state primitive of modern web frameworks like SolidJS, Qwik, Angular, Vue, and Preact.
100% Test Coverage: The bloc_signals and bloc_signals_flutter packages maintain 100% line coverage for all codebase paths. The API is locked down with strict automated unit and integration tests.

Summary: You aren't adopting a "from scratch" state engine; you are adopting a structured interface wrapper over highly optimized, production-ready primitives.

Objection 2: "We tried BLoC and moved to Riverpod. Why go back?"

The Critic

"We migrated from BLoC to Riverpod because we hated streams, microtask queues, visual rendering lag, and boilerplate. Why would we go back to BLoC?"

The Response

BlocSignal solves the exact pain points that drove teams to Riverpod in the first place, while avoiding Riverpod's own drawbacks:

Synchronous Updates: Unlike classic BLoC which propagates state changes asynchronously via Dart Stream microtask queues, BlocSignal propagates updates synchronously in the same frame. Just like Riverpod, calling emit() instantly notifies downstream listeners.
Widget-Tree Scoped Lifecycle: Riverpod relies on global provider scopes. Scoping state to specific routes, dialogs, or subtrees requires complex caching or parameter bindings. BlocSignal restores Flutter's native dependency injection model using BlocSignalProvider (built on InheritedWidget). When a widget unmounts, the bloc's resources are automatically closed.
No Stream Boilerplate: Instead of using complex RxDart stream operations to derive state, you can declare lightweight, cached, and automatically updated derived values using computed() signals inside your constructor:

  late final ReadOnlySignal<bool> isCartEmpty = computed(() => stateValue.items.isEmpty);

Automatic De-duplication: Classic BLoC triggers transition listeners for every emit. BlocSignal de-duplicates equal states (==) out of the box, preventing redundant widget rebuilds.

Objection 3: "It's not enterprise battle-ready."

The Critic

"Enterprise apps need logging, metrics, error tracking, and strict guidelines. Lightweight state libraries are toys that don't scale."

The Response

BlocSignal was built from day one with enterprise constraints in mind:

Native OpenTelemetry (OTel) Observability: In enterprise environments, tracing requests across systems is vital. BlocSignal includes OtelBlocSignalObserver which:
- Automatically tracks event transitions, asynchronous executions, and errors.
- Maps them directly to OpenTelemetry Spans.
- Implements bounded span caching (capped at 1000 items, evicting oldest) to guarantee zero memory leaks.
Failure Safety: Event registry zones capture handler exceptions without disrupting the state container lifecycle, routing them dynamically to telemetry observers.
Strict Quality Rules: The project enforces strict very_good_analysis lints (the enterprise-standard ruleset in Flutter) and 100% doc comment coverage.

Objection 4: "Why not just use raw Signals? What is the value of wrapping them in BLoC?"

The Critic

"If we already have access to the signals package, why introduce BLoC? Can't we just use raw signal objects inside plain controller classes?"

The Response

Raw signals provide fine-grained reactivity but lack architectural discipline. In large team environments, raw mutable signals can lead to spaghetti state management:

Enforced Unidirectional Data Flow: With raw signals, widgets can read and write to signals directly from anywhere (e.g. counter.value++ inside a button). BlocSignal enforces a clear event-driven boundary: widgets can only dispatch events via .add(), and the container's state is exposed as a ReadonlySignal, meaning only the bloc can call emit().
Traceability: Because mutations are routed through discrete events, we can observe, trace, and debug transitions globally (e.g., via OpenTelemetry), which is impossible with raw, ad-hoc signal changes.
Uniformity: It provides a unified pattern for teams. Instead of every developer building custom notifier/controller classes in their own style, everyone inherits from BlocSignal or Cubit patterns, ensuring consistency across feature modules.

Objection 5: "How do we coordinate overlapping asynchronous events? (Loss of `bloc_concurrency`)"

The Critic

"Standard BLoC uses stream concurrency transformers like restartable() or droppable() to cancel or queue overlapping events of the same type. How do we achieve these essential concurrent behaviors without streams?"

The Response

While classic BLoC utilizes RxDart stream transformers, BlocSignal allows teams to orchestrate concurrency through native Dart async patterns, signal effects, or light-weight guard clauses.

Concurrent Execution by Default: If multiple handlers are invoked, they execute concurrently using Future.wait orchestration under the hood, ensuring no tasks are blocked.
Simple Declarative Guards: Implementing concurrency strategies like droppable is trivial. For instance, we can check a loading state before executing the business logic:

   on<LoadData>((event, emit) async {
     if (stateValue is DataLoading) return; // Droppable pattern
     emit(DataLoading());
     // Fetch data...
   });

Cancellation (Restartable Pattern): To replicate a restartable() pattern (where a new event cancels the previous active task), keep a reference to a cancellation token or active future inside the bloc:

   CancelableOperation? _activeOperation;

   on<SearchQueryChanged>((event, emit) async {
     await _activeOperation?.cancel();
     _activeOperation = CancelableOperation.fromFuture(api.search(event.query));

     final results = await _activeOperation!.value;
     emit(SearchSuccess(results));
   });

Feature Comparison Matrix

The table below summarizes the key trade-offs between the three main approaches:

Feature	Classic BLoC (Streams)	Riverpod (v2/v3)	BlocSignal (Signals v7)
Propagation	Asynchronous (Microtask)	Synchronous	Synchronous
Dependency Injection	Widget Tree Scoped	Global Scopes / `ref`	Widget Tree Scoped
State De-duplication	Manual (`distinct()`)	Automatic	Automatic (`==`)
Derived State	Complex (RxDart / Streams)	Declarative (`ref.watch`)	Declarative (`computed`)
Lifecycle Hook	Manual / `BlocProvider`	Auto-Dispose (`ref.keepAlive`)	Automatic (Unmount / `close`)
Observability	`BlocObserver` (Local)	`ProviderObserver` (Local)	OTel Tracing (`OtelObserver`)
Test Overhead	High (Stream queues)	Medium (`ProviderContainer`)	Low (Synchronous Asserts)

Conclusion

BlocSignal is the evolution of two great state management philosophies. It offers the safety and scale of BLoC combined with the developer experience and speed of Signals.

Have you tried bridging these patterns in your Flutter apps? Let me know in the comments below!

Introducing BlocSignal: Unidirectional Data Flow Meets Reactive Signals

Randal L. Schwartz — Sun, 19 Jul 2026 20:42:47 +0000

State management in Flutter has always been a tale of two philosophies:

The Unidirectional, Event-Driven Architecture (BLoC/Cubit): Exceptional for structuring business logic in large-scale applications. It provides clear separations, standard developer workflows, and centralized transition observers. But it runs on Dart Streams, introducing asynchronous microtask scheduling and event-propagation lag.
Fine-Grained Reactive Primitives (Signals): Blazing fast, synchronous, and boilerplate-free. However, without standard guardrails, pure signal codebases can sometimes feel like the "Wild West" when multiple developers try to coordinate complex side effects.

What if you could have the architectural safety and predictability of BLoC combined with the performance and reactive simplicity of Signals?

Enter BlocSignal.

BlocSignal bridges these two paradigms, bringing synchronous, glitch-free propagation, automatic state de-duplication, and advanced signals reactivity to the classic BLoC pattern.

⚡ Why BlocSignal?

In classic BLoC, every emitted state is dispatched asynchronously on a stream. If you emit identical states consecutively, downstream widgets rebuild anyway unless you configure distinct filters.

BlocSignal rewrites the engine under the hood:

Synchronous Propagation: State updates via emit(newState) propagate instantly to downstream calculations and widget rebuilds in the exact same frame. No more waiting on microtasks.
Automatic De-duplication: States are automatically compared using == equality. If a state doesn't change, downstream effects and builders are skipped entirely.
Declarative Reactivity: The bloc exposes its state as a reactive ReadonlySignal<State>. This allows you to compose derived state properties using computed(...) and register side effects via effect(...).

🛠️ The Event Handler Design: Two Flavors of Safety

When managing events in standard BLoC, you typically register handlers in the constructor scope using .on<Event>. In BlocSignal, we support both this dynamic registration pattern and compile-time safe pattern matching.

🧬 Flavor 1: Dynamic Registration with `.on<Event>`

This is the familiar, standard BLoC approach. It is dynamic and easy to write:

import 'package:bloc_signals/bloc_signals.dart';

sealed class CounterEvent {}
class Increment extends CounterEvent {}
class Decrement extends CounterEvent {}

class CounterBloc extends BlocSignal<CounterEvent, int> {
  CounterBloc() : super(initialState: 0) {
    // Dynamic runtime registration
    on<Increment>((event, emit) => emit(stateValue + 1));
    on<Decrement>((event, emit) => emit(stateValue - 1));
  }
}

When to use: Perfect for simple event topologies or when mapping a small set of actions.

🛡️ Flavor 2: Compile-Time Safe Exhaustiveness with Switch Expressions

Because .on<T> registers handlers dynamically at runtime, the Dart compiler cannot verify if you've handled every subclass of a sealed class.

To achieve 100% compile-time safety, you can override onEvent(event) and use a Dart switch expression. If you add a new event subclass and forget to handle it, your project will fail to compile, preventing runtime bugs:

import 'package:bloc_signals/bloc_signals.dart';

sealed class CounterEvent {}
class Increment extends CounterEvent {}
class Decrement extends CounterEvent {}
class Reset extends CounterEvent {}

class CounterBloc extends BlocSignal<CounterEvent, int> {
  CounterBloc() : super(initialState: 0);

  @override
  FutureOr<void> onEvent(CounterEvent event) {
    // The compiler strictly enforces that all CounterEvent subclasses are handled
    final nextState = switch (event) {
      Increment() => stateValue + 1,
      Decrement() => stateValue - 1,
      Reset()     => 0,
    };
    emit(nextState);
  }
}

When to use: Production enterprise features with complex, evolving sealed event hierarchies.

🎨 Consuming State in Flutter

Integrating BlocSignal into your Flutter widgets is a breeze. It uses familiar provider/builder APIs, but optimizes them using signal-based rebuilding.

1. Providing the State

Inject your state container into the widget tree using BlocSignalProvider:

BlocSignalProvider<CounterBloc>(
  create: (context) => CounterBloc(),
  child: const CounterScreen(),
)

(Note that BlocSignal for Flutter doesn't use the Provider package—we implement our own lightweight InheritedWidget subclass, eliminating one more external dependency.)

2. Building the UI

Rebuild sections of the UI using BlocSignalBuilder. Because it reads the underlying signal value, it subscribes and unsubscribes from state changes automatically:

BlocSignalBuilder<CounterBloc, int>(
  builder: (context, count) {
    return Text(
      '$count',
      style: Theme.of(context).textTheme.headlineMedium,
    );
  },
)

🚀 Advanced Composition: Computed Signals & Effects

Since the state is powered by standard Dart signals, you can compose derived state effortlessly:

Inside the Constructor (Scoped)

You can declare reactive signals properties directly inside the class constructor. They will automatically be disposed of when the bloc is closed:

class TaskBloc extends BlocSignal<TaskEvent, List<Task>> {
  late final ReadonlySignal<int> completedCount;

  TaskBloc() : super(initialState: []) {
    // Automatically updates whenever the state changes
    completedCount = computed(() => stateValue.where((t) => t.isCompleted).length);

    // Auto-disposed side effects
    effect(() {
      print('Outstanding tasks: ${stateValue.length - completedCount()}');
    });
  }
}

Outside the Constructor (Consumer)

Consumers can subscribe to a bloc's reactive state signal directly to create external computed chains:

final taskBloc = TaskBloc();

// External computed signal
final hasOutstandingTasks = computed(() => taskBloc.state().any((t) => !t.isCompleted));

📈 Enterprise Observability

In production environments, tracking state transitions is critical. BlocSignal zones track transitions triggered by specific events.

By registering the OtelBlocSignalObserver (from otel_bloc_signals), transitions, actions, and errors map directly to OpenTelemetry traces, ensuring you have absolute visibility into user flows:

BlocSignalObserver.instance = OtelBlocSignalObserver(
  tracerProvider: myTracerProvider,
);

🏁 Summary & Resources

BlocSignal takes the best parts of two worlds. It gives you the structured boundaries and event hierarchies of BLoC/Cubit, backed by the raw performance, synchronous execution, and declarative power of Signals.

Ready to check it out? Explore the packages on Pub:

📦 bloc_signals – Core state management container.
📦 bloc_signals_flutter – High-performance widgets and custom providers.
📦 otel_bloc_signals – OpenTelemetry tracing and observability observer.
💻 GitHub Repository

DEV Community: Randal L. Schwartz

How We Achieved Full BLoC API & Protocol Parity in BlocSignal 0.2.0

1. Core Observability: Changes, Transitions, and Observers

Global Interception

Local Overrides

2. Flutter Bindings Parity

Lazy Provider Initialization

Conditional Listening (listenWhen)

3. Solving the context.select Memory Leak (Under the Hood)

The Bug: Strong Reference Cycle Leak

The Fix: WeakReference to the Rescue

4. Necessary Exceptions (Because of Streams)

1. Custom EventTransformers

2. Debouncing Events

Bonus: Automated Migrations with AI Coding Skills

Conclusion

BLoC meets Signals: How to Pitch BlocSignal to Your Dev Leads

Objection 1: "It's brand new! Why should we adopt an untested library?"

The Critic

The Response

Objection 2: "We tried BLoC and moved to Riverpod. Why go back?"

The Critic

The Response

Objection 3: "It's not enterprise battle-ready."

The Critic

The Response

Objection 4: "Why not just use raw Signals? What is the value of wrapping them in BLoC?"

The Critic

The Response

Objection 5: "How do we coordinate overlapping asynchronous events? (Loss of bloc_concurrency)"

The Critic

The Response

Feature Comparison Matrix

Conclusion

Introducing BlocSignal: Unidirectional Data Flow Meets Reactive Signals

⚡ Why BlocSignal?

🛠️ The Event Handler Design: Two Flavors of Safety

🧬 Flavor 1: Dynamic Registration with .on<Event>

🛡️ Flavor 2: Compile-Time Safe Exhaustiveness with Switch Expressions

🎨 Consuming State in Flutter

1. Providing the State

2. Building the UI

🚀 Advanced Composition: Computed Signals & Effects

Inside the Constructor (Scoped)

Outside the Constructor (Consumer)

📈 Enterprise Observability

🏁 Summary & Resources

Conditional Listening (`listenWhen`)

3. Solving the `context.select` Memory Leak (Under the Hood)

The Fix: `WeakReference` to the Rescue

1. Custom `EventTransformer`s

Objection 5: "How do we coordinate overlapping asynchronous events? (Loss of `bloc_concurrency`)"

🧬 Flavor 1: Dynamic Registration with `.on<Event>`