Week 8: Riverpod: Providers, Notifiers & Compile-Time Safety

1. Providers Without BuildContext

flutter pub add flutter_riverpod

void main() {
  runApp(const ProviderScope(child: MyApp()));
}

final greetingProvider = Provider<String>((ref) => 'Hello, Flutter!');

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

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final greeting = ref.watch(greetingProvider);
    return Text(greeting);
  }
}

Providers are defined as top-level, global variables — but they're not global mutable state in the dangerous sense; ProviderScope gives each one a real, overridable, testable instance, which is precisely what removing the BuildContext dependency makes possible.

2. Modeling Mutable State with Notifier

class CartNotifier extends Notifier<List<String>> {
  @override
  List<String> build() => []; // initial state

  void add(String item) {
    state = [...state, item]; // reassigning state triggers listeners
  }

  void remove(String item) {
    state = state.where((i) => i != item).toList();
  }
}

final cartProvider = NotifierProvider<CartNotifier, List<String>>(CartNotifier.new);

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

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final items = ref.watch(cartProvider);
    return Badge(label: Text('${items.length}'));
  }
}

// elsewhere, mutating:
ref.read(cartProvider.notifier).add('Widget');

Reassigning state (rather than mutating it in place, as [...state, item] does above) is deliberate — Riverpod compares the old and new state to decide whether to notify listeners, which requires a genuinely new value, not an in-place mutation of the same list.

3. Compile-Time Safety & Testing

Provider's context.watch<CartModel>() fails at runtime, with a thrown exception, if no matching provider exists above that widget in the tree. Riverpod's providers are strongly typed top-level references — a typo or a missing provider is caught by the analyzer, before the app ever runs.

test('adding an item increases cart length', () {
  final container = ProviderContainer();
  addTearDown(container.dispose);

  container.read(cartProvider.notifier).add('Widget');

  expect(container.read(cartProvider).length, 1);
});

ProviderContainer gives direct access to provider state with no BuildContext and no widget tree at all — a real, meaningful advantage for testing business logic in isolation, ahead of Week 16's testing work, without needing WidgetTester just to verify a notifier's behavior.

4. Provider vs. Riverpod vs. Bloc

• Provider — a solid choice for a smaller app, or a team already deeply familiar with it; simplest mental model, tied to BuildContext.
• Riverpod — the default recommendation going forward in this course: compile-time safety, easy testing, no context dependency, and it's what the rest of this curriculum builds on.
• Bloc — worth reaching for when a team wants a strict, explicit separation between events (inputs) and states (outputs), often for larger teams or apps with complex, auditable business logic where that ceremony pays for itself.

All three solve the same underlying problem from Week 6 — none is "more correct" in the abstract; the right choice depends on team size, how much explicit structure the app's state logic actually needs, and (realistically) what a team already knows.

5. Hands-on Exercise

6. Knowledge Check

Four quick questions. Expand each to check your answer.