Mutation<T>

Verfolgt einen einzelnen asynchronen Schreibvorgang und stellt seinen Lebenszyklus als bindbaren Zustand bereit; bei jedem Fortschritt benachrichtigt sie den angehängten Listener, damit die besitzende Komponente neu rendern kann.

public class Mutation<T> : DejaObservable

Konstruktoren#

Mutation()#

public Mutation()

Erstellt eine Mutation, die ihren Cache-Client von der besitzenden Komponente auflöst (falls vorhanden).

Mutation(DejaClient)#

public Mutation(DejaClient client)

Erstellt eine Mutation, die an client gebunden ist — für den Einsatz außerhalb einer Komponente. Wirft eine ArgumentNullException, wenn client null ist.

Zustand#

Member	Typ	Beschreibung
IsLoading	`bool`	True, während die Mutation läuft.
IsError	`bool`	True, wenn die jüngste Ausführung fehlgeschlagen ist.
ErrorMessage	`string?`	Die Fehlermeldung der jüngsten Ausführung, wenn `IsError` true ist.
Data	`T?`	Das Ergebnis der jüngsten erfolgreichen Ausführung. Void-Mutationsformen lassen es unberührt; ein Fehler setzt es auf den Default zurück.

Methoden#

Execute (shorthand)#

public Task Execute(Func<Task<T>> mutationFunction, Action<MutationParameters<T>>? configure = null)

Führt eine Mutation aus — die Kurzform für den häufigen Fall; alles Weitere (typischerweise InvalidateKeys) setzt der Configure-Hook. Wirft eine ArgumentNullException, wenn mutationFunction null ist.

Execute (cancellation-aware shorthand)#

public Task Execute(Func<CancellationToken, Task<T>> mutationFunction, Action<MutationParameters<T>>? configure = null)

Führt eine abbruchfähige Mutation aus. Der Token ist der Lifetime-Token der besitzenden Komponente; ein laufender Schreibvorgang wird also aufgegeben, wenn die Komponente disposed wird:

_addTodo.Execute(token => Api.AddTodoAsync(title, token));

Execute (full form)#

public Task Execute(MutationParameters<T> parameters)

Führt die durch parameters beschriebene Mutation aus. Ist der effektive Token bereits abgebrochen (die Komponente ist weg), kehrt der Aufruf zurück, ohne den Schreibvorgang zu starten. Bei Erfolg laufen die Erfolgs-Callbacks, danach werden die InvalidateKeys invalidiert — nach OnSuccess, sodass ein Callback, der das Ergebnis beobachtet, läuft, bevor abhängige Queries mit dem Refetch beginnen.

Fehlerkontrakt#

Bei einem Fehler wird Data auf den Default zurückgesetzt, der Fehlerzustand veröffentlicht, und die Fehler-Callbacks laufen. Eine InvalidOperationException, die die ursprüngliche Exception umschließt, wird nur geworfen, wenn kein Fehler-Callback übergeben wurde — verdrahte OnError (oder einen beliebigen anderen Fehler-Callback), und der Fehler bleibt behandelt, statt in den Komponenten-Lifecycle zu entweichen. Abbruch ist kein Fehler: kein Fehlerzustand, keine Callbacks (Settled eingeschlossen).