我如何使用信号构建我的 Angular 组件

Dans ce court article je souhaite vous montrer comment j'aime structurer mes composants avec des signaux, sans bibliothèque externe. Bien sûr, des choses comme NgRx joueraient un rôle énorme pour rendre notre code plus robuste, mais commençons simplement !

Tout d'abord je définis tous mes états avec des signaux :

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

Il en va de même pour les entrées ! Si mon composant a besoin d'une entrée, je le déclare avec la fonction new input() d'Angular, qui me donne également un signal. Et s'il s'agit d'un paramètre de route, j'utilise input.required().

Ensuite, si je veux montrer un état qui peut être dérivé d'un autre, j'utilise toujours calculé :

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

Alors, si vous me connaissez, vous savez à quel point je méprise l'exécution d'effets secondaires asynchrones directement dans les méthodes de classe... ?

export class TodoListComponent {
  todoService = inject(TodoService);

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

Pourquoi demandez-vous ? Parce que si la méthode est celle qui déclenche directement l'effet secondaire (dans ce cas, appeler l'abonnement), vous n'avez aucun contrôle sur la contre-pression.

La contre-pression peut se résumer ainsi : que se passe-t-il si l'utilisateur bascule la tâche alors que l'appel précédent n'est pas terminé ?

Il y a un certain nombre de problèmes, par exemple :

1. Voulons-nous même effectuer le deuxième appel ? Ou attendre que le premier ait fini ? Ou devrions-nous annuler le premier ?
2. Et si nous basculions différents éléments en peu de temps ?
3. Et si nous voulons introduire une sorte de anti-rebond ou de accélérateur ?

Si vous connaissez RxJS (et si vous lisez ceci, vous devriez le faire maintenant !) vous savez que le premier problème est facilement résolu avec les 4 opérateurs d'aplatissement (mergeMap, concatMap, switchMap, exhaustMap).

Ensuite, si vous connaissez bien RxJS, vous savez que vous pouvez résoudre le deuxième problème avec un opérateur génial appelé groupBy !

Mais pour utiliser toute cette bonté, vous devez avoir une source observable, donc... pas une méthode.

Sujets

Pensez à un sujet comme un observable ouvert (non terminé) et vide. C'est l'outil parfait pour représenter des événements personnalisés.

Tous les événements de notre composant peuvent être représentés par des Sujets :

export class TodoListComponent {
  ...

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

Ensuite, notre modèle peut simplement les appeler lorsque cela est nécessaire, au lieu d'appeler des méthodes, par exemple :

<button (click)="deleteTodo$.next(todo.id)">delete</button>

Maintenant que nos sources sont Observables, nous pouvons utiliser nos chers opérateurs : créons quelques effets.

Effets

J'aime définir mes effets à l'intérieur du constructeur afin de pouvoir utiliser l'opérateur takeUntilDestroyed() pour nettoyer l'effet lorsque le composant est détruit ! Ainsi, par exemple :

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

Ici j'utilise concatMap afin de conserver l'ordre des réponses, afin que les tâches soient ajoutées dans l'ordre. Cela signifie qu'il n'y a pas d'appels simultanés. Je pense que c'est parfait pour les opérations d'ajout, mais cela peut être un mauvais choix pour d'autres appels : par exemple, pour une requête GET, il est généralement préférable d'utiliser exhaustMap ou switchMap, selon le cas d'utilisation.

J'utilise également une approche appelée Mise à jour pessimiste, ce qui signifie que j'attends la fin de l'appel pour mettre à jour mon état interne. C'est une préférence personnelle ! Vous pouvez ajouter la tâche immédiatement, puis la rétablir en utilisant un catchError si l'API appelle des erreurs.

Ensuite, il y a la fonction d'effet d'Angular qui est destinée à être utilisée en conjonction avec des signaux : j'utilise cette fonction pour les tâches de synchronisation. Par exemple, lorsqu'un paramètre change dans l'URL (faisant référence à un nouvel ID d'entité), je souhaiterai peut-être mettre à jour un formulaire avec la nouvelle entité :

// 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());
  })
}

Remarquez que nous n'avons pas de contrôle sur la contre-pression avec cette technique. Pour ce genre de chose, c'est bien, mais rappelez-vous : c'est pourquoi nous avons toujours besoin de RxJS pour créer des applications sans bugs. Ou une autre bibliothèque qui résume cette complexité sous le capot.

Devenir complètement réactif n'est pas toujours une bonne idée

De nombreux états que nous représentons avec des signaux pourraient être techniquement considérés comme des états asynchrones dérivés. Par exemple, notre liste Todo pourrait être considérée comme un état dérivé du serveur :

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

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

Cette approche est similaire à celle utilisée par des bibliothèques telles que TanStack Query, dans lesquelles vous invalidez manuellement une requête lorsque vous avez besoin des nouvelles données. Autrement dit, vous vous rendez toujours sur le serveur pour chaque mutation.

Cela peut être une bonne chose dans certains scénarios, mais il y a 2 choses à considérer :

1. Cela rend difficile la mise à jour manuelle de l’état (mises à jour optimistes). Ceci est facilité par des bibliothèques telles que TanStack Query, mais le faire manuellement est pénible.
2. Cela rend le code un peu plus difficile à comprendre pour la plupart des développeurs, c'est ce que je vois en tant que consultant travaillant quotidiennement sur ce genre de choses.

En bref, je ne le recommande généralement pas. Et j'ai dit généralement ! :)

结论

我希望你喜欢这篇短文！总结一下：

• 将你的状态定义为信号
• 将派生状态定义为计算信号
• 将异步效果定义为 Observables
• 用效果定义您的同步效果

我确信，如果您遵循这些原则，您的应用程序将会更容易维护！

以上是我如何使用信号构建我的 Angular 组件的详细内容。更多信息请关注PHP中文网其他相关文章！