Un nouveau modèle mental pour la réactivité, pas seulement une nouvelle API –

Les signaux angulaires ne sont pas seulement une autre caractéristique. Ils représentent une façon différente de penser au flux de données. Si vous venez de RXJS ou Standard @Input() / @Output() liaisons, vous pourriez considérer les signaux comme une syntaxe plus simple pour les valeurs observables. Cependant, c’est comme dire qu’un violon n’est qu’un plus petit violoncelle. La forme de l’instrument affecte le type de musique que vous créez.

Dans cet article, je ne répéterai pas la documentation ou ne vous guiderai pas à travers un autre contre-exemple. Au lieu de cela, je vais présenter une nouvelle façon de penser que les signaux permettent, ainsi que de vrais défis auxquels j’ai été confronté en les utilisant en production.

Signaux comme variables réactives, pas les flux

Pensez aux signaux comme variables réactivespas de flux de données. C’est le changement clé de la perspective. Dans RXJS, nous poussons généralement des valeurs dans un flux, les combinons et répondons avec des effets secondaires via Subcribe (). Les signaux font tourner ce concept. Vous les lisez comme des variables. Angular suit automatiquement les dépendances et déclenche les réactions.

Voici la meilleure façon d’expliquer les signaux dans le code:

const firstName = signal('John');

const lastName = signal('Doe');

const fullName = computed(() => `${firstName()} ${lastName()}`);

Dans cet exemple, FullName est automatiquement recalculé lorsque FirstName ou LastName change. Vous n’avez pas besoin de penser en termes de logique de carte, de combinélate ou de démolition. Vous déclarez simplement les relations.

Si cela ressemble à Vue ou Solidjs, ce n’est pas une coïncidence.

Gotcha # 1: les dépendances implicites peuvent se retourner contre

Lorsque vous lisez à partir d’un signal à l’intérieur d’un calcul calculé () ou d’effet (), des pistes angulaires qui se lisent comme une dépendance. Mais cela peut mal tourner rapidement lorsque vous n’êtes pas au courant de ces lectures.

let counter = signal(0);

const doubled = computed(() => {

  console.log('Recomputing...');

  return counter() * 2;

});

Vous pouvez vous attendre à ce que cela fonctionne uniquement lorsque le compteur change, mais si vous lisez accidentellement un autre signal dans la même fonction (par exemple, un indicateur de journalisation), il devient également une dépendance. Soudain, le bascule d’un drapeau en mode de débogage commence à recalculer votre logique mathématique.

Conseil: Garder la logique calculée et affecter étroit et déterministe. Sinon, vous aurez des mises à jour fantômes que vous ne pouvez pas déboguer.

Signaux vs Rxjs: où les signaux brillent – et où ils ne le font pas

Soyons clairs: les signaux ne remplacent pas les RXJ. Ils sont conçus pour fonctionner à côté. Mais comprendre quand utiliser chacun est critique.

Les signaux excellent à la modélisation de la valeur dans le temps. RXJS excelle à la modélisation événements au fil du temps.

Gotcha # 2: les signaux calculés ne se cachent pas comme vous le pensez

Une chose surprenante que j’ai découverte: calculée () ne met pas en valeur comme UseMemo () de React ou même comme vous pourriez vous attendre d’un Getter.

Chaque fois que vous lisez à partir d’un signal calculé (), la logique remonte si ses entrées ont changé. Mais si vous l’appelez plusieurs fois dans un modèle (disons dans * ngif et encore dans {{}}), vous pouvez payer le coût plus d’une fois.

Conseil: Si un calcul est coûteux, envisagez de le stocker dans un const local dans la classe de composants et référençant cela dans le modèle. Ou enveloppez-le dans un autre signal.

Repenser la forme de l’état: les signaux aiment plat, pas profond

Dans Classic Angular avec les services et les RXJ, il est courant de modéliser l’état comme ceci:

const state$ = new BehaviorSubject({

  user: null,

  settings: {},

  isLoading: false

});

Dans les signaux, les objets réactifs profondément imbriqués sont gênants. Vous ne pouvez pas dire user (). Paramètres (). Thème () – c’est une lecture sur une lecture sur une lecture. Au lieu de cela, vous voudrez s’aplatir:

const user = signal<User | null>(null);

const settings = signal<Settings>({});

Conseil: Modélisez chaque élément d’état avec son propre signal. Vous obtiendrez une flexibilité et un contrôle de réactivité plus facile.

Scénario pratique: Personnalisation de l’étiquette de formulaire

Supposons que vous ayez un RecherchesideBarComponent et que vous souhaitez personnaliser ses étiquettes à partir d’un parent. Voici la manière naïve:

@Input() labels = signal<MapSidebarLabels>();

What happens if you try to derive a computed value?

labelsFinal = computed(() => {

  const raw = this.labels();

  return { ...raw, title: raw.title.toUpperCase() };

});

Maintenant, supposons dans le parent que vous écrivez:

<search-sidebar [labels]="labelsFinal()" />

Cela fonctionne, mais vous appelez un signal dans un signal. Et si vous modifiez votre modèle <search-sidebar [labels]="labelsFinal" />il échoue avec un décalage de type.

Conseil: Le système d’entrée d’Angular n’est pas encore entièrement natif du signal. Jusqu’à ce que ce soit, aplatir la valeur avant de passer les entrées.

Gotcha # 3: effet() Coule immédiatement – et peut-être encore

Contrairement à Rxjs sous-accroché (), qui ne tire que lorsque quelque chose émet, Effect () tire une fois sur la création, même si le signal n’a pas encore changé.

effect(() => {

  console.log("API call for", userId());

});

Cela s’exécutera une fois immédiatement, même si l’utilisateur n’a pas encore changé. Soyez prudent lorsque vous placez des effets secondaires comme les appels HTTP ou le suivi de l’analyse à l’intérieur de l’effet ().

Conseil: Guard Effect () Logic avec des vérifications nulles ou des rendements précoces si nécessaire.

Réflexions finales

Les signaux dans Angular ne sont pas seulement une nouvelle syntaxe, ils sont un changement dans le modèle mental. Une fois que vous arrêtez de penser dans les observables et commencez à penser dans des variables qui réagissent, vous constaterez que vos composants sont plus petits, plus rapides et plus faciles à raisonner.

Mais comme tout nouvel outil, les signaux sont livrés avec des arêtes vives. Connaître les compromis, apprendre les modèles, et surtout, Ne traitez pas les signaux comme des getters fantaisistes. Ils sont beaucoup plus puissants que cela, mais seulement si vous comprenez le modèle.