Zarządzanie stanem we Flutterze w 2026: Riverpod vs Bloc vs GetX

Zarządzanie stanem we Flutterze określa sposób przepływu danych pomiędzy widgetami w aplikacji. W 2026 roku ekosystem zdominowały trzy rozwiązania: Riverpod 3.0 z bezpieczeństwem typów na etapie kompilacji, Bloc 9.0 z korporacyjnym systemem śledzenia zdarzeń oraz GetX z malejącym, lecz wciąż obecnym udziałem w rynku. Wybór odpowiedniego rozwiązania wpływa na testowalność, skalowalność i długoterminowe koszty utrzymania.

Riverpod 3.0: bezpieczeństwo kompilacji i automatyczne ponawianie

Riverpod 3.0 wprowadził fundamentalną zmianę w sposobie deklarowania i konsumowania stanu w aplikacjach Flutter. Generowanie kodu oparte na adnotacjach wychwytuje błędy zależności na etapie kompilacji zamiast w czasie wykonania, eliminując całą klasę błędów, które wcześniej wymagały ręcznego testowania.

Mechanizm automatycznego ponawiania dla providerów, które zakończyły się niepowodzeniem, obsługuje przejściowe błędy sieciowe bez ręcznej interwencji. Gdy obliczenie providera kończy się błędem, Riverpod automatycznie ponawia próbę z konfigurowalnym opóźnieniem, redukując boilerplate związany z obsługą błędów.

import 'package:riverpod_annotation/riverpod_annotation.dart';

part 'counter_provider.g.dart';

// Code generation ensures compile-time safety
@riverpod
class Counter extends _$Counter {
  @override
  int build() => 0; // Initial state

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

Adnotacja @riverpod generuje cały boilerplate providera. Niezgodności typów, brakujące nadpisania i cykliczne zależności ujawniają się podczas kompilacji.

import 'package:riverpod_annotation/riverpod_annotation.dart';

part 'user_repository_provider.g.dart';

@riverpod
Future<User> currentUser(Ref ref) async {
  final authService = ref.watch(authServiceProvider);
  final userId = authService.currentUserId;

  // Auto-retry on network failure (Riverpod 3.0)
  final response = await ref.watch(
    httpClientProvider,
  ).get('/api/users/$userId');

  return User.fromJson(response.data);
}

Riverpod 3.0 automatycznie wstrzymuje nasłuchiwanie providerów, gdy widget znika z ekranu, co ogranicza niepotrzebne obliczenia i poprawia żywotność baterii na urządzeniach mobilnych.

Bloc 9.0: architektura zdarzeniowa dla aplikacji korporacyjnych

Bloc 9.0 wymusza ścisłe rozdzielenie zdarzeń, stanów i logiki biznesowej. Każda zmiana stanu jest mapowana na konkretne zdarzenie, tworząc ścieżkę audytu wymaganą przez branże regulowane. Kontrole bezpieczeństwa montowania w wersji 9.0 zapobiegają wykonywaniu callbacków na zwolnionych widgetach.

sealed class AuthenticationEvent {}

final class LoginRequested extends AuthenticationEvent {
  final String email;
  final String password;
  LoginRequested({required this.email, required this.password});
}

final class LogoutRequested extends AuthenticationEvent {}

final class SessionRestored extends AuthenticationEvent {
  final String token;
  SessionRestored({required this.token});
}

Klasy sealed z Dart 3 gwarantują wyczerpujące dopasowanie wzorców na zdarzeniach. Kompilator wymusza obsługę każdego typu zdarzenia.

import 'package:flutter_bloc/flutter_bloc.dart';

class AuthenticationBloc
    extends Bloc<AuthenticationEvent, AuthenticationState> {
  final AuthRepository _authRepo;
  final TokenStorage _tokenStorage;

  AuthenticationBloc({
    required AuthRepository authRepo,
    required TokenStorage tokenStorage,
  })  : _authRepo = authRepo,
        _tokenStorage = tokenStorage,
        super(AuthenticationInitial()) {
    on<LoginRequested>(_onLoginRequested);
    on<LogoutRequested>(_onLogoutRequested);
    on<SessionRestored>(_onSessionRestored);
  }

  Future<void> _onLoginRequested(
    LoginRequested event,
    Emitter<AuthenticationState> emit,
  ) async {
    emit(AuthenticationLoading());
    try {
      final token = await _authRepo.login(
        email: event.email,
        password: event.password,
      );
      await _tokenStorage.save(token);
      emit(AuthenticationSuccess(token: token));
    } catch (e) {
      emit(AuthenticationFailure(message: e.toString()));
    }
  }

  Future<void> _onLogoutRequested(
    LogoutRequested event,
    Emitter<AuthenticationState> emit,
  ) async {
    await _tokenStorage.clear();
    emit(AuthenticationInitial());
  }

  Future<void> _onSessionRestored(
    SessionRestored event,
    Emitter<AuthenticationState> emit,
  ) async {
    emit(AuthenticationSuccess(token: event.token));
  }
}

Każdy handler zdarzenia generuje przejrzystą zmianę stanu. Middleware logujący może rejestrować każde zdarzenie do celów debugowania lub zgodności. Interfejs EmittableStateStreamableSource w Bloc 9.0 upraszcza testowanie, umożliwiając tworzenie lekkich implementacji mockowych.

Transformery zdarzeń w Bloc: obsługa wysokoczęstotliwościowego wejścia

Bloc udostępnia wbudowane transformery zdarzeń rozwiązujące typowe problemy współbieżności. Wyszukiwanie podczas pisania, szybkie kliknięcia przycisków i strumienie danych w czasie rzeczywistym korzystają z deklaratywnego przetwarzania zdarzeń.

import 'package:bloc_concurrency/bloc_concurrency.dart';
import 'package:flutter_bloc/flutter_bloc.dart';

class SearchBloc extends Bloc<SearchEvent, SearchState> {
  final SearchRepository _repository;

  SearchBloc({required SearchRepository repository})
      : _repository = repository,
        super(SearchInitial()) {
    // restartable() cancels previous search on new input
    on<SearchQueryChanged>(
      _onQueryChanged,
      transformer: restartable(),
    );
    // droppable() ignores events while processing
    on<SearchResultSelected>(
      _onResultSelected,
      transformer: droppable(),
    );
  }

  Future<void> _onQueryChanged(
    SearchQueryChanged event,
    Emitter<SearchState> emit,
  ) async {
    if (event.query.length < 3) {
      emit(SearchInitial());
      return;
    }
    emit(SearchLoading());
    final results = await _repository.search(event.query);
    emit(SearchLoaded(results: results));
  }

  Future<void> _onResultSelected(
    SearchResultSelected event,
    Emitter<SearchState> emit,
  ) async {
    emit(SearchNavigating(result: event.result));
  }
}

Transformer restartable() anuluje trwające wyszukiwanie, gdy pojawi się nowe zapytanie, zapobiegając nadpisaniu świeżych wyników przestarzałymi danymi. Transformer droppable() ignoruje duplikaty kliknięć podczas przetwarzania nawigacji.

GetX: dług techniczny i realia migracji

GetX zyskał popularność dzięki szybkości prototypowania i minimalnemu boilerplate. W 2026 roku biblioteka zmaga się z kryzysem utrzymania: sporadyczne aktualizacje, wąskie gardło jednego opiekuna i rosnące niekompatybilności z najnowszymi wersjami Flutter SDK. Aplikacje produkcyjne oparte na GetX napotykają problemy z cyklem życia kontrolerów i wycieki pamięci spowodowane niejawnymi globalnymi singletonami.

import 'package:get/get.dart';

// Global singleton - difficult to test and scope
class CounterController extends GetxController {
  final count = 0.obs; // Reactive observable

  void increment() => count.value++;
  void decrement() => count.value--;

  // Lifecycle hooks - disposal timing is unpredictable
  @override
  void onClose() {
    // Cleanup may not execute reliably
    super.onClose();
  }
}

// Usage in widget
class CounterPage extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    // Get.put creates a global singleton
    final controller = Get.put(CounterController());
    return Obx(() => Text('${controller.count}'));
  }
}

Wywołanie Get.put() rejestruje kontrolery jako globalne singletony. W skomplikowanych przepływach nawigacyjnych kontrolery utrzymują się poza zamierzonym zakresem, pochłaniając pamięć. Reaktywne zmienne .obs omijają standardowy system powiadamiania o stanie Fluttera, co czyni integrację z innymi pakietami zawodną.

Migracja z GetX do Riverpod: krok po kroku

Zespoły utrzymujące bazy kodu oparte na GetX mogą przeprowadzać migrację do Riverpod przyrostowo. Obie biblioteki współistnieją w tym samym projekcie, umożliwiając konwersję ekran po ekranie bez konieczności pełnego przepisywania aplikacji.

// Step 1: Replace GetX controller with Riverpod notifier
// Before (GetX)
class ProductController extends GetxController {
  final products = <Product>[].obs;
  final isLoading = false.obs;

  Future<void> loadProducts() async {
    isLoading.value = true;
    products.value = await ProductApi.fetchAll();
    isLoading.value = false;
  }
}

// After (Riverpod 3.0)
@riverpod
class ProductList extends _$ProductList {
  @override
  Future<List<Product>> build() async {
    // Auto-retry on failure, auto-pause when off-screen
    return ProductApi.fetchAll();
  }

  Future<void> refresh() async {
    ref.invalidateSelf();
  }
}

// Step 2: Replace widget bindings
// Before (GetX)
class ProductPage extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    final ctrl = Get.put(ProductController());
    return Obx(() {
      if (ctrl.isLoading.value) return CircularProgressIndicator();
      return ListView.builder(
        itemCount: ctrl.products.length,
        itemBuilder: (_, i) => ProductTile(ctrl.products[i]),
      );
    });
  }
}

// After (Riverpod 3.0)
class ProductPage extends ConsumerWidget {
  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final productsAsync = ref.watch(productListProvider);
    return productsAsync.when(
      loading: () => const CircularProgressIndicator(),
      error: (err, stack) => ErrorDisplay(error: err),
      data: (products) => ListView.builder(
        itemCount: products.length,
        itemBuilder: (_, i) => ProductTile(products[i]),
      ),
    );
  }
}

Wersja oparta na Riverpod obsługuje stany ładowania, błędu i danych jawnie poprzez AsyncValue.when(). Brak globalnych singletonów, brak ręcznego zarządzania cyklem życia i automatyczne usuwanie po odmontowaniu widgetu.

Porównanie wydajności: efektywność przebudowy widgetów

Efektywność przebudowy bezpośrednio wpływa na płynność animacji. Każde rozwiązanie obsługuje przebudowę widgetów inaczej, a różnice stają się mierzalne na listach zawierających setki elementów.

| Metric | Riverpod 3.0 | Bloc 9.0 | GetX | |--------|-------------|----------|------| | Selective rebuild | select() filter | BlocSelector | .obs per field | | Compile-time safety | Full (code gen) | Partial (sealed classes) | None | | Auto-dispose | Built-in | Manual via close() | Unreliable | | Pause when off-screen | Automatic (3.0) | Manual | Not supported | | Event traceability | Provider observer | Full event log | None | | Testing isolation | ProviderContainer.test() | EmittableStateStreamableSource | Requires Get.testMode | | Bundle size impact | ~45KB | ~38KB | ~120KB (includes routing, DI, HTTP) |

Metoda select() w Riverpod i BlocSelector w Bloc umożliwiają precyzyjną przebudowę, aktualizując jedynie poddrzewo widgetów zależne od zmienionych danych. Zmienne .obs w GetX osiągają podobną granularność na poziomie poszczególnych pól, lecz nie zapewniają weryfikacji grafu zależności na etapie kompilacji.

Strategie testowania w poszczególnych rozwiązaniach

Testowalność często decyduje o tym, które rozwiązanie skaluje się wraz z rosnącym zespołem. Każda biblioteka podchodzi do testowania inaczej.

// Riverpod test - isolated container
import 'package:flutter_test/flutter_test.dart';
import 'package:riverpod/riverpod.dart';

void main() {
  test('Counter increments', () {
    final container = ProviderContainer.test();
    // Override dependencies for isolation
    final counter = container.read(counterProvider.notifier);

    expect(container.read(counterProvider), 0);
    counter.increment();
    expect(container.read(counterProvider), 1);
  });
}

// Bloc test - event-driven verification
import 'package:bloc_test/bloc_test.dart';
import 'package:flutter_test/flutter_test.dart';

void main() {
  blocTest<AuthenticationBloc, AuthenticationState>(
    'emits [loading, success] on valid login',
    build: () => AuthenticationBloc(
      authRepo: MockAuthRepo(),
      tokenStorage: MockTokenStorage(),
    ),
    act: (bloc) => bloc.add(
      LoginRequested(email: 'dev@test.com', password: 'secure123'),
    ),
    expect: () => [
      isA<AuthenticationLoading>(),
      isA<AuthenticationSuccess>(),
    ],
  );
}

ProviderContainer.test() w Riverpod tworzy izolowany graf zależności dla każdego testu. Helper blocTest w Bloc weryfikuje dokładne sekwencje przejść stanów, odpowiadając architekturze zdarzeniowej. Testowanie GetX wymaga ustawienia Get.testMode = true i ręcznego zarządzania cyklem życia kontrolerów, co często prowadzi do niestabilnych testów w środowiskach CI.

Macierz decyzyjna: wybór odpowiedniego rozwiązania

Ograniczenia projektowe determinują najlepsze dopasowanie. Wielkość zespołu, wymogi regulacyjne i istniejąca baza kodu mają wpływ na decyzję.

Riverpod 3.0 sprawdza się, gdy zespół ceni bezpieczeństwo na etapie kompilacji, projekt wymaga asynchronicznego pobierania danych z automatycznym odzyskiwaniem po błędach lub baza kodu jest tworzona od podstaw. Krzywa uczenia się jest umiarkowana: deweloperzy zaznajomieni z Provider przechodzą naturalnie.

Bloc 9.0 sprawdza się, gdy projekt działa w branży regulowanej (fintech, ochrona zdrowia), zespół potrzebuje pełnej śledzowalności zdarzeń do celów audytu lub aplikacja obsługuje złożone przepływy współbieżne, takie jak przetwarzanie płatności. Koszt boilerplate zwraca się w utrzymywalności na dużą skalę.

GetX sprawdza się wyłącznie przy utrzymywaniu istniejących baz kodu GetX, gdy koszt migracji przekracza dostępny budżet. Rozpoczynanie nowych projektów z GetX w 2026 roku wprowadza dług techniczny od pierwszego dnia. Oficjalna dokumentacja Fluttera nie wymienia GetX wśród zalecanych rozwiązań.

Pogłębione ćwiczenia z wzorców zarządzania stanem we Flutterze oferuje moduł podstawy zarządzania stanem Flutter, obejmujący fundamentalne koncepcje testowane na rozmowach kwalifikacyjnych. Moduł wzorzec provider eksploruje strategie wstrzykiwania zależności mające zastosowanie we wszystkich trzech rozwiązaniach.

Podsumowanie

• Riverpod 3.0 zapewnia bezpieczeństwo na etapie kompilacji poprzez generowanie kodu, automatyczne ponawianie dla providerów zakończonych błędem oraz wsparcie wstrzymywania i wznawiania, które redukuje zużycie baterii na urządzeniach mobilnych
• Bloc 9.0 wymusza zdarzeniowe przejścia stanów z pełnymi możliwościami audytu, co czyni go standardem dla aplikacji korporacyjnych w branżach regulowanych
• GetX zmaga się z kryzysem utrzymania w 2026 roku, ze sporadycznymi aktualizacjami i rosnącymi niekompatybilnościami z SDK; istniejące projekty GetX powinny planować przyrostową migrację do Riverpod
• Migracja z GetX do Riverpod odbywa się ekran po ekranie bez konieczności pełnego przepisywania, ponieważ obie biblioteki współistnieją w tym samym projekcie
• Izolacja testowa znacząco się różni: Riverpod wykorzystuje ProviderContainer.test(), Bloc używa blocTest z weryfikacją sekwencji zdarzeń, a GetX wymaga kruchej konfiguracji globalnego trybu testowego
• Rozmiar pakietu ma znaczenie na urządzeniach mobilnych: Riverpod (~45 KB) i Bloc (~38 KB) dostarczają wyspecjalizowane pakiety, podczas gdy GetX (~120 KB) łączy niewykorzystywane funkcje