cd /news/developer-tools/grand-central-station-why-bloc-river… · home topics developer-tools article
[ARTICLE · art-115466] src=dev.to ↗ pub= topic=developer-tools verified=true sentiment=↑ positive

Grand Central Station: Why BLoC, Riverpod, and BlocSignal Are Now True Peers

Randal L. Schwartz announced the release of bloc_signals_bloc and a major update to bloc_signals_riverpod, making BLoC, Riverpod, and BlocSignal first-class, bidirectional peers in Flutter state management. The new packages allow seamless, type-safe, lifecycle-managed integration between the three state containers, eliminating the need for risky rewrites or clunky adapter boilerplate.

read6 min views1 publishedAug 30, 2026

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

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

If you have spent any time in the Flutter community over the past eight years, you have witnessed the great "State Management Wars."

On one track sat Classic BLoC: strict, battle-tested, enterprise-grade, but heavily reliant on asynchronous Dart Stream

microtasks. On an adjacent track sat Riverpod: offering compile-time safety and declarative dependency graph plumbing, but steering increasingly toward mandatory code generation and build_runner

iteration tax. On the newest high-speed track arrived Signals: offering raw sub-microsecond synchronous reactivity and fine-grained UI rebuilding.

For years, choosing a state management library felt like choosing an isolated railroad network. If an engineering team built their core application with flutter_bloc

or flutter_riverpod

and wanted to take advantage of synchronous Signals for a new high-frequency feature, conventional wisdom dictated a painful choice: either undertake a risky, multi-month rewrite or suffer through clunky, second-class adapter boilerplate.

Traditional "interop" packages in our ecosystem have almost always been an afterthought—awkward, leaky wrappers designed to tolerate legacy code until someone finds the budget to delete it.

Today, with the release of ** bloc_signals_bloc** and a major update to

bloc_signals_riverpod

BLoC, Riverpod, and BlocSignal are no longer competing silos. They are first-class, bidirectional peers.

Imagine walking into a majestic railway terminal—vaulted glass arches overhead, golden sunbeams cutting through the air, and railway block signal gantries glowing bright green.

Pulling up to the platforms side by side on three parallel steel tracks are three distinct locomotives:

  🚂 Track 1: Classic BLoC (The Steam Locomotive) ─────┐
                                                        │
  🚚 Track 2: Riverpod (The Heavy Freight Hauler) ──────┼──► [ Grand Central State Terminal ] ◄──► Synchronous Signals
                                                        │
  🚄 Track 3: BlocSignal (The High-Speed Maglev) ───────┘

In Grand Central Terminal, the tracks do not collide, and no train is treated as second-class rolling stock. Platforms sit adjacent to each other. Passengers (state, events, actions) walk across the concourse between trains with zero baggage check fees, zero customs delays, and zero microtask penalties.

In most architectures, adapting one state container to another requires wrapping everything in custom StreamController

instances, registering manual listener callbacks, and remembering to clean up disposers to prevent memory leaks.

Under BlocSignal

, peer integration is completely bidirectional, lifecycle-managed, and type-safe:

From Target ➔ To Target How It Works Developer Ergonomics
Classic BLoC ➔ BlocSignal
classicBloc.toBlocSignal()
Exposes synchronous .state signal + forwards .add(event)
Classic Cubit ➔ CubitSignal
classicCubit.toBlocSignal()
Exposes synchronous .state signal + typed .cubit methods
Riverpod Provider ➔ BlocSignal
provider.toBlocSignal(ref)
Exposes synchronous .state signal + typed .notifier methods + auto-disposal
BlocSignal ➔ Classic BLoC
blocSignal.toClassicBloc()
Direct drop-in for legacy flutter_bloc BlocBuilder / BlocListener
CubitSignal ➔ Classic Cubit
cubitSignal.toClassicCubit()
Direct drop-in for legacy flutter_bloc widgets
BlocSignal / CubitSignal ➔ Riverpod
blocSignal.toProvider()
Direct drop-in for Riverpod ref.watch and ref.read
Riverpod AsyncValue ↔ Signals AsyncState
.toAsyncState() / .toAsyncValue()
Seamless mapping across sealed /error/data states

Let's put this into practice with a concrete example.

What does it look like when all three state engines work together in a single Flutter screen?

Here is a complete, runnable Flutter app where a Classic BLoC, a Riverpod Notifier, and a Modern CubitSignal live side by side. Each manages its own domain state, yet they compose synchronously into a unified Grand Total using a single computed

signal in under 65 lines of code:

import 'package:flutter/material.dart';
import 'package:flutter_riverpod/flutter_riverpod.dart';
import 'package:bloc/bloc.dart' as bloc_lib;
import 'package:bloc_signals/bloc_signals.dart';
import 'package:bloc_signals_bloc/bloc_signals_bloc.dart';
import 'package:bloc_signals_riverpod/bloc_signals_riverpod.dart';
import 'package:signals_flutter/signals_flutter.dart';

// 🚂 1. CLASSIC BLOC: The Steam Engine (Explicit Event -> State)
class ClassicCounterBloc extends bloc_lib.Bloc<int, int> {
  ClassicCounterBloc() : super(0) {
    on<int>((event, emit) => emit(state + event));
  }
}

// 🚚 2. RIVERPOD: The Freight Hauler (Declarative Notifier)
class RiverpodCounter extends Notifier<int> {
  @override
  int build() => 0;
  void increment() => state++;
}
final riverpodCountProvider =
    NotifierProvider<RiverpodCounter, int>(RiverpodCounter.new);

// 🚄 3. BLOCSIGNAL: The High-Speed Maglev (Synchronous Signals)
class ModernSignalCubit extends CubitSignal<int> {
  ModernSignalCubit() : super(initialState: 0);
  void increment() => emit(stateValue + 1);
}

// 🏛️ GRAND CENTRAL TERMINAL: The Peer Counter Screen
class GrandCentralCounterScreen extends ConsumerWidget {
  const GrandCentralCounterScreen({
    super.key,
    required this.classicBloc,
    required this.signalCubit,
  });

  final ClassicCounterBloc classicBloc;
  final ModernSignalCubit signalCubit;

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    // 🔀 Adapt BLoC and Riverpod into first-class signal peers:
    final blocPeer = classicBloc.toBlocSignal();
    final riverpodPeer = riverpodCountProvider.toBlocSignal(ref);

    // ⚡ Synchronously compute the Grand Total across all three rail lines:
    final grandTotal = computed(
      () => blocPeer.state() + riverpodPeer.state() + signalCubit.state(),
    );

    return Scaffold(
      appBar: AppBar(title: const Text('Grand Central State Terminal')),
      body: Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: [
            Text('🚂 Classic BLoC Count: ${blocPeer.stateValue}'),
            Text('🚚 Riverpod Count: ${riverpodPeer.stateValue}'),
            Text('🚄 BlocSignal Count: ${signalCubit.stateValue}'),
            const Divider(height: 32, indent: 64, endIndent: 64),
            // Reactively updates the instant ANY train leaves its station!
            Watch((context) => Text(
              '🏁 Grand Total: ${grandTotal()}',
              style: Theme.of(context).textTheme.headlineMedium,
            )),
          ],
        ),
      ),
      floatingActionButton: Row(
        mainAxisAlignment: MainAxisAlignment.end,
        children: [
          FloatingActionButton.extended(
            heroTag: 'bloc',
            label: const Text('+1 BLoC'),
            onPressed: () => blocPeer.add(1),
          ),
          const SizedBox(width: 8),
          FloatingActionButton.extended(
            heroTag: 'riverpod',
            label: const Text('+1 Riverpod'),
            onPressed: () => riverpodPeer.notifier.increment(),
          ),
          const SizedBox(width: 8),
          FloatingActionButton.extended(
            heroTag: 'signal',
            label: const Text('+1 Signal'),
            onPressed: () => signalCubit.increment(),
          ),
        ],
      ),
    );
  }
}

void main() {
  // Initialize classic BLoC and modern CubitSignal instances:
  final classicBloc = ClassicCounterBloc();
  final signalCubit = ModernSignalCubit();

  runApp(
    // Wrap with Riverpod's ProviderScope at the application root:
    ProviderScope(
      child: MaterialApp(
        debugShowCheckedModeBanner: false,
        home: GrandCentralCounterScreen(
          classicBloc: classicBloc,
          signalCubit: signalCubit,
        ),
      ),
    ),
  );
}

blocPeer.add(1)

dispatches directly into the underlying classic Bloc

event queue.riverpodPeer.notifier.increment()

calls the underlying RiverpodCounter

methods with full type safety.signalCubit.increment()

triggers immediate synchronous signal emission.counterProvider.toBlocSignal(ref)

automatically registers ref.onDispose

to close the underlying bridge when the widget or provider scope unmounts. No memory leaks.grandTotal

: computed(() => blocPeer.state() + riverpodPeer.state() + signalCubit.state())

. package:bloc

, package:riverpod

, and package:bloc_signals

simultaneously. When any of the three states update, grandTotal

recalculates Peer status is not a one-way street. What if you build a cutting-edge feature using modern BlocSignal

containers, but you need to embed it inside an existing application that relies entirely on flutter_bloc

's BlocBuilder

or Riverpod's ConsumerWidget

?

You don't need to rewrite your containers!

flutter_bloc

Trees

final modernCubit = ModernSignalCubit();

// Adapt to a classic flutter_bloc Cubit:
final classicCubit = modernCubit.toClassicCubit();

// Consume directly inside existing flutter_bloc widgets with standard types:
BlocBuilder<bloc_lib.Cubit<int>, int>(
  bloc: classicCubit,
  builder: (context, state) => Text('Legacy BLoC UI: $state'),
);

ProviderScope

Trees

final modernCubit = ModernSignalCubit();

// Expose modern CubitSignal as a standard Riverpod NotifierProvider:
final myRiverpodProvider = modernCubit.toProvider();

// In any Riverpod ConsumerWidget:
Widget build(BuildContext context, WidgetRef ref) {
  final count = ref.watch(myRiverpodProvider);
  return ElevatedButton(
    onPressed: () => ref.read(myRiverpodProvider.notifier).cubit.increment(),
    child: Text('Riverpod UI: $count'),
  );
}

This architectural milestone eliminates the single largest point of friction in Flutter development:

BlocSignal

into a massive legacy Riverpod or BLoC production codebase one screen, one dialog, or one widget at a time.BlocSignal

containers with sub-microsecond rendering speed.State management in Flutter does not have to be an ideological battleground.

Whether your architecture runs on the Classic BLoC Iron Horse, the Riverpod Freight Hauler, or the BlocSignal Bullet Train, Grand Central Terminal ensures green lights across all lines.

To get started today, add the peer packages to your pubspec.yaml

:

dependencies:
  bloc_signals: ^1.0.0
  bloc_signals_bloc: ^1.0.0      # For Classic BLoC peer bridges
  bloc_signals_riverpod: ^1.2.0  # For Riverpod peer bridges
  bloc_signals_flutter: ^1.0.0   # For Flutter widget bindings

Check out the complete documentation, interactive API catalogs, and live showcase apps at ** blocsignal.dev**.

See you on the tracks!

── more in #developer-tools 4 stories · sorted by recency
── more on @randal l. schwartz 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
Live at https://your-agent.zahid.host
Get free account → Pricing
from €0/mo · no card required
LIVE [news/grand-central-statio…] indexed:0 read:6min 2026-08-30 ·