DEV Community: Randal L. Schwartz

Riverpod to BlocSignal: Incremental Migration and Zero-Codegen Signals for Flutter

Randal L. Schwartz — Wed, 12 Aug 2026 23:05:09 +0000

Introduction: Combining Riverpod Safety with Zero Codegen

If you've been building Flutter apps with Riverpod, you already know the joy of compile-time provider safety, auto-disposal, and synchronous notification propagation via ProviderListenable. Riverpod fundamentally raised the bar for Flutter state management.

However, as projects grow, many Riverpod developers run into familiar friction points:

Code Generation Overhead: Depending heavily on riverpod_generator and waiting on build_runner watches during rapid UI iteration.
Complex Provider Trees: Managing nested ProviderScope overrides and .family cache eviction policies when scaling large teams.
All-or-Nothing Migration Concerns: Wanting to trial new reactive primitives or event-driven BLoC architectures without rewriting an entire codebase.

What if you could combine the compile-time safety and synchronous reactivity you love in Riverpod with zero code generation, fine-grained signal graph reactivity, and the ability to trial or migrate incrementally screen-by-screen?

Enter BlocSignal and bloc_signals_riverpod.

The Core Ergonomics: Riverpod `Notifier` vs. `CubitSignal`

Let's compare the classic Todos application—one of the benchmark examples in the official Riverpod monorepo—ported directly to BlocSignal.

The Riverpod Approach (Requires `@riverpod` & `build_runner`)

In modern Riverpod, creating a todo list with reactive filtering typically involves a generated Notifier and separate provider getters or ref.watch selectors:

@riverpod
class TodoList extends _$TodoList {
  @override
  List<Todo> build() => const [];

  void addTodo(String description) {
    state = [...state, Todo(id: DateTime.now().toString(), description: description)];
  }

  void toggle(String id) {
    state = [
      for (final todo in state)
        if (todo.id == id) todo.copyWith(completed: !todo.completed) else todo
    ];
  }
}

// Derived filter provider
@riverpod
List<Todo> filteredTodos(Ref ref) {
  final todos = ref.watch(todoListProvider);
  final filter = ref.watch(todoFilterProvider);
  return switch (filter) {
    TodoFilter.all => todos,
    TodoFilter.active => todos.where((t) => !t.completed).toList(),
    TodoFilter.completed => todos.where((t) => t.completed).toList(),
  };
}

The BlocSignal Approach (100% Pure Dart 3, No Codegen)

With BlocSignal, your state container is a standard handwritten Dart class (CubitSignal<List<Todo>>). Reactive derivations like filteredTodos and uncompletedCount are declared inline using signals computed():

import 'package:bloc_signals/bloc_signals.dart';
import 'package:flutter/foundation.dart';
import 'package:signals_core/signals_core.dart';

class TodosCubit extends CubitSignal<List<Todo>> {
  // Pass `equals: listEquals` to enforce value-based list equality for state de-duplication!
  TodosCubit([List<Todo> initialTodos = const []])
      : super(initialState: initialTodos, equals: listEquals) {
    // 1. Reactive filter signal
    filter = signal(TodoFilter.all);

    // 2. Synchronously derived computed signals
    filteredTodos = computed(() {
      return switch (filter.value) {
        TodoFilter.all => stateValue,
        TodoFilter.active => stateValue.where((t) => !t.completed).toList(),
        TodoFilter.completed => stateValue.where((t) => t.completed).toList(),
      };
    });

    uncompletedCount = computed(() => stateValue.where((t) => !t.completed).length);
  }

  late final Signal<TodoFilter> filter;
  late final ReadonlySignal<List<Todo>> filteredTodos;
  late final ReadonlySignal<int> uncompletedCount;

  void addTodo(String description) {
    emit([...stateValue, Todo(id: DateTime.now().toString(), description: description)]);
  }

  void toggle(String id) {
    emit([
      for (final todo in stateValue)
        if (todo.id == id) todo.copyWith(completed: !todo.completed) else todo
    ]);
  }

  void setFilter(TodoFilter newFilter) => filter.value = newFilter;

  @override
  Future<void> close() async {
    filter.dispose();
    filteredTodos.dispose();
    uncompletedCount.dispose();
    await super.close();
  }
}

What Changed?

No build_runner: No .g.dart generated files, no background watchers, no build step delays.
Built-In Custom Equality (equals: listEquals): Because Dart List instances don't override == by default, passing equals: listEquals configures the underlying signal graph to de-duplicate state emissions based on list content equality.
Fine-Grained Signal Graph: Updates to filter.value or calling emit(...) re-evaluate computed() derivations synchronously and notify only dependent widgets.
Explicit Container Lifecycles: Disposing the cubit disposes its internal signals automatically.

Zero Risk: Incremental Trial & Bidirectional Interop

You do not need to rewrite your application to try BlocSignal. With the bloc_signals_riverpod package, you can seamlessly bridge the two frameworks in both directions.

dependencies:
  bloc_signals: ^1.0.0
  bloc_signals_flutter: ^1.0.0
  bloc_signals_riverpod: ^1.0.0

Option A: Expose a `BlocSignal` / `CubitSignal` to Existing Riverpod Widgets

Want to write a new feature or state controller with BlocSignal, but keep your existing Riverpod UI layer (ConsumerWidget, WidgetRef)?

Simply call .toProvider():

import 'package:bloc_signals_riverpod/bloc_signals_riverpod.dart';

// Create your new BlocSignal or CubitSignal
final todosCubit = TodosCubit();

// Convert it directly into a Riverpod NotifierProvider!
final todosProvider = todosCubit.toProvider();

// Now consume it anywhere in existing Riverpod widgets:
class LegacyRiverpodWidget extends ConsumerWidget {
  const LegacyRiverpodWidget({super.key});

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    // Rebuilds reactively whenever todosCubit emits!
    final todos = ref.watch(todosProvider);

    return ListView.builder(
      itemCount: todos.length,
      itemBuilder: (context, i) => Text(todos[i].description),
    );
  }
}

Option B: Adapt an Existing Riverpod Provider into `BlocSignal`

Have a legacy Riverpod provider that you need to read from a new BlocSignalBuilder widget?

Use .toBlocSignal(ref):

import 'package:bloc_signals_riverpod/bloc_signals_riverpod.dart';

class NewFeatureWidget extends ConsumerWidget {
  const NewFeatureWidget({super.key});

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    // Adapt any Riverpod ProviderListenable into a BlocSignal container!
    // Automatically binds ref.onDispose to close the container when disposed.
    final todosBloc = legacyRiverpodProvider.toBlocSignal(ref);

    return BlocSignalBuilder<BlocSignalBase<List<Todo>>, List<Todo>>(
      bloc: todosBloc,
      builder: (context, todos) {
        return ListView.builder(
          itemCount: todos.length,
          itemBuilder: (context, i) => Text(todos[i].description),
        );
      },
    );
  }
}

Converting `AsyncValue` <-> `AsyncState`

bloc_signals_riverpod also provides extension methods to map seamlessly between Riverpod's AsyncValue and Signals' AsyncState:

// Riverpod AsyncValue to Signals AsyncState
final asyncState = riverpodAsyncValue.toAsyncState();

// Signals AsyncState to Riverpod AsyncValue
final asyncValue = signalsAsyncState.toAsyncValue();

Explore the Official Riverpod Ports on blocsignal.dev

To prove the DX gains and side-by-side equivalence, we've ported canonical state management examples directly from the official rrousselGit/riverpod monorepo into the BlocSignal open-source repository:

📝 Riverpod Todos (examples/riverpod_todos):
- Replaces @riverpod codegen and Notifier with CubitSignal<List<Todo>> and synchronous computed() signals for reactive filter tabs and stats.
🔍 Pub.dev Package Search (examples/riverpod_pub):
- Replaces Riverpod AsyncNotifier with BlocSignal and a streamless restartable() event transformer that automatically cancels in-flight API requests on keypresses without Rx streams.
🦸 Marvel Character Browser (examples/riverpod_marvel):
- Demonstrates API pagination, character search, and widget tree scoping via BlocSignalProvider.value.

Explore all 20 side-by-side benchmark ports across BLoC, Signals, and Riverpod live at blocsignal.dev/#ported-examples!

Built-In AI Agent Skills for Automated Migration

If you use AI coding assistants like Antigravity, Gemini, Cursor, or GitHub Copilot, BlocSignal publishes a dedicated Agent Plugin skill bundle (riverpod_migration.md).

When your AI assistant inspects a project with BlocSignal skills enabled, it automatically understands:

How to map StateNotifierProvider / NotifierProvider to CubitSignal;
How to preserve auto-disposal and cancellation contracts;
How to refactor ConsumerWidget rebuild boundaries to BlocSignalBuilder or SignalBuilder;
How to apply bloc_signals_riverpod interop adapters during multi-phase refactoring.

Summary

You don't need to throw away your existing architecture to enjoy the speed, simplicity, and zero-codegen elegance of reactive signals.

With bloc_signals_riverpod, you can trial BlocSignal on a single screen today, bridge your existing Riverpod providers seamlessly, and upgrade your developer experience at your own pace.

🌐 Website & Comparison Benchmarks: blocsignal.dev
📦 Pub.dev Packages: bloc_signals | bloc_signals_flutter | bloc_signals_riverpod
🐙 GitHub Repository: RandalSchwartz/BlocSignal

Unit Testing in BlocSignal: The Practical Handbook

Randal L. Schwartz — Sun, 09 Aug 2026 15:31:53 +0000

A Practical Guide to Faster, Deterministic Flutter & Dart Unit Testing

If you’ve ever written unit tests for classic package:bloc applications using bloc_test, you know the drill: build your BLoC, dispatch an event in act, and assert state emissions in expect.

Under the hood, classic BLoC processes state updates asynchronously via Dart microtask-queue Streams. While robust, testing asynchronous streams can introduce microtask timing headaches, race conditions, or the need to drain queues or use fakeAsync when testing complex side-effects.

In BlocSignal, state updates propagate synchronously. Calling emit(newState) updates the underlying signal graph in the exact same call stack frame.

This handbook is a practical, recipe-based guide to testing BlocSignal and CubitSignal applications using package:bloc_signals_test. Whether you’re coming from classic BLoC or brand new to Signals, this guide shows you how to test every scenario cleanly—and why it’s significantly easier than classic stream-based testing.

🤖 AI Assistant Tip: Working with an AI coding assistant (like Antigravity, Gemini CLI, or Cursor)? The official bloc-signals plugin includes a pre-built testing skill (plugins/bloc-signals/skills/bloc-signals/) that automatically teaches your AI assistant these exact testing conventions, observer scoping rules, and declarative blocSignalTest patterns!

🛠️ Quick Reference: BLoC Streams vs. BlocSignal Testing

Testing Task	Classic BLoC (`package:bloc_test`)	BlocSignal (`package:bloc_signals_test`)	Why it’s easier in BlocSignal
Execution Environment	Often requires `flutter test` engine	Pure `dart test` execution	Blazing Speed: Business logic tests run in pure Dart CLI without booting Flutter UI engine.
Simple State Assertions	Requires async stream listener or `blocTest`	Direct `expect(cubit.state, 1)` or `blocSignalTest`	Synchronous: State updates on the next line of code without microtask delay.
Failure Diagnostics	Legacy `Instance of 'CounterCubit'`	Built-in `toString()`: `CounterCubit(0)`	Clear Logs: Failed assertions print state value directly in console.
State Seeding	`seed: () => State(...)`	`build: () => MyCubit(initialState: ...)`	Direct Constructor Seeding: No hidden seed queue or stream overrides.
Concurrency Transformers	Requires `fakeAsync` / async timer pumps	Pure Dart `Future` / `Mutex` locks	Deterministic Execution: No microtask stream queue lagging behind event dispatches.
De-duplication Testing	Dependent on `Equatable` mixins	Built-in `==` equality de-duplication	Automatic: Duplicate states never trigger redundant test steps or UI builds.

📖 Recipe Handbook

Recipe 1: Direct Imperative Unit Testing (Zero Helper Overhead)

Because state updates in BlocSignal and CubitSignal happen synchronously, you don’t need any helper package or async pump for straightforward unit tests! You can inspect cubit.state immediately on the next line of code:

import 'package:bloc_signals/bloc_signals.dart';
import 'package:test/test.dart';

class CounterCubit extends CubitSignal<int> {
  CounterCubit([super.initialState = 0]);

  void increment() => emit(state + 1);
  void decrement() => emit(state - 1);
}

void main() {
  group('CounterCubit (Direct Synchronous Testing)', () {
    test('initial state is 0', () {
      final cubit = CounterCubit();
      expect(cubit.state, equals(0));
      cubit.close();
    });

    test('increment updates state synchronously in the same call frame', () {
      final cubit = CounterCubit();

      cubit.increment();
      // No await, no microtask pump, no stream listener delay!
      expect(cubit.state, equals(1));

      cubit.increment();
      expect(cubit.state, equals(2));

      cubit.close();
    });
  });
}

💡 Why it’s easier than BLoC: You don't need await bloc.stream.first or expectLater(). What you call is what you immediately assert. Furthermore, if an assertion fails, BlocSignalBase.toString() outputs CounterCubit(1) instead of generic Instance of 'CounterCubit', making test failure diagnostics crystal clear.

Recipe 2: Declarative Testing with `blocSignalTest`

For structured test suites, package:bloc_signals_test provides the blocSignalTest helper. It mirrors the exact API of blocTest from package:bloc_test so BLoC developers feel right at home:

import 'package:bloc_signals_test/bloc_signals_test.dart';
import 'package:test/test.dart';

void main() {
  group('CounterCubit (blocSignalTest)', () {
    blocSignalTest<CounterCubit, int>(
      'emits [1] when increment is called',
      build: () => CounterCubit(),
      act: (cubit) => cubit.increment(),
      expect: () => [1],
    );

    blocSignalTest<CounterCubit, int>(
      'emits [1, 2] when increment is called twice',
      build: () => CounterCubit(),
      act: (cubit) {
        cubit.increment();
        cubit.increment();
      },
      expect: () => [1, 2],
    );

    blocSignalTest<CounterCubit, int>(
      'supports state seeding directly in build()',
      build: () => CounterCubit(10), // Seeded with 10
      act: (cubit) => cubit.increment(),
      expect: () => [11],
    );
  });
}

Recipe 3: Testing Reified Events & Streamless Concurrency Transformers

When testing event-driven BlocSignal classes (bloc.add(event)), blocSignalTest records every state transition triggered by your event handlers.

In addition, BlocSignal supports streamless event concurrency transformers (droppable(), sequential(), restartable(), Mutex) built on pure Dart higher-order functions:

sealed class CounterEvent {}
class IncrementEvent extends CounterEvent {}
class DecrementEvent extends CounterEvent {}

class CounterBloc extends BlocSignal<CounterEvent, int> {
  CounterBloc() : super(0) {
    // Pass concurrency transformers directly without Rx Streams:
    on<IncrementEvent>(
      (event, emit) => emit(state + 1),
      transformer: sequential(),
    );
    on<DecrementEvent>(
      (event, emit) => emit(state - 1),
      transformer: droppable(),
    );
  }
}

void main() {
  group('CounterBloc Event Testing', () {
    blocSignalTest<CounterBloc, int>(
      'emits [1, 0] when IncrementEvent and DecrementEvent are added',
      build: () => CounterBloc(),
      act: (bloc) {
        bloc.add(IncrementEvent());
        bloc.add(DecrementEvent());
      },
      expect: () => [1, 0],
    );
  });
}

Automatic De-duplication

Signals automatically de-duplicate identical states using == equality. Re-emitting an identical state is safely ignored without triggering redundant test steps or UI rebuilds:

class UserCubit extends CubitSignal<String> {
  UserCubit() : super('Alice');

  void updateName(String name) => emit(name);
}

blocSignalTest<UserCubit, String>(
  'automatically de-duplicates identical state emissions',
  build: () => UserCubit(),
  act: (cubit) => cubit.updateName('Alice'), // Same as initial state
  expect: () => [], // No redundant emission!
);

Recipe 4: Testing Asynchronous APIs & Error Routing

When an event handler triggers asynchronous Futures (such as REST API calls or database queries), operational exceptions are captured automatically and routed to onError. blocSignalTest allows you to assert both state transitions and caught exceptions:

class AuthBloc extends BlocSignal<AuthEvent, AuthState> {
  final AuthRepository repository;

  AuthBloc(this.repository) : super(AuthInitial()) {
    on<LoginRequested>((event, emit) async {
      emit(AuthLoading());
      try {
        final user = await repository.login(event.email, event.password);
        emit(AuthAuthenticated(user));
      } catch (e) {
        emit(AuthFailure(e.toString()));
      }
    });
  }
}

void main() {
  group('AuthBloc Async Tests', () {
    blocSignalTest<AuthBloc, AuthState>(
      'emits [AuthLoading, AuthAuthenticated] on successful login',
      build: () => AuthBloc(MockAuthRepository(success: true)),
      act: (bloc) => bloc.add(LoginRequested('user@example.com', 'pass123')),
      expect: () => [
        AuthLoading(),
        AuthAuthenticated(User(id: '1', email: 'user@example.com')),
      ],
    );

    blocSignalTest<AuthBloc, AuthState>(
      'emits [AuthLoading, AuthFailure] and captures error on failure',
      build: () => AuthBloc(MockAuthRepository(success: false)),
      act: (bloc) => bloc.add(LoginRequested('user@example.com', 'wrong')),
      expect: () => [
        AuthLoading(),
        AuthFailure('Unauthorized'),
      ],
      errors: () => [
        isA<UnauthorizedException>(),
      ],
    );
  });
}

Recipe 5: Testing Hydrated Persistence & Replay Undo/Redo

When using satellite packages like bloc_signals_hydrate or bloc_signals_replay, testing state persistence and undo/redo stacks is completely synchronous:

// Testing HydratedCubitSignal with in-memory storage mock:
void main() {
  setUp(() {
    HydratedStorage.storage = MockHydratedStorage();
  });

  blocSignalTest<HydratedCounterCubit, int>(
    'restores persisted state on instantiation',
    build: () => HydratedCounterCubit(),
    act: (cubit) => cubit.increment(),
    verify: (cubit) {
      expect(HydratedStorage.storage.read('HydratedCounterCubit'), equals({'value': 1}));
    },
  );
}

Recipe 6: Testing Observers & Global Telemetry Scoping

If you are testing custom BlocSignalObserver implementations (such as OpenTelemetry tracing or logging observers), blocSignalTest automatically manages observer setup before build() is invoked—ensuring onCreate, onEvent, onTransition, onChange, and onClose lifecycle events are captured cleanly:

void main() {
  group('Observer Telemetry Scoping', () {
    late TestObserver testObserver;

    setUp(() {
      testObserver = TestObserver();
    });

    blocSignalTest<CounterCubit, int>(
      'captures onCreate and onClose in test observer',
      build: () => CounterCubit(),
      act: (cubit) => cubit.increment(),
      verify: (cubit) {
        expect(testObserver.createdContainers, hasLength(1));
        expect(testObserver.transitions, hasLength(1));
      },
    );
  });
}

🤖 Built-in AI Agent Testing Skill

One of the biggest advantages of BlocSignal is its first-class AI agent integration.

When building or testing applications with AI coding tools (such as Antigravity, Gemini CLI, or Cursor), the official bloc-signals plugin bundles a dedicated agent skill (plugins/bloc-signals/skills/bloc-signals/):

Automated Test Scaffolding: Teaches AI agents to write declarative blocSignalTest unit tests following clean 100% coverage patterns.
Observer Scoping Rules: Ensures AI assistants attach test observers before build() to capture onCreate lifecycle events.
Synchronous Assertion Guidance: Prevents AI tools from adding unnecessary await tester.pumpAndSettle() or Future.delayed calls when testing pure signal state updates.

You can validate your local AI agent setup at any time by running:

dart run tool/validate_agent_plugin.dart

🚀 Conclusion

Unit testing state machines doesn't have to mean fighting asynchronous microtask streams or writing boilerplate pump loops.

With BlocSignal and bloc_signals_test:

State updates propagate synchronously in the exact frame they occur.
Pure Dart core tests run in milliseconds via dart test without Flutter engine startup overhead.
The API is 100% familiar to anyone who knows package:bloc_test.
AI coding agents come equipped with pre-built skills to help you write 100% covered test suites effortlessly.

Resources & Links

📦 package:bloc_signals_test on pub.dev
🌐 Official Documentation & Interactive Demos: blocsignal.dev
🐙 Open Source Repository: GitHub (RandalSchwartz/BlocSignal)

Happy testing! 🧪✨

From Raw Signals to BlocSignal: Taming Reactivity for Enterprise Scale

Randal L. Schwartz — Sat, 08 Aug 2026 19:37:57 +0000

By Randal L. Schwartz & the BlocSignal Team

🌟 Introduction: The Modern State Management Dilemma

State management in Flutter and Dart has arrived at an intriguing crossroads.

In a previous article, Why ValueNotifier Fails at Scale: The Non-Composability Problem (and How Signals Fix It), we explored how moving from Flutter's built-in ValueNotifier / ChangeNotifier to Signal-based reactive primitives (signal(), computed(), effect()) solves the non-composability wall. Signals brought fine-grained reactivity, sub-millisecond updates, automatic dependency tracking, and 0ms microtask queue latency.

However, as enterprise teams and large client projects adopted raw signals, a new "pitfall of freedom" emerged:

"When any UI widget can read, write, or overwrite .value on a global signal from anywhere in the codebase, architecture breaks down."

Unstructured, writable signals scattered across files create test leakage, untraceable state mutations during PR reviews, and chaotic state graphs.

This brings us to a fundamental historical lesson:

We tamed globals by creating library, class, and function-local scope. BlocSignal tames Signals by similar means.

In this article, we’ll explore how BlocSignal bridges the gap—taking developers from raw, unstructured Signals to an architectural layer that delivers BLoC’s enterprise discipline with Signals’ zero-microtask synchronous speed.

⚠️ Step 1: The Pitfall of Raw Signals ("Too Much Freedom")

While Signals solve the reactivity and composability problems, using raw signals directly in enterprise applications introduces architectural entropy.

❌ The "Before": Global Writable Signal Spaghetti

// 1. Global writable signal (shared mutable state)
final authSignal = signal<AuthState>(LoggedOut());

// 2. UI Widgets mutating state directly from anywhere
class LoginButton extends StatelessWidget {
  const LoginButton({super.key});

  @override
  Widget build(BuildContext context) {
    return ElevatedButton(
      onPressed: () async {
        // Direct mutation scattered across UI components
        authSignal.value = Authenticating(); 
        try {
          final user = await api.login();
          authSignal.value = Authenticated(user); 
        } catch (e, st) {
          authSignal.value = AuthError(e, st);
        }
      },
      child: const Text('Login'),
    );
  }
}

The Pain Points in Enterprise Teams:

Uncontrolled Mutation: Any widget, helper function, or background callback can bypass domain rules and overwrite .value.
Lost Traceability: When authSignal transitions to AuthError, which of the 12 UI files triggered it? You have no cause-and-effect audit trail.
Test Leakage: Global signals bleed state across unit test runs unless explicitly reset before every single test case.

🔒 Step 2: Taming Signals with `CubitSignal`

BlocSignal addresses this by encapsulating signals inside structured state containers. The simplest container is CubitSignal<StateType>.

✅ The "After": Encapsulated & Scoped Reactivity

// 1. Business Logic Encapsulated inside CubitSignal
class AuthCubit extends CubitSignal<AuthState> {
  AuthCubit(this._api) : super(LoggedOut());
  final ApiService _api;

  Future<void> login() async {
    // Restricted internal mutation via emit()
    emit(Authenticating());
    try {
      final user = await _api.login();
      emit(Authenticated(user));
    } catch (e, st) {
      emit(AuthError(e, st));
    }
  }
}

// 2. UI triggers intent; Cubit encapsulates mutation & scope
class LoginButton extends StatelessWidget {
  const LoginButton({super.key});

  @override
  Widget build(BuildContext context) {
    return ElevatedButton(
      onPressed: () => context.read<AuthCubit>().login(),
      child: const Text('Login'),
    );
  }
}

Why This Tames the Chaos:

Single-Direction Data Flow: UI widgets call methods (authCubit.login()); state mutations (emit()) are strictly internal and private to AuthCubit.
Scoped Lifecycle: Provided via BlocSignalProvider and automatically disposed (close()) when unmounted.
Universal Observability: Every state transition automatically triggers BlocSignalObserver for centralized logging and OpenTelemetry tracing (otel_bloc_signals).

🚀 Step 3: Elevating to BLoC: Dispatch Rigor & Event Hierarchies

For complex applications, direct method dispatches (cubit.method()) are not enough. Enterprise software requires reified event dispatches (bloc.add(Event())) for event sourcing, audit logging, and concurrency control.

BlocSignal brings full BLoC dispatch rigor to Signals—enhanced by Dart 3 sealed classes and pattern matching.

Sealed Class Event Hierarchies

Rather than registering dozens of repetitive event handlers, define expressible event sub-hierarchies:

// 1. Sealed Event Hierarchy
sealed class PaymentEvent {}

sealed class PaymentErrorEvent extends PaymentEvent {
  final String message;
  const PaymentErrorEvent(this.message);
}

class NetworkErrorEvent extends PaymentErrorEvent {
  final int statusCode;
  const NetworkErrorEvent(this.statusCode, super.message);
}

class CardDeclinedEvent extends PaymentErrorEvent {
  final String cardLastFour;
  const CardDeclinedEvent(this.cardLastFour, super.message);
}

// 2. Catch-All Parent Event Handler in PaymentBloc
class PaymentBloc extends BlocSignal<PaymentEvent, PaymentState> {
  PaymentBloc() : super(const PaymentInitial()) {
    // Single handler for all PaymentErrorEvents!
    on<PaymentErrorEvent>((event, emit) {
      // Dart 3 pattern matching & destructuring
      switch (event) {
        case NetworkErrorEvent(:final statusCode, :final message):
          emit(PaymentState.failed('HTTP $statusCode: $message'));
        case CardDeclinedEvent(:final cardLastFour):
          emit(PaymentState.failed('Card ending in $cardLastFour was declined.'));
      }
    });
  }
}

Benefits of Reified Event Hierarchies:

Exhaustive Pattern Matching: Dart 3 enforces compile-time exhaustiveness checking over sealed event types.
Auditability: Every add(Event) dispatches a discrete, serializable event object through onEvent and onTransition for full cause-and-effect tracing.
Streamless Event Concurrency: Control execution using droppable(), sequential(), restartable(), or custom Mutex locks—without Rx streams or microtask allocation overhead.

⚡ Step 4: The Secret Sauce: Synchronous Graph Propagation

In classic package:bloc, state updates travel over asynchronous Stream microtask queues. Calling emit() inside a handler enqueues a microtask tick before downstream widgets re-render.

In BlocSignal, the underlying state engine uses Signals:

emit(newState) ──(Synchronous)──> Signal.value = newState ──(Immediate)──> SignalBuilder.markNeedsBuild()

When you call emit(newState) in BlocSignal:

The underlying signal value is updated synchronously in the exact same call frame.
Downstream computed() derivations, effect() callbacks, and SignalBuilder elements evaluate immediately.
Control returns to your code in the exact same frame—giving you 0ms microtask latency.
Flutter consolidates multiple markNeedsBuild() triggers into a single clean frame render at the end of the frame boundary.

🛠️ Step 5: Enterprise Superpowers Out of the Box

Because BlocSignalBase maintains a unified architectural contract, you get enterprise superpowers across Flutter and Jaspr Web (blocsignal.dev):

Feature	Package	Description
OpenTelemetry Spans	`bloc_signals_otel`	Automatically maps events, transitions, and errors into W3C OpenTelemetry trace spans with leak-safe bounded maps.
State Hydration	`bloc_signals_hydrate`	Persists state synchronously to `localStorage` / disk so app restarts render hydrated data on frame 1 without UI flicker.
Undo / Redo History	`bloc_signals_replay`	Wraps containers with `ReplayCubitMixin` for instant time-travel state rollback in forms, canvases, and text editors.
Jaspr Web Parity	`bloc_signals_jaspr`	Runs pure Dart state machines on Jaspr web SSR/SSG apps with zero Flutter SDK overhead.

🎯 Summary: Best of Both Worlds

You no longer have to choose between BLoC's structural discipline and Signals' lightning performance.

Raw Signals
   │ (Lacks Encapsulation & Dispatch Rigor)
   ▼
BlocSignal
├── BLoC Discipline (Single-direction emit, Event Hierarchies, Observability)
└── Signal Performance (Fine-grained computed graphs, 0ms Synchronous Speed)

By moving from raw Signals to BlocSignal:

You tame reactivity with scoped, testable containers.
You eliminate stream microtask lag with synchronous signal propagation.
You scale enterprise teams with reified event hierarchies, OTEL tracing, and clean architectural boundaries.

📚 Further Reading & Related Articles

Previous Article: Why ValueNotifier Fails at Scale: The Non-Composability Problem (and How Signals Fix It)
Web & Pure Dart Deep Dive: Beyond Flutter: Running BlocSignal State Machines in Pure Dart, Jaspr Web, and CLI Tools
Official Website & Demos: blocsignal.dev
GitHub Repository: RandalSchwartz/BlocSignal

Exploring Form Management Patterns in Flutter with BlocSignal

Randal L. Schwartz — Tue, 04 Aug 2026 23:10:31 +0000

Form management is one of the most frequent daily challenges in modern Flutter development. Whether building a simple login screen, a settings form, or an enterprise multi-step checkout wizard, developers constantly wrestle with a familiar set of questions:

How do I keep input validation reactive without triggering full-screen widget rebuilds?
Should validation error messages live inside my state model, or be evaluated dynamically?
When should I use a simple Cubit vs. a reified Bloc event pipeline?

In this article, we’ll explore how BlocSignal—which bridges traditional BLoC event architecture with Rody Davis’s signals primitives—solves these problems elegantly. We’ll look at the fundamental rule of Primary vs. Derived State, compare three distinct form architectural patterns, and provide a decision matrix to help you pick the right approach for your next Flutter project.

1. Primary vs. Derived State with Signals

Before diving into event dispatching or bloc patterns, let's examine the single biggest source of form bugs in Flutter applications: State Duplication.

The Anti-Pattern: Storing Validation Errors in State

In classic state management implementations, developers often define form state models that look like this:

// ❌ ANTI-PATTERN: Storing derived validation fields in state
class BadLoginFormState {
  final String email;
  final String password;
  final String? emailError;    // ⚠️ Redundant derived state!
  final String? passwordError; // ⚠️ Redundant derived state!
  final bool isValid;          // ⚠️ Redundant derived state!
  final bool isSubmitting;
}

Whenever the email changes, the developer must manually run validation checks, update emailError, recalculate isValid, and call copyWith(...).

This approach creates several problems:

Desynchronization: It is easy to update email but forget to recalculate isValid or reset emailError.
Boilerplate: Every state mutation requires repetitive validation logic scattered across event handlers.
Redundant Rebuilds: Emitting new state objects just to update an error string can trigger unneeded widget renders.

The Solution: Derived State via `computed()` Signals

With BlocSignal, state holds Primary State only—the actual single source of truth:

// ✅ RECOMMENDED: Pure Primary State
@immutable
class LoginFormState {
  const LoginFormState({
    this.email = '',
    this.password = '',
    this.isSubmitting = false,
    this.isSuccess = false,
  });

  final String email;
  final String password;
  final bool isSubmitting;
  final bool isSuccess;
}

Validation logic is defined outside the state class as reactive computed() signals directly inside your CubitSignal or BlocSignal:

class LoginFormBloc extends BlocSignal<LoginFormEvent, LoginFormState> {
  LoginFormBloc() : super(initialState: const LoginFormState());

  /// Derived Signal: Evaluates email error lazily & reactively
  late final ReadonlySignal<String?> emailError = computed(() {
    final email = stateValue.email;
    if (email.isEmpty) return null;
    if (!email.contains('@') || !email.contains('.')) {
      return 'Please enter a valid email address';
    }
    return null;
  });

  /// Derived Signal: Evaluates password error lazily & reactively
  late final ReadonlySignal<String?> passwordError = computed(() {
    final pass = stateValue.password;
    if (pass.isEmpty) return null;
    if (pass.length < 6) return 'Password must be at least 6 characters';
    return null;
  });

  /// Derived Signal: Overall form validity
  late final ReadonlySignal<bool> isValid = computed(() {
    final s = stateValue;
    return s.email.isNotEmpty &&
        s.password.isNotEmpty &&
        emailError.value == null &&
        passwordError.value == null;
  });
}

💡 Production Tip: The basic string checks shown in these educational snippets serve as simple examples. In production applications, use a dedicated validation package such as email_validator (EmailValidator.validate(email)) for full RFC-compliant email verification.

Why This is a Game-Changer

Lazy & Memoized: computed() signals recalculate only when stateValue.email or stateValue.password changes. If other fields change (for example, isSubmitting), the computed value is cached without running regex or validation logic.
Synchronous & Zero-Lag: Unlike Rx Streams running on microtask queues, signal updates propagate synchronously in the exact same frame. Keystrokes instantly update field error hints with 0ms lag.
Impossible to Desynchronize: isValid is mathematically guaranteed to match the true state of emailError and passwordError.

2. Pattern Comparison: 3 Ways to Structure Forms

Depending on your form’s complexity, BlocSignal supports three distinct architectural patterns. Let me show you how each pattern looks in practice.

Pattern A: `CubitSignal` (Direct & Pragmatic)

For standard CRUD screens, dialog inputs, or simple login forms, CubitSignal offers the lowest ceremony. The UI invokes imperative cubit methods directly without declaring separate event classes.

class LoginFormCubit extends CubitSignal<LoginFormState> {
  LoginFormCubit() : super(const LoginFormState());

  late final ReadonlySignal<String?> emailError = computed(() {
    final email = stateValue.email;
    if (email.isEmpty) return null;
    return email.contains('@') ? null : 'Invalid email format';
  });

  late final ReadonlySignal<bool> isValid = computed(() =>
    stateValue.email.isNotEmpty &&
    stateValue.password.length >= 6 &&
    emailError.value == null
  );

  void emailChanged(String email) {
    emit(stateValue.copyWith(email: email, isSuccess: false));
  }

  void passwordChanged(String password) {
    emit(stateValue.copyWith(password: password, isSuccess: false));
  }

  Future<void> submit() async {
    if (!isValid.value) return;
    emit(stateValue.copyWith(isSubmitting: true));
    await Future.delayed(const Duration(seconds: 1)); // Simulate API call
    emit(stateValue.copyWith(isSubmitting: false, isSuccess: true));
  }
}

Flutter UI Integration (Pattern A)

class LoginFormWidget extends StatelessWidget {
  const LoginFormWidget({super.key});

  @override
  Widget build(BuildContext context) {
    final cubit = context.read<LoginFormCubit>();

    return Column(
      children: [
        // Email Input
        BlocSignalBuilder<LoginFormCubit, LoginFormState>(
          builder: (context, state) {
            return TextField(
              decoration: InputDecoration(
                labelText: 'Email',
                errorText: cubit.emailError.value,
              ),
              onChanged: cubit.emailChanged,
            );
          },
        ),

        // Submit Button
        BlocSignalBuilder<LoginFormCubit, LoginFormState>(
          builder: (context, state) {
            if (state.isSubmitting) return const CircularProgressIndicator();
            return ElevatedButton(
              onPressed: cubit.isValid.value ? cubit.submit : null,
              child: const Text('Login'),
            );
          },
        ),
      ],
    );
  }
}

Pros: Zero event boilerplate, clean API, fastest to write.
Best for: Standard form screens, dialogs, local settings inputs.

Pattern B: `BlocSignal` with Pure Reducers (`(state, event) => newState`)

When building enterprise applications, multi-step checkout wizards, or features requiring event-sourcing and audit logging, reified events (bloc.add(Event())) are essential.

Dart 3 pattern matching allows you to process all form events inside a single on<FormEvent> handler as a pure state reducer:

sealed class FormEvent { const FormEvent(); }
final class EmailChanged extends FormEvent { const EmailChanged(this.email); final String email; }
final class PasswordChanged extends FormEvent { const PasswordChanged(this.password); final String password; }
final class FormSubmitted extends FormEvent { const FormSubmitted(); }

class ReducerFormBloc extends BlocSignal<FormEvent, LoginFormState> {
  ReducerFormBloc() : super(initialState: const LoginFormState()) {
    on<FormEvent>((event, emit) async {
      final nextState = switch (event) {
        EmailChanged(:final email) => stateValue.copyWith(email: email),
        PasswordChanged(:final password) => stateValue.copyWith(password: password),
        FormSubmitted() => await _handleSubmission(),
      };
      emit(nextState);
    });
  }

  late final ReadonlySignal<String?> emailError = computed(() =>
    stateValue.email.contains('@') ? null : 'Invalid email'
  );

  late final ReadonlySignal<bool> isValid = computed(() =>
    stateValue.email.isNotEmpty && stateValue.password.length >= 6
  );

  Future<LoginFormState> _handleSubmission() async {
    if (!isValid.value) return stateValue;
    // Perform async submission work...
    await Future.delayed(const Duration(milliseconds: 800));
    return stateValue.copyWith(isSubmitting: false, isSuccess: true);
  }
}

Pros: Pure functional transitions, 100% event traceability (onEvent + onTransition) for DevTools and OpenTelemetry (bloc_signals_otel), no scattered emit() side-effects.
Best for: Multi-step forms, wizards, payment flows, compliance/analytics-heavy apps.

Pattern C: Classic Class-per-Event with Concurrency Transformers

Some forms require time-based event transformation—such as debouncing asynchronous server availability checks (for example, "Is username taken?") or dropping duplicate submit taps (droppable()).

BlocSignal supports streamless event concurrency transformers using pure Dart higher-order functions:

class AdvancedFormBloc extends BlocSignal<FormEvent, LoginFormState> {
  AdvancedFormBloc() : super(initialState: const LoginFormState()) {
    // Register individual handlers with custom concurrency transformers
    on<EmailChanged>(_onEmailChanged, transformer: debounce(const Duration(milliseconds: 300)));
    on<FormSubmitted>(_onSubmitted, transformer: droppable());
  }

  late final ReadonlySignal<String?> emailError = computed(() =>
    stateValue.email.contains('@') ? null : 'Invalid email'
  );

  late final ReadonlySignal<bool> isValid = computed(() =>
    stateValue.email.isNotEmpty && emailError.value == null
  );

  void _onEmailChanged(EmailChanged event, void Function(LoginFormState) emit) {
    emit(stateValue.copyWith(email: event.email));
  }

  Future<void> _onSubmitted(FormSubmitted event, void Function(LoginFormState) emit) async {
    if (!isValid.value) return;
    emit(stateValue.copyWith(isSubmitting: true));
    await Future.delayed(const Duration(milliseconds: 1000));
    emit(stateValue.copyWith(isSubmitting: false, isSuccess: true));
  }
}

Pros: Built-in protection against double-submits (droppable()), automatic debouncing for server calls (debounce()), and zero-stream memory allocations.
Best for: Forms with real-time API validation hooks or rapid input debouncing.

3. Decision Matrix: Choosing the Right Pattern

Here is a quick cheat sheet to help you choose the right form management pattern for your Flutter application:

Feature / Requirement	Pattern A (`CubitSignal`)	Pattern B (Pure Reducers)	Pattern C (Concurrency Handlers)
Boilerplate & Ceremony	Lowest ⚡	Medium 🛠️	Higher 📦
State Reducer Style	Direct Methods	Pure `switch (event)`	Dedicated Handlers
Event Audit / Telemetry	State-only	✅ 100% Traceable	✅ 100% Traceable
Event Concurrency Transformers	Manual Timers	Manual Timers	✅ Built-in (`droppable`, `debounce`)
Recommended Use Case	Standard CRUD & Dialogs	Multi-step Wizards & Enterprise	Async API Validation Forms

Summary

BlocSignal brings together the best of both worlds for Flutter form management:

Primary vs. Derived State Separation: Keep state models minimal and leverage computed() signals for instant, memoized validation without out-of-sync bugs.
Synchronous Reactivity: Form validations calculate synchronously, ensuring frame-perfect responsiveness on user keystrokes.
Flexible Architectural Choices: Pick CubitSignal for low ceremony, Pure Reducer BlocSignal for event auditing, or Concurrency Transformers for complex async input flows.

Happy coding with BlocSignal! 🚀

Resources & Open Source Code

📦 BlocSignal Monorepo: GitHub - RandalSchwartz/BlocSignal
💡 Form Validation Example: examples/flutter_form_validation

Porting 16 BLoC & Signal Benchmark Apps to BlocSignal: Elevating Flutter UX & DX

Randal L. Schwartz — Sun, 02 Aug 2026 18:21:58 +0000

🚀 Ported Example Benchmark Suite Live on `blocsignal.dev`!

If you’ve been evaluating BlocSignal—the monorepo package bridging the predictable event-driven BLoC architecture with Rody Davis's reactive signals v7 primitives—we’ve got something big to share.

We just launched a dedicated Ported Example Suite containing 16 full-featured, runnable benchmark applications adapted directly from the official felangel/bloc (10 apps) and rodydavis/signals.dart (6 apps) example repositories.

🌐 Explore the Live Benchmark Suite: https://blocsignal.dev/ported-examples

💡 Why Port These Benchmark Apps?

State management benchmarks are best understood through real-world applications. By porting these established examples 1-to-1, developers can compare BlocSignal side-by-side with original implementations to see concrete architectural benefits:

1. Synchronous Frame Updates (Better Test DX)

In classic BLoC, state updates propagate asynchronously over microtask streams. In BlocSignal, emit() updates state synchronously on the exact same frame. This eliminates microtask queue latency, making widget building feel instant and allowing unit tests to assert expect(bloc.stateValue, ...) without pumpAndSettle or stream delays.

2. Reactive `computed()` Derivations (Zero Event Plumbing)

In complex apps like Todos or Dynamic Forms, classic BLoC often requires dispatching intermediate filter events or wiring up CombineLatestStream. With BlocSignal, you declare late final ReadonlySignal<List<Todo>> filteredTodos = computed(...) right inside the constructor. When state changes, downstream signals derive updated values reactively and lazily.

3. Streamless Event Concurrency Transformers (Lower Overhead)

Event concurrency transformers (sequential(), droppable(), restartable()) in BlocSignal are implemented as streamless higher-order functions using pure Dart Mutex locks. You get full request-cancellation and debouncing capabilities (e.g. in GitHub Search) with zero RxStream memory allocations.

📦 What's Included in the Suite?

Ports from `felangel/bloc` (10 Applications)

⏱️ flutter_timer — Ticker countdown with pause/resume & automatic teardowns
📝 flutter_todos — Flagship Todo CRUD app with computed reactive filters & stats
🌦️ flutter_weather — Weather search with temperature toggle & cross-cubit theme driving
🔀 flutter_dynamic_form — Cascading vehicle dropdowns (Brand → Model → Trim)
🪄 flutter_wizard — Multi-step registration flow with step validation signals
✅ flutter_form_validation — Synchronous real-time input field validation
⚡ bloc_concurrency_visualizer — Interactive execution timeline for streamless transformers
🔍 github_search — Debounced repository search using restartable()
📋 flutter_complex_list — Multi-selection list, batch deletion & BlocSignalSelector rebuilds
🌊 flutter_bloc_with_stream — Stream interop via StreamBlocSignal & .toStream()

Ports from `rodydavis/signals.dart` (6 Applications)

🧮 eval_calculator — Expression parsing & arithmetic state machine
🎨 flutter_colorband — Reactive RGBA color swatches & slider composition
🔌 get_it_signals — Service locator DI integration with get_it
⏳ flutter_async — Async state handling (AsyncData, AsyncLoading, AsyncError)
🏗️ clean_architecture — 3-tier Presentation / Domain / Data architecture
💾 persist_shared_preferences — State hydration with HydratedCubitSignal

Each card on blocsignal.dev/ported-examples features dual direct links pointing to both our BlocSignal monorepo source code and the original upstream source code on GitHub.

Check out the benchmark suite and let us know what you think! ⭐️

🔗 https://blocsignal.dev/ported-examples

Solving Riverpod’s Family Provider Cache Dilemma with Signals & mapSignal

Randal L. Schwartz — Sun, 02 Aug 2026 01:34:18 +0000

Eliminating Stale Data Silos & Complex Invalidation Loops in Flutter Apps

Key Takeaway: When separate family providers store parameterized network queries as isolated state silos, updating an entity in one subset creates stale data across others. By shifting to a normalized entity store (mapSignal) and reactive projections (computed), cache invalidations, duplicate network calls, and stale relational data disappear completely.

1. The Real-World Dilemma

In a popular Stack Overflow question (#79988023), a developer encountered a common architectural bottleneck when using Riverpod 3 family providers alongside a backend REST API (e.g. FastAPI/Pydantic):

Column 1 (Planned & In Progress)  ---> ref.watch(tasksProvider(Filter([planned, inProgress])))
Column 2 (In Progress & Done)     ---> ref.watch(tasksProvider(Filter([inProgress, done])))

Notice that Task B (inProgress) is displayed in both columns simultaneously.

The Two Core Pain Points

Overlapping Subset Inconsistency:
If a user moves Task B from inProgress to done, calling patchTask(Task B) modifies the entity on the backend. But on the frontend, which family provider should be updated?
- Updating only Column 2 leaves Column 1 showing stale data.
- Calling ref.invalidate(tasksProvider) across all families forces a full re-fetch of every filtered list from the server, causing redundant network traffic and UI flashes.
Stale Relational Data:
Each Task embeds a lastEditor User object (User lastEditor). If user Robert renames himself to Bob, Task A in memory still displays "Robert" because its embedded snapshot is disconnected from user state updates. Refetching every task query just to reflect a single user name change is inefficient and fragile.

2. Root Cause: Parameterized Fetchers as Isolated Silos

The root cause of this problem is not unique to Riverpod—it happens in standard BLoC, Redux, or Provider whenever parameterized fetchers double as local state containers.

[ Family Key: Filter A ]  --->  Stores [ Task A, Task B ]  (Isolated Silo 1)
[ Family Key: Filter B ]  --->  Stores [ Task B, Task C ]  (Isolated Silo 2)

Because Task B exists as two separate, duplicated objects across two isolated provider instances:

Modifying instance B1 inside Silo 1 does not update instance B2 in Silo 2.
Neither provider knows about the other.
The developer is forced to choose between complex multi-provider mutation loops or blunt-force global cache invalidation.

3. The Signal Solution: Normalization + Fine-Grained Reactivity

By shifting from parameterized state silos to a Reactive Signals Architecture (using package:signals and BlocSignal), the problem simplifies dramatically.

Instead of each family provider managing its own list of entities, we establish two core principles:

Normalized Single Source of Truth: All entities live in key-value entity maps (mapSignal).
Derived Projections: Filtered views become lightweight computed signals that derive their lists directly from the normalized store.

                  +-----------------------------------+
                  |   mapSignal<String, Task> tasks   |  <--- Single Source of Truth
                  +-----------------------------------+
                                /       \
                               /         \
   +---------------------------------+  +---------------------------------+
   | computed() Column 1 (Planned/In) |  | computed() Column 2 (In/Done)  |
   +---------------------------------+  +---------------------------------+

4. Unlocking Granular Reactivity with `mapSignal` (`SignalMap`)

A key enabler for this pattern in Dart is mapSignal (SignalMap from package:signals).

Unlike a standard signal<Map<K, V>>({}) where modifying a single entry requires replacing or cloning the entire map object, a mapSignal provides key-level fine-grained reactivity:

import 'package:signals/signals.dart';

// Single normalized entity stores
final tasks = mapSignal<String, Task>({});
final users = mapSignal<String, User>({});

Advantage 1: In-Place Entity Updates with Zero Network Overhead

When patchTask returns the updated Task B (status: TaskStatus.done), you update the normalized store directly:

// Mutating a single key automatically notifies subscribers
tasks['task_b_id'] = updatedTaskB;

What happens next?

tasks triggers reactivity only for task_b_id and collection subscribers.
column1Tasks (computed) automatically re-evaluates and drops Task B (since it is no longer planned or inProgress).
column2Tasks (computed) automatically re-evaluates and retains Task B with its updated done status.
Zero manual family invalidations required.
Zero secondary API requests.

Advantage 2: Effortless Relational Sync (Solving Problem 2)

To handle nested relations cleanly, tasks store foreign keys (lastEditorId) rather than embedded snapshot objects:

class Task {
  final String uuid;
  final TaskStatus status;
  final String lastEditorId; // Foreign key reference

  const Task({
    required this.uuid,
    required this.status,
    required this.lastEditorId,
  });
}

In your UI or View Model, derive the relation reactively:

Widget build(BuildContext context) {
  // Read editor reactively from the normalized user store
  final editor = users[task.lastEditorId];
  return Text('Last edited by: ${editor?.name ?? "Unknown"}');
}

When Robert changes his name to Bob:

users['robert_id'] = User(id: 'robert_id', name: 'Bob');

Result: Every widget across the entire application displaying a task edited by Robert immediately re-renders with "Bob". You don't need to sweep through task lists, write manual cascade listeners, or invalidate query endpoints.

5. Side-by-Side Comparison

Architectural Aspect	Riverpod Family Provider Silos	Normalized Signals (`mapSignal` + `computed`)
State Storage	Fragmented across parameterized family instances	Single normalized entity map (`mapSignal`)
Subset Filtering	Separate async network fetch per family key	Client-side `computed()` projection over single store
Entity Mutations	Must sweep & update all active family parameters	Single key update: `tasks[id] = updatedEntity`
Update Scope	All-or-nothing provider invalidation	Fine-grained dependency tracking down to affected UI elements
Relational Data	Embedded snapshots become stale	Reactive foreign-key lookup (`users[task.lastEditorId]`)
Network Requests	Multiplied per filter combination	Single query populates shared store

6. Code Example: Implementing the Pattern

Defining Models & Normalized Stores

import 'package:signals/signals.dart';

enum TaskStatus { planned, inProgress, done }

class Task {
  final String uuid;
  final TaskStatus status;
  final String lastEditorId;

  const Task({
    required this.uuid,
    required this.status,
    required this.lastEditorId,
  });
}

class User {
  final String id;
  final String name;

  const User({required this.id, required this.name});
}

// 1. Single Source of Truth
final tasks = mapSignal<String, Task>({});
final users = mapSignal<String, User>({});

Creating Reactive Subset Views with `computed`

// 2. Computed Projections for Columns
final column1Tasks = computed(() {
  return tasks.values
      .where((t) => t.status == TaskStatus.planned || t.status == TaskStatus.inProgress)
      .toList();
});

final column2Tasks = computed(() {
  return tasks.values
      .where((t) => t.status == TaskStatus.inProgress || t.status == TaskStatus.done)
      .toList();
});

Performing Updates

// Updating Task B status instantly updates both Column 1 and Column 2 in-memory
void updateTaskStatus(String taskId, TaskStatus newStatus) {
  final current = tasks[taskId];
  if (current != null) {
    tasks[taskId] = Task(
      uuid: current.uuid,
      status: newStatus,
      lastEditorId: current.lastEditorId,
    );
  }
}

// Renaming a user instantly updates every task UI displaying that user
void updateUserName(String userId, String newName) {
  users[userId] = User(id: userId, name: newName);
}

7. Bridge with Existing Ecosystems (`BlocSignal` & Riverpod Interop)

If your app already uses Riverpod or classic BLoC, you don't need to replace your entire framework to leverage this pattern:

Riverpod Interop (bloc_signals_riverpod): Expose the normalized mapSignal or computed projections as Riverpod providers using .toBlocSignal(ref) or signal adapters.
BLoC Interop (BlocSignal): Maintain your event-driven workflow in Cubits/Blocs while backing the internal state with normalized signals (mapSignal), combining predictable event handlers with zero-cost reactivity.

Summary

Cache inconsistency and stale relational snapshots are natural side-effects of treating parameterized network queries as isolated state containers. By separating data storage (normalized mapSignal) from view filtering (computed signals), state management transforms from a web of manual invalidations into an automated, self-updating reactive pipeline.

Layered Architecture in Flutter with BlocSignal: Bringing BLoC Discipline and Signals Speed to CodeWithAndrea’s Pattern

Randal L. Schwartz — Fri, 31 Jul 2026 16:57:16 +0000

Clean, Predictable, and Fine-Grained Reactivity Across All Four Layers of Your Application

Whether you are building a small side project or an enterprise Flutter application, structuring your codebase into clean, decoupled layers is the single best investment you can make for long-term maintainability.

For years, one of the finest reference guides for Flutter architecture has been Andrea Bizzotto’s (CodeWithAndrea.com) classic series on Flutter Application Architecture. It is a masterpiece of pragmatic software design. Whenever developers ask me how to structure large-scale Flutter applications, Andrea’s 4-layer architecture guide—spanning Domain, Data, Application, and Presentation—is the exact resource I point them to.

Originally designed around Riverpod and standard state containers, Andrea's pattern provides a clear separation of concerns. But as Flutter state management has evolved, developers are seeking ways to combine the structural discipline and event traceability of BLoC with the fine-grained, synchronous speed of modern signals.

Enter BlocSignal.

In this article, we adapt Andrea’s proven 4-layer architecture to BlocSignal. We’ll explore how BlocSignal simplifies each layer by replacing microtask queue latency with synchronous frame propagation, eliminating callback spaghetti with declarative computed() dependency graphs, and bringing instant Frame 1 state hydration to offline-first apps.

🏗️ The 4-Layer Architecture Overview

In a clean layered architecture, dependencies point strictly inward toward the Domain layer, while data flows in a clean unidirectional loop:

┌─────────────────────────────────────────────────────────┐
│                   Presentation Layer                    │
│    (Widgets, Screens, CubitSignal / BlocSignal)        │
└────────────────────────────┬────────────────────────────┘
                             │
                             ▼
┌─────────────────────────────────────────────────────────┐
│                    Application Layer                    │
│      (Service Classes, Derived computed() Signals)      │
└────────────────────────────┬────────────────────────────┘
                             │
                             ▼
┌─────────────────────────────────────────────────────────┐
│                       Data Layer                        │
│   (Repositories, Data Sources, Hydrated Storage)        │
└────────────────────────────┬────────────────────────────┘
                             │
                             ▼
┌─────────────────────────────────────────────────────────┐
│                      Domain Layer                       │
│    (Entities, Value Objects, AsyncState<T>, Rules)      │
└────────────────────────────┴────────────────────────────┘

Each layer has a single, well-defined responsibility:

Domain Layer: Pure Dart entities, immutable models, and asynchronous state representations (AsyncState<T>).
Data Layer: Repositories, API data sources, and local persistent caching (bloc_signals_hydrate).
Application Layer: Service classes coordinating multi-repository transactions and reactive computed() / futureSignal() business logic.
Presentation Layer: State controllers (CubitSignal/BlocSignal) and fine-grained Flutter UI widgets (BlocSignalBuilder, signal.watch(), context.select()).

Let's examine how to build each layer with BlocSignal.

1. The Domain Layer: Pure Entities & Async State

The Domain Layer contains the core business models and data structures of your application. It must remain 100% pure Dart—free from Flutter UI dependencies, HTTP clients, or database drivers.

Modeling Domain Entities

In BlocSignal, state containers automatically de-duplicate emissions when newState == oldState. By implementing proper equality contracts (using standard Dart ==, equatable, or freezed), downstream UI rebuilds and reactive computations are automatically skipped in O(1) time whenever data doesn't change.

// domain/cart_item.dart
import 'package:meta/meta.dart';

@immutable
class CartItem {
  const CartItem({
    required this.id,
    required this.name,
    required this.price,
    required this.quantity,
  });

  final String id;
  final String name;
  final double price;
  final int quantity;

  double get total => price * quantity;

  CartItem copyWith({int? quantity}) {
    return CartItem(
      id: id,
      name: name,
      price: price,
      quantity: quantity ?? this.quantity,
    );
  }

  @override
  bool operator ==(Object other) =>
      identical(this, other) ||
      other is CartItem &&
          runtimeType == other.runtimeType &&
          id == other.id &&
          quantity == other.quantity;

  @override
  int get hashCode => Object.hash(id, quantity);
}

Representing Asynchronous State (`AsyncState<T>`)

When operations involve network requests or database reads, state models need to represent loading, data, and error states cleanly.

BlocSignal provides AsyncState<T> (with sealed variants AsyncData, AsyncLoading, and AsyncError), making async state modeling intuitive for UI layers:

// domain/user_profile.dart
import 'package:bloc_signals/bloc_signals.dart';

typedef UserProfileState = AsyncState<UserProfile>;

class UserProfile {
  const UserProfile({
    required this.id,
    required this.email,
    required this.name,
  });

  final String id;
  final String email;
  final String name;
}

2. The Data Layer: Repositories & Instant Hydration

The Data Layer is responsible for fetching, storing, and persisting data from external sources (REST APIs, GraphQL, Firebase, SQLite).

Repositories

Repositories hide network or database complexities behind clean interfaces:

// data/auth_repository.dart
import '../domain/user_profile.dart';

abstract class AuthRepository {
  Future<UserProfile> fetchCurrentUser();
  Future<void> signOut();
}

class ApiAuthRepository implements AuthRepository {
  @override
  Future<UserProfile> fetchCurrentUser() async {
    // Simulated REST API fetch
    await Future<void>.delayed(const Duration(milliseconds: 500));
    return const UserProfile(
      id: 'usr_101',
      email: 'alex@example.com',
      name: 'Alex Developer',
    );
  }

  @override
  Future<void> signOut() async {
    await Future<void>.delayed(const Duration(milliseconds: 200));
  }
}

Offline Caching & Frame 1 Hydration (`bloc_signals_hydrate`)

Standard stream-based state containers often suffer from "initial startup flicker" because state restoration runs asynchronously after the first UI render pass.

With bloc_signals_hydrate, HydratedCubitSignal hydrates state synchronously during object construction. Your cached offline data renders on frame 1 without loading spinners or layout jumps.

Eliminating Try/Catch Boilerplate with `futureSignal`

Even inside Cubit async methods, you don't need to write repetitive try / catch / emit(AsyncLoading()) / emit(AsyncData()) blocks.

By creating a futureSignal(), the signal automatically transitions through AsyncLoading → AsyncData or AsyncError. Subscribing emit to the futureSignal and returning s.future gives you zero try/catch code while letting UI callers (like pull-to-refresh widgets) await the returned Future:

// data/user_session_cubit.dart
import 'package:bloc_signals/bloc_signals.dart';
import 'package:bloc_signals_hydrate/bloc_signals_hydrate.dart';
import '../domain/user_profile.dart';
import 'auth_repository.dart';

class UserSessionCubit extends HydratedCubitSignal<UserProfileState> {
  UserSessionCubit(this._authRepository) : super(const AsyncLoading());

  final AuthRepository _authRepository;

  Future<UserProfile> loadUser() {
    // 1. futureSignal handles AsyncLoading -> AsyncData / AsyncError automatically
    final s = futureSignal(() => _authRepository.fetchCurrentUser());

    // 2. Subscribe state emissions directly to the futureSignal's AsyncState
    s.subscribe((asyncState) => emit(asyncState));

    // 3. Return s.future so callers (e.g. RefreshIndicator) can await completion!
    return s.future;
  }

  @override
  UserProfileState? fromJson(dynamic json) {
    // Elegant Dart 3 map pattern matching (zero manual casting required!)
    return switch (json) {
      {
        'id': String id,
        'email': String email,
        'name': String name,
      } => AsyncData(UserProfile(id: id, email: email, name: name)),
      _ => null,
    };
  }

  @override
  dynamic toJson(UserProfileState state) {
    return switch (state) {
      AsyncData(:final value) => {
          'id': value.id,
          'email': value.email,
          'name': value.name,
        },
      _ => null,
    };
  }
}

3. The Application Layer: Services & Declarative `computed()` Signals

The Application Layer (Service Layer) coordinates multi-repository transactions and encapsulates cross-cutting business rules.

Eliminating Manual Callback Spaghetti with `computed()`

In traditional architectures, service classes require manual listener subscriptions, stream transformers, or manual disposal teardowns to keep multi-repository states in sync.

In BlocSignal, services leverage fine-grained computed() signals declared cleanly as late final properties. Derived values calculate lazily and update automatically with zero manual listener management:

// application/checkout_service.dart
import 'package:bloc_signals/bloc_signals.dart';
import '../domain/cart_item.dart';
import '../domain/user_profile.dart';
import '../data/user_session_cubit.dart';

class CheckoutService {
  CheckoutService({
    required this.cartItemsSignal,
    required this.userSessionCubit,
  });

  final ReadonlySignal<List<CartItem>> cartItemsSignal;
  final UserSessionCubit userSessionCubit;

  // Declarative inline computed signals across multiple layers
  late final subtotalSignal = computed(() {
    final items = cartItemsSignal.value;
    return items.fold<double>(0, (sum, item) => sum + item.total);
  });

  late final taxSignal = computed(() {
    // 8% tax applied to subtotal
    return subtotalSignal.value * 0.08;
  });

  late final grandTotalSignal = computed(() {
    return subtotalSignal.value + taxSignal.value;
  });

  late final isEligibleForCheckoutSignal = computed(() {
    final hasItems = cartItemsSignal.value.isNotEmpty;
    final isAuthenticated = userSessionCubit.stateValue is AsyncData<UserProfile>;
    return hasItems && isAuthenticated;
  });
}

💡 Why is no dispose() method needed?
In classic Rx streams or ValueNotifier, calling .listen() or .addListener() inside a service creates permanent subscription links that leak memory unless manually cancelled via a dispose() method.

Signals work differently: a computed() signal is lazy and self-tearing-down. It only subscribes to its upstream dependencies (cartItemsSignal, userSessionCubit.state) while downstream UI widgets are actively watching it. The moment widgets unmount and subscriber counts hit zero, computed() automatically detaches its listeners from upstream sources. No dispose(), no StreamSubscription.cancel(), and zero memory leaks.

4. The Presentation Layer: Controllers & Surgical UI Rebuilds

The Presentation Layer consists of state controllers (CubitSignal or BlocSignal) and Flutter UI widgets.

Choosing Between `CubitSignal` and `BlocSignal`

CubitSignal: Ideal for direct method-driven state updates (e.g., cartCubit.addItem(...)).
BlocSignal: Ideal for complex event-driven workflows requiring streamless event transformers (droppable(), sequential(), restartable(), or custom Mutex locks).

// presentation/cart_cubit.dart
import 'package:bloc_signals/bloc_signals.dart';
import '../domain/cart_item.dart';

class CartCubit extends CubitSignal<List<CartItem>> {
  CartCubit() : super(const []);

  void addItem(CartItem item) {
    final existingIndex = stateValue.indexWhere((i) => i.id == item.id);
    if (existingIndex >= 0) {
      final updated = List<CartItem>.from(stateValue);
      final current = updated[existingIndex];
      updated[existingIndex] = current.copyWith(quantity: current.quantity + 1);
      emit(updated);
    } else {
      emit([...stateValue, item]);
    }
  }

  void removeItem(String id) {
    emit(stateValue.where((item) => item.id != id).toList());
  }
}

Automatic Error Routing & Operational Resilience

In BlocSignal, asynchronous event handlers (FutureOr<void>) automatically capture operational runtime exceptions and route them to onError and active telemetry observers (such as OtelBlocSignalObserver or DevToolsBlocSignalObserver). Programmer faults fail fast, while business exceptions transition safely without crashing the UI.

Surgical UI Binding (`signal.watch`)

In Flutter widgets, BlocSignal integrates natively with package:bloc_signals_flutter. Any widget holding a reference to a service, Cubit, or signal (via constructor injection, GetIt, or Riverpod) can simply call signal.watch(context) to subscribe to surgical, fine-grained rebuilds:

// presentation/checkout_screen.dart
import 'package:flutter/material.dart';
import 'package:bloc_signals_flutter/bloc_signals_flutter.dart';
import '../application/checkout_service.dart';
import 'cart_cubit.dart';

class CheckoutSummaryWidget extends StatelessWidget {
  const CheckoutSummaryWidget({
    super.key,
    required this.cartCubit,
    required this.checkoutService,
  });

  final CartCubit cartCubit;
  final CheckoutService checkoutService;

  @override
  Widget build(BuildContext context) {
    // 1. Watch CartCubit state signal directly (no InheritedWidget lookup needed!)
    final cartItems = cartCubit.state.watch(context);
    final cartItemCount = cartItems.fold<int>(0, (sum, i) => sum + i.quantity);

    // 2. Watch computed signals from CheckoutService
    final grandTotal = checkoutService.grandTotalSignal.watch(context);
    final isEligible = checkoutService.isEligibleForCheckoutSignal.watch(context);

    return Column(
      children: [
        Text(
          'Total ($cartItemCount items): \$${grandTotal.toStringAsFixed(2)}',
          style: Theme.of(context).textTheme.headlineMedium,
        ),
        const SizedBox(height: 16),
        ElevatedButton(
          onPressed: isEligible ? () => _processOrder(context) : null,
          child: const Text('Complete Purchase'),
        ),
      ],
    );
  }

  void _processOrder(BuildContext context) {
    ScaffoldMessenger.of(context).showSnackBar(
      const SnackBar(content: Text('Order placed successfully!')),
    );
  }
}

💡 Dependency Injection Freedom: Why BlocSignalProvider is Optional
In classic BLoC or package:provider, widgets must look up state containers from the BuildContext tree using InheritedWidget (BlocProvider.of(context)).

In BlocSignal, because signals manage their own fine-grained subscriptions internally, any widget holding a reference to a signal or service (via constructor injection, GetIt, or Riverpod) can simply call signal.watch(context). You are free to use constructor passing, service locators, or BlocSignalProvider—the framework never forces a rigid UI tree setup on you.

5. Testing Each Layer Deterministically

One of the greatest benefits of synchronous signal propagation is deterministic unit testing.

In stream-based BLoCs, testing asynchronous microtask queues requires await pump() or delayed stream draining. In BlocSignal, state propagation is synchronous. Combined with package:bloc_signals_test, unit testing across all 4 layers executes instantly without non-deterministic timing flakiness:

// test/application/checkout_service_test.dart
import 'package:bloc_signals_test/bloc_signals_test.dart';
import 'package:flutter_test/flutter_test.dart';
import 'package:bloc_signals/bloc_signals.dart';
import '../../data/user_session_cubit.dart';
import '../../domain/cart_item.dart';
import '../../application/checkout_service.dart';

void main() {
  group('CheckoutService Layer Integration Tests', () {
    late CartCubit cartCubit;
    late UserSessionCubit userSessionCubit;
    late CheckoutService checkoutService;

    setUp(() {
      cartCubit = CartCubit();
      userSessionCubit = UserSessionCubit(MockAuthRepository());
      checkoutService = CheckoutService(
        cartItemsSignal: cartCubit.state,
        userSessionCubit: userSessionCubit,
      );
    });

    tearDown(() async {
      await cartCubit.close();
      await userSessionCubit.close();
    });

    test('calculates subtotal, tax, and grand total synchronously on item addition', () {
      expect(checkoutService.subtotalSignal.value, equals(0.0));

      cartCubit.addItem(const CartItem(
        id: 'p1',
        name: 'Dart T-Shirt',
        price: 20.0,
        quantity: 2,
      ));

      // Synchronous assertions—no await pump() required!
      expect(checkoutService.subtotalSignal.value, equals(40.0));
      expect(checkoutService.taxSignal.value, equals(3.20));
      expect(checkoutService.grandTotalSignal.value, equals(43.20));
    });
  });
}

🎯 Summary & Key Takeaways

Adapting Andrea Bizzotto’s 4-Layer Architecture to BlocSignal gives you the best of both worlds:

Domain Layer: Clean, pure Dart models with O(1) equality de-duplication and expressive AsyncState<T> modeling.
Data Layer: Instant Frame 1 offline hydration via bloc_signals_hydrate with zero startup flicker.
Application Layer: Declarative, leak-free business logic using computed() and futureSignal() across multiple repositories with zero try/catch or teardown boilerplate.
Presentation Layer: BLoC event discipline with fine-grained UI rebuilds via signal.watch()—with zero BlocSignalProvider or BuildContext requirements!
Testing: Instant, 100% deterministic unit testing with bloc_signals_test.

Links & Resources

📖 Read Andrea Bizzotto’s original reference: CodeWithAndrea — Flutter App Architecture
📦 Package on Pub.dev: bloc_signals
🐙 GitHub Repository: RandalSchwartz/BlocSignal

Beyond Flutter: Running BlocSignal State Machines in Pure Dart, Jaspr Web, and CLI Tools

Randal L. Schwartz — Tue, 28 Jul 2026 20:13:36 +0000

Universal State Management for Every Dart Platform

For years, developers have associated state management almost exclusively with Flutter UI widgets. While core packages like package:bloc are technically pure Dart, running stream-based state machines in non-UI Dart environments often feels clunky. Handling asynchronous streams (bloc.stream.listen) in CLI tools, Jaspr web apps, or server backends requires managing manual subscriptions and dealing with microtask event queue delays.

Modern Dart is far more than a Flutter UI engine. Dart now powers:

🖥️ CLI Tools & Automation Scripts
🌐 Web Applications via Jaspr (the Dart web framework for SSR & static sites)
☁️ Server-Side Backends via Serverpod or Dart Frog
📦 Shared Domain Libraries & Full-Stack Monorepos

With BlocSignal, running state machines across pure Dart targets becomes effortless. By replacing asynchronous stream pipelines with synchronous, reactive signals, BlocSignal brings 0ms synchronous state reads (.stateValue), declarative computed() composition, and universal DevTools telemetry to every Dart platform!

In this article, we’ll explore how BlocSignal unlocks universal state management across CLI tools, Jaspr web apps, server backends, and Flutter applications with zero code duplication.

🏗️ The Pure Dart Architecture (`package:bloc_signals`)

BlocSignal is designed around strict package separation:

┌─────────────────────────────────────────────────────────────┐
│               bloc_signals (100% Pure Dart)                 │
│  - BlocSignalBase, CubitSignal, BlocSignal                     │
│  - Signal<T>, ReadonlySignal<T>, computed()                   │
│  - Streamless Transformers (droppable, restartable, Mutex)  │
│  - DevTools & Observer Hooks (dart:developer)              │
└──────────────────────────────┬──────────────────────────────┘
                               │
       ┌───────────────────────┴───────────────────────┐
       ▼                                               ▼
bloc_signals_flutter                            bloc_signals_riverpod
(Widget bindings, SignalBuilder,                 (Bidirectional Riverpod
 BlocSignalProvider, context.select)              Interop Adapters)

package:bloc_signals (Core): Has zero dependencies on the Flutter SDK. It compiles natively for Dart VM, Dart Web (dart2js / dart2wasm), and CLI executables.
package:bloc_signals_flutter (Flutter Bindings): Adds optional Flutter UI wrappers (SignalBuilder, BlocSignalProvider, context.select) for Flutter applications.

Because the core engine lives in pure Dart, your business logic, event handlers, and signal graphs can be shared 100% untouched between your server, CLI, web, and mobile targets!

🛠️ Use Case 1: Terminal CLI Tools & Background Workers

Imagine building a CLI deployment tool or background task runner in Dart. You want predictable state transitions, logging observers, and event queuing without needing Flutter UI.

With bloc_signals, you build your state machine directly in pure Dart:

import 'dart:async';
import 'package:bloc_signals/bloc_signals.dart';

// 1. Define Events & State
sealed class DeployEvent {}
class StartDeploy extends DeployEvent {}
class StepCompleted extends DeployEvent { final String step; StepCompleted(this.step); }

class DeployState {
  final String status;
  final List<String> completedSteps;
  const DeployState({this.status = 'Idle', this.completedSteps = const []});
}

// 2. Pure Dart BLoC State Machine
class DeployBloc extends BlocSignal<DeployEvent, DeployState> {
  DeployBloc() : super(const DeployState()) {
    on<StartDeploy>((event, emit) async {
      emit(DeployState(status: 'Running', completedSteps: stateValue.completedSteps));

      await _runStep('Compiling Assets');
      emit(DeployState(status: 'Running', completedSteps: [...stateValue.completedSteps, 'Compiling Assets']));

      await _runStep('Uploading Bundle');
      emit(DeployState(status: 'Finished', completedSteps: [...stateValue.completedSteps, 'Uploading Bundle']));
    });
  }

  Future<void> _runStep(String name) async {
    await Future.delayed(const Duration(milliseconds: 500));
  }
}

// 3. Run in CLI main()
Future<void> main() async {
  // Attach observer for automatic console logging
  BlocSignalObserver.observer = StandardLogObserver();

  final deployer = DeployBloc();

  // Watch state synchronously via signal!
  deployer.state.subscribe((state) {
    print('--> CLI Status Update: ${state.status} (${state.completedSteps.length} steps complete)');
  });

  deployer.add(StartDeploy());
  await Future.delayed(const Duration(seconds: 2));
  await deployer.close();
}

class StandardLogObserver extends BlocSignalObserver {
  @override
  void onTransition(BlocSignalBase bloc, Transition transition) {
    print('[LOG] ${bloc.runtimeType}: ${transition.currentState.status} -> ${transition.nextState.status}');
  }
}

Running dart run bin/deploy.dart executes the BLoC state machine natively with full observer logging—zero Flutter engine required!

🌐 Use Case 2: Web Applications with Jaspr (Dart Web Framework)

Jaspr is the modern Dart web framework that enables server-side rendering (SSR), static site generation (SSG), and web hydration in pure Dart.

Because Jaspr components render HTML DOM elements instead of Flutter Canvas widgets, traditional flutter_bloc widgets cannot be used.

With BlocSignal, because bloc.state is natively a ReadonlySignal<S>, it integrates seamlessly into Jaspr components!

import 'package:jaspr/jaspr.dart';
import 'package:bloc_signals/bloc_signals.dart';

// Shared BLoC used across Web, Server, and Mobile!
class CounterBloc extends CubitSignal<int> {
  CounterBloc() : super(0);
  void increment() => emit(stateValue + 1);
}

// Jaspr Web Component
class WebCounterView extends StatelessComponent {
  final CounterBloc counter;
  const WebCounterView({required this.counter, super.key});

  @override
  Iterable<Component> build(BuildContext context) sync* {
    // 1. Subscribe to state signal directly in Jaspr!
    yield div([
      h1([text('Count: ${counter.stateValue}')]),
      button(
        onClick: () => counter.increment(),
        [text('Increment')],
      ),
    ]);
  }
}

Your BLoC state machines compile directly to lightweight WebAssembly (dart2wasm) or JavaScript (dart2js) without bringing down the heavy Flutter Web engine canvas!

☁️ Use Case 3: Full-Stack Backends (Serverpod)

When building backend services in Serverpod (or Dart Frog / Shelf), managing complex server session caches, multi-step transaction pipelines, or real-time streaming state containers requires reliable state machines.

BlocSignal brings enterprise BLoC state containers and synchronous state inspections directly to Serverpod endpoints:

import 'package:serverpod/serverpod.dart';
import 'package:bloc_signals/bloc_signals.dart';

class UserSessionEndpoint extends Endpoint {
  final sessionState = SessionManagerCubit();

  Future<bool> validateUserSession(Session session, String userId) async {
    // ⚡️ Synchronous, zero-latency state read on the server!
    if (sessionState.stateValue.activeUserIds.contains(userId)) {
      return true;
    }

    // Trigger state transition logic
    sessionState.registerActiveUser(userId);
    return true;
  }
}

Because .stateValue reads synchronously, your server endpoints inspect state instantly without awaiting microtask event loop ticks, guaranteeing high-throughput request handling.

📡 Universal Observability via `dart:developer`

One of the biggest pain points of building non-UI Dart applications is a lack of developer tools and telemetry.

BlocSignal includes DevToolsBlocSignalObserver, which posts state transition events directly through dart:developer’s SDK protocol (developer.postEvent).

void main() {
  // Enables VM Service DevTools telemetry for ANY Dart process!
  BlocSignalObserver.observer = DevToolsBlocSignalObserver();

  final bloc = MyBusinessBloc();
  // State transitions, errors, and lifecycle events are automatically 
  // streamed to Dart DevTools timeline & VM Service inspect panels!
}

Whether your app runs in the terminal, on a Dart Frog server, in a Jaspr web browser, or inside a Flutter iOS/Android app, the exact same DevTools inspector and event timeline works everywhere!

📊 Feature Matrix: Classic Stream BLoC vs. Universal `BlocSignal`

Feature / Capability	Classic Stream BLoC (`package:bloc`)	Universal `BlocSignal`
State Primitive	Asynchronous Stream (`bloc.stream`)	Synchronous `ReadonlySignal<S>` (`bloc.state`)
State Read Latency	Asynchronous Microtask Queue	Synchronous 0ms Read (`.stateValue`)
Derived Composition	Stream Transformers / RxDart	Declarative `computed()` Signals
Jaspr Web & HTML DOM	Manual stream subscriptions in components	Native Signal DOM Bindings
Serverpod Endpoints	Async stream listeners / future ticks	Synchronous 0ms `.stateValue` Reads
DevTools Telemetry	Basic print logs / observers	Universal `dart:developer` VM Service Events
De-duplication	Manual `distinct()` / Equatable	Automatic `==` Signal De-duplication

🎯 Conclusion

State management shouldn't be trapped inside UI widget trees or restricted by asynchronous stream event loops.

By grounding BLoC state containers on pure Dart signals, BlocSignal empowers you to write your business logic once and deploy it seamlessly across full-stack Dart applications:

🖥️ CLI Tools: Clean event observers and terminal state machines.
🌐 Jaspr Web: Native HTML DOM rendering with WASM compilation.
☁️ Serverpod Backends: Synchronous 0ms state reads for high-throughput APIs.
📱 Flutter Mobile/Desktop: Rich UI widget bindings with zero boilerplate.

🔗 Explore the Ecosystem

📦 bloc_signals on pub.dev: pub.dev/packages/bloc_signals
🌐 Jaspr Web Framework: jaspr.site
🐙 GitHub Repository: github.com/RandalSchwartz/BlocSignal

Why ValueNotifier Fails at Scale: The Non-Composability Problem (and How Signals Fix It)

Randal L. Schwartz — Tue, 28 Jul 2026 16:14:00 +0000

From Listener Spaghetti to Declarative Reactive Composition

When Flutter developers start building applications, ValueNotifier<T> and ValueListenableBuilder often seem like the perfect lightweight solution. Built directly into the Flutter SDK, ValueNotifier holds a single piece of data, notifies listeners when updated, and requires zero third-party dependencies.

For simple isolated state—like toggling a switch or incrementing a counter—ValueNotifier works fine.

💡 The Pure Dart Limitation: Because ValueNotifier and ValueListenable are defined inside package:flutter/foundation.dart, they are tightly coupled to the Flutter SDK. For pure Dart projects (CLI tools, server backends like Dart Frog, or Jaspr web applications), ValueNotifier is completely unavailable. Signals and bloc_signals, by contrast, are pure Dart primitives that run anywhere Dart runs!

However, as applications grow beyond trivial counter demos, developers inevitably run into a major architectural brick wall: ValueNotifier is fundamentally non-composable.

In this article, we’ll analyze why ValueNotifier fails as application complexity scales, how reactive signals solve the non-composability problem at first principles, and how BlocSignal combines signal speed with enterprise BLoC discipline.

🛑 Why `ValueNotifier` Fails at Scale

The moment your UI state depends on more than one piece of data, ValueNotifier starts showing its structural flaws.

1. Callback Spaghetti & Manual Listener Wiring

Suppose you have a user profile form with firstNameNotifier and lastNameNotifier, and you want to compute a derived fullName or isValid property.

Because ValueNotifier cannot observe other notifiers automatically, you must manually wire up listener callbacks:

class ProfileController {
  final firstNameNotifier = ValueNotifier<String>('');
  final lastNameNotifier = ValueNotifier<String>('');
  final fullNameNotifier = ValueNotifier<String>('');

  ProfileController() {
    // Manual wiring required for every single dependency!
    firstNameNotifier.addListener(_updateFullName);
    lastNameNotifier.addListener(_updateFullName);
  }

  void _updateFullName() {
    fullNameNotifier.value = '${firstNameNotifier.value} ${lastNameNotifier.value}';
  }
}

Notice what happened here:

You had to manually write helper methods (_updateFullName) to bridge data updates.
You had to manually attach addListener calls for every dependent field.
As dependencies grow (N fields feeding into M derived properties), the boilerplate grows quadratically (O(N × M)), quickly degrading into fragile callback spaghetti.

2. The Memory Leak Trap

ValueNotifier maintains an internal list of callback listeners using strong references. If you attach a listener callback, you MUST manually remove it when the controller or widget is disposed:

void dispose() {
  // Forget any of these, and your objects leak in memory!
  firstNameNotifier.removeListener(_updateFullName);
  lastNameNotifier.removeListener(_updateFullName);
  firstNameNotifier.dispose();
  lastNameNotifier.dispose();
  fullNameNotifier.dispose();
}

Forgetting even a single removeListener call leaves an active callback reference in memory, preventing garbage collection and creating insidious, hard-to-trace memory leaks in production.

3. Nested `ValueListenableBuilder` Pyramids of Doom

When consuming multiple ValueNotifiers in the Flutter UI layer, standard widgets force deep nesting:

// ❌ Nested builder pyramid of doom!
ValueListenableBuilder<String>(
  valueListenable: controller.firstNameNotifier,
  builder: (context, firstName, _) {
    return ValueListenableBuilder<String>(
      valueListenable: controller.lastNameNotifier,
      builder: (context, lastName, _) {
        return Text('User: $firstName $lastName');
      },
    );
  },
)

Combining 3 or 4 ValueNotifier fields leads to 4-level deep widget indentation, harming code readability and making refactoring a headache.

⚡️ The Signal Paradigm Shift: Automatic & Declarative Composition

Signals eliminate the root cause of these problems by introducing automatic dynamic dependency tracking and declarative computed state.

In a signals-based architecture:

Signals track dependencies dynamically when their .value is read.
There are no manual addListener or removeListener calls.
Derived state is expressed declaratively using computed().

Declarative Derived State with `computed`

Here is how the exact same derived fullName logic looks with signals:

final firstName = signal('');
final lastName = signal('');

// ✨ 1 line of code! Automatically tracks firstName and lastName!
final fullName = computed(() => '${firstName.value} ${lastName.value}');

Look at how much simpler this is:

Zero Manual Wiring: computed() automatically detects that firstName.value and lastName.value were read during execution and registers them as dependencies.
Zero Memory Leaks: When subscribers unbind or widgets unmount, signal dependency graphs clean themselves up automatically.
Automatic De-duplication: computed() emits only when the calculated string actually changes (==), preventing redundant widget rebuilds.

🔄 Lazy Pull Evaluation vs. Unconditional Push Execution

There is also a profound CPU efficiency difference between ValueNotifier and computed():

ValueNotifier is an Eager Push Model: Updating an upstream notifier forces listener callbacks to execute immediately and unconditionally—even if the derived value is off-screen or no UI component is currently observing it. This wastes CPU cycles on unneeded calculations.
computed() is a Lazy Pull Model: A computed() signal marks itself dirty when dependencies change, but never executes its derivation closure until an active observer actually reads .value. If no widget or listener is observing the computed signal, zero CPU cycles are wasted!

🏗️ Enterprise Rigor with `BlocSignal`

While raw signals excel at reactive state composition, large-scale enterprise applications also need predictable state transition rules, event-driven debugging, and team discipline.

That's where BlocSignal comes in.

BlocSignal bridges Rody Davis’s signals.dart with the BLoC pattern:

bloc.state / cubit.state is natively a ReadonlySignal<S>.
State transitions propagate synchronously in the exact frame emitted.
Derived signals (computed) integrate seamlessly alongside event handlers (on<Event>) or Cubit state methods.

💻 Side-by-Side Code Comparison

Let me compare a complete user profile form controller and UI built with legacy ValueNotifier vs. modern BlocSignal.

❌ Before: Legacy `ValueNotifier` Approach

import 'package:flutter/material.dart';

class LegacyProfileController {
  final firstName = ValueNotifier<String>('');
  final lastName = ValueNotifier<String>('');
  final fullName = ValueNotifier<String>('');

  LegacyProfileController() {
    firstName.addListener(_updateFullName);
    lastName.addListener(_updateFullName);
  }

  void _updateFullName() {
    fullName.value = '${firstName.value} ${lastName.value}'.trim();
  }

  void dispose() {
    firstName.removeListener(_updateFullName);
    lastName.removeListener(_updateFullName);
    firstName.dispose();
    lastName.dispose();
    fullName.dispose();
  }
}

class LegacyProfileView extends StatefulWidget {
  const LegacyProfileView({super.key});

  @override
  State<LegacyProfileView> createState() => _LegacyProfileViewState();
}

class _LegacyProfileViewState extends State<LegacyProfileView> {
  late final LegacyProfileController controller;

  @override
  void initState() {
    super.initState();
    controller = LegacyProfileController();
  }

  @override
  void dispose() {
    controller.dispose();
    super.dispose();
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: ValueListenableBuilder<String>(
        valueListenable: controller.fullName,
        builder: (context, fullName, _) {
          return Text('Full Name: $fullName');
        },
      ),
    );
  }
}

✅ After: Modern `CubitSignal` / `BlocSignal` Approach

import 'package:flutter/material.dart';
import 'package:bloc_signals/bloc_signals.dart';
import 'package:bloc_signals_flutter/bloc_signals_flutter.dart';
import 'package:signals_core/signals_core.dart';

class ProfileState {
  final String firstName;
  final String lastName;

  const ProfileState({this.firstName = '', this.lastName = ''});

  @override
  bool operator ==(Object other) =>
      identical(this, other) ||
      other is ProfileState &&
          runtimeType == other.runtimeType &&
          firstName == other.firstName &&
          lastName == other.lastName;

  @override
  int get hashCode => firstName.hashCode ^ lastName.hashCode;
}

class ProfileCubit extends CubitSignal<ProfileState> {
  ProfileCubit() : super(const ProfileState());

  // ✨ Declarative derived signal computed directly from state!
  late final ReadonlySignal<String> fullName = computed(() {
    return '${stateValue.firstName} ${stateValue.lastName}'.trim();
  });

  void updateFirstName(String first) {
    emit(ProfileState(firstName: first, lastName: stateValue.lastName));
  }

  void updateLastName(String last) {
    emit(ProfileState(firstName: stateValue.firstName, lastName: last));
  }
}

class ModernProfileView extends StatelessWidget {
  const ModernProfileView({super.key});

  @override
  Widget build(BuildContext context) {
    return BlocSignalProvider(
      create: (_) => ProfileCubit(),
      child: Scaffold(
        body: Builder(
          builder: (context) {
            final cubit = context.read<ProfileCubit>();

            // Watch the computed fullName signal directly!
            return SignalBuilder(
              builder: (context) => Text('Full Name: ${cubit.fullName.value}'),
            );
          },
        ),
      ),
    );
  }
}

📊 Architectural Mapping Table

Feature / Metric	Legacy `ValueNotifier`	Modern Signals / `BlocSignal`
Dependency Tracking	Manual (`addListener` / `removeListener`)	Automatic & Dynamic (zero listener code)
Derived State	Manual callback calculation & `notifyListeners`	Declarative `computed()` (1 line of code)
Evaluation Model	Eager Push (executes callbacks unconditionally)	Lazy Pull (evaluates `computed()` only when observed)
Memory Leak Risk	High (missing `removeListener` leaks memory)	Zero (subscribers unbind automatically)
UI Nesting	Deep (`ValueListenableBuilder` pyramids)	Flat (`SignalBuilder`, `context.select`)
State Equality	Manual check in setter	Automatic `==` de-duplication
DevTools & Observers	None built-in	`BlocSignalObserver` & DevTools Telemetry

🎯 Conclusion

ValueNotifier served a valuable purpose in early Flutter versions as a bare-bones primitive, but attempting to scale it across real-world application features leads directly to callback spaghetti, memory leaks, and UI nesting pyramids.

By switching to signal-based reactivity with BlocSignal:

You gain declarative, leak-free state composition with computed().
Your UI code stays clean, flat, and readable.
Your application retains enterprise BLoC event discipline, observer tracing, and DevTools observability.

🔗 Resources & Next Steps

📦 bloc_signals on pub.dev: pub.dev/packages/bloc_signals
🪝 signals on pub.dev: pub.dev/packages/signals
🐙 GitHub Repository: github.com/RandalSchwartz/BlocSignal

Seamless Flutter Hooks Integration with BlocSignal via signals_hooks

Randal L. Schwartz — Mon, 27 Jul 2026 22:37:30 +0000

Zero Glue Code. Streamless Reactivity. Pure Hook Composition.

If you’ve built Flutter applications using flutter_hooks, you know how empowering hook-based composition can be. By replacing boilerplate StatefulWidget lifecycles with declarative hooks like useState, useMemoized, and useEffect, Flutter Hooks makes widget code remarkably concise.

However, when developers tried bridging classic flutter_bloc into a HookWidget, friction quickly emerged. Because classic BLoC states are published asynchronously across Stream pipelines, consuming state or reacting to side-effects required either:

Nesting heavy widget wrappers (BlocBuilder, BlocListener, BlocSelector) inside the build() method of a HookWidget.
Depending on third-party, dedicated glue-code packages (such as flutter_hooks_bloc) that wrapped BLoC streams into custom hooks like useBloc, useBlocBuilder, and useBlocListener.

With BlocSignal, that paradigm changes completely.

💡 The Core Architectural Insight

Unlike classic BLoC, where state updates stream asynchronously through microtask event queues, BlocSignal builds on Rody Davis’s signals.dart primitives.

In BlocSignal:

bloc.state is natively a ReadonlySignal<StateType>.
State transitions propagate synchronously in the exact frame they are emitted.
Equal states are automatically de-duplicated using == equality.

Because bloc.state is already a native ReadonlySignal, BlocSignal does not need a custom flutter_hooks_bloc_signals adapter package!

Instead, any HookWidget can consume, derive, or react to BlocSignal state out-of-the-box using the official signals_hooks package.

🪝 Key Capabilities & Patterns

Let me walk you through how BlocSignal and signals_hooks simplify state management in HookWidget implementations.

1. Direct State Consumption (`useSignalValue` / `useWatch`)

In classic BLoC with Flutter Hooks, subscribing to a BLoC required a useBlocBuilder(bloc) hook or a nested BlocBuilder widget.

With BlocSignal + signals_hooks, bloc.state is simply a signal. You can read and subscribe to it using useSignalValue(bloc.state) or useWatch(bloc.state):

final count = useSignalValue(bloc.state);

Whenever bloc.emit() updates the state, useSignalValue registers a dependency on the hook element and triggers a synchronous rebuild.

2. Streamless Side Effects (`useSignalEffect`)

In classic BLoC, executing one-off side effects (such as showing a SnackBar, triggering navigation, or logging analytics) forced you to wrap your UI in a BlocListener or call useBlocListener.

Because BlocSignal updates synchronously, you can write inline reactive side effects using useSignalEffect:

useSignalEffect(() {
  // Reading `bloc.stateValue` (or `bloc.state.value`) inside the callback
  // automatically registers `bloc.state` as a reactive dependency!
  if (bloc.stateValue > 10) {
    ScaffoldMessenger.of(context).showSnackBar(
      const SnackBar(content: Text('Threshold reached!')),
    );
  }
});

No widget tree nesting required. The effect callback executes synchronously upon transition and automatically unsubscribes when the HookWidget unmounts.

💡 Bonus Tip: BlocSignalBase provides the convenient .stateValue getter (which delegates directly to bloc.state.value). You can use bloc.stateValue inside useSignalEffect, useComputed, or event handlers like emit(stateValue + 1) for clean, concise state access!

3. Fine-Grained Derived Selectors (`useComputed`)

Filtering rebuilds in classic BLoC required setting up BlocSelector<MyBloc, MyState, SelectedType> or calling useBlocSelector.

With BlocSignal + signals_hooks, fine-grained selector logic is written cleanly using useComputed:

final isEven = useComputed(() => bloc.stateValue.isEven);

useComputed creates an inline derived signal. Because signals de-duplicate identical outputs, your widget will only rebuild when count.isEven toggles between true and false — avoiding unnecessary builds when count increments from 2 to 4.

4. Lifecycle Teardown & Scope Safety

In typical production applications, BLoCs are provided upstream in the widget tree using BlocSignalProvider. When consuming a provided BLoC inside a HookWidget, zero creation or teardown boilerplate is needed:

// Provided upstream via BlocSignalProvider — Provider handles lifetime & close() automatically!
final bloc = context.read<CounterBloc>();

Widget-Local BLoC Instances

If a HookWidget happens to own its own local BLoC, you can instantiate and dispose of it using standard Flutter Hooks primitives:

// Create once for the widget's lifetime & close when unmounted
final bloc = useMemoized(() => CounterBloc());
useEffect(() => bloc.close, [bloc]);

💡 Quick Tip: If your app uses many widget-local BLoCs, you can define a simple 3-line helper once in your codebase:
B useCreateBloc<B extends BlocSignalBase>(B Function() builder) {
  final bloc = useMemoized(builder);
  useEffect(() => bloc.close, [bloc]);
  return bloc;
}
This gives you single-line local instantiation (final bloc = useCreateBloc(() => CounterBloc());) without needing an extra third-party package!

💻 Side-by-Side Comparison

Let's compare classic flutter_hooks_bloc with modern BlocSignal + signals_hooks.

❌ Before: Legacy `flutter_hooks_bloc` Glue Code

import 'package:flutter/material.dart';
import 'package:flutter_hooks/flutter_hooks.dart';
import 'package:flutter_hooks_bloc/flutter_hooks_bloc.dart';

class LegacyCounterView extends HookWidget {
  const LegacyCounterView({super.key});

  @override
  Widget build(BuildContext context) {
    // Requires specialized third-party useBloc hook
    final bloc = useBloc<CounterBloc, int>();

    // Requires specialized hook for state rebuilds
    final count = useBlocBuilder(bloc);

    // Requires specialized hook for side effects
    useBlocListener<CounterBloc, int>(bloc, (context, state) {
      if (state > 10) {
        ScaffoldMessenger.of(context).showSnackBar(
          const SnackBar(content: Text('Count is high!')),
        );
      }
    });

    return Scaffold(
      body: Center(child: Text('Count: $count')),
      floatingActionButton: FloatingActionButton(
        onPressed: () => bloc.add(Increment()),
        child: const Icon(Icons.add),
      ),
    );
  }
}

✅ After: Modern `BlocSignal` + `signals_hooks`

import 'package:flutter/material.dart';
import 'package:flutter_hooks/flutter_hooks.dart';
import 'package:signals_hooks/signals_hooks.dart';
import 'package:bloc_signals/bloc_signals.dart';

class ModernCounterView extends HookWidget {
  const ModernCounterView({super.key});

  @override
  Widget build(BuildContext context) {
    // 1. Memoize the BLoC for the widget's entire lifetime & teardown on unmount
    final bloc = useMemoized(() => CounterBloc());
    useEffect(() => bloc.close, [bloc]);

    // 2. Read & watch BLoC state directly as a signal
    final count = useSignalValue(bloc.state);

    // 2. Inline reactive side effects (no listener widget wrapper needed!)
    useSignalEffect(() {
      if (bloc.stateValue > 10) {
        ScaffoldMessenger.of(context).showSnackBar(
          const SnackBar(content: Text('Count is high!')),
        );
      }
    });

    // 3. Inline fine-grained computed selector (no selector widget needed!)
    final isEven = useComputed(() => bloc.stateValue.isEven);

    return Scaffold(
      body: Center(
        child: Text('Count: $count (Even: ${isEven.value})'),
      ),
      floatingActionButton: FloatingActionButton(
        onPressed: () => bloc.add(Increment()),
        child: const Icon(Icons.add),
      ),
    );
  }
}

📊 Architectural Mapping Table

Pattern / Goal	Legacy `flutter_hooks_bloc`	Modern `BlocSignal` + `signals_hooks`	Key Advantage
Accessing BLoC	`useBloc<B, S>()`	`context.read<MyBloc>()` or `useMemoized`	Standard provider read or hook; zero custom BLoC lifecycle package
State Rebuilds	`useBlocBuilder(bloc)`	`useSignalValue(bloc.state)`	Native signal subscription; works with any `ReadonlySignal<S>`
Side Effects	`useBlocListener(bloc, fn)`	`useSignalEffect(() => ...)`	Inlined reactive effect; zero widget tree wrappers
State Selection	`useBlocSelector(bloc, fn)`	`useComputed(() => ...)`	Functional signal derivation with automatic `==` equality filtering
Glue Packages	`flutter_hooks_bloc`	None (`signals_hooks` only)	Zero custom adapter packages required

🎯 Conclusion

By grounding the BLoC pattern on synchronous, reactive signals, BlocSignal harmonizes two of Flutter’s most powerful state management paradigms: the predictable event-driven architecture of BLoC and the clean, functional composition of Flutter Hooks.

You no longer need dedicated glue-code adapter packages or deep widget tree nesting to use BLoC inside HookWidgets. With signals_hooks, your BLoC states, computed selectors, and side effects fit naturally into standard hook workflows.

🔗 Explore More

📦 bloc_signals on pub.dev: pub.dev/packages/bloc_signals
🪝 signals_hooks on pub.dev: pub.dev/packages/signals_hooks
🐙 GitHub Repository: github.com/RandalSchwartz/BlocSignal

Switching Tracks in BlocSignal: The Universal State Switchyard for BLoC, Riverpod, and Provider

Randal L. Schwartz — Mon, 27 Jul 2026 15:37:53 +0000

By Randal L. Schwartz, and a few million TPU cycles

Motto: "With the rigor of Bloc and the flex and speed of Signal"

Why You Don't Have to Tear Up Your Codebase to Enjoy the Speed of Synchronous Signals

If you have followed my talks, articles, or comments in the Flutter community over the years, you know I have been a strong advocate for Riverpod. Riverpod solved many of the fundamental global-state scoping issues inherent in classic InheritedWidget patterns, providing compile-safe dependency injection and clean state isolation.

However, as the Flutter ecosystem evolved toward Riverpod 3, I grew increasingly wary of the direction being pushed: a heavy reliance on mandatory code generation (@riverpod annotations, build_runner, macros). Code generation introduces build-step friction, bloats compile times, and makes debugging generated syntax opaque.

On the other side of the tracks sat BLoC. While I appreciated BLoC's structured, predictable event-to-state machine pattern (on<Event>), I was never a big fan of classic BLoC's reliance on underlying Dart Streams. Streams operate asynchronously via microtask queues—introducing subtle frame-rendering latency—and require extensive stream-transformer ceremony for simple state updates.

Then came Signals (specifically Rody Davis's signals package). Signals brought raw speed, zero microtask overhead, fine-grained composable reactivity, and pure Dart portability.

That realization birthed BlocSignal: combining BLoC's disciplined, enterprise event-state architecture with Signals' synchronous reactivity.

And more importantly, it solved the single biggest pain point in Flutter development: the migration trap.

🚂 The Core Metaphor: "Switching Tracks in BlocSignal"

In Flutter development, choosing a state management tool often feels like choosing a railroad company. If your team built an application on package:provider or flutter_bloc and wants to adopt Riverpod or Signals, traditional wisdom dictates a nightmare: tearing up all your existing tracks and rebuilding your rail lines from scratch.

BlocSignal rejects this all-or-nothing trap. Named after the classic railway block signal—the system that manages train traffic safely to prevent collisions—BlocSignal acts as a central railway switchyard.

  Classic BLoC Line (Streams) ─────────┐
                                       │
  Riverpod Express (Providers) ────────┼──► [ BlocSignal Central Switchyard ] ◄──► Pure Reactive Signals
                                       │
  Provider Local (Listenables) ────────┘

You do not need to abandon your existing rail network or halt traffic. Whether your feature runs on the Riverpod Express, BLoC Stream Line, or Flutter's native ChangeNotifier local track, you can switch tracks synchronously at the BlocSignal switchyard and keep your train moving smoothly!

⚡ The Synchronous Signal Core: Green Lights All the Way

In classic flutter_bloc, state updates flow through StreamController microtask queues:

// Classic BLoC: Asynchronous microtask queue scheduling
emit(newState); // State arrives on the next microtask tick

In BlocSignal, bloc.state is natively a ReadonlySignal<State>. State propagation is 100% synchronous:

// BlocSignal: Synchronous signal graph propagation
emit(newState); // Downstream computeds & UI elements update IN THE EXACT SAME FRAME

Because ReadonlySignal is a lightweight, primitive reactive node, external state objects (Stream, ProviderListenable, ValueListenable) can be adapted into a BlocSignal (or vice-versa) with zero-cost bridge wrappers.

Furthermore, all BlocSignal interop bridges support custom equality comparators (equals: (prev, next) => ...), preserving strict state de-duplication rules across track switches.

Let's walk through the three main rail lines.

🚆 Track 1: BLoC, Redux & Stream Interop (`package:bloc_signals`)

If you have legacy BLoCs, Redux stores, or RxDart observables, you can bridge them onto the BlocSignal switchyard without breaking existing stream subscribers.

Ingesting Streams & Redux

Use StreamBlocSignal to turn any Dart Stream into a BlocSignalBase container:

import 'package:bloc_signals/bloc_signals.dart';

// 1. Adapt a standard Dart Stream / RxDart Observable
final streamCubit = StreamBlocSignal<int>(
  stream: myLegacyStream,
  initialState: 0,
);

// 2. Adapt a Redux Store
final reduxCubit = StreamBlocSignal<AppState>(
  stream: reduxStore.onChange,
  initialState: reduxStore.state,
);

Exporting `BlocSignal` to Stream

Need to feed a legacy StreamBuilder or BlocBuilder? Expose any BlocSignal as a standard Dart stream:

final Stream<MyState> stream = myBlocSignal.toStream();

🚆 Track 2: Riverpod Interop (`package:bloc_signals_riverpod`)

For developers using Riverpod for dependency injection who want to avoid code generation and microtask delays, package:bloc_signals_riverpod provides zero-boilerplate bidirectional adapters.

Ingesting Riverpod Providers (With Automatic Teardown!)

Convert any Riverpod ProviderListenable into a BlocSignal:

import 'package:bloc_signals_riverpod/bloc_signals_riverpod.dart';

// Ingest a Riverpod provider into BlocSignal
// Automatically binds ref.onDispose(bloc.close) under the hood!
final userBloc = userProvider.toBlocSignal(ref);

💡 No Retain Count Leaks: Passing ref (or WidgetRef / ProviderContainer) automatically registers ref.onDispose teardown hooks. When the parent Riverpod container or widget unmounts, the underlying BlocSignal is closed automatically.

Exporting `BlocSignal` to Riverpod

Turn any BlocSignal into a standard Riverpod NotifierProvider:

final NotifierProvider<Notifier<CounterState>, CounterState> riverpodProvider = 
    myCounterBloc.toProvider();

Riverpod 3 `AsyncValue` ↔ Signals `AsyncState` Bridge

Riverpod 3 introduced sealed AsyncValue classes. bloc_signals_riverpod includes seamless conversions:

final AsyncState<UserData> signalsState = riverpodAsyncValue.toAsyncState();
final AsyncValue<UserData> riverpodValue = signalsAsyncState.toAsyncValue();

🚈 Track 3: Flutter `Listenable` & `package:provider` (`package:bloc_signals_flutter`)

Flutter's native ChangeNotifier, ValueNotifier, and package:provider remain heavily used across thousands of codebases.

Ingesting `Listenable` and `ValueNotifier`

Convert any Flutter Listenable directly into a BlocSignalBase:

import 'package:bloc_signals_flutter/bloc_signals_flutter.dart';

// ValueNotifier -> BlocSignal
final countCubit = myValueNotifier.toBlocSignal();

// ChangeNotifier -> BlocSignal
final authCubit = myChangeNotifier.toBlocSignal(
  readState: () => myChangeNotifier.currentUser,
);

Exporting `BlocSignal` to `ValueListenable`

Expose any BlocSignal as a standard Flutter ValueListenable<T>:

final ValueListenable<int> listenable = myBlocSignal.toValueListenable();

// Consume via package:provider's ValueListenableProvider
ValueListenableProvider<int>.value(
  value: listenable,
  child: Consumer<int>(
    builder: (context, count, _) => Text('Count: $count'),
  ),
);

🔄 Multi-Track Routing: Synchronizing Across Ecosystems

Because every adapter maps cleanly to BlocSignalBase, you can route state across multiple track lines in a single, synchronous pipeline!

Example: Provider ➔ `BlocSignal` ➔ Riverpod

Imagine a legacy ChangeNotifier form field that needs to be consumed by a new Riverpod feature:

// 1. Ingest Flutter ChangeNotifier into a BlocSignal Cubit
final formCubit = myChangeNotifier.toBlocSignal(
  readState: () => myChangeNotifier.formValue,
);

// 2. Export the Cubit directly as a Riverpod NotifierProvider
final riverpodFormContainer = formCubit.toProvider();

State changes in myChangeNotifier propagate synchronously through formCubit into Riverpod in the exact same frame, with zero frame lag or microtask queuing!

🤖 AI Agent Skills: Your Automated Signal Operator

One of the most exciting aspects of modern Dart and Flutter development is AI-assisted coding. However, generic AI assistants often generate outdated, deprecated, or incorrect state management patterns.

To solve this, every package in the BlocSignal ecosystem ships with dedicated AI Agent Skills (plugins/bloc-signals/skills/bloc-signals/).

plugins/bloc-signals/skills/bloc-signals/
├── SKILL.md                 # Master agent skill entrypoint
├── architecture.md          # Core synchronous signal graph invariants
├── event_handlers.md        # Concurrency transformers (droppable, sequential)
├── testing.md               # Declarative testing with bloc_signals_test
└── interoperability.md      # Ecosystem bridge matrix & migration recipes

When you use AI coding assistants equipped with these skills (such as Gemini, Antigravity, Claude, Cursor, or Context7), your AI agent acts like an expert signal operator:

Resolves accurate, up-to-date BlocSignal API contracts without hallucination.
Applies correct teardown rules (ref.onDispose, unawaited(super.onEvent(event))).
Generates declarative blocSignalTest suites with 100% line coverage.
Provides instant, step-by-step migration recipes from legacy BLoC or Riverpod codebases.

🎯 Summary & The Interoperability Matrix

State management should serve your project—not lock you into a rigid framework. With BlocSignal, you retain the architectural discipline of BLoC state machines, gain the raw speed of synchronous Signals, and bridge your existing Riverpod or Provider codebases effortlessly.

📋 Cheat-Sheet Interoperability Matrix

Source Paradigm	From Source ➔ `BlocSignal`	From `BlocSignal` ➔ Target	Target Package
BLoC / Stream	`StreamBlocSignal(stream)`	`blocSignal.toStream()`	`bloc_signals`
Redux	`StreamBlocSignal(store.onChange)`	`blocSignal.toStream()`	`bloc_signals`
Riverpod	`provider.toBlocSignal(ref)`	`blocSignal.toProvider()`	`bloc_signals_riverpod`
Provider (Listenable)	`listenable.toBlocSignal()`	`blocSignal.toValueListenable()`	`bloc_signals_flutter`
Riverpod Async	`asyncValue.toAsyncState()`	`asyncState.toAsyncValue()`	`bloc_signals_riverpod`

🚀 Get Started Today

Check out the official open-source packages and AI skills on GitHub:

📦 GitHub Repository: github.com/RandalSchwartz/BlocSignal
🛠️ Core Package: pub.dev/packages/bloc_signals
📱 Flutter UI Package: pub.dev/packages/bloc_signals_flutter
🌊 Riverpod Interop: pub.dev/packages/bloc_signals_riverpod
🧪 Testing Package: pub.dev/packages/bloc_signals_test
🤖 AI Agent Skill Bundle: plugins/bloc-signals/skills/bloc-signals

Stop tearing up your tracks. Step up to the switchyard, switch tracks with BlocSignal, and keep your Flutter trains running on time! 🚂

The Six Flavors of Dependency Injection in Flutter

Randal L. Schwartz — Fri, 24 Jul 2026 18:11:07 +0000

title: "The Six Flavors of Dependency Injection in Flutter"
published: true
description: "Dependency injection isn't just one pattern or package. Here is a breakdown of all six distinct DI mechanisms in Dart & Flutter, from InheritedWidget to compile-time IoC."

tags: flutter, dart, architecture, mobile

Understanding the full spectrum of state location, service retrieval, and IoC in Dart & Flutter

Dependency Injection (DI) is often discussed as if it were a single pattern or package. In Flutter, developers frequently debate get_it vs Provider vs Riverpod as if they are competing for the exact same job.

In reality, Dependency Injection in Flutter exists on a spectrum. There are six distinct "flavors" of dependency injection and service location in Dart and Flutter—ranging from basic compile-time parameters to advanced code-generated IoC containers.

Understanding all six flavors allows you to choose the simplest, safest mechanism for each layer of your application.

Flavor 1: Constructor Injection (Direct Passing)

The simplest and purest form of DI in Dart. Dependencies are passed explicitly through class constructors.

class UserProfileWidget extends StatelessWidget {
  const UserProfileWidget({
    super.key,
    required this.repository,
  });

  final UserRepository repository;

  @override
  Widget build(BuildContext context) {
    return Text(repository.currentUser.name);
  }
}

How it works: Pure Dart object composition.
Pros: 100% compile-time type safe. Zero runtime lookup failures. Effortless unit & widget testing with mocks.
Cons: Can lead to "prop drilling" if deep widget subtrees need to pass dependencies down multiple levels.

Flavor 2: InheritedWidget & Provider (Tree-Based Scoped Context)

Flutter's built-in mechanism for passing data down the widget tree without manual prop drilling. Packages like provider and flutter_bloc build on top of InheritedWidget.

// Providing
BlocProvider<UserBloc>(
  create: (context) => UserBloc(),
  child: const UserProfileWidget(),
);

// Consuming
class UserProfileWidget extends StatelessWidget {
  const UserProfileWidget({super.key});

  @override
  Widget build(BuildContext context) {
    final userBloc = context.read<UserBloc>();
    return Text(userBloc.state.name);
  }
}

How it works: Walks up the Flutter BuildContext element tree at runtime to locate an ancestor matching type T.
Pros: Automatically scopes lifecycles to widget subtrees; cleans up resources when routes pop.
Cons: Subject to runtime ProviderNotFoundException if a widget attempts to read a type not provided in an ancestor scope.

Flavor 3: Service Locator / Registry (`GetIt`)

Decouples dependency lookup completely from Flutter's BuildContext by registering singletons, lazy singletons, or factories in a central global registry.

// Setup / Registration
final getIt = GetIt.instance;

void setupDependencies() {
  getIt.registerSingleton<UserRepository>(UserRepositoryImpl());
}

// Consuming anywhere in UI or logic
class UserProfileWidget extends StatelessWidget {
  const UserProfileWidget({super.key});

  @override
  Widget build(BuildContext context) {
    final repository = getIt<UserRepository>();
    return Text(repository.currentUser.name);
  }
}

How it works: Hash-map registry lookup by Type T.
Pros: Accessible anywhere (inside or outside the widget tree) without BuildContext.
Cons: Runtime lookup failure if a type isn't registered before access; requires discipline in managing global scope lifecycles.

Flavor 4: Top-Level Globals & Static Singletons

Pure Dart global final variables or static class getters. Often overlooked due to traditional OOP anti-global bias, but extremely effective for true app-wide singletons.

// Top-level global final instance
final authService = AuthService();

class LoginButton extends StatelessWidget {
  const LoginButton({super.key});

  @override
  Widget build(BuildContext context) {
    return ElevatedButton(
      onPressed: () => authService.login(),
      child: const Text('Log In'),
    );
  }
}

How it works: Direct top-level Dart memory references.
Pros: Instant, zero-overhead access everywhere. Guaranteed initialization on app start.
Cons: Must be used intentionally; requires @visibleForTesting or reset methods for test isolation.

Flavor 5: Reactive Signal Primitives (`BlocSignal` / `Signals`)

Combines state management with dependency access. Reactive signals allow widgets to subscribe directly to state primitives or blocs without BuildContext lookup overhead.

// Top-level or injected reactive bloc
final counterBloc = CounterBloc();

class CounterView extends StatelessWidget {
  const CounterView({super.key});

  @override
  Widget build(BuildContext context) {
    return SignalBuilder(
      builder: (context, child) => Text('Count: ${counterBloc.state.value}'),
    );
  }
}

How it works: Synchronous reactive signal subscriptions (SignalBuilder).
Pros: Synchronous state updates on the call stack; flexible location (works with globals, constructors, or locators); zero microtask lag.
Cons: Requires using signal-aware UI builders (SignalBuilder).

Flavor 6: Compile-Time Code Generation & IoC (`injectable`, `riverpod`)

Uses Dart code generation (build_runner) to resolve dependency graphs at compile time, combining annotations with type-safe locator generation.

@injectable
class UserRepository {
  UserRepository(this.apiClient);
  final ApiClient apiClient;
}

@InjectableInit()
void configureDependencies() => getIt.init();

How it works: Static analysis during build time generates explicit registration code.
Pros: Catches missing dependency graph links during build_runner; automates complex dependency wiring.
Cons: Requires code generation build step (build_runner); longer build times.

Summary Comparison Matrix

Flavor	Location Mechanism	`BuildContext` Required?	Type Safety	Best Used For
1. Constructor Injection	Parameter passing	❌ No	100% Compile-Time	Child widgets, reusable UI components
2. InheritedWidget / Provider	Tree element traversal	✅ Yes	Runtime checked	Route/screen-scoped UI state
3. Service Locator (`GetIt`)	Central Type Registry	❌ No	Runtime checked	Repositories, APIs, services
4. Top-Level Globals	Global `final` variable	❌ No	100% Compile-Time	App-wide singletons (Auth, Theme)
5. Reactive Signals	Synchronous Signal binding	❌ No	100% Compile-Time	Event/state reactivity without tree lock
6. Code-Generated IoC	Generated graph wiring	❌ No	Compile-Time verified	Large enterprises with complex graphs

Conclusion

No single flavor fits every situation in a Flutter application. A clean, modern Flutter architecture often combines multiple flavors:

Use Constructor Injection for widget component boundaries.
Use Globals or Signals for app-wide reactive state.
Use Service Locators or Providers for feature repositories and scoped lifecycles.

Which flavor of dependency injection do you use most in your Flutter projects? Let’s discuss in the comments!

DEV Community: Randal L. Schwartz

Riverpod to BlocSignal: Incremental Migration and Zero-Codegen Signals for Flutter

Introduction: Combining Riverpod Safety with Zero Codegen

The Core Ergonomics: Riverpod Notifier vs. CubitSignal

The Riverpod Approach (Requires @riverpod & build_runner)

The BlocSignal Approach (100% Pure Dart 3, No Codegen)

What Changed?

Zero Risk: Incremental Trial & Bidirectional Interop

Option A: Expose a BlocSignal / CubitSignal to Existing Riverpod Widgets

Option B: Adapt an Existing Riverpod Provider into BlocSignal

Converting AsyncValue <-> AsyncState

Explore the Official Riverpod Ports on blocsignal.dev

Built-In AI Agent Skills for Automated Migration

Summary

Unit Testing in BlocSignal: The Practical Handbook

A Practical Guide to Faster, Deterministic Flutter & Dart Unit Testing

🛠️ Quick Reference: BLoC Streams vs. BlocSignal Testing

📖 Recipe Handbook

Recipe 1: Direct Imperative Unit Testing (Zero Helper Overhead)

Recipe 2: Declarative Testing with blocSignalTest

Recipe 3: Testing Reified Events & Streamless Concurrency Transformers

Automatic De-duplication

Recipe 4: Testing Asynchronous APIs & Error Routing

Recipe 5: Testing Hydrated Persistence & Replay Undo/Redo

Recipe 6: Testing Observers & Global Telemetry Scoping

🤖 Built-in AI Agent Testing Skill

🚀 Conclusion

Resources & Links

From Raw Signals to BlocSignal: Taming Reactivity for Enterprise Scale

🌟 Introduction: The Modern State Management Dilemma

⚠️ Step 1: The Pitfall of Raw Signals ("Too Much Freedom")

❌ The "Before": Global Writable Signal Spaghetti

The Pain Points in Enterprise Teams:

🔒 Step 2: Taming Signals with CubitSignal

✅ The "After": Encapsulated & Scoped Reactivity

Why This Tames the Chaos:

🚀 Step 3: Elevating to BLoC: Dispatch Rigor & Event Hierarchies

Sealed Class Event Hierarchies

Benefits of Reified Event Hierarchies:

⚡ Step 4: The Secret Sauce: Synchronous Graph Propagation

🛠️ Step 5: Enterprise Superpowers Out of the Box

🎯 Summary: Best of Both Worlds

📚 Further Reading & Related Articles

Exploring Form Management Patterns in Flutter with BlocSignal

1. Primary vs. Derived State with Signals

The Anti-Pattern: Storing Validation Errors in State

The Solution: Derived State via computed() Signals

Why This is a Game-Changer

2. Pattern Comparison: 3 Ways to Structure Forms

Pattern A: CubitSignal (Direct & Pragmatic)

Flutter UI Integration (Pattern A)

Pattern B: BlocSignal with Pure Reducers ((state, event) => newState)

Pattern C: Classic Class-per-Event with Concurrency Transformers

3. Decision Matrix: Choosing the Right Pattern

Summary

Resources & Open Source Code

Porting 16 BLoC & Signal Benchmark Apps to BlocSignal: Elevating Flutter UX & DX

🚀 Ported Example Benchmark Suite Live on blocsignal.dev!

💡 Why Port These Benchmark Apps?

1. Synchronous Frame Updates (Better Test DX)

2. Reactive computed() Derivations (Zero Event Plumbing)

3. Streamless Event Concurrency Transformers (Lower Overhead)

📦 What's Included in the Suite?

Ports from felangel/bloc (10 Applications)

Ports from rodydavis/signals.dart (6 Applications)

Solving Riverpod’s Family Provider Cache Dilemma with Signals & mapSignal

Eliminating Stale Data Silos & Complex Invalidation Loops in Flutter Apps

1. The Real-World Dilemma

The Two Core Pain Points

2. Root Cause: Parameterized Fetchers as Isolated Silos

3. The Signal Solution: Normalization + Fine-Grained Reactivity

4. Unlocking Granular Reactivity with mapSignal (SignalMap)

Advantage 1: In-Place Entity Updates with Zero Network Overhead

Advantage 2: Effortless Relational Sync (Solving Problem 2)

5. Side-by-Side Comparison

6. Code Example: Implementing the Pattern

Defining Models & Normalized Stores

Creating Reactive Subset Views with computed

Performing Updates

7. Bridge with Existing Ecosystems (BlocSignal & Riverpod Interop)

The Core Ergonomics: Riverpod `Notifier` vs. `CubitSignal`

The Riverpod Approach (Requires `@riverpod` & `build_runner`)

Option A: Expose a `BlocSignal` / `CubitSignal` to Existing Riverpod Widgets

Option B: Adapt an Existing Riverpod Provider into `BlocSignal`

Converting `AsyncValue` <-> `AsyncState`

Recipe 2: Declarative Testing with `blocSignalTest`

🔒 Step 2: Taming Signals with `CubitSignal`

The Solution: Derived State via `computed()` Signals

Pattern A: `CubitSignal` (Direct & Pragmatic)

Pattern B: `BlocSignal` with Pure Reducers (`(state, event) => newState`)

🚀 Ported Example Benchmark Suite Live on `blocsignal.dev`!

2. Reactive `computed()` Derivations (Zero Event Plumbing)

Ports from `felangel/bloc` (10 Applications)

Ports from `rodydavis/signals.dart` (6 Applications)

4. Unlocking Granular Reactivity with `mapSignal` (`SignalMap`)

Creating Reactive Subset Views with `computed`

7. Bridge with Existing Ecosystems (`BlocSignal` & Riverpod Interop)

Representing Asynchronous State (`AsyncState<T>`)

Offline Caching & Frame 1 Hydration (`bloc_signals_hydrate`)

Eliminating Try/Catch Boilerplate with `futureSignal`

3. The Application Layer: Services & Declarative `computed()` Signals

Eliminating Manual Callback Spaghetti with `computed()`

Choosing Between `CubitSignal` and `BlocSignal`

Surgical UI Binding (`signal.watch`)

🏗️ The Pure Dart Architecture (`package:bloc_signals`)

📡 Universal Observability via `dart:developer`

📊 Feature Matrix: Classic Stream BLoC vs. Universal `BlocSignal`

🛑 Why `ValueNotifier` Fails at Scale

3. Nested `ValueListenableBuilder` Pyramids of Doom

Declarative Derived State with `computed`

🏗️ Enterprise Rigor with `BlocSignal`

❌ Before: Legacy `ValueNotifier` Approach

✅ After: Modern `CubitSignal` / `BlocSignal` Approach

1. Direct State Consumption (`useSignalValue` / `useWatch`)

2. Streamless Side Effects (`useSignalEffect`)

3. Fine-Grained Derived Selectors (`useComputed`)

❌ Before: Legacy `flutter_hooks_bloc` Glue Code

✅ After: Modern `BlocSignal` + `signals_hooks`

🚆 Track 1: BLoC, Redux & Stream Interop (`package:bloc_signals`)

Exporting `BlocSignal` to Stream

🚆 Track 2: Riverpod Interop (`package:bloc_signals_riverpod`)