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 :
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.
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.
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.
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 :
En bref, je ne le recommande généralement pas. Et j'ai dit généralement ! :)
我希望你喜欢这篇短文！总结一下：
我确信，如果您遵循这些原则，您的应用程序将会更容易维护！
以上是我如何使用信号构建我的 Angular 组件的详细内容。更多信息请关注PHP中文网其他相关文章！
