Tag: state-management

ref.watch abonniert und baut neu, ref.read liest einmal und baut nie neu. Verwenden Sie watch in jeder build-Methode und read ausschließlich in Event-Callbacks. Hier sind die Entscheidungsmatrix, der Quellcode beider Methoden in flutter_riverpod 3.4.3 und die vier stillen Fehlerfälle: watch in einem Callback, read im Rumpf eines Providers, read auf einem autoDispose-Provider und read als vermeintliche Optimierung.

Ein Key ist die Identitätshälfte von Widget.canUpdate, der einen Zeile im Framework, die entscheidet, ob ein Element und sein State wiederverwendet oder verworfen werden. Was das in der Praxis bedeutet, welche Listenänderungen ohne Keys den State beschädigen, welcher Key-Typ passt und wo der Key stehen muss, damit er wirkt.

Die Wahl entscheidet der Rückgabetyp von build(): T bedeutet Notifier, FutureOr<T> bedeutet AsyncNotifier, Stream<T> bedeutet StreamNotifier. Hier sind die Entscheidungsmatrix, die zugrunde liegende Typhierarchie sowie die Fallstricke beim ==-Filtern und beim Überschreiben des State. Verifiziert mit flutter_riverpod 3.4.2 auf Flutter 3.44.2.

Schritt für Schritt vom widget-lokalen setState zu einem Riverpod-3.x-Notifier: klassifizieren, was das Widget wirklich verlässt, den Notifier schreiben, auf ConsumerWidget umstellen und die Fallstricke überstehen, die setState-Umsteiger treffen: Filterung per ==, erneute Ausführung von build() und unterschiedliche autoDispose-Voreinstellungen. Getestet mit Flutter 3.44, Dart 3.x und flutter_riverpod 3.3.2.

In Riverpod 3.0 filtert jeder Provider Listener-Benachrichtigungen mit ==, nicht per Identität. Ein StreamProvider, der dasselbe veränderliche Objekt erneut emittiert, baut die UI nach dem ersten Frame nicht mehr neu auf. Hier erfahren Sie, warum das passiert, und drei Wege, es zu beheben. Getestet mit flutter_riverpod 3.3.2, Flutter 3.44, Dart 3.x.

Riverpod 3.0 wiederholt einen fehlgeschlagenen Provider standardmaessig bis zu 10-mal. Uebergeben Sie eine Retry-Funktion, die null zurueckgibt, an ProviderScope, ProviderContainer oder einen einzelnen Provider, um das abzuschalten oder zu begrenzen.

Ein Schritt-für-Schritt-Upgrade von flutter_riverpod 2.x auf 3.x: die Pakete anheben, StateProvider und Verwandte auf den Legacy-Import umziehen, die AutoDispose- und Family-Ref-Typen loswerden, ProviderException-Wrapping und automatische Wiederholung handhaben und das ==-Benachrichtigungsfiltern beheben, das StreamProvider-Events stillschweigend verwirft. Getestet mit Flutter 3.44, Dart 3.x, flutter_riverpod 3.3.2.

Riverpod 3.0 verpackt Fehler, die beim Lesen eines Providers auftreten, in eine ProviderException. Fangen Sie diesen Typ ab und lesen Sie e.exception, um Ihren ursprünglichen Fehler zurückzubekommen, oder verwenden Sie AsyncValue.error, das nicht verpackt ist.

In einem Notifier lösen Sie die Abhängigkeiten vor dem await auf und schützen dann die state-Schreiboperation mit if (!ref.mounted) return. Das ist der Riverpod-3.0-Ersatz für das alte onDispose-Mixin und verhindert eine UnmountedRefException, wenn ein Provider mitten in einem await verworfen wird. Getestet mit flutter_riverpod 3.x, Flutter 3.44, Dart 3.x.

Eine schrittweise Migration vom provider-Paket zu Riverpod 3.x in einer echten Flutter-App: ChangeNotifierProvider zu Notifier, MultiProvider zu ProviderScope, context.watch zu ref.watch, ProxyProvider zu ref.watch-Komposition, plus die Gleichheits- und Lifecycle-Fallstricke, die Sie erwischen. Getestet mit Flutter 3.27.1, Dart 3.11, provider 6.1.5, flutter_riverpod 3.3.1.