Riverpod

Riverpod Provider Lifecycle Matrix (Memo)

Diese Übersicht verdeutlicht das Verhalten von Riverpod-Providern in Abhängigkeit von ihrer Konfiguration (autoDispose, keepAlive und permanent) bei verschiedenen Events und Aktionen.

Vergleich der Provider-Lebenszyklen

Situation / Aktion	1. Nur autoDispose	2. autoDispose + keepAlive()	3. Ohne autoDispose (Permanent)
Letzter Listener weg(z. B. Page-Wechsel)	⚰️ Disposed (Komplett gelöscht)	✅ Bleibt am Leben (Zustand wird gecacht)	✅ Bleibt am Leben (Für immer im RAM)
Manuelles ref.invalidate()	⚰️ Disposed (💤 Wartet auf neuen Listener)	⚰️ Disposed (💤 Wartet auf neuen Listener)	🔄 Sofortiger Neustart (Wird sofort neu berechnet)
Manuelles ref.refresh()	🔄 Sofortiger Neustart (Wird sofort neu erzwungen)	🔄 Sofortiger Neustart (Wird sofort neu erzwungen)	🔄 Sofortiger Neustart (Wird sofort neu erzwungen)
Abhängigkeit ändert sich(ref.watch im Body)	🔄 Sofortiger Neustart (Wird sofort neu berechnet)	🔄 Sofortiger Neustart (Wird sofort neu berechnet)	🔄 Sofortiger Neustart (Wird sofort neu berechnet)
Aufruf von link.close()	🚫 Nicht möglich(Gibt keinen Link)	🔄 Wechselt zu Verhalten 1: • Mit Listener? -> Bleibt aktiv. • Ohne Listener? -> ⚰️ Sofort gelöscht	🚫 Nicht möglich(Gibt keinen Link)

---

Kern-Erkenntnisse & Notizen

1. Der feine Unterschied zwischen keepAlive() und Permanent (Ohne autoDispose)

Wenn du ein ref.invalidate() aufrufst, verhalten sich Spalte 2 und Spalte 3 unterschiedlich, falls gerade kein Widget aktiv zuhört (kein aktiver Listener):

• Permanenter Provider (Spalte 3): Startet nach dem Invalidate sofort im Hintergrund eine neue Berechnung (z. B. einen Netzwerk-Request), selbst wenn die Daten aktuell niemand sieht.
• keepAlive-Provider (Spalte 2): Wirft die alten Daten weg und geht in den Ruhezustand über. Er berechnet sich erst dann neu, wenn wieder ein Widget den Provider aktiv anfordert. Das spart Ressourcen!

2. Die Funktionsweise von link.close()

Der Aufruf von link.close() löscht den Provider nicht zwangsläufig sofort, sondern hebt lediglich das "Kündigungsschutz-Privileg" auf. Es wird geprüft:

• Sind noch Widgets da, die den Provider via ref.watch beobachten? Wenn ja, bleibt er aktiv (rutscht aber auf das Standard-Verhalten von Spalte 1 ab).
• Ist der Nutzer bereits auf einer anderen Seite und es gibt keine Listener mehr? Wenn ja, wird der Provider exakt in der Millisekunde des close()-Aufrufs zerstört.