How I structure my Angular components with Signals

In diesem kurzen Artikel möchte ich Ihnen zeigen, wie ich meine Komponenten gerne mit Signalen strukturiere, ohne externe Bibliothek. Natürlich würden Dinge wie NgRx eine große Rolle spielen, um unseren Code robuster zu machen, aber fangen wir einfach an!

Zuerst definiere ich alle meine Zustände mit Signalen:

export class TodoListComponent {
  todos = signal<todo>([]);
}
</todo>

Das Gleiche gilt auch für Eingaben! Wenn meine Komponente eine Eingabe benötigt, deklariere ich sie mit der neuen Funktion input() von Angular, die mir ebenfalls ein Signal gibt. Und wenn es sich um einen Routenparameter handelt, verwende ich input.required().

Wenn ich dann einen Zustand anzeigen möchte, der von einem anderen abgeleitet werden kann, verwende ich immer berechnet:

completedTodos = computed(() => this.todos().filter(t => t.completed));

Wenn Sie mich dann kennen, wissen Sie, wie sehr ich es verabscheue, asynchrone Nebenwirkungen direkt in Klassenmethoden auszuführen ... ?

export class TodoListComponent {
  todoService = inject(TodoService);

  toggleTodo(id: string) {
    this.todoService.toggle(id).subscribe(newTodo => ...);
  }
}

Warum fragst du? Denn wenn die Methode diejenige ist, die den Nebeneffekt direkt auslöst (in diesem Fall der Aufruf von subscribe), haben Sie keine Kontrolle über den Gegendruck.

Der Gegendruck lässt sich folgendermaßen zusammenfassen: Was passiert, wenn der Benutzer die Aufgabe umschaltet, während der vorherige Anruf noch nicht beendet wurde?

Es gibt eine Reihe von Problemen, zum Beispiel:

1. Wollen wir den zweiten Anruf überhaupt durchführen? Oder warten, bis der erste fertig ist? Oder sollten wir die erste absagen?
2. Was wäre, wenn wir in kurzer Zeit verschiedene Elemente umschalten würden?
3. Was wäre, wenn wir eine Art Entprellung oder Drosselung einführen möchten?

Wenn Sie RxJS kennen (und wenn Sie dies lesen, sollten Sie es jetzt wissen!), wissen Sie, dass das erste Problem mit den 4 Flattening-Operatoren (mergeMap, concatMap, switchMap, ExhaustMap) leicht gelöst werden kann.

Wenn Sie RxJS recht gut kennen, wissen Sie, dass Sie das zweite Problem mit einem tollen Operator namens „groupBy“ lösen können!

Aber um all diese Vorteile nutzen zu können, benötigen Sie eine beobachtbare Quelle, also... keine Methode.

Themen

Stellen Sie sich ein Subjekt wie ein offenes (nicht abgeschlossenes), leeres Observable vor. Es ist das perfekte Werkzeug, um benutzerdefinierte Ereignisse darzustellen.

Alle Ereignisse in unserer Komponente können durch Themen dargestellt werden:

export class TodoListComponent {
  ...

  toggleTodo$ = new Subject<string>();
  deleteTodo$ = new Subject<string>();
  addTodo$ = new Subject<void>();
}
</void></string></string>

Dann kann unsere Vorlage sie bei Bedarf einfach aufrufen, anstatt Methoden aufzurufen, zum Beispiel:

<button>delete</button>

Jetzt, da unsere Quellen Observables sind, können wir unsere lieben Operatoren verwenden: Lasst uns einige Effekte erzeugen.

Effekte

Ich definiere meine Effekte gerne innerhalb des Konstruktors, damit ich den takeUntilDestroyed()-Operator verwenden kann, um den Effekt zu bereinigen, wenn die Komponente zerstört wird! Also zum Beispiel:

constructor() {
  this.addTodo$.pipe(
    concatMap(() => this.todoService.add())
    takeUntilDestroyed()
  ).subscribe(newTodo => this.todos.update(todos => [...todos, newTodo]));
}

Hier verwende ich concatMap, um die Reihenfolge der Antworten beizubehalten, sodass die Aufgaben der Reihe nach hinzugefügt werden. Dies bedeutet, dass es keine gleichzeitigen Anrufe gibt. Ich denke, es ist perfekt für Add-Vorgänge, aber für andere Aufrufe ist es möglicherweise die falsche Wahl: Beispielsweise ist es für eine GET-Anfrage normalerweise besser, ExhaustMap oder SwitchMap zu verwenden, je nach Anwendungsfall.

Ich verwende auch einen Ansatz namens Pessimistisches Update, was bedeutet, dass ich auf das Ende des Anrufs warte, um meinen internen Zustand zu aktualisieren. Das ist eine persönliche Präferenz! Sie können die Aufgabe sofort hinzufügen und sie dann mit einem CatchError wiederherstellen, wenn beim API-Aufruf ein Fehler auftritt.

Dann gibt es noch die eigentliche Effektfunktion von Angular, die in Verbindung mit Signalen verwendet werden soll: Ich verwende diese Funktion für Synchronisationsaufgaben. Wenn sich beispielsweise ein Parameter in der URL ändert (der sich auf eine neue Entitäts-ID bezieht), möchte ich möglicherweise ein Formular mit der neuen Entität aktualisieren:

// This comes from the router
id = input.required<string>();

// Always stores the current invoice information
currentInvoice = toSignal(toObservable(this.id).pipe(
  switchMap(id => this.invoiceService.get(id))
));

constructor() {
  effect(() => {
    // Assuming the 2 structures match, every time we browse
    // to a new invoice, the form gets populated
    this.form.patchValue(this.currentInvoice());
  })
}
</string>

Beachten Sie, dass wir mit dieser Technik keine Kontrolle über den Gegendruck haben. Für so etwas ist es in Ordnung, aber denken Sie daran: Deshalb brauchen wir immer noch RxJS, um fehlerfreie Apps zu erstellen. Oder eine andere Bibliothek, die diese Komplexität unter der Haube abstrahiert.

Es ist nicht immer eine gute Idee, vollständig auf Reaktiv zu setzen

Viele Zustände, die wir mit Signalen darstellen, könnten technisch gesehen als abgeleitete asynchrone Zustände betrachtet werden. Beispielsweise könnte unsere Todo-Liste als abgeleiteter Status vom Server betrachtet werden:

// Trigger this when you need to refetch the todos
fetchTodos$ = new Subject<void>();

todos = toSignal(toObservable(this.fetchTodos$).pipe(
  switchMap(id => this.todoService.getAll())
));
</void>

Dieser Ansatz ähnelt dem von Bibliotheken wie TanStack Query verwendeten Ansatz, bei dem Sie eine Abfrage manuell ungültig machen, wenn Sie die neuen Daten benötigen. Mit anderen Worten, Sie gehen für jede Mutation immer zum Server.

Das mag in manchen Szenarien gut sein, aber es gibt zwei Dinge zu beachten:

1. Es erschwert die manuelle Aktualisierung des Status (optimistische Aktualisierungen). Dies wird durch Bibliotheken wie TanStack Query erleichtert, aber die manuelle Durchführung ist mühsam.
2. Es macht den Code für die meisten Entwickler etwas schwieriger zu verstehen, das ist es, was ich als Berater sehe, der täglich an solchen Dingen arbeitet.

Kurz gesagt, ich empfehle es normalerweise nicht. Und ich sagte normalerweise! :)

Conclusion

I hope you liked this short article! As a summary:

• Define your states as signals
• Define your derived states as computed signals
• Define your asynchronous effect as Observables
• Define your synchronozation effects with effects

I'm sure that if you follow these principles your apps will be much easier to maintain!

The above is the detailed content of How I structure my Angular components with Signals. For more information, please follow other related articles on the PHP Chinese website!