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 sprawdzi się w większości projektów dzięki bezpieczeństwu na etapie kompilacji i minimalnemu boilerplate. Bloc 9.0 pozostaje standardem w branżach regulowanych, wymagających audytowalnych śladów zdarzeń. GetX powinien być brany pod uwagę wyłącznie przy utrzymywaniu istniejących baz kodu bez budżetu na migrację. ## 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. ```dart // counter_provider.dart 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. ```dart // user_repository_provider.dart import 'package:riverpod_annotation/riverpod_annotation.dart'; part 'user_repository_provider.g.dart'; @riverpod Future 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. ```dart // authentication_event.dart 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. ```dart // authentication_bloc.dart import 'package:flutter_bloc/flutter_bloc.dart'; class AuthenticationBloc extends Bloc { final AuthRepository _authRepo; final TokenStorage _tokenStorage; AuthenticationBloc({ required AuthRepository authRepo, required TokenStorage tokenStorage, }) : _authRepo = authRepo, _tokenStorage = tokenStorage, super(AuthenticationInitial()) { on(_onLoginRequested); on(_onLogoutRequested); on(_onSessionRestored); } Future _onLoginRequested( LoginRequested event, Emitter 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 _onLogoutRequested( LogoutRequested event, Emitter emit, ) async { await _tokenStorage.clear(); emit(AuthenticationInitial()); } Future _onSessionRestored( SessionRestored event, Emitter 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ń. ```dart // search_bloc.dart import 'package:bloc_concurrency/bloc_concurrency.dart'; import 'package:flutter_bloc/flutter_bloc.dart'; class SearchBloc extends Bloc { final SearchRepository _repository; SearchBloc({required SearchRepository repository}) : _repository = repository, super(SearchInitial()) { // restartable() cancels previous search on new input on( _onQueryChanged, transformer: restartable(), ); // droppable() ignores events while processing on( _onResultSelected, transformer: droppable(), ); } Future _onQueryChanged( SearchQueryChanged event, Emitter emit, ) async { if (event.query.length < 3) { emit(SearchInitial()); return; } emit(SearchLoading()); final results = await _repository.search(event.query); emit(SearchLoaded(results: results)); } Future _onResultSelected( SearchResultSelected event, Emitter 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. ```dart // counter_controller.dart (GetX pattern) 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. ```dart // Step 1: Replace GetX controller with Riverpod notifier // Before (GetX) class ProductController extends GetxController { final products = [].obs; final isLoading = false.obs; Future loadProducts() async { isLoading.value = true; products.value = await ProductApi.fetchAll(); isLoading.value = false; } } // After (Riverpod 3.0) @riverpod class ProductList extends _$ProductList { @override Future> build() async { // Auto-retry on failure, auto-pause when off-screen return ProductApi.fetchAll(); } Future refresh() async { ref.invalidateSelf(); } } ``` ```dart // 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. GetX łączy routing, wstrzykiwanie zależności, klienta HTTP i zarządzanie stanem w jednym pakiecie. Aplikacje korzystające wyłącznie z zarządzania stanem importują całą bibliotekę o rozmiarze 120 KB. Riverpod i Bloc to wyspecjalizowane pakiety realizujące jedno zadanie. ## 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. ```dart // 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); }); } ``` ```dart // Bloc test - event-driven verification import 'package:bloc_test/bloc_test.dart'; import 'package:flutter_test/flutter_test.dart'; void main() { blocTest( '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(), isA(), ], ); } ``` `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. Zarządzanie stanem we Flutterze to jeden z najczęściej poruszanych tematów na rozmowach kwalifikacyjnych dla deweloperów mobilnych. Zrozumienie kompromisów między Riverpod, Bloc i GetX świadczy o dojrzałości architektonicznej. Warto przećwiczyć wyjaśnianie, kiedy każde rozwiązanie pasuje, a kiedy nie. ## 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](https://docs.flutter.dev/data-and-backend/state-mgmt/options) 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](/technologies/flutter/interview-questions/state-management-basics), obejmujący fundamentalne koncepcje testowane na rozmowach kwalifikacyjnych. Moduł [wzorzec provider](/technologies/flutter/interview-questions/provider-pattern) 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