Comment gérer efficacement l'état dans Angular

La gestion de l’état fait la différence entre une application Angular qui évolue avec élégance et une application qui devient un cauchemar de maintenance. Pourtant, la plupart des développeurs se heurtent à une question fondamentale : quand faut-il opter pour les Signals, les services, RxJS ou NgRx ?

Cet article propose un cadre pratique pour choisir la bonne approche de gestion d’état Angular en fonction de vos besoins réels, et non de bonnes pratiques théoriques. Nous explorerons les cas où les Signals Angular brillent, où les services avec RxJS sont pertinents, et quand NgRx ou SignalStore deviennent nécessaires.

Comprendre la portée de l’état dans les applications Angular

Avant de choisir vos outils, comprenez la portée de votre état. Les applications Angular comportent généralement trois couches d’état distinctes, chacune nécessitant des stratégies de gestion différentes.

État local du composant

L’état local naît et meurt avec un seul composant. Pensez aux champs de formulaire, aux bascules d’interface utilisateur ou aux calculs temporaires. Pour ces scénarios, les bonnes pratiques d’état des composants Angular privilégient la simplicité : utilisez les Signals pour un état réactif ou de simples propriétés de classe pour des valeurs statiques.

@Component({
  selector: 'app-product-card',
  template: `
    <div [class.expanded]="isExpanded()">
      <button (click)="toggle()">{{ isExpanded() ? 'Less' : 'More' }}</button>
    </div>
  `
})
export class ProductCardComponent {
  isExpanded = signal(false);
  
  toggle() {
    this.isExpanded.update(v => !v);
  }
}

État partagé de la fonctionnalité

Lorsque plusieurs composants au sein d’une fonctionnalité ont besoin des mêmes données, les services deviennent votre point de coordination. Un panier d’achat qui apparaît dans l’en-tête, la barre latérale et la page de paiement nécessite une gestion centralisée, mais pas nécessairement un store global.

État global de l’application

Le statut d’authentification, les préférences utilisateur et les notifications à l’échelle de l’application affectent l’ensemble de votre application. C’est là que la gestion de l’état global dans Angular nécessite une réflexion approfondie sur le rapport complexité/maintenabilité.

Angular Signals : le choix moderne par défaut pour l’état réactif

Depuis Angular 16, les Signals offrent une réactivité fine sans la complexité des observables. Ils excellent dans les mises à jour d’état synchrones et les valeurs calculées.

Quand les Signals excellent

Utilisez les Signals lorsque vous avez besoin d’un état réactif qui :

• Se met à jour de manière synchrone
• Dérive des valeurs calculées efficacement
• S’intègre parfaitement avec la détection de changements d’Angular

@Injectable({ providedIn: 'root' })
export class CartService {
  private items = signal<CartItem[]>([]);
  
  // Computed signals update automatically
  total = computed(() => 
    this.items().reduce((sum, item) => sum + item.price * item.quantity, 0)
  );
  
  addItem(item: CartItem) {
    this.items.update(items => [...items, item]);
  }
}

L’avantage clé ? Les Signals éliminent les pièges courants de RxJS comme la gestion des souscriptions et les fuites mémoire, tout en offrant de meilleures performances grâce à des mises à jour granulaires.

État basé sur les services avec RxJS

Pour les opérations asynchrones et les flux de données complexes, les observables RxJS restent inestimables. Le débat Angular Signals vs NgRx manque souvent ce juste milieu : les services avec RxJS gèrent de nombreux scénarios réels sans surcharge de framework.

Combiner Signals et RxJS

Les applications Angular modernes bénéficient souvent d’approches hybrides :

@Injectable({ providedIn: 'root' })
export class UserService {
  private currentUser = signal<User | null>(null);
  
  // Expose as readonly signal
  user = this.currentUser.asReadonly();
  
  constructor(private http: HttpClient) {}
  
  loadUser(id: string) {
    return this.http.get<User>(`/api/users/${id}`).pipe(
      tap(user => this.currentUser.set(user)),
      catchError(error => {
        this.currentUser.set(null);
        return throwError(() => error);
      })
    );
  }
}

Ce modèle vous donne la simplicité des Signals pour le stockage d’état avec la puissance de RxJS pour les opérations asynchrones.

NgRx et SignalStore : quand la complexité exige de la structure

NgRx a du sens lorsque vous avez des exigences d’état véritablement complexes : collaboration multi-utilisateurs, mises à jour optimistes, débogage temporel ou coordination extensive entre fonctionnalités.

NgRx SignalStore : l’alternative légère

NgRx SignalStore et les Signals se combinent pour offrir de la structure sans code superflu. SignalStore fournit des modèles de gestion d’état tout en exploitant les performances natives des Signals d’Angular :

export const CartStore = signalStore(
  { providedIn: 'root' },
  withState(initialState),
  withComputed((state) => ({
    itemCount: computed(() => state.items().length),
    isEmpty: computed(() => state.items().length === 0)
  })),
  withMethods((store) => ({
    addItem: (item: CartItem) => 
      patchState(store, { items: [...store.items(), item] }),
    clear: () => 
      patchState(store, { items: [] })
  }))
);

SignalStore atteint le juste équilibre pour les applications qui ont besoin de plus de structure que les services mais moins de cérémonie que NgRx traditionnel.

Faire le bon choix : un cadre de décision pratique

Arrêtez de vous demander « quelle gestion d’état est la meilleure ? » et commencez à vous demander « de quoi cet état spécifique a-t-il besoin ? »

Utilisez directement les Signals lorsque :

• L’état est synchrone et local
• Vous avez besoin de valeurs calculées
• Les performances comptent pour des mises à jour fréquentes

Utilisez les Services avec Signals/RxJS lorsque :

• Plusieurs composants partagent l’état
• Vous gérez des opérations asynchrones
• La logique d’état est spécifique à une fonctionnalité

Envisagez NgRx SignalStore lorsque :

• Vous avez besoin de modèles cohérents entre les équipes
• Les interactions d’état deviennent complexes
• Vous voulez de la structure sans Redux complet

Adoptez NgRx traditionnel lorsque :

• Vous construisez des applications d’entreprise avec des exigences strictes
• Plusieurs développeurs ont besoin de modèles prévisibles
• Vous avez besoin de DevTools, de débogage temporel ou d’effets

Pièges courants à éviter

La plus grosse erreur en gestion d’état Angular n’est pas de choisir le mauvais outil, c’est la sur-ingénierie. Ne mettez pas chaque compteur dans NgRx. Ne créez pas de services pour un état exclusif à un composant. N’utilisez pas RxJS quand les Signals suffiraient.

Commencez simple. Extrayez vers des services lorsque les composants partagent l’état. Introduisez des stores lorsque les services deviennent ingérables. Cette approche incrémentale évite à la fois la sous-ingénierie et la sur-ingénierie.

Conclusion

Une gestion d’état efficace dans Angular ne consiste pas à choisir une seule approche pour tout. Les applications Angular modernes prospèrent grâce à des stratégies en couches : les Signals pour la réactivité locale, les services pour la logique partagée et les stores pour la coordination complexe.

Commencez avec les Signals par défaut. Passez aux services lorsque le partage devient nécessaire. Réservez NgRx, qu’il soit traditionnel ou SignalStore, pour les défis d’état véritablement complexes. Cette approche pragmatique maintient votre base de code maintenable tout en évitant l’optimisation prématurée.

La meilleure stratégie de gestion d’état est la plus simple qui résout votre problème réel.

FAQ

Gain Debugging Superpowers

Unleash the power of session replay to reproduce bugs, track slowdowns and uncover frustrations in your app. Get complete visibility into your frontend with OpenReplay — the most advanced open-source session replay tool for developers. Check our GitHub repo and join the thousands of developers in our community.