Services & gestion d'état : le store à signals

La leçon 11 a mis l'état des postes dans un service. Mais un signal public au milieu d'un service, ce n'est pas encore une gestion d'état : n'importe qui peut le muter, la logique fuit dans les composants, les dérivations se dupliquent. Cette leçon transforme PosteService en un vrai store léger : état privé, sélecteurs dérivés, actions — une seule porte d'écriture. Et on répond à la question que tout lead se pose : quand ça suffit, et quand sortir l'artillerie (NgRx).

1. Trois rôles à séparer : état, sélecteurs, actions

Un store, même léger, distingue trois choses. C'est la clé pour ne pas retomber dans le chaos :

2. Le store en pratique — PosteService v2

On reprend le service de la leçon 11 et on le structure. L'état devient entièrement privé ; on n'expose que des sélecteurs en lecture seule et des actions.

import { Injectable, signal, computed, inject } from '@angular/core';
import { HttpClient } from '@angular/common/http';

type Statut = 'idle' | 'chargement' | 'prêt' | 'erreur';

@Injectable({ providedIn: 'root' })
export class PosteService {
  private http = inject(HttpClient);

  // ── ÉTAT : privé, seul le service écrit ──
  private _postes = signal<Poste[]>([]);
  private _filtre = signal<'tous' | 'actifs'>('tous');
  private _statut = signal<Statut>('idle');

  // ── SÉLECTEURS : dérivés, exposés en lecture seule ──
  readonly statut = this._statut.asReadonly();
  readonly postes = computed(() =>
    this._filtre() === 'actifs'
      ? this._postes().filter(p => p.actif)
      : this._postes());          // la liste filtrée, calculée UNE fois
  readonly nbPostes = computed(() => this.postes().length);

  // ── ACTIONS : les seules portes d'écriture ──
  charger() {
    if (this._statut() === 'prêt' || this._statut() === 'chargement') return; // idempotent : un seul fetch
    this._statut.set('chargement');
    this.http.get<Poste[]>('/api/postes').subscribe({
      next: list => { this._postes.set(list); this._statut.set('prêt'); },
      error: () => this._statut.set('erreur'),
    });
  }

  definirFiltre(f: string) {                 // l'action valide l'entrée à la frontière
    this._filtre.set(f === 'actifs' ? 'actifs' : 'tous');
  }
}

Regarde ce que ça donne : le filtrage n'est écrit qu'une fois (le computed postes), l'état de chargement est explicite (un signal statut, pas trois booléens éparpillés), et aucun composant ne peut écrire dans _postes ou _filtre — ils passent forcément par une action.

const Statut = {
  Idle: 'idle', Chargement: 'chargement', Pret: 'prêt', Erreur: 'erreur',
} as const;
type Statut = typeof Statut[keyof typeof Statut]; // 'idle' | 'chargement' | 'prêt' | 'erreur'

this._statut.set(Statut.Chargement); // se lit comme un enum, mais c'est une union de strings

Astuce : const Statut (la valeur) et type Statut (le type) peuvent porter le même nom — TypeScript les range dans deux espaces distincts. Le reste de la leçon garde l'union nue pour rester lisible, mais retiens le pattern as const dès qu'un jeu de valeurs se répète.

3. Le composant devient « bête » (et c'est le but)

Une fois l'état et la logique dans le store, le composant se réduit à : lire des sélecteurs, appeler des actions. Il ne décide plus rien.

@Component({
  selector: 'app-liste-postes',
  standalone: true,
  template: `
    <select #filtre (change)="store.definirFiltre(filtre.value)">
      <option value="tous">Tous</option>
      <option value="actifs">Actifs</option>
    </select>

    @switch (store.statut()) {
      @case ('chargement') { <p>Chargement…</p> }
      @case ('erreur')     { <p>Erreur de chargement.</p> }
      @default {
        <p>{{ store.nbPostes() }} poste(s)</p>
        <ul>
          @for (p of store.postes(); track p.id) { <li>{{ p.nom }}</li> }
        </ul>
      }
    }
  `,
})
export class ListePostesComponent {
  protected store = inject(PosteService);
  constructor() { this.store.charger(); }
}

Zéro logique métier dans le composant : il branche des sélecteurs (store.postes(), store.statut()) au template et délègue les intentions (definirFiltre) au store. Un deuxième écran qui affiche les mêmes postes injecte le même service et voit le même état, filtre compris — gratuitement (leçon 11).

4. Quand ça suffit, quand sortir NgRx

Ce store à signals couvre l'écrasante majorité des écrans ERP. La question de lead n'est pas « quel framework d'état ? » mais « ai-je vraiment besoin de plus ? ». Repères :

5. Vérifie ta compréhension