DEV Community: Romain Geffrault

@craft-ng: Associer l’art de la composition & du state management dans Angular

Romain Geffrault — Wed, 01 Apr 2026 17:33:31 +0000

Quand je construis une feature Angular un peu sérieuse, je veux toujours la même chose:

une seule source de vérité
un flux de données clair
un code composable
une DX solide
et surtout une type-safety qui m'évite de jouer aux devinettes
des outils pour pensés pour simplifier l'UX/UI

C'est exactement l'objectif de @craft-ng.

Une lib complète de state management pour tous les types d'état d'une application:

client state: états locaux, listes, UI, sélection...
server state: chargement, cache, mutation, pagination, optimistic update...
URL state: query params synchronisés, type-safe, avec fallback

Des utilitaires prêts à l'emploi pour se rendre la vie plus facile.

Une approche Method-based ou Event-based pour s'adapter à tous les styles de code.

Qu'ils soient simples ou complexes, le principe reste toujours le même.

Les « primitives », basées sur les signals, ont chacune leur rôle et portent un state et sa logique.
Elles sont utilisables directement dans les composants et les services.
Elles suivent toutes le même principe : primitive(config, insertion1, insertion2, ...).
Les insertions servent à ajouter de la logique (modifiers, réactions, états dérivés, method-based/event-based...).
Ce pattern, combiné aux utilitaires de craft-ng insert..., permet d'obtenir un niveau inégalé de composition, offrant une gestion fluide aussi bien pour les cas simples que complexes.
Un store craft est disponible pour orchestrer ces primitives. Il peut être composé par d'autres stores, et être lui-même composable.

Dans cet article, je vais:

présenter la structure commune des primitives
montrer comment exposer méthodes, état dérivés, et réagir à un événement via les insertions
donner un exemple concret pour chaque primitive
faire un tour rapide des insertions utiles
expliquer pourquoi source$ (event-based) change vraiment la façon de structurer le state
terminer avec injectService et le store craft

⚠️ @craft-ng est une librairie experimentale. Je ne recommande pas de l'utiliser en production pour le moment. Cet article est avant tout un partage des concepts.

La doc: https://ng-angular-stack.github.io/craft/

1) Une structure commune à toutes les primitives

Que tu utilises state, query, mutation, asyncProcess ou queryParam, la logique de composition reste la même:

une configuration de base
des insertions pour exposer des méthodes / des états dérives / des réactions

import { computed } from '@angular/core';

const counter = state(
  0, // config
  // insertion 1
  ({ set, update }) => ({
    increment: () => update((current) => current + 1),
    reset: () => set(0),
  }),
  // insertion 2
  ({ state }) => ({
    isOdd: computed(() => state() % 2 === 1),
  }),
);

counter.increment();
counter.isOdd();

Ce point est clé: tu n'apprends pas 5 APIs différentes, tu apprends un modèle mental unique.

2) Les primitives: fonctionnement + exemples concrets

Dans la pratique, chaque primtive apporte ses fonctionnalités qui lui sont propres, et le composant/service/store m'aide à les orchestrer.

state

state gère le client state synchrone.
C'est la base pour modéliser un état client, global ou local, le composer, et le spécialiser.

Combiné à insertSelect, le state devient redoutable pour gérer des structures imbriquées de manière fluide et type-safe.

type User = { id: string; name: string; selected: boolean };

const usersState = state(
  {
    filters: { search: '' },
    users: [] as User[],
  },
  insertSelect('filters', ({ set }) => ({
    set,
  })),
);

usersState.selectFilters().set('@craft-ng');

Ce que j'aime ici:

les méthodes suivent la structure du state
la lecture du code reste directe

Pourquoi avoir créé un state alors qu'il y a déjà les signals d'Angular ?

pour bénéficier du système de composition via les insertions
exposer les méthodes qui modifient l'état pour le rendre prédictif
encapsuler toute la logique qui lui est associée

mutation

mutation: sert a modifier (UPDATE/PUT/PATCH/DELETE) des données cote serveur.

Version méthode directe avec .mutate(...):

const updateUser = mutation({
  method: (payload: { id: string; name: string }) => payload,
  loader: async ({ params }) => {
    const response = await fetch(`/api/users/${params.id}`, {
      method: 'PATCH',
      body: JSON.stringify(params),
    });
    return response.json() as User;
  },
});

updateUser.mutate({ id: '42', name: 'Romain' });

On peut aussi les appeler en parallèle, avec des identifiers, pour gérer des cas plus complexes (cf. l'exemple dans full-demo).

Pourquoi avoir créé une mutation alors qu'il y a déjà les resources d'Angular ?

pour bénéficier du système de composition via les insertions
permettre des appels api en parallèle via les identifiers
retourner des craftException typés en cas d'erreur métier (ex: validation), pour ne pas perdre d'information et offrir la meilleure UX/UI à tes utilisateurs
peut s'appeler comme une méthode directe myMutationRef.mutate(...)

query

query: gère le server state (chargement, valeur, erreur, cache) et peut tourner en parallèle via identifier (ex: pour faire de la pagination).

C'est la primitive qui est faîte pour représenter une ressource distante, avec des utilitaires pour gérer le cache, les updates liés aux mutations, la pagination...

Avec insertPaginationPlaceholderData + insertReactOnMutation, on obtient:

une pagination fluide
des updates réactifs liés aux mutations (optimistic update/patch, auto reload).
moins de code impératif

import {
  insertPaginationPlaceholderData,
  insertReactOnMutation,
  mutation,
  query,
} from '@craft-ng/core';

const updateUser = mutation({
  method: (payload: { id: string; name: string }) => payload,
  loader: async ({ params }) => params,
});

const page = signal(1);
const usersQuery = query(
  {
    params: page,
    identifier: (page) => `${page}`,
    loader: async ({ params: currentPage }) =>
      fetch(`/api/users?page=${currentPage}`).then((r) => r.json()),
  },
  insertPaginationPlaceholderData,
  insertReactOnMutation(updateUser, {
    patch: {
      name: ({ mutationParams }) => mutationParams.name,
    },
  }),
);

Pourquoi avoir créé une query alors qu'il y a déjà les resources d'Angular ?

pour bénéficier du système de composition via les insertions
permettre des appels api en parallèle via les identifiers
retourner des craftException typés en cas d'erreur métier (ex: validation), pour ne pas perdre d'information et offrir la meilleure UX/UI à tes utilisateurs

asyncProcess

asyncProcess est idéal pour des traitements async qui ne sont pas strictement des queries/métiers CRUD (debounce, wrappers API natives, orchestration).

import { asyncProcess } from '@craft-ng/core';

const delaySearch = asyncProcess({
  method: (term: string) => term,
  loader: async ({ params: term }) => {
    await new Promise((resolve) => setTimeout(resolve, 250));
    return term;
  },
});

delaySearch.safeValue(); // undefined
delaySearch.status(); // 'idle'
delaySearch.method('@craft-ng');
delaySearch.status(); // 'loading' -> after 250ms -> 'resolved'
delaySearch.safeValue(); // '@craft-ng'

Pourquoi avoir créé un asyncProcess alors qu'il y a déjà les resources d'Angular ?

permet de profiter du système de composition via les insertions
retourner des craftException typés en cas d'erreur métier

queryParam

queryParam synchronise l'état avec l'URL, tout en restant type-safe (parse/serialize/fallback).

import { queryParam } from '@craft-ng/core';

const tableParams = queryParam(
  {
    state: {
      page: {
        fallbackValue: 1,
        parse: (v) => parseInt(v, 10),
        serialize: (v) => String(v),
      },
      search: {
        fallbackValue: '',
        parse: (v) => v,
        serialize: (v) => v,
      },
    },
  },
  ({ patch, reset }) => ({ patch, reset }),
);

tableParams.patch({ page: 2 });

Pourquoi avoir créé un queryParam alors qu'on peut utiliser withComponentInputBindingpour récupérer un query param dans un input ?

queryParam peut être utilisé dans un service providé au niveau du composant
possède une valeur de fallback en cas de non présence du query param ou d'une valeur invalide
permet de modifier ce query param via les insertions
profite du système de composition via les insertions
permet de retourner des craftException typés en cas d'erreur métier au parse d'un query param

Exemples de la doc qui m'ont inspiré

Si tu veux voir des versions plus complètes des patterns présentes ici, je te conseille particulièrement:

les exemples primitives (query, mutation, full demo): https://ng-angular-stack.github.io/craft/examples
l'approche list-with-pagination pour visualiser insertPaginationPlaceholderData en contexte
les exemples Pixel Art / Pixel Art Matrix pour voir insertSelect sur des structures plus profondes
la section exceptions pour les cas métier avec erreurs type-safe, pour ne pas perdre d'information et offrir la meilleure UX/UI à tes utilisateurs

Ces exemples m'ont servi de base pour structurer les snippets de cet article.

3) Exposer des méthodes et état dérivé avec les insertions (Method-based)

Tu peux partir simple, puis enrichir sans casser le contrat initial.

Method-based insertions

import { state } from '@craft-ng/core';
const counter = state(0, ({ update, set }) => ({
  increment: () => update((current) => current + 1),
  decrement: () => update((current) => current - 1),
  reset: () => set(0),
}));
console.log(counter()); // 0
counter.increment();
console.log(counter()); // 1
counter.reset();
console.log(counter()); // 0

Source-based insertions (Event-based)

import { source$, state, on$ } from '@craft-ng/core';

const incrementTrigger$ = source$<void>();
const resetTrigger$ = source$<void>();
const counter = state(0, ({ set }) => ({
  increment: on$(incrementTrigger$, () => set((v) => v + 1)),
  reset: on$(resetTrigger$, () => set(0)),
}));
console.log(counter()); // 0
incrementTrigger$.emit();
console.log(counter()); // 1
resetTrigger$.emit();
console.log(counter()); // 0

Créer de la logique réutilisable est très simple

Tu peux extraire une insertion dans une fonction custom et la rebrancher partout:

const counter = state(0, (context) => myCustomFn(context));

Implémentation simple (dans cet esprit):

const myCustomFn = ({
  update,
  set,
  state,
}: {
  update: (updater: (v: number) => number) => void;
  set: (value: number) => void;
  state: Signal<number>;
}) => ({
  increment: () => update((current) => current + 1),
  decrement: () => update((current) => current - 1),
  reset: () => set(0),
  isOdd: computed(() => state() % 2 === 1),
});

const myState = state(0, (context) => myCustomFn(context));

myState.increment();
myState.isOdd();

Pour les cas plus poussés, j'étudie différents patterns pour que ca reste aussi simple que possible cote API et usage.

4) Tour rapide de quelques insertions utiles

Voici quelques insertions qui me semblent particulièrement utiles pour gérer des cas courants. Je ferai un focus dessus dans de prochains articles.

insertPaginationPlaceholderData (query)

Pour garder les données de la page precedente pendant le chargement de la suivante.
Resultat: UX plus fluide, moins de flicker.

insertReactOnMutation (query)

Pour synchroniser automatiquement le cache query avec le resultat d'une mutation (patch/optimistic/reload selon le besoin).

insertLocalStoragePersister (state/query/asyncProcess)

Pour persister et rehydrater automatiquement avec localStorage.
Tres utile pour garder l'état entre sessions.

insertEntities (state)

Pour manipuler des collections avec des utilitaires prets a l'emploi (add, set, update, remove, upsert...), en restant type-safe.

insertSelect (state)

Pour cibler un sous-arbre d'état et exposer des méthodes/dérives au bon endroit.
Hyper utile sur des structures imbriquées. (Prochainement disponible)

5) Pourquoi source$ est un vrai levier d'architecture

source$ est l'outil que j'utilise pour garder des states granulaires sans perdre la simplicite d'orchestration.

Cela correspond grosso-modo à un subject dans RxJS.

Cas 1: plusieurs states réagissent au même événement

Au lieu d'un gros state qui gère tout, plusieurs states petits et lisibles peuvent réagir au même trigger.

import { on$, source$, state } from '@craft-ng/core';

const resetFilters$ = source$<void>();

const search = state('', ({ set }) => ({
  set,
  reset: on$(resetFilters$, () => set('')),
}));

const page = state(1, ({ set }) => ({
  set,
  reset: on$(resetFilters$, () => set(1)),
}));

resetFilters$.emit();

Ca donne:

responsabilités claires
meilleure DX
flux de mise à jour plus facile à raisonner

Et surtout: tu peux commencer avec une méthode exposée, puis migrer vers une réaction on$ sans rearchitecture lourde.

Cas 2: state imbriqué + insertSelect

Dans des structures profondes, insertSelect permet d'associer des méthodes et des états dérivés à une niveau plus profond.
Parfois, j'utilise source$ à un haut niveau, puis je réagis à cette source$ depuis des niveau imbriqués.
Cela me permet de modifier l'état au plus proche de l'endroit où il est modifié.

Pour les states complexes avec des imbrications, le modèle mentale devient plus souple et plus facile à raisonner.

Cas 3: event-driven (et pont avec Observable)

source$ + on$ permettent de réagir à des événements, y compris depuis un Observable.
Pour ceux qui aiment l'event-driven, c'est très naturel.

Et si tu veux rester dans un style state-driven et réagir à des changements d'état, il y a aussi:

reactiveWritableSignal

Dans cet exemple, ce me permet de créer un linkedSignal, qui réagit à des changements d'états de d'autres signals.
Cela me permet retirer les ids qui ont été supprimés de la sélection, sans devoir faire du code impératif pour écouter les changements de page et de suppression.

const selectedIds = reactiveWritableSignal([] as string[], (sync) => ({
  resetWhenCurrentPageIsResolved: sync(
    users.currentPageStatus,
    ({ params, current }) => (params === 'resolved' ? [] : current),
  ),
  resetWhenBulkDeleteIsResolved: sync(
    bulkDelete.status,
    ({ params, current }) => (params === 'resolved' ? [] : current),
  ),
})); // WritableSignal<string[]>

afterRecomputation : qui déclenche son callBack si le résultat de sa source n'est pas undefined.
toSource: transforme un signal en source. La première lecture d'une source renverra toujours undefined, puis dès que la source change, le résultat sera synchronisé.

6) La philosophie continue avec injectService

injectService permet de construire une facade typée au-dessus d'un service Angular .
Tu exposes uniquement ce qui est utile au cas d'usage, tu dérives proprement, et tu gardes la maitrise de l'API publique.

import { computed } from '@angular/core';
import { injectService } from '@craft-ng/core';

const checkout = injectService(
  CheckoutService,
  ({ cart, total, submitOrder }) => ({
    total,
    itemCount: computed(() => cart().length),
    submit: submitOrder,
  }),
  ({ insertions }) => ({
    canSubmit: computed(() => insertions.itemCount() > 0),
  }),
);

checkout.canSubmit();

7) Et au-dessus: le store `craft`

La lib expose aussi un store craft, toujours basé sur la composition, la type-safety et le découplage.
Tu peux composer states, queries, mutations, sources, inputs et query params dans une architecture cohérente, sans perdre le contrôle fin.

Plus de détails dans un prochain article, sinon il y a la doc ;D

Conclusion

Si je devais résumer @craft-ng en une phrase:
composer des briques simples pour gérer des logiques complexes, sans quitter un modèle déclaratif/reactif/type-safe.

Et la lib ne s'arrête pas là.
A l'heure où j'écris cet article, d'autres utilitaires arrivent dans la même philosophie.

Le prochain utilitaire, si je devais n'en partager qu'un :

un formulaire à la pointe de la technologie (en plus de tout ce que permet le signal form d'Angular):
- création de formulaire en parallèle
- intégration avec les autres primitives (pour le submit, et les validations asynchrones)
- gestion fine des erreurs (validation, submit, async validators), tout est inféré, permettant d'avoir la liste exhaustive des erreurs associées à un champ.
- Gestion de la logique interdépendante grâce aux mécanismes de composition offerts par la lib.

(Actuellement, j'ai un wrapper du signalForm, mais j'ai 2 cas qui sont impossibles à gérer. J'attends un peu de voir si Angular permet d'étendre le signalForm, ou si je dois faire une implémentation custom pour garder la philosophie de composition et de type-safety.)

N'hésite pas à aller voir la doc ou à mettre une étoile sur le repo si tu veux suivre l'évolution de la lib, ou à me faire un retour si tu as des idées d'amélioration !

Je suis Romain Geffrault.
Développeur Angular et créateur de @craft-ng
Suis-moi pour plus de contenu sur Angular

Docs: https://ng-angular-stack.github.io/craft/

Use Angular HostDirective for all of your component facades

Romain Geffrault — Fri, 19 Dec 2025 06:16:17 +0000

I really like the component HostDirective pattern, which enables logic composition.

I use it each time I want to reuse UI/UX logic in my dumb component.

But recently, I realized that I can use HostDirective to write my component facade.

While there are already some great articles that talk about hostDirective for dumb component.

Let's explore, why you should use HostDirective for your component facade.

What are HostDirectives ?

Host directives allow you to attach a directive to a component without needing to reference it explicitly in the template. They enable behavior composition, code reuse, and cleaner templates.

Attach directives directly to components
Share logic without template pollution
Expose properties and methods from directives
Simplify architecture and improve reusability

Simple Example

// This directive adds hover behavior to an element
@Directive({
  selector: "[appHover]",
  standalone: true,
})
export class HoverDirective {
  @HostBinding("style.background") bg = "transparent";

  @HostListener("mouseover")
  onHover() {
    this.bg = "lightblue";
  }

  @HostListener("mouseout")
  onOut() {
    this.bg = "transparent";
  }
}

// Component using HoverDirective as a hostDirective
@Component({
  selector: "app-card",
  template: `<p>Hover me!</p>`,
  standalone: true,
  hostDirectives: [HoverDirective],
})
export class CardComponent {}

The component automatically inherits the hover behavior without needing to add the directive in the template.

Share directive inputs/outputs

It is also possible from the component, to expose the inputs/outputs of the directive.

@Component({
  selector: "admin-menu",
  template: "admin-menu.html",
  hostDirectives: [
    {
      directive: MenuBehavior,
      inputs: ["menuId"],
      outputs: ["menuClosed"],
    },
  ],
})
export class AdminMenu {}

Check the official doc about HostDirective, that show other options.

Now, let's create a component facade to see how perfect they are for this case.

Create a component facade directive

For this demo, I will create a counter directive, that will be used as a facade for the child counter component.

The counter directive will have a value and 2 method increase and decrease.

It will also expose isOdd$ output.

@Directive({ standalone: true })
export class ChildCounterFacadeDirective {
  public readonly counterValue = model<number>(0);

  public readonly isOdd = computed(() => !!(this.counterValue() % 2));

  public readonly isOdd$ = outputFromObservable(toObservable(this.isOdd));

  public increase() {
    this.counterValue.update((v) => v + 1);
  }

  public decrease() {
    this.counterValue.update((v) => v - 1);
  }
}

How to implement the counter facade directive in a component

The child counter component will use the counter directive as a facade.

import { ChangeDetectionStrategy, Component, inject } from "@angular/core";
import { ChildCounterFacadeDirective } from "./child-counter-facade.directive";

@Component({
  selector: "app-child-counter",
  changeDetection: ChangeDetectionStrategy.OnPush,
  hostDirectives: [
    {
      directive: ChildCounterFacadeDirective,
      inputs: ["counterValue"],
      outputs: ["counterValueChange", "isOdd$"],
    },
  ],
  template: `
    Child Counter: {{ childCounterFacadeDirective.counterValue() }}

    <button (click)="childCounterFacadeDirective.increase()">Increase</button>
    <button (click)="childCounterFacadeDirective.decrease()">Decrease</button>
  `,
})
export class ChildCounterComponent {
  protected readonly childCounterFacadeDirective = inject(
    ChildCounterFacadeDirective
  );
}

ChildCounterFacadeDirective is only referenced in hostDirectives You do not need to import and provide ChildCounterFacadeDirective
'counterValue' is exposed as an input
'counterValueChange' is exposed as an output
'isOdd$' is exposed as an output
ChildCounterFacadeDirective is injected in the component and can be directly used in the template

As you can see, using a host directive instead of a service reduces drastically the code.

You do not need to struggle to create input / outputs in your component then to pass this value to your service...

So the component looks very clean.

Let's see how the parents can interact with the child counter component.

How to interact with a child component that use an host directive ?

@Component({
  selector: "app-root",
  imports: [ChildCounterComponent],
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `
    <div>parentValue: {{ parentValue() }}</div>
    <app-child-counter
      [(counterValue)]="parentValue"
      (isOdd$)="isOdd($event)"
    />

    @if(logCD()) {
    <div></div>
    }
  `,
})
export class App {
  protected parentValue = signal(10);

  isOdd(isOdd: boolean) {
    console.log("isOdd", isOdd);
  }

  logCD() {
    console.log("CD run");
    return false;
  }
}

After importing the child component, it still one line:
<app-child-counter [(counterValue)]="parentValue" (isOdd$)="isOdd(($event))"/>

The app-child-counter looks like a regular component.

That's why I like this pattern, it looks the same from outside, but it helps to remove almost all logic from our component.

I do not say that you should implement a facade for each component. It is your decision.

There are some limitations about this pattern that you may appreciate.

Facade directive - Demo link

Here you can find a stackblitz demo

HostDirective facade pattern limitations

It is not possible to derive a service to a directive.

For eg. if you rely on SignalStore to create your component facade, you can not generate a directive or something that can be used as an hostDirective.

I hope, Angular will evolve and enable this kind of pattern.

(Maybe with the selectorless feature)

My point of view about Angular input/output

Even if I am used to component and directive inputs / outputs, this is a weird concept.

I think this concept can be removed and I think Angular should allow to bind all public properties and methods.

All public is bindable.

It will enable to write a component, almost like you write a service.

Conclusion

HostDirective is an awesome pattern, mainly because it allows to compose your component logic.

Creating a directive for facade component logic reduces the needed code.

If you like this article, please add a like, or a comment.

Have you already used hostDirective like that?

Follow me on LinkedIn for an Angular content.
👉 Romain Geffrault

My other articles that you may like:

99% of Angular developers don’t know that Signals can be used this way.

Romain Geffrault — Thu, 18 Dec 2025 07:41:43 +0000

Mastering Angular Signals: Understanding Angular Signal Recomputation Reactions (part 2)

Romain Geffrault ・ Dec 2

#rxjs #angular #typescript

StoryTime Angular : mon blog, le SEO et le choc du SSR

Romain Geffrault — Sun, 14 Dec 2025 17:47:11 +0000

Mon premier gros projet Angular, ce n’est pas une app d’entreprise ni un side project à moitié fini.

C’est mon blog sur le sommeil.

À l’époque, je voulais lancer un vrai site, en production, avec de vraies contraintes : contenu, SEO, performance, déploiement… et surtout avec Angular pour monter en compétence.

Un backend simple, volontairement

Côté backend, j’ai fait un choix très pragmatique : PHP pur.

Pourquoi ?

J’en avais déjà fait auparavant
C’est ultra simple à héberger
Pas besoin d’une infra compliquée pour un blog

Le backend servait surtout d’API basique pour gérer les articles. Rien de fancy, mais efficace.

Angular sans IA… et ça marchait quand même

La création du blog s’est plutôt bien passée.

À l’époque, pas d’IA pour mâcher le travail, mais avec de la doc, de la débrouille et beaucoup de tests, j’ai réussi à sortir une première version assez rapidement.

J’avais choisi Angular pour une raison simple :

👉 je le connaissais déjà un peu, et je voulais vraiment monter en niveau dessus.

Écrire du contenu : beaucoup plus dur que coder

Là où j’ai sous-estimé le travail, c’est sur la création de contenu.

Peu de connaissances en SEO
Première vraie expérience d’écriture régulière
Doutes constants sur la qualité de ce que je produisais

Clairement, écrire est un métier à part entière.

Un outil maison pour publier mes articles

Plutôt que d’écrire directement dans une interface web, j’ai monté mon propre outil de publication.

Mon workflow :

J’écrivais mes articles sur Google Docs
Je les importais dans mon outil Angular
L’import était (au début) semi-automatique

Et là, apprentissage inattendu : les regex.

Google Docs rajoute énormément de balises, de styles et de déchets HTML.

Pour nettoyer tout ça correctement, j’ai passé des heures à :

comprendre les regex
les tester
les casser
les améliorer

C’est clairement à ce moment-là que je suis devenu à l’aise avec les expressions régulières.

Le mur du SEO et du CSR

Une fois le blog en ligne… grosse déception.

Mes pages étaient mal indexées, voire pas du tout visibles sur Google.

C’est là que j’ai appris une chose essentielle :

Google n’aime pas (ou en tout cas ne recommande pas) les sites en Client Side Rendering pour le SEO.

Mon blog Angular était entièrement en CSR.

Angular Universal : la plus grosse galère de ma vie Angular

La solution semblait évidente : Angular Universal (à l’époque).

En pratique ?

👉 Un enfer.

Je crois sincèrement que je n’ai jamais autant galéré sur une feature.

Très peu de documentation
Presque aucun tutoriel clair
Peu de retours d’expérience
Personne autour de moi qui faisait ça

Déployer du SSR quand on n’a jamais touché à un serveur

Autre mur : le déploiement.

Je n’avais jamais vraiment :

configuré un serveur
géré des ports
compris comment faire tourner un serveur Node derrière un site existant

J’ai dû apprendre sur le tas :

comment exposer Angular Universal
comment faire cohabiter PHP et Node
comment ne pas tout casser en prod

C’était dur, frustrant… mais extrêmement formateur.

Les meta tags dynamiques : autre combat

Autre point ultra pénible :

👉 les meta tags dynamiques par page

À l’époque :

quasiment aucune doc
très peu d’exemples concrets

J’ai mis beaucoup de temps à comprendre comment faire ça proprement, avant de découvrir Renderer2, qui m’a enfin permis de manipuler le DOM correctement côté serveur.

Avec le recul

Avec le temps :

Angular a énormément évolué
Le SSR est devenu plus accessible
Les outils sont plus matures
La documentation est bien meilleure

Aujourd’hui, mettre en place ce genre de projet SSR est beaucoup plus simple qu’à l’époque (et encore ?).

Mais cette expérience reste, pour moi, l’une des plus formatrices :

Angular en profondeur
SEO réel, pas théorique
déploiement
serveur
contraintes de production

Bref, un projet imparfait, mais une énorme étape dans mon parcours de développeur frontend.

Maintenant, il date un peu, mais il semble toujours util pour les visiteurs.

Le lien, si cela t'intéresse:
sommeilprofond.fr

Follow me on LinkedIn for an Angular Advent calendar.
👉 Romain Geffrault

Create Your Own TanStackQuery In Angular 🤝 RxJs

Romain Geffrault — Thu, 11 Dec 2025 18:07:39 +0000

I have a project that is stuck on Angular v13 and cannot upgrade to newer versions, but I needed to implement a declarative server state tool that greatly simplifies the developer experience.

In this series of articles, I will share a complete declarative server state tool built entirely with RxJS and compatible with older Angular versions.

When talking about server state management, we often think about TanStack Query. We will not implement all of its functionalities, but you will have the right fundamentals to build them.

I do not adopt the same philosophy as TanStack Query; my utilities react declaratively while preserving type safety.

I worked extensively on my personal state management tool, which includes server state management, using only Signals.

I learned a lot about the problem and some declarative ways to manage it.

So I decided to create an RxJS tool that you can easily use in your project.

First, I'll introduce the fundamental building blocks: resource$ and resourceByGroup$.

Then, in subsequent articles, I'll cover more advanced utilities: query$, mutation$, and asyncMethod.

What `resource$` will enable for server state management?

The Angular official resources are mainly used to track async data fetching.

It is pretty straightforward to implement that kind of behavior with RxJS.

But I chose to add more advanced features that are not exposed in Angular resources, because we will use it as our custom implementation to create a server state management tool.

Here is what my resource$ can do:

track async request status
catch errors
accept a local value
reload on demand

RxJS offers some behaviors that are relatively easy to implement and very convenient when dealing with server state:

repeat the stream when completed (more or less the equivalent of a reload)
declarative server state reactions are easier to write, which enables:
- optimistic update / update ...
- fallback on error...

One more thing: our resource$ utility can also be used for mutations (POST/PUT/PATCH/DELETE). However, I'll still provide a mutation$ implementation that makes your code more concise and composable.

`resource$` usage and implementation

Here is my implementation, which also preserves the latest value by default.

This means that when a new request is made, the previous value remains available, which avoids screen flickering.

Usage:

  private readonly destroy$ = new Subject();
  ngOnDestroy() {
    this.destroy$.next();
    this.destroy$.complete();
  }


  protected readonly myResource$ = resource$({
    params$: this.id$,
    loader: ({ params: id }) =>
      this.checksService.getCheck$(id),
    destroy$: this.destroy$
  });

  // in the template:
  <ng-container *ngIf="myResource$ | async as myResource">
   hasValue: {{myResource.hasValue}}
   isLoading: {{myResource.isLoading}}
   status: {{myResource.status}}
   hasError: {{myResource.hasError}}
   error: {{myResource.error}}
   value: {{myResource.value}}
  </ng-container>

  // in ts logic, outside observable stream
  this.myResource$.snapshot();

Code:

// polyfill to prevent type inference in generic types
export type NoInfer<T> = [T][T extends any ? 0 : never];

export function resource$<ResourceState, Params>({
  params$,
  loader,
  initialValue,
  initialParams,
  setValue$,
  destroy$,
  reload$,
}: {
  params$: Observable<Params>;
  loader: (param: { params: Params }) => Observable<ResourceState>;
  initialValue?: NoInfer<ResourceState>;
  initialParams?: NoInfer<Params>;
  setValue$?: (
    resourceSnapshot: () => ResourceLike<ResourceState, Params>
  ) => Observable<NoInfer<ResourceState> | undefined>;
  reload$?: Observable<unknown>;
  destroy$: Observable<unknown>;
}) {
  let resourceSnapshot: undefined | ResourceLike<ResourceState, Params> =
    undefined;
  let pramasSnapshot: undefined | Params = initialParams;
  const dataFromLoader$ = merge(
    params$,
    reload$?.pipe(
      filter((params) => !!params),
      map(() => pramasSnapshot as Params)
    ) ?? EMPTY
  ).pipe(
    tap((params) => (pramasSnapshot = params)),
    switchMap((params) =>
      loader({ params }).pipe(
        map(
          (value) =>
            ({
              hasValue: true,
              isLoading: false,
              status: "resolved",
              hasError: false,
              error: undefined,
              value,
              params,
            } as ResourceLike<ResourceState, Params>)
        ),
        startWith({
          hasValue: !!initialValue,
          isLoading: true,
          status: "loading",
          hasError: false,
          error: undefined,
          value: initialValue,
          params,
        } as ResourceLike<ResourceState, Params>),
        catchError((error) =>
          of({
            hasValue: false,
            isLoading: false,
            status: "error",
            hasError: true,
            error,
            value: undefined,
            params,
          } as ResourceLike<ResourceState, Params>)
        )
      )
    )
  );

  const localSet$ =
    setValue$?.(
      () => resourceSnapshot as ResourceLike<ResourceState, Params>
    ).pipe(
      map(
        (value) =>
          ({
            hasValue: !!value,
            isLoading: false,
            status: "local",
            hasError: true,
            error: undefined,
            value: value,
            params: undefined,
          } as ResourceLike<ResourceState, Params>)
      )
    ) ?? EMPTY;

  const stream$ = merge(dataFromLoader$, localSet$).pipe(
    // used to preserve the last value
    scan((acc, cur) => {
      if (!cur.hasValue && !cur.hasError) {
        return {
          ...cur,
          value: acc.value,
        };
      }
      return cur;
    }, idleResource<ResourceState, Params>(initialValue, initialParams)),
    startWith(
      idleResource(initialValue, initialParams) as ResourceLike<
        ResourceState,
        Params
      >
    ),
    tap((resource) => (resourceSnapshot = resource)),
    shareReplay({
      refCount: true,
      bufferSize: 1,
    })
  );
  stream$.pipe(takeUntil(destroy$)).subscribe();
  return Object.assign(stream$, {
    snapshot: () => resourceSnapshot,
    params: () => pramasSnapshot,
  });
}

export type ResourceLike<State, Params> = {
  readonly isLoading: boolean;
  readonly hasValue: boolean;
  readonly status: ResourceStatus;
  readonly hasError: boolean;
  readonly error: any | undefined;
  readonly value: State | undefined;
  readonly params: Params | undefined;
};

export const idleResource = <ResourceState, Params>(
  initialValue?: ResourceState,
  initialParams?: Params
): ResourceLike<ResourceState, Params> => ({
  hasValue: !!initialValue,
  isLoading: false,
  status: "idle",
  hasError: false,
  error: undefined,
  value: initialValue,
  params: initialParams,
});
type ResourceStatus =
  | "idle"
  | "error"
  | "loading"
  | "reloading"
  | "resolved"
  | "local";

1- Yes, I have no access to takeUntilDestroyed, so I have to pass a destroy$ observable in order to unsubscribe properly
2- I chose to expose a snapshot, because I want the possibility to get the current state without subscribing (it just fits well in the current codebase)
3- You may customize this implementation to fit your needs.

This implementation exposes a declarative way to reload the async request (reload$).

You can bind it to an interval
It is also possible to reload after a source$ error (check the next demo)

Before presenting more elaborate use cases, let me address some important limitations.

This implementation may change as I work on it, by adding or changing some functionalities.

Like the official resource, our utility does not handle typed errors (they are all inferred as any).

So you may improve the way API errors are handled.

It is also possible to improve the fallback part (when applying an optimistic update from a mutation that ultimately fails).

Both the official Angular Resource and this resource$ do not allow parallel requests, which is very problematic. So let's create a resourceByGroup$ that enables parallel requests.

`resourceByGroup$` usage and implementation

resourceByGroup$ is used to make parallel requests. It has the same options as resource$ with one additional required option: identifier.

The identifier is a callback function that is called each time param$ emits.

Its return value is used as a key for each parallel request.

Because resourceByGroup$ will return a Map-Like object:


{
    key1: ResourceLike<...>,
    key2: ResourceLike<...>,
}

Each time the identifier callback returns a non-existing value, it will instantiate a new corresponding resource.

Usage:

  private readonly destroy$ = new Subject();
  ngOnDestroy() {
    this.destroy$.next();
    this.destroy$.complete();
  }


  protected readonly myResourceByGroup$ = resourceByGroup$({
    params$: this.id$,
    identifier: (id) => id,
    loader: ({ params: id }) =>
      this.checksService.getCheck$(id),
    destroy$: this.destroy$
  });

  // in the template:
   <div *ngFor="let resource of myResourceByGroup$ | async | keyvalue">
    key: {{ resource.key }}
    hasValue: {{resource.value.hasValue}}
    isLoading: {{resource.value.isLoading}}
    status: {{resource.value.status}}
    hasError: {{resource.value.hasError}}
    error: {{resource.value.error}}
    value: {{resource.value.value}}}
   </div>

   // or
    <div *ngFor="let item of myList">
    //...
    <ng-container
        *ngIf="
            myResourceByGroup$.select(item.id)
            | async as resourceItem
        "
    >
     // ...
    </ng-container>
   </div>

Code:

// polyfill to prevent type inference in generic types
export type NoInfer<T> = [T][T extends any ? 0 : never];

export type ResourceByGroupRef$<GroupIdentifier, ResourceState, Params> =
  Observable<{
    [identifier in GroupIdentifier & string]: ResourceLike<
      ResourceState,
      Params
    >;
  }> & {
    select: (
      id: GroupIdentifier
    ) => Observable<ResourceLike<ResourceState, Params>>;
    selectField: <Field extends keyof ResourceLike<ResourceState, Params>>(
      id: GroupIdentifier,
      field: Field
    ) => Observable<ResourceLike<ResourceState, Params>[Field]>;
    change$: Observable<{
      identifier: GroupIdentifier;
      resource: ResourceLike<ResourceState, Params>;
    }>;
  };

type ResourceMappingByGroup<GroupIdentifier, ResourceState, Params> = {
  resourceByGroup: {
    [identifier in GroupIdentifier & string]: ResourceLike<
      ResourceState,
      Params
    >;
  };
  lastChange$: {
    identifier: GroupIdentifier;
    resource: ResourceLike<ResourceState, Params>;
  };
};

export function resourceByGroup$<ResourceState, Params, GroupIdentifier>({
  params$,
  identifier,
  loader,
  initialValue,
  destroy$,
}: {
  params$: Observable<Params>;
  identifier: (params: NoInfer<NonNullable<Params>>) => GroupIdentifier;
  loader: (param: { params: Params }) => Observable<ResourceState>;
  initialValue?: NoInfer<ResourceState>;
  destroy$: Observable<unknown>;
}): ResourceByGroupRef$<GroupIdentifier, ResourceState, Params> {
  const resourceByGroup$ = params$.pipe(
    groupBy(
      (params) => identifier(params as NonNullable<Params>),
      (params) => params
    ),
    mergeMap((paramsByGroup$) =>
      resource$({
        params$: paramsByGroup$,
        loader,
        initialValue,
        destroy$,
      }).pipe(
        map((resource) => ({
          resource,
          identifier: paramsByGroup$.key,
        }))
      )
    ),
    scan(
      (acc, { resource, identifier }) => {
        return {
          resourceByGroup: {
            ...acc.resourceByGroup,
            [identifier as GroupIdentifier & string]: resource,
          },
          lastChange$: {
            identifier,
            resource,
          },
        };
      },
      { resourceByGroup: {}, lastChange$: {} } as ResourceMappingByGroup<
        GroupIdentifier,
        ResourceState,
        Params
      >
    ),
    startWith({
      resourceByGroup: {},
      lastChange$: {},
    } as ResourceMappingByGroup<GroupIdentifier, ResourceState, Params>),
    shareReplay({ refCount: true, bufferSize: 1 })
  );

  resourceByGroup$.pipe(takeUntil(destroy$)).subscribe();

  return Object.assign(
    resourceByGroup$.pipe(map(({ resourceByGroup }) => resourceByGroup)),
    {
      select: (id: GroupIdentifier) =>
        resourceByGroup$.pipe(
          map(({ resourceByGroup }) => {
            const result =
              resourceByGroup[id as GroupIdentifier & string] ||
              idleResource(initialValue);
            return result;
          })
        ),
      selectField: (
        id: GroupIdentifier,
        field: keyof ResourceLike<ResourceState, Params>
      ) =>
        resourceByGroup$.pipe(
          map(({ resourceByGroup }) => {
            return (
              resourceByGroup[id as GroupIdentifier & string]?.[field] ||
              idleResource(initialValue)
            );
          })
        ),
      change$: resourceByGroup$.pipe(
        map(({ lastChange$ }) => lastChange$),
        filter((data) => !!data.resource)
      ),
    }
  ) as ResourceByGroupRef$<GroupIdentifier, ResourceState, Params>;
}

Since I cannot use @let from Angular Control Flow, I added some utilities that I can use in my templates.
Some of them will also be used to simplify the upcoming server state utility functions.

Demo `resource$` and `resourceByGroup$`

Here, I created a small example that displays a list of users.

You can update the user name optimistically
You can trigger an update error that will force the users list to refresh

Demo resource$ and resourceByGroup$

In the next article, I will share some StackBlitz demos that will help you understand how to use it.

resource$ and resourceByGroup$ can be used like that. The next utilities (query$, mutation$, and asyncMethod) will be used to improve the DX.

If you like this article, please leave a comment or a like. I don't have that much feedback yet.

A small overview of my state management tool

I would like to show you my experimental state management tool that handles server state.

It will do almost the same as the previous example, except that it also handles query params state.

This tool depends only on Signals and RxJS is fully optional.

I wrote other articles that you might like:

Follow me on LinkedIn for an Angular Advent calendar.
👉 Romain Geffrault

Mastering Angular Signals: Understanding Angular Signal Recomputation Reactions (part 2)

Romain Geffrault — Tue, 02 Dec 2025 05:36:49 +0000

If you haven’t already read the first part of this series, you may want to take a look at it before reading this article.
Here is the link

How to Implement Signal Reactions

I think this is the least obvious use case for Signals.

But Signals can indeed be used to implement something close to an Event‑Driven Architecture (with some limitations) — a Recomputation Event‑Driven Architecture.

This article focuses on how a signal state can be affected by a signal recomputation event.

When I first shared my thoughts on this idea, almost nobody believed it.

So let me show you how Signals can achieve this — and what their limitations are.

At first, it wasn’t obvious to find this pattern; I haven’t seen anyone else use Signals this way.

So it’s still experimental — but my first tests are awesome! 🚀

Recomputation‑Event‑Driven Architecture with Signal Reactions — Principles

There are multiple ways to modify a signal state based on a signal recomputation event.

Here, I will show you my favorite technique (which can certainly be improved).

As mentioned earlier, this technique is inspired by the resource API.

When you pass an undefined value to a resource parameter (params), it does not trigger the loader.

I decided to push this concept further — and that’s what enables the recomputation‑event‑driven mechanism.

The idea is simple: if a Signal returns undefined, it should not react to it.

In RxJS, this is similar to an observable returning EMPTY, which pauses the flow.

To react to a signal recomputation event, we need to use an effect.

As we will see, not all patterns can be handled using a linkedSignal.

How to Implement a Recomputation Event Mechanism Using Signals

// Event signal
const myEvent = signal<{} | undefined>(undefined);

// State signal
const myState = signal(0);

// Effect reacting to the recomputation event
effect(() => {
  if (!myEvent()) {
    return;
  }
  myState.update((value) => value + 3);
});

Each time myEvent is triggered with myEvent.set({}) or myEvent.update(() => ({})), myState will increment by 3.

Since myEvent() returns undefined on the first read, the initialization won’t increment myState.

So we have a relatively simple system.

However, this pattern is a bit weak if myEvent is shared across the app.

If some part of the app starts listening to myEvent after it has already been triggered, it will still execute the effect.

So let me introduce a utility function called source, which solves this problem.

Implementing a `source` Utility Function

source ensures that listeners always receive undefined as the first value and skip any previous emissions.

It can certainly be improved, but here is my implementation, where I added options such as preserveLastValue.

// Utility signal creation with improved recomputation event handling
import { linkedSignal, Signal, signal, ValueEqualityFn } from "@angular/core";

export interface Source<T> extends Signal<T | undefined> {
  set: (value: T) => void;
  preserveLastValue: Signal<T | undefined>;
}

export function source<T>(options?: {
  equal?: ValueEqualityFn<NoInfer<T> | undefined>;
  debugName?: string;
}): Source<T> {
  const sourceState = signal<T | undefined>(undefined, {
    ...(options?.equal && { equal: options.equal }),
    ...(options?.debugName && {
      debugName: options.debugName + "_sourceState",
    }),
  });

  const listener = (listenerOptions: { nullishFirstValue?: boolean }) =>
    linkedSignal<T, T | undefined>({
      source: sourceState as Signal<T>,
      computation: (currentSourceState, previousData) => {
        if (!previousData && listenerOptions?.nullishFirstValue !== false) {
          return undefined;
        }
        return currentSourceState;
      },
      ...(options?.equal && { equal: options.equal }),
      ...(options?.debugName && { debugName: options.debugName }),
    });

  return Object.assign(listener({ nullishFirstValue: true }), {
    preserveLastValue: listener({ nullishFirstValue: false }),
    set: sourceState.set,
  }) as Source<T>;
}

Here are some related tests:

// Tests for the source utility
describe("source", () => {
  beforeEach(() => {
    vi.useFakeTimers();
  });

  afterEach(() => {
    vi.resetAllMocks();
  });

  it("should generate a source that sets values and allows listeners to receive them", () => {
    const mySource = source<string>();
    expectTypeOf(mySource).toEqualTypeOf<Source<string>>();

    const myListener = computed(() => mySource());

    expect(myListener()).toBe(undefined);

    mySource.set("Hello World");
    expect(myListener()).toBe("Hello World");

    mySource.set("Hello Ng‑Query");
    expect(myListener()).toBe("Hello Ng‑Query");
  });

  it("A late listener should not receive previously set values", () => {
    const mySource = source<string>();

    mySource.set("Hello World");

    const myListener = computed(() => mySource());
    expect(myListener()).toBe(undefined);

    mySource.set("Hello Ng‑Query v2");
    expect(myListener()).toBe("Hello Ng‑Query v2");
  });

  it('A late listener should receive the last value when using "preserveLastValue"', () => {
    const mySource = source<string>();

    mySource.set("Hello World");

    const myListener = computed(() => mySource.preserveLastValue());
    expect(myListener()).toBe("Hello World");

    mySource.set("Hello Ng‑Query v2");
    expect(myListener()).toBe("Hello Ng‑Query v2");
  });
});

Now that we have covered the theory, let’s look at a practical use case.

A Practical Use Case for Signal Reaction Architecture

In my previous article, I shared a diagram where certain states need to react to a userLogout recomputation event.

Let's implement the reset logic when userLogout is triggered:

const userLogout = source<{}>();

@Injectable({ providedIn: "root" })
export class ProductsStates {
  private readonly allProducts = signal([] as Product[]);
  private readonly favoriteProducts = signal([] as Product[]);
  private readonly suggestionsProducts = signal([] as Product[]);

  private readonly _resetOnLogoutEffect = effect(() => {
    if (!userLogout()) {
      return;
    }
    this.favoriteProducts.set([]);
    this.suggestionsProducts.set([]);
  });

  // Other updaters...
}

@Injectable({ providedIn: "root" })
export class UserCartState {
  private readonly cart = signal([] as Cart[]);

  private readonly _resetCartOnLogoutEffect = effect(() => {
    if (!userLogout()) {
      return;
    }
    this.cart.set([]);
  });

  // Other updaters...
}

As you can see, when userLogout is triggered, it resets parts of the products and cart states in a declarative way (at the store level).

Even if there are multiple ways to handle user logout, this pattern is useful when writing declarative state updates.

You may wonder if this is truly useful. For my personal use, it absolutely is. At the end of this article, I will show an example based on one of my tools that relies completely on this pattern to create 100% declarative states.

Before discussing limitations, there is another pattern that allows reacting to signal recomputation events without using any effect.

How to Implement Declarative State and Its Reactions Using `linkedSignal`?

There is another technique that lets us react whenever a signal recomputation event is "computed".

To detect which signal recomputation event is triggered, we can use a linkedSignal.

We map all the reaction events in the linkedSignal source, then compare the previous recomputation event value with the new one in the computed section.

Here is an implementation of this pattern:

  // This block sets up increment/decrement sources and links them to a declarative counter.
  protected readonly increment = source<{}>();
  protected readonly decrement = source<{}>();

  protected readonly counter = linkedSignal<
    {
      increment: {} | undefined;
      decrement: {} | undefined;
    },
    number
  >({
    source: () => ({
      increment: this.increment(),
      decrement: this.decrement(),
    }),
    computation: (currentSource, previous) => {
      if (!previous || previous.value === undefined) {
        return 0;
      }

      if (currentSource.increment !== previous.source.increment) {
        return previous.value + 1;
      }

      if (currentSource.decrement !== previous.source.decrement) {
        return previous.value - 1;
      }

      return previous.value;
    },
  }).asReadonly();

As you can see, this enables you to write fully declarative state logic without any effects.

Here is the demo of this signal‑recomputation‑event approach with linkedSignal.

How does it work?

By passing a reaction recomputation event map to the linkedSignal source, we can check whether the value of any signal source has changed.

If it changes, it means a signal recomputation event has been "recomputed".

I will soon share another article where I implement a simple server‑state utility based on this principle, which allows:

tracking async state (using resources)
optimistic updates / updates on success / fallback on error
all in a declarative way.

Now, let's discuss the real limitations of signal recomputation reaction events that you should be aware of when using this mechanism.

Even this simple example can hide a design issue 😅

What Are the Limitations of Signal Reactions?

When implementing a Signal Recomputation Event Architecture, you should be aware of 5 major behaviors that are not (always) avoidable.

1 - Reactions Are Not Fully Synchronous When a Signal Changes

When a signal (or source) is updated using source.set(...) or source.update(...), recomputation reactions are not immediate. They are not fully synchronous.

As shown in this demo. It compares Observable reactions to Signal reactions:

Observable reactions are fully synchronous
Signal reactions are not fully synchronous

Why Are Signal Reactions Not Fully Synchronous?

I will try to explain this with my own words. If I make any mistakes, please correct me.

This is due to the internal pull‑based mechanism of Signals.

This behavior is intentional and offers several benefits.

All writable signals are considered as producers (meaning they can be changed imperatively). This includes signal(...), linkedSignal(...), and model(...)
Listeners/consumers include computed, effect, linkedSignal(...) (because they can depend on signals), and component inputs input(...)
A consumer may depend on multiple signals that can be producers or other consumers, such as:

computed(() => signalNumber1() + signalNumber2());

And these sources may change within the same "cycle":

update() {
  // 👇 producer
  signalNumber1.set(...);
  // 👇 producer
  signalNumber2.set(...);
}

Without the pull mechanism, this computed callback would run twice.

This is a simple case. But some signals can depend on other signals, etc., forming a full dependency graph.

And the template would re-render every time the computed runs.

(This is not entirely true because template rendering also depends on the ChangeDetectionScheduler.)

But the main issue arises when passing a signal to a child component input.

Without the pull behavior, a child component input would see every intermediate value and may emit outputs based on them.

This could trigger additional cycles, potentially long to resolve (or worse, infinite).

How the Pull Mechanism Works

Indeed, there are 2 phases:

Push Phase (Synchronous):

When a signal/producer is written, its value is updated
The signal is marked as dirty and its version is incremented
All consumers (computed signals, effects, templates) are marked as dirty
All parent components up to the root are marked LViewFlags.HasChildViewsToRefresh so Angular knows which branches of the component tree need to be checked during change detection
The scheduler is notified and schedules a tick (if not already scheduled). The scheduled tick takes a few milliseconds before being executed, which allows multiple signal changes to be coalesced into a single change detection cycle

No callbacks are executed at this point — only propagation of "dirty" flags

Pull Phase (Lazy evaluation):

Angular schedules change detection via microtask or RAF (requestAnimationFrame)
When the tick executes:
- Consumers recalculate their values only when read (by the template / effect)
- Templates refresh and read the latest signal values
- DOM is updated with the new values
- Effects are scheduled and executed

This results in two distinct phases:

Push phase — Propagates "dirty" state synchronously through the reactive graph
Pull phase — Lazily recomputes values and updates the DOM when change detection runs

Important: If a derived signal (computed, linkedSignal, etc.) is read during the push phase (e.g., in synchronous code after signal.set()), it will immediately execute its callback and recompute its value before change detection runs. The pull mechanism is triggered whenever a signal is read, not just during change detection.

Now, let's describe practical limitations.

2 - Reactions React Only to the Last Produced Value

If a signal is updated multiple times within the same push phase (set or update).

Consumer callbacks (computed / effect / linkedSignal / input / model) will be triggered only once, with the final value.

There is a signal producer numberSource and two consumers that catch the maximum propagated value.

The source is updated like this:

changeSourceValue() {
  const currentMaxValue = this.maxValue();

  this.numberSource.set(currentMaxValue + 1000);
  this.numberSource.set(currentMaxValue + 100);
  this.numberSource.set(currentMaxValue + 10);
  this.numberSource.set(currentMaxValue + 1);
}

Here is a demo showing that maxValue increases only by 1 (instead of 1111)

Running the demo shows that consumers only receive:

currentMaxValue + 1

This is important to keep in mind.

Signal consumers only get the last set value of a signal producer.

How to Catch All Values That Are Set During the Push Phase?

I created a utility function to capture all values set on a signal during the Push phase.

Example:

this.numberSource.set(currentMaxValue + 1000);
this.numberSource.set(currentMaxValue + 100);
this.numberSource.set(currentMaxValue + 10);
this.numberSource.set(currentMaxValue + 1);

Instead of receiving only the last value, the consumer can receive all values as an array.

This is done with a custom stackedSource.

Each time set is called, it pushes the value to an internal array.
When this producer is read (during the Pull phase), it returns all captured values and clears the stack.

Here is the demo using stackedSource.

I do not know the drawbacks of this technique, as I do not currently need it.

Here is a way to capture all the producer values, but you cannot capture intermediate values of a signal consumer.

3 - Multiple Reactions May Occur Within the Same Cycle

Signal reactions are delayed until the end of the cycle (at the pull phase).

If multiple signal sources change in the same cycle, multiple reactions may occur.

In our linkedSignal example, the implementation is not designed to handle this scenario:

If increment and decrement both update during the same cycle, only the increment reaction is processed

To solve this, instead of returning the reaction value directly, we propagate an internal value so that both reactions can be handled within the same cycle.

Now, increment and decrement changes can be handled in the same cycle.

Depending on your needs, you may have to adjust your pattern.

The order of reactions matters. Make sure that reactions within linkedSignals can be run in the same callback invocation.

4 - The Order of Effects Matters

effect also has limitations you should know.

Consider two effects watching two sources.

  source1 = source<{}>();
  source2 = source<{}>();

  _source1Effect = effect(() => {
    if (!this.source1()) return;
    console.log('Effect 1');
  });

  _source2Effect = effect(() => {
    if (!this.source2()) return;
    console.log('Effect 2');
  });

  update() {
    this.source2.set({}); // ! source2 change before source1
    this.source1.set({});
  }

When source2 changes before source1 during the same cycle, which effect logs first?

Here is the reproduction.

“Effect 1” always logs before “Effect 2”.

The order of declaration determines execution order.

If you swap the declaration order, logs invert accordingly.

5 - Make Sure Your `linkedSignal` Is Read When Using It with Reactions

If your linkedSignal uses reactions, the reactions will only be triggered if this linkedSignal is read (during the cycle where the reaction is produced).

Otherwise, the linkedSignal will miss the value.

And worse, it will react to the last produced value when it is read again.

Here is a demo where you can see this behavior

use the toggle button to display/hide the linkedSignal value
use the increment button to produce a reaction
use the update button to update the value imperatively

Then, check what happens when the linkedSignal is hidden/visible.

Where Should You Not Use Signal Reactions?

From my experience, Signal Reactions are not well suited for handling certain types of event orchestration.

Since reactions can have multiple producer sources that change during the same cycle, you cannot know which one changed first.

It is still possible to use them, but you must handle this case arbitrarily.

For me, this is where Observables and RxJS are more relevant.

From my experience, Signal Reactions are not designed to handle event orchestration.

Take a Step Back from Signal Reactions

Even if my article encourages exploring Signal Reactions, it is still something relatively new.

This means that we do not yet have much knowledge about potential drawbacks that are not yet listed.

And Signal Reactions can turn into a “smell pattern”.

So take a step back, analyze, and experiment on your own.

Some Community Feedback ⚠️

Some Angular developers strongly discourage using Signals as events.

Because they can lead to unexpected behavior — and this is true.

I try to list all of them, but I may miss some, and not all developers may be aware of the drawbacks.

This can lead to an app with unexpected behavior.

My Point of View About Signal Reactions

I am still experimenting with Signal Reactions.

For now, I like using them at the low level of the app, when they deal with component DOM events (like a button click, the scroll reaching a target...).

So I keep using them in my personal projects for now, until I am confident with them.

Before ending with Signal Recomputation Reactions, I would like to share
some utility functions that may also help you.

Signal Recomputation utilities `toSource` / `computedSource` / `sourceFromEvent`

`toSource` transforms a Signal into a `source`

toSource creates a source from a signal (writable or not).

Usage:

const mySignal = signal("init");
const mySource = toSource(mySignal);

Now, the first read of mySource from a new consumer will return
undefined.

Code:

export function toSource<SourceState, ComputedValue>(
  signalOrigin: Signal<SourceState> | WritableSignal<SourceState>,
  options?: {
    computed?: (sourceValue: NoInfer<SourceState>) => ComputedValue;
    equal?: ValueEqualityFn<NoInfer<SourceState> | undefined>;
    debugName?: string;
  }
): ReadonlySource<
  IsUnknown<ComputedValue> extends true ? SourceState : ComputedValue
> {
  const sourceState = linkedSignal<SourceState | undefined>(signalOrigin, {
    ...(options?.equal && { equal: options?.equal }), // add the equal function here, it may help to detect changes when using scalar values
    ...(options?.debugName && {
      debugName: options?.debugName + "_sourceState",
    }),
  });

  const listener = (listenerOptions: { nullishFirstValue?: boolean }) =>
    linkedSignal<SourceState, any>({
      source: sourceState as Signal<SourceState>,
      computation: (currentSourceState, previousData) => {
        // always return undefined when first listened
        if (!previousData && listenerOptions?.nullishFirstValue !== false) {
          return undefined;
        }
        //! use untracked to avoid the computed being re-evaluated when used inside another effect/computed
        return untracked(() =>
          options?.computed
            ? options?.computed?.(currentSourceState)
            : currentSourceState
        );
      },
      ...(options?.equal && { equal: options?.equal }),
      ...(options?.debugName && { debugName: options?.debugName }),
    });
  return Object.assign(
    listener({
      nullishFirstValue: true,
    }),
    {
      preserveLastValue: listener({
        nullishFirstValue: false,
      }),
    }
  ) as ReadonlySource<any>;
}

export type IsUnknown<T> = unknown extends T
  ? [T] extends [unknown]
    ? true
    : false
  : false;

export type ReadonlySource<T> = Signal<T | undefined> & {
  preserveLastValue: Signal<T | undefined>;
};

`computedSource` use it to derive a source

Useful if you need to map your source value without affecting the
existing one.

Usage:

const mySignal = source<{ text: string }>();
const mySource = computedSource(
  mySignal,
  (sourceValue) => sourceValue.text + " Derived Source Text"
);

Code:

export function computedSource<SourceState, ComputedValue>(
  signalOrigin: Source<SourceState> | ReadonlySource<SourceState>,
  computedFn: (sourceValue: NoInfer<SourceState>) => ComputedValue,
  options?: {
    equal?: ValueEqualityFn<NoInfer<ComputedValue> | undefined>;
    debugName?: string;
  }
): ReadonlySource<ComputedValue> {
  const listener = (listenerOptions: { nullishFirstValue?: boolean }) =>
    linkedSignal<SourceState, ComputedValue | undefined>({
      source: signalOrigin as Signal<SourceState>,
      computation: (currentSourceState, previousData) => {
        // always return undefined when first listened
        if (!previousData && listenerOptions?.nullishFirstValue !== false) {
          return undefined;
        }

        return computedFn(currentSourceState);
      },
      ...(options?.equal && { equal: options?.equal }),
      ...(options?.debugName && { debugName: options?.debugName }),
    });
  return Object.assign(
    listener({
      nullishFirstValue: true,
    }),
    {
      preserveLastValue: listener({
        nullishFirstValue: false,
      }),
    }
  ) as ReadonlySource<any>;
}
export type ReadonlySource<T> = Signal<T | undefined> & {
  preserveLastValue: Signal<T | undefined>;
};
export interface Source<T> extends Signal<T | undefined> {
  set: (value: T) => void;
  preserveLastValue: Signal<T | undefined>;
}

`sourceFromEvent` derive a DOM event into a Signal source

Useful if you want to create a Signal source from a DOM event.

Each new consumer will get undefined as the first value.

Usage:

const buttonClickedSource = sourceFromEvent<MouseEvent>(button, "click");

const buttonClickedPointerPositionSource = sourceFromEvent(button, "click", {
  computedValue: (event: MouseEvent) => ({
    offsetX: event.offsetX,
    offsetY: event.offsetY,
  }),
});

Remark: The computedValue callback is triggered each time an event is
emitted. (It may not be the best name.)

Code:

export type SourceFromEvent<T> = Source<T> & {
  dispose: () => void;
};

export function sourceFromEvent<T>(
  target: EventTarget,
  eventName: string,
  options?: {
    event?: boolean | AddEventListenerOptions;
    computedValue?: never;
    source: {
      equal?: ValueEqualityFn<NoInfer<T> | undefined>;
      debugName?: string;
    };
  }
): SourceFromEvent<T>;
export function sourceFromEvent<T, ComputedValue>(
  target: EventTarget,
  eventName: string,
  options?: {
    event?: boolean | AddEventListenerOptions;
    computedValue: (event: T) => ComputedValue;
    source?: {
      equal?: ValueEqualityFn<NoInfer<T> | undefined>;
      debugName?: string;
    };
  }
): SourceFromEvent<ComputedValue>;
export function sourceFromEvent(
  target: EventTarget,
  eventName: string,
  options?: {
    event?: boolean | AddEventListenerOptions;
    computedValue?: (event: Event) => unknown;
    source?: {
      equal?: ValueEqualityFn<NoInfer<unknown> | undefined>;
      debugName?: string;
    };
  }
): SourceFromEvent<unknown> {
  assertInInjectionContext(sourceFromEvent);
  const eventSignalSource = source<unknown>(options?.source);

  const listener = (event: Event) => {
    if (options?.computedValue) {
      const computed = options.computedValue(event);
      eventSignalSource.set(computed);
      return;
    }
    eventSignalSource.set(event);
  };

  target.addEventListener(eventName, listener, options?.event);

  const destroyRef = inject(DestroyRef);

  const dispose = () => {
    target.removeEventListener(eventName, listener, options?.event);
  };

  destroyRef.onDestroy(() => {
    dispose();
  });

  return Object.assign(eventSignalSource, {
    dispose,
  });
}

export interface Source<T> extends Signal<T | undefined> {
  set: (value: T) => void;
  preserveLastValue: Signal<T | undefined>;
}

Using Signal Recomputation Reactions in declarative store

Here a sneakpick of my states management tool where I fully integrate all of this principles.

The store expose 2 states, counter and search.
When the recomputation is triggered after the reset source that has change, it will reset the counter and search value.

Acknowledgements

I would like to thank Lucas Garcia, who challenged me extensively on Signals, their internal mechanisms, and the way I communicate about them.
If there is only one thing to do after reading this article, it is to go and read his debates on linkedin (discord...). I learn a tremendous amount from the insights he shares—they are a real gold mine for being challenged and discovering new perspectives.

I would also like to thank Mathieu Riegler, who strongly emphasized that I should not associate Signals with events, so as not to confuse their proper usage (I hope I have at least partially succeeded on that front).

I would also like to thank the Angular team for introducing Signals. Their ease of use makes it hard to realize the amount of work happening under the hood. Congratulations for this remarkable achievement.

Finally, I would like to thank everyone who commented on my LinkedIn posts to share ideas, feedback, and constructive criticism.

Follow me on LinkedIn for an Angular Advent calendar.
👉 Romain Geffrault

Mastering Angular Signals: Understanding Agular Signal Reactions (part 2)

Romain Geffrault — Mon, 01 Dec 2025 05:37:33 +0000

If you haven’t already read the first part of this series, you may want to take a look at it before reading this article.
Here is the link

How to Implement Signal Reactions

I think this is the least obvious use case for Signals.

But Signals can indeed be used to implement something close to an Event‑Driven Architecture (with some limitations).

This article focuses on how a signal state can be affected by a signal event.

When I first shared my thoughts on this idea, almost nobody believed it.

So let me show you how Signals can achieve this — and what their limitations are.

At first, it wasn’t obvious to find this pattern; I haven’t seen anyone else use Signals this way.

So it’s still experimental — but my first tests are awesome! 🚀

Event‑Driven Architecture with Signals Reactions — Principles

There are multiple ways to modify a signal state based on a signal event.

Here, I will show you my favorite technique (which can certainly be improved).

As mentioned earlier, this technique is inspired by the resource API.

When you pass an undefined value to a resource parameter (params), it does not trigger the loader.

I decided to push this concept further — and that’s what enables the event‑driven mechanism.

The idea is simple: if a Signal returns undefined, it should not react to it.

In RxJS, this is similar to an observable returning EMPTY, which pauses the flow.

To react to a signal event, we need to use an effect.

As we will see, not all patterns can be handled using a linkedSignal.

How to Implement an Event Mechanism Using Signals

// Event signal
const myEvent = signal<{} | undefined>(undefined);

// State signal
const myState = signal(0);

// Effect reacting to the event
effect(() => {
  if (!myEvent()) {
    return;
  }
  myState.update(value => value + 3);
});

Each time myEvent is triggered with myEvent.set({}) or myEvent.update(() => ({})), myState will increment by 3.

Since myEvent() returns undefined on first read, the initialization won’t increment myState.

So we have a relatively simple system.

However, this pattern is a bit weak if myEvent is shared across the app.

If some part of the app starts listening to myEvent after it has already been triggered, it will still execute the effect.

So let me introduce a utility function called source, which solves this problem.

Implementing a `source` Utility Function

source ensures that listeners always receive undefined as the first value and skip any previous emissions.

It can certainly be improved, but here is my implementation, where I added options such as preserveLastValue.

// Utility signal creation with improved event handling
import { linkedSignal, Signal, signal, ValueEqualityFn } from "@angular/core";

export interface Source<T> extends Signal<T | undefined> {
  set: (value: T) => void;
  preserveLastValue: Signal<T | undefined>;
}

export function source<T>(options?: {
  equal?: ValueEqualityFn<NoInfer<T> | undefined>;
  debugName?: string;
}): Source<T> {
  const sourceState = signal<T | undefined>(undefined, {
    ...(options?.equal && { equal: options.equal }),
    ...(options?.debugName && { debugName: options.debugName + "_sourceState" }),
  });

  const listener = (listenerOptions: { nullishFirstValue?: boolean }) =>
    linkedSignal<T, T | undefined>({
      source: sourceState as Signal<T>,
      computation: (currentSourceState, previousData) => {
        if (!previousData && listenerOptions?.nullishFirstValue !== false) {
          return undefined;
        }
        return currentSourceState;
      },
      ...(options?.equal && { equal: options.equal }),
      ...(options?.debugName && { debugName: options.debugName }),
    });

  return Object.assign(
    listener({ nullishFirstValue: true }),
    {
      preserveLastValue: listener({ nullishFirstValue: false }),
      set: sourceState.set,
    }
  ) as Source<T>;
}

Here are some related tests:

// Tests for the source utility
describe("source", () => {
  beforeEach(() => {
    vi.useFakeTimers();
  });

  afterEach(() => {
    vi.resetAllMocks();
  });

  it("should generate a source that emits values and allows listeners to receive them", () => {
    const mySource = source<string>();
    expectTypeOf(mySource).toEqualTypeOf<Source<string>>();

    const myListener = computed(() => mySource());

    expect(myListener()).toBe(undefined);

    mySource.set("Hello World");
    expect(myListener()).toBe("Hello World");

    mySource.set("Hello Ng‑Query");
    expect(myListener()).toBe("Hello Ng‑Query");
  });

  it("A late listener should not receive previously emitted values", () => {
    const mySource = source<string>();

    mySource.set("Hello World");

    const myListener = computed(() => mySource());
    expect(myListener()).toBe(undefined);

    mySource.set("Hello Ng‑Query v2");
    expect(myListener()).toBe("Hello Ng‑Query v2");
  });

  it('A late listener should receive the last value when using "preserveLastValue"', () => {
    const mySource = source<string>();

    mySource.set("Hello World");

    const myListener = computed(() => mySource.preserveLastValue());
    expect(myListener()).toBe("Hello World");

    mySource.set("Hello Ng‑Query v2");
    expect(myListener()).toBe("Hello Ng‑Query v2");
  });
});

Now that we covered the theory, let’s look at a practical use case.

A Practical Use Case for Signal Reaction Architecture

In my previous article, I shared a diagram where certain states need to react to a userLogout event.

Let's implement the reset logic when userLogout is triggered:

const userLogout = source<{}>();

@Injectable({ providedIn: "root" })
export class ProductsStates {
  private readonly allProducts = signal([] as Product[]);
  private readonly favoriteProducts = signal([] as Product[]);
  private readonly suggestionsProducts = signal([] as Product[]);

  private readonly _resetOnLogoutEffect = effect(() => {
    if (!userLogout()) {
      return;
    }
    this.favoriteProducts.set([]);
    this.suggestionsProducts.set([]);
  });

  // Other updaters...
}

@Injectable({ providedIn: "root" })
export class UserCartState {
  private readonly cart = signal([] as Cart[]);

  private readonly _resetCartOnLogoutEffect = effect(() => {
    if (!userLogout()) {
      return;
    }
    this.cart.set([]);
  });

  // Other updaters...
}

As you can see, when userLogout is triggered, it resets parts of the products and cart states in a declarative way (at the store level).

Even if there are multiple ways to handle user logout, this pattern is useful when writing declarative state updates.

Before discussing limitations, there is another pattern that allows reacting to signal events without using any effect.

How to implement declarative state with a linkedSignal that reacts to multiple Signal events?

How to implement declarative state with `linkedSignal` that reacts to multiple signal events?

There is another technique that lets us react whenever an event is emitted.

To detect which signal event is triggered, we can use a linkedSignal.

We map all the events in the linkedSignal source, then compare the previous event value with the new one in the computed section.

Here is an implementation of this pattern:

  // This block sets up increment/decrement sources and links them to a declarative counter.
  protected readonly increment = source<{}>();
  protected readonly decrement = source<{}>();

  protected readonly counter = linkedSignal<
    {
      increment: {} | undefined;
      decrement: {} | undefined;
    },
    number
  >({
    source: () => ({
      increment: this.increment(),
      decrement: this.decrement(),
    }),
    computation: (currentSource, previous) => {
      if (!previous || previous.value === undefined) {
        return 0;
      }

      if (currentSource.increment !== previous.source.increment) {
        return previous.value + 1;
      }

      if (currentSource.decrement !== previous.source.decrement) {
        return previous.value - 1;
      }

      return previous.value;
    },
  });

As you can see, this enables you to write fully declarative state logic without any effects.

Here is the demo of this signal-event approach with linkedSignal.

How does it work?

By passing an event map to the linkedSignal source, we can check whether the value of any signal source has changed.

If it changes, it means a signal event has been emitted.

I will soon share another article where I implement a simple server‑state utility based on this principle, which allows:

tracking async state (using resources)
optimistic updates / updates on success / fallback on error
all in a declarative way.

Now, let's discuss the real limitations of signal reactions events that you should be aware of when using this mechanism.

Even this simple example can hide a design issue 👇

This article is written in four parts. Here is the next part.

Follow me on LinkedIn for an Angular Advent calendar.
👉 Romain Geffrault

Learn more about how to use Angular Signals in my latest article.

Romain Geffrault — Sun, 16 Nov 2025 12:55:52 +0000

Mastering Angular Signals: A Complete Guide Beyond RxJS

Romain Geffrault ・ Nov 5

#angular #rxjs #typescript #webdev

Mastering Angular Signals: A Complete Guide Beyond RxJS

Romain Geffrault — Wed, 05 Nov 2025 11:13:47 +0000

There’s only one thing that Signals can’t do like RxJs. Otherwise, Signals are by far the better choice in Angular.

I’ve been using Signals a lot lately, and quite extensively.

And honestly, it’s such a pleasure to work with — it’s much more accessible than RxJs.

Signals integrate much better into the framework than RxJs does (for example, inputs, viewChild... now return signals).

But before going any further, I have no issue working with RxJs.

However, that’s not the case for most developers who are just starting out with Angular or who don’t want to fully commit to learning RxJs.

So, I set out on a quest to make the more advanced RxJs patterns accessible using Signals.

At first, it wasn’t easy at all — but over time, I found Signal-based equivalents for many RxJs patterns that I liked.

I’ve often talked about this in my LinkedIn posts.

But there was still one last point — one reason why RxJs kept a small advantage when designing an app, something that Signals didn’t have.

Most articles and examples I’ve seen on the topic don’t go that far with Signals and haven’t yet encountered this final challenge.

Here’s what I thought was impossible to do with Signals.

In RxJs, there’s the BehaviorSubject, whose behavior is quite similar to that of a Signal.

And there’s the Subject, which doesn’t have an equivalent in Signals.

Yet, from my point of view, the behavior provided by a Subject is practically indispensable in an application.

It allows a state to react to an event (e.g., when userLogout is triggered, some states should be reset) and to trigger a change only when that event emits a value.

That’s the essence of event-driven architecture. And declarative code.

Why is this kind of behavior necessary?

Because when multiple states need to be updated after an event, you’d otherwise have to trigger each one manually — and it’s easy to forget one.

Very quickly, you can end up with inconsistent states.

Whereas if each state can declaratively react to an event on its own, it’s much easier to maintain and to understand what’s happening.

But until recently, I thought it was impossible to implement such event-driven behavior with Signals — yet after some experimentation, I now believe it actually is.

After much reflection, I think I’ve found an equivalent approach to what can be done with RxJs, and for me, it’s perfectly fine.

The mindset is different — it’s tied to the pull-based update mechanism of Signals versus the push-based nature of RxJs.

I won’t go too deep into that technical aspect — it’s interesting, but I feel like it can limit creativity in how we use Signals to replace RxJs.

This article will help you to understand what is possible to do and how I think Signals can be used to create Angular application without friction.

This article will follow this plan:

7 Powerful tips after hundreds of hours mastering advanced signal patterns (part 1)
Transforming an Angular RxJs example into signals (part 1)
Build a truly event-driven architecture using only signals (part 2)
Does rxjs still matter in a signal-first angular world? (part 2)
Essential utilities and what’s still missing in signals today (part 3)
Effects in signals — game-changer or hidden trap? (part 3)
Create a debounce signal utility without rxjs — step by step (part 3)

As you can see, I won’t explain how signal, computed, linkedSignal, or effect work — there are plenty of articles that already cover that.

7 Powerful tips after hundreds of hours mastering advanced signal patterns

RxJs is not the perfect tool for declarative pattern, Signals does better.

I have a created ng-query a server state management tools similar to TanStackQuery, but that only relies on Signal (RxJs is fully optional).

I learn a lot on how Signals can be used.

And here the most importantes things that I learn and you can use to implements Signals without friction.

(Of course, it is opinionated 😉)

1 - Your code should use declrative patterns.

Using imperative code is very bad when working with Signals.

You’ll quickly end up writing spaghetti code just to achieve your goals.

One of the biggest advantages of Signals actually comes from their limitations — such as the resource and effect functions, which are essential (as we’ll see in more detail later). They enforce writing code within a reactive context (similar to the injection context).

Whereas RxJs allowed code to be written “anywhere,” which encouraged imperative patterns.

onSubmit(form: MyForm) { 
 this.isLoading = true;
 this.myApiService.save$(form.value).subscribe(() => {
     this.isLoading = false;
  })
}

In this example, which I’m sure you’ve already seen:

There’s no error handling
If onSubmit is triggered twice in a row, it will cause unwanted parallel requests
The isLoading management is imperative, making the code more complex than it should be
You can’t react to it directly (you have to manually call a function or emit an event)

(Of course, there are better RxJs patterns to avoid these issues — I’ve shared some on this blog.)

With Signals and the use of Resources, the ways of doing things are more limited, which enforces a declarative coding approach.

saveForm = signal<MyFormType | undefined>(undefined)
saveResource = resource({
  params: this.saveForm,
  loader: ({params: form}) => this.myApiService.save(form)
})

PS: Here, I’m using a resource to perform a mutation — and it’s totally fine to do it this way.

Advantages:

Declarative code
Handles all asynchronous states: loading, resolved, etc.
Allows deriving other states easily

ex:

saveResource = resource(...)
dataResource = resource(...)

// 👇 derived state
isLoading = computed(() => dataResource.status() === 'loading' || saveResource.status() === 'loading')

Indirectly, Signals and their utilities force you to write declarative code, unlike RxJs, which doesn’t impose such limitations — something I personally see as more of a drawback than an advantage in Angular.

2 - Signals promote State-Driven Architecture

When working with Signals and using a declarative pattern, you should design your app with a state-driven development mindset.

This means you should use computed or linkedParams to react to changes in another state.

If you’re familiar with event-driven development, it’s very similar — but instead of referencing an event, you directly reference the source state.

class UserService {
  readonly userResource = resource({
   loader: () => this.api.getUser()
  });

  readonly userId = computed(() => this.userResource.hasValue() ?  this.userResource.value().id : undefined);
}

class ProductService {
  readonly productsResource = resource({
   params: this.userService.userId
   loader: ({params: userId}) => this.api.getProduct(userId)
  })
}

class ChatMessagesService {
  readonly currentChatId = signal<string | undefined>(undefined);

  readonly chatMessagesResource = resource({
   params: this.userService.userId
   loader: ({params: userId}) => this.api.getChatMessage(userId)
  })

  readonly currentChat = computed(() => this.chatMessagesResource.hasValue() ? this.chatMessagesResource.value()[this.currentChatId] : undefined)
}

It’s so much easier to understand the data flow of the whole app with this pattern.

Even when defining TypeScript types, in this small example, most of the types are declared at the backend API call level.

👉 Yes, you can also implement this pattern with RxJs. But I haven’t seen many articles showing this kind of example.

You’ll sometimes need to implement an event-driven architecture — I’ll show you how later in this article.

3 - Track all async processes like `Resources` do

💬 Signals are synchronous; they are not designed to handle async operations.

👆 That’s wrong (though maybe there are technical limitations I haven’t encountered yet).

Resources provide a way to track asynchronous processes by exposing their status and value through a signal.

So, my take is that for every async operation (query, mutation, debounce, waiting, etc.), you should always wrap the code to track both the async status and its value.

This is the key to working properly with Signals.

Instead of writing:

const search = signal("");
const isLoading = signal(false);
const hasError = signal(false);
const items = toSignal(
  toObservable(search).pipe(
    debounceTime(300),
    tap(() => {
      isLoading.set(true);
      hasError.set(false);
    }),
    switchMap((searchValue) => fetchItems(searchValue)),
    tap({
      next: () => isLoading.set(false),
      error: () => {
        isLoading.set(false);
        hasError.set(true);
      },
    })
  ),
  {
    initialValue: [],
  }
);

Does something like:

const search = signal("");

const debouncedSearch = decounce(search, 300);

const itemsResource = resource({
  params: () => debouncedSearch.status === 'resolved' ? search() : undefined,
  loader: ({ params: searchValue }) => fetchItems(searchValue),
});

Where RxJs promotes writing all logic in a single pipe, Signals encourage breaking down each step.

It’s possible to create a similar pipe for Signals, but it should be done intentionally — because the pipe pattern tends to hide useful information you might want to access.

In the second example, it becomes possible to display a custom icon to show the user that the current search is debouncing.

This approach also perfectly anticipates future Angular rendering improvements.

I believe the goal is to re-render only the part of the DOM where a Signal has changed (although, for now, Angular still re-renders the whole component where the Signal changed, even with ChangeDetection.OnPush).

4 - The `undefined` keyword is important

The undefined keyword is very important when working with Signals.

If you don’t already know, when passing an undefined value to a resource, it puts the resource into the idle state and prevents the resource loader from triggering.

dataResource = resource({
  params: () => undefined,
  loader: ({params}) => this.myApiService.getData(params)
})

dataResource.status(); // 'idle', will never change because params is undefined

Keep this in mind — the Angular team intentionally chose this behavior, and it’s quite intuitive.

It’s somewhat similar to the EMPTY keyword in RxJs, which stops the stream execution (without completing it), meaning the next steps won’t run until another valid observable is emitted instead of EMPTY.

For more advanced patterns, you might want to wrap most Angular Signal utilities to avoid reacting to specific keywords (by using a Symbol, for example).

So, when creating your own Signal utilities, you may want to replicate this kind of behavior.

When the source is undefined:

Do not trigger the process
Set it to an idle state (for async processes)

5 - Do not expose Effect code

You may need to use effect, and that’s totally fine — especially if you follow my guidelines.

Sometimes, effect is irreplaceable; even toObservable uses it.

And it works great — I once had a case with nested effects, and I couldn’t believe everything was properly destroyed, preventing any memory leaks.

Don’t be afraid to use an effect; it’s actually safer than a subscription.

Because you’re forced to use it within a reactive context, Angular will automatically handle its cleanup correctly.

Unlike RxJs subscriptions, which can be created outside the reactive context and require the developer to manage the unsubscription manually.

It’s essential for creating utilities like debounce and turning imperative code into declarative code.

Nonetheless, I believe every effect function should be wrapped inside a utility function.

Unless you’re simply logging something, or triggering a side effect like opening a modal, exposing an effect directly in a component or service might be a sign of poor practice.

"triggering a side effect like opening a modal", it often depends on you modal API. Some can be fully declarative.
But keep in mind, that you should able to easily know if the a modal is open or not.

I know it’s not always easy — but keep that in mind.

6 - Actually you will need to write imperative code

If you follow this advice and wrap all your async code in a resource-like utility function, you may need to write some imperative code.

If you rely only on signals, handling async operations might force you to create one or more signals to store both the value and the status.

Within such a function, you’ll need to update your signals imperatively to reflect the current value and status.

And that’s totally fine, this imperative code is scoped to a relatively small function and, in theory, won’t expand beyond that.

Here are some examples that abstract away the imperative code:

const randomValueAfter5sRef = randomValueAfter5s(); //👈 Their is imperative code wrapped inside randomValueAfter5s
randomValueAfter5sRef.status() // 'loading', 'resolved'

function randomValueAfter5s() {
 const value = signal<number | undefined>();
 const status = signal<'loading' | 'resolved'>('loading');

 setTimeout(() => {
    value.set(Math.random()); // imperative code
    status.set('resolved'); // imperative code
 }, 5000);

 return {
   value,
   status
 }
}

const randomValueAfter5sRef = randomValueAfter5s();
randomValueAfter5sRef.status() // 'loading', 'resolved'

function randomValueAfter5s() {
 const value = signal<number | undefined>();
 const status = signal<'loading' | 'resolved'>('loading');

 setTimeout(() => {
    value.set(Math.random()); // imperative code
    status.set('resolved'); // imperative code
 }, 5000);

 return {
   value,
   status
 }
}

Here's another example:

Firstly: It may look weird (I am lacking imagination 😂, so I may change it, and I wan to keep the debounce implementation for the final part)
It will open a modal 2s after initialization
It will also open the modal 2s after the input change

The behavior may look strange (it is not the same delay behavior as the delay operator from RxJs).

Stackblitz link

When looking at the component, all the code is declarative (except opening/closing the modal).

<div>
      <label for="search">search</label>
      <input
        id="search"
        [value]="search()"
      (input)="search.set($any($event.target).value)"
      />
    </div>

    <div>
      delayedSearch ({{ delayedSearch.status() }}): {{ delayedSearch.value() }}
    </div>

    <div>
      Modal status ({{ modalHandler.status() }}): {{ modalHandler.value() }}
    </div>



    <dialog #modal class="modal">
      <h2>Text</h2>
      <p>{{ modalHandler.value() }}</p>
      <button autofocus (click)="modalHandler.close()">Close</button>
    </dialog>

export class App {
  private readonly modalref = viewChild<ElementRef<HTMLDialogElement>>('modal');
  protected readonly modalHandler = modalHandler(this.modalref); // 👈 declarative code

  protected readonly search = signal('Initial value'); // 👈 declarative code
  protected readonly delayedSearch = delay(this.search, 2000); // 👈 declarative code

  // 👇 Exposing an effect here is ok, due to the current Modal API
  private readonly _OpenModalAfterDelayEffect = effect(() => {
    // 👇 The status value will be used to trigger the effect callback
    if (this.delayedSearch.status() !== 'resolved') {
      return;
    }

    // 👇 use untracked to avoid to trigger the effect callback when the value change
    untracked(() => {
      this.modalHandler.open(this.delayedSearch.value() ?? ''); // 👈 imperative code
    });
  });
}

It respects all the previous points.

The effect and the imperative code are wrapped inside a utility function.

Except for the effect used to open the modal, which is fine here, as it mostly depends on your modal API. But thanks to the modalHandler we can track the modal status.

Delay:

export function delay<T>(source: () => T, ms: number) {
  const value = signal<T | undefined>(undefined);
  const status = signal<'loading' | 'resolved'>('loading');
  let timeout: ReturnType<typeof setTimeout> | null = null;

  // 👇 encapsulated effect
  effect(() => {
    const _sourceValue = source(); // track the sourceValue change
    if (timeout) return;

    status.set('loading');

    timeout = setTimeout(() => {
      value.set(source()); // 👈 imperative code and use to trigger the effect callback
      status.set('resolved'); // 👈 imperative code
      if (timeout) {
        clearTimeout(timeout); // 👈 imperative code
        timeout = null; // 👈 imperative code
      }
    }, ms);
  });

  return {
    value: value.asReadonly(),
    status: status.asReadonly(),
  };
}

modalHandler:

function modalHandler(
  modalRef: Signal<ElementRef<HTMLDialogElement> | undefined>
) {
  const value = signal('');
  const status = signal<'closed' | 'opened'>('closed');

  // 👇 encapsulated effect
  effect(() => {
    if (status() === 'opened') {
      modalRef()?.nativeElement.showModal();
    } else {
      modalRef()?.nativeElement.close();
    }
  });

  // 🔆 In the next article part, we will see how to use signal to implements events and remove close/open imperative api
  return {
    value: value.asReadonly(),
    status: status.asReadonly(),
    close: () => status.set('closed'), // 👈 imperative code
    open: (text: string) => {
      value.set(text); // 👈 imperative code, ok since the function is small and encapsulated
      status.set('opened'); // 👈 imperative code, ok since the function is small and encapsulated
    },
  };
}

7 - Debugging

From my experience, debugging Signal issues is harder than debugging RxJs.

When it runs into an infinite loop, it can be tricky to identify the cause of the problem.

Here are a few small tips that might help you:

Try using Angular DevTools to inspect the Signal graph.
Avoid reacting to changes in an entire object; instead, react only when specific properties change.

Instead of:

const myComplexeDerivedObject = computed(() => {
  const complexObjectValue = complexObject();
  ...
});

Do:

const complexObjectId = computed(() => complexObject().id);
const myComplexeDerivedObject = computed(() => {
  const _complexObjectIdValue = complexObjectId(); 
  // Only react when the id changes, not when other properties of the complexObject do
  untracked(() => {
    const complexObjectValue = complexObject();
    ...
  })
})

Add an equality function and use console.log or a debugger.

const myComplexeDerivedObject = computed(() => {
  const complexObjectValue = complexObject();
  ...
}, {
  equal: (cur, prev) => { 
      console.log({cur, prev});
      debugger;
      return cur === prev; // default mode
    }
});

Try wrapping most of your code in untracked, even in places where it might not seem necessary to make it non-reactive.

I once had an issue with an infinite Signal update because I had Signals inside a linkedSignal computation that changed and re-triggered the computation at the same time. I believe that’s not the intended behavior.

Even though I find debugging Signals harder, I’ve encountered far fewer issues compared to working with RxJs and I need less knowledge to fix the problem.

Transforming an Angular RxJS Example into Signals

While writing this article, I came across a post on X shared by Miloš Krstić (@grizlizli).

The example shows some RxJS code that he used to:

open a confirmation dialog,
if confirmed by the user, delete the targeted entity,
and then remove that entity from the resource used to fetch the list of entities.

The code looks like this (I simplified it a little bit):

  entitiesResource = resource(...);

  protected remove(entity: Entity): void {
    this.dialog()
      .open(RemoveEntityModalComponent, {
        data: { entity }
      })
      .afterClosed()
      .pipe(
        filter(confirmed => confirmed),
        switchMap(() => this.entityService.deleteEntity$(entity.id)),
        takeUntilDestroy(this.destroyRef)
      )
      .subscribe(() => {
        this.entitiesResource.update(entities => entities?.filter(e => e.id !== entity.id));
      });
  }

My Analysis Based on the Previous Part of the Article

The example looks pretty solid, and the author properly handles the unsubscription.

Here, I’ll propose another approach based on Signals, following the same principles as before.

Here’s what could be improved:

The main weakness of the example is that there’s nothing preventing remove from being called multiple times (unless the dialog itself blocks this behavior).
The RemoveEntityModalComponent is eagerly loaded (it could be lazy-loaded, but I won’t cover that here).
If the user refuses to delete the entity, the subscription persists until the destroyRef is triggered. This may be harmless, but it still represents a minor memory leak.
The user has no way to know if a deletion is currently in progress (especially if it’s asynchronous).
The current setup only allows deleting one entity at a time — which might be fine, but still limiting.
The subscription is inside a method, which hides the status of the async process.
The code does not handle errors when deletion fails.
An optimistic deletion approach could improve the user experience (though it might not be strictly necessary).
The code doesn’t account for fast loading, which can cause layout shifts — for example, when a loader briefly appears before the final data is displayed. This hurts the UX.
The code doesn’t offer an easy way to persist the resource value (e.g., in localStorage). That could be helpful if the user refreshes the page while keeping the data visible.
Finally, it doesn’t provide an easy way to prefetch data.

I know some of these points may go beyond the original scope, but I’ll show how to address them using a proper tool.

Converting the RxJS Example to a Signal-Based Solution

Here’s a small improvement that can be achieved using Signals:

  entitiesResource = resource(...);

  removeEntity = signal<Entity | undefined>(undefined, {
    equals: false, // enable to set same entity again
  });

  removeEntityDialogRef = rxResource({
    params: this.removeEntity,
    stream: ({ params: entity }) =>
      this.dialog()
        .open(RemoveEntityModalComponent, {
          data: { entity },
        })
        .afterClosed(),
  });

  removeEntity = rxResource({
    params: () =>
      this.removeEntityDialogRef.value()
        ? this.removeEntity.value()
        : undefined,
    stream: ({ params: entity }) => this.entityService.deleteEntity$(entity.id),
  });

  remove(entity: Entity) {
    this.removeEntity.set(entity);
  }

  _onRemovedEntity = effect(() => {
    if (this.removeEntity.status() === 'resolved') {
      this.entitiesResource.update((entities) =>
        entities?.filter((e) => e.id !== entity.id)
      );
    }
    if (this.removeEntity.status() === 'error') {
      this.entitiesResource.reload();
    }
  });

It almost addresses all the weaknesses mentioned earlier.

Since the dialog is based on an observable, we don’t need to refactor that part of the code yet (it can be quite complex). Instead, we can simply bind it to an rxResource.

Otherwise, this example doesn’t really need to use RxJS anymore, and it’s relatively easy to switch to Signals.

In the next part, I’ll show how the dialog API can be adapted to implement events based on Signals.

Implementing Advanced Patterns Effortlessly

Moreover, this new pattern allows us to implement parallel entity deletion, which wasn’t really possible (or easily controllable) before.

Thanks to the declarative nature of the code, enabling this behavior only requires using resourceByGroup, which allows parallel requests.

It’s not an official resource — I created it myself.

Here’s a LinkedIn post presenting it, along with the implementation.

  removeEntityByGroup = rxResourceByGroup({
    params: () =>
      this.removeEntityDialogRef.value()
        ? this.removeEntity.value()
        : undefined,
    identifier: (params) => params.id,
    stream: ({ params: entity }) => this.entityService.deleteEntity$(entity.id),
  });

This is the same property exposed by resource, with an identifier used to create a key that indexes a mapper object.

You can access the dedicated resource like this:

removeEntityByGroup[entity.id]?.status() === 'loading'

Going Further — Making the Code Fully Declarative with One of My Tools

There’s still an effect used to update the entitiesResource to keep the resource value in sync without reloading it.

Personally, I consider this a bad practice, but I understand it’s more challenging to implement a fully declarative resource — so it might be acceptable in this case.

As you may know, entitiesResource represents server state (it should reflect what’s stored in the backend).

Using client-side state management tools like NgRx (global or Signal Store) or NGXS doesn’t really improve the developer experience compared to what we’ve already achieved.

This is where your project should rely on a proper server state management tool.

For example:

TanStack Query for Angular, or
my latest tool: ng-query, which is built on signalStore and pure Signals (RxJS is optional, but still experimental).

With TanStack Query, you’d need to create a wrapper that binds the targeted entity to a mutation — which can be a bit tricky if you’re not used to it.

ng-query is more suitable, but I’m currently working on an even simpler solution that I’d like to show you.

It doesn’t have a name yet, but here’s an implementation of the example that fully addresses all the points mentioned earlier.

Tell me if you like the idea.

Conclusion (Part 1)

When working with Signals, remember:

Your code should follow declarative patterns.
Signals promote a state-driven architecture.
Track all asynchronous processes, just like Resources do.
The undefined keyword is meaningful — use it intentionally.
Don’t expose your Effect logic directly.

Find clean, reusable patterns that you can apply easily and consistently.

I’ll also share some useful patterns for handling server state declaratively — without needing any external tools.

(But first, I’ll finish publishing this series of articles.)

Try to think Signal-first. RxJS will become increasingly optional, and most RxJS code can be transformed into Signals.

As you adopt more Signal-based patterns, you’ll eventually need to implement an event-like system.

That’s the topic of the next article!

If you’re interested in how to do that and don’t want to wait, send me a message on LinkedIn. I’ll share some snippets with you.

If you don’t know me, I’m Romain Geffrault, and I regularly share Angular/TypeScript/RxJs/Signal content.
Check out my other articles and follow me on LinkedIn Romain Geffrault

Angular: The ultimate guide to creating a smart infinite scroll (using RxJs)

Romain Geffrault — Tue, 30 Sep 2025 16:28:05 +0000

I had to create a custom infinite scroll.

To keep this example simple:

It should handle a "load more" action
It should handle a "refresh" action (it should repeat all the async call to get fresh data)
The current state should be preserved during the refresh

So I was looking for some articles on Google and it was a disaster.

Most articles promote a solution that includes a lot of boilerplate, with imperative code that is difficult to read.
Even the functionalities were very limited.
There are some nice libraries that may be useful, but they should be used directly inside the template by using their component or directive.
The closest solutions that I found were using a pattern with RxJs scan or scanMap. But again, it was not possible to extend the pattern to match my needs.

Angular Dev promotes the benefits of using Rxjs, but it looks like it is not mastered enough to be used for common cases. It is a little annoying for junior dev that need to implement such functionalities.

So I had to find a more powerful pattern that is more scalable.

Create an infinite scroll orchestrator

For this demonstration, I will share a solution that uses only RxJs, because I worked on a project that does not have Signals yet.

Use a powerful RxJs pattern

The solution that I have found is based on a reusable pattern that you should learn if you use RxJs. Here is a dedicated article about it RxJS > Signals ? Mon pattern préféré.

It looks like that:

The first part included in the merge declares all the sources and how it should affect the state (by returning a callback function that takes a current state as an argument).

The second part is the scan RxJs operator that preserves the state and calls the "reducer" of the event emitted.

The third part is a startWith that will enable it to emit an initial value before any source emits a value.

How can this base handle an infinite scroll pattern?

Creating an infinite scroll pattern that can scale

Now, it is relatively simple to adapt this pattern to handle infinite scroll, but the way to handle the refresh behavior is not common.

Instead of just making an async call and accumulating its result by using the scan, I will use the groupBy RxJs operator (if you are not familiar with this operator, I wrote an article about it: Angular: Granular CRUD Request Status Tracking on a List (RxJs groupBy 🙏).

And it enables us to easily store the response per page.

Then, the final result will accumulate all the data by parsing each cached page response.

It is like creating a computed or derived result.

Furthermore, all my async calls use stateStream (a custom operator available in the StackBlitz) that is similar to the Angular resource. It enables us to track the async request status.

Another main difference with RxJs solutions that you can find about infinite scroll is that the sources are preserved (one source is created per page thanks to the groupBy).

Why is it important? Because we can use the power of the repeat RxJs operator to trigger the refresh (just by adding one line).

Angular smart infinite scroll orchestrator pattern

So, here's my solution that satisfies my needs and even more.

private readonly page$ = new BehaviorSubject(1);

private readonly postsData$ = merge(
    this.page$.pipe(
      groupBy((page) => page),
      mergeMap((page$) =>
        getPosts(page$.key, this.batchSize).pipe(
          repeat({
            delay: () => this.refreshTrigger$,
          }),
          map((data) => ({ ...data, page: page$.key })),
          map((statedPosts) => (state: PostsPerPage) => ({
            ...state,
            [statedPosts.page]: {
              ...statedPosts,
              result: statedPosts.isLoaded
                ? statedPosts.result
                : // keep previous result during reloading
                  state[statedPosts.page]?.result ?? [],
            },
          }))
        )
      )
    )
  ).pipe(
    scan((acc, fn) => {
      return (fn as any)(acc);
    }, {} as PostsPerPage),
    withLatestFrom(this.page$),
    map(([data, page]: [PostsPerPage, number]) => {
      const hasFirstPage = !!data[page];
      const isFirstPageLoaded =
        Object.keys(data).length > 0 &&
        Object.values(data).some((statedData) => statedData.isLoaded);

      const currentPage = data[page];
      const hasMore =
        currentPage?.isLoaded &&
        !!currentPage?.result?.length &&
        (currentPage?.result.length || 0) >= 3;

      const concatenatedPosts = Object.values(data)
        .map((statedData) => {
          return statedData.result ?? [];
        })
        .flat();

      return {
        dataPerPage: data,
        isFirstPageLoaded,
        isLoading:
          Object.values(data).some((statedData) => statedData.isLoading) ||
          !hasFirstPage,
        isLoaded: Object.values(data).some((statedData) => statedData.isLoaded),
        hasMore,
        result: this.removeDuplicatedPosts(concatenatedPosts),
      };
    }),
    shareReplay({
      refCount: true,
      bufferSize: 1,
    })
  );

As you can see after the scan operator, there is withLatestFrom that I use to get the last page value (It could be retrieved by other way).

Then, there is a map that I use to compute all properties that I need to use in my template.

Here you can play with it, thanks to StackBlitz.

The template was generated using Bolt

Conclusion

So, I think it is a smart way to deal with infinite scroll that can be adapted to specific needs without the need to use a library.

I think it scales well, because I had to implement another functionality and it was relatively easy to add it.

I had to listen to a websocket and add incoming posts to the list displayed only if some conditions were validated.

I like this RxJs solution, but it is also possible to do it without RxJs, by just using Signal. I have already converted a similar pattern from RxJs to Signal. I may write an article about it. And it is something I will provide inside my tool @ng-query, that is a powerful tool to handle common complex UX with a simple DX.

I know my infinite scroll requirements were specific and may be different from yours. But I think, this pattern can help you build a robust solution.

Let me know what you think about this pattern and if you have questions, please write them in the comment below!

If you don’t know me, I’m Romain Geffrault, and I regularly share Angular/TypeScript/RxJs/Signal content. Check out my other articles and follow me on LinkedIn Romain Geffrault

⚡ Optimizing Angular Signals with Smart Equality Checks

Romain Geffrault — Sun, 07 Sep 2025 05:21:10 +0000

Signals are a powerful tool in Angular to handle reactivity, but they can easily cause unnecessary updates, wasted requests, and performance issues if not carefully managed. In this article, we’ll explore how Signals emit updates, why equality checks (equal) matter, and how to implement efficient deep comparison strategies to keep your applications smooth and reliable.

🔄 How Signals Emit Updates

Each time the reference changes, the Signal is considered “dirty”, and all derived Signals, the DOM, and effect functions will also update.

When the signal return a string or a number, it compare the value using ===(But this article is about dealing whith object returned by the signal)

🚫 Preventing Useless Updates with `equal`

To avoid unnecessary Signal pipeline updates, you can use the equal option to manually define comparison logic.

This looks simple for shallow objects, but with deep objects the work becomes much heavier and harder to maintain.

📡 Angular Resource and Annoying Updates from the Source

The same issue exists with Angular Resource. You may use a Signal as a source for the params option.

This triggers an async call each time the Signal emits a new value. However, each new call cancels the previous one (similar to switchMap in RxJS).

This not only causes unnecessary requests but also removes the previous value from the Resource, which can lead to strange side effects like flaky page rendering.

⚖️ Performance of `equal` with Deep Nested Objects

To prevent unnecessary updates, you could add manual equality checks before calling mySignal.set(...) or mySignal.update(...).

But this is easy to forget. That’s why I prefer using the equal option:

signal({ id: 1 }, { equal: (a, b) => a.id === b.id });

However, when dealing with deeply nested objects, equality checks can become expensive. Andrew Jarrett explored the fastest JavaScript solution for deep equals comparison, which might be helpful.

🚀 How to Make JavaScript’s Fastest Deep Equal Comparison

Here’s his article: How to build JavaScript's fastest “deep equals” function.

The solution looks like this:

const addressEquals = Function(
  "x",
  "y",
  `
  if (x === y) return true
  if (x.street1 !== y.street1) return false
  if (x.street2 !== y.street2) return false
  if (x.city !== y.city) return false
  return true
`
);

This solution consists of wrapping your comparaison inside a string and evaluate it with the constructor of the Function.

This approach is fast but not type-safe. If your object’s shape changes, you could forget to update the comparison string.

But even if it is not typesafe, I think, it is possible to create a dedicated Type test and using a custom Type mapper to transform the object into a target string with the same shape of your object

interface MyObject {...};
const MyObjectComparaisonString = `...` as const
type IsMyDeepEqualsStringCorrect = Expect<Equal<ToDeepEqualsComparaion<MyObjectType>, typeof MyObjectComparaisonString >>

This is just an idea, but it can be enough for your needs.

But if you already use a schema library, this lib is a perfect for your needs !

📦 `@traversable`: A Simple Solution for Deep Equality with Schema Validators

Andrew Jarrett also created a library that makes deep equality trivial when working with schema validators.

Using zod as an example:

import { z } from "zod";
import { zx } from "@traversable/zod";

const Address = z.object({
  street1: z.string(),
  street2: z.optional(z.string()),
  city: z.string(),
});

// Create the deep equal function 👇
const addressEquals = zx.deepEqual(Address);

addressEquals(
  { street1: "221B Baker St", city: "London" },
  { street1: "221B Baker St", city: "London" }
); // => true

When used with a Signal:

const address = signal(..., { equal: addressEquals });
const streetViewFromAddressResource = resource({ params: address, ... });

Now streetViewFromAddressResource is only called when the address really changes.

This works with multiple schema libraries:

Zod
JSON Schema
ArkType
TypeBox
Valibot

It’s a clean solution that evolves with your schema without manual updates.

Note: Be aware that if your object/schema contains functions or dates, the way they are handled may be uncertain. (It is working correctly 👇)
Andrew Jarrett responce 🙏

👉 If you found this article useful, don’t hesitate to leave a 👍 or share your thoughts in the comments — I’d love to hear your feedback!

If you don’t know me, I’m Romain Geffrault, and I regularly share Angular/TypeScript/RxJs/Signal content. Check out my other articles and follow me on LinkedIn Romain Geffrault

⚡ Optimizing Angular Signals with Smart Equality Checks

Romain Geffrault — Sun, 07 Sep 2025 05:21:10 +0000

🔄 How Signals Emit Updates

Each time the reference changes, the Signal is considered “dirty”, and all derived Signals, the DOM, and effect functions will also update.

🚫 Preventing Useless Updates with `equal`

To avoid unnecessary Signal pipeline updates, you can use the equal option to manually define comparison logic.

This looks simple for shallow objects, but with deep objects the work becomes much heavier and harder to maintain.

📡 Angular Resource and Annoying Updates from the Source

The same issue exists with Angular Resource. You may use a Signal as a source for the params option.

This triggers an async call each time the Signal emits a new value. However, each new call cancels the previous one (similar to switchMap in RxJS).

This not only causes unnecessary requests but also removes the previous value from the Resource, which can lead to strange side effects like flaky page rendering.

⚖️ Performance of `equal` with Deep Nested Objects

To prevent unnecessary updates, you could add manual equality checks before calling mySignal.set(...) or mySignal.update(...).

But this is easy to forget. That’s why I prefer using the equal option:

signal({ id: 1 }, { equal: (a, b) => a.id === b.id });

However, when dealing with deeply nested objects, equality checks can become expensive. Andrew Jarrett explored the fastest JavaScript solution for deep equals comparison, which might be helpful.

🚀 How to Make JavaScript’s Fastest Deep Equal Comparison

Here’s his article: How to build JavaScript's fastest “deep equals” function.

The solution looks like this:

const addressEquals = Function(
  "x",
  "y",
  `
  if (x === y) return true
  if (x.street1 !== y.street1) return false
  if (x.street2 !== y.street2) return false
  if (x.city !== y.city) return false
  return true
`
);

This approach is fast but not type-safe. If your object’s shape changes, you could forget to update the comparison string.

📦 `@traversable`: A Simple Solution for Deep Equality with Schema Validators

Andrew Jarrett also created a library that makes deep equality trivial when working with schema validators.

Using zod as an example:

import { z } from "zod";
import { zx } from "@traversable/zod";

const Address = z.object({
  street1: z.string(),
  street2: z.optional(z.string()),
  city: z.string(),
});

// Create the deep equal function 👇
const addressEquals = zx.deepEqual(Address);

addressEquals(
  { street1: "221B Baker St", city: "London" },
  { street1: "221B Baker St", city: "London" }
); // => true

When used with a Signal:

const address = signal(..., { equal: addressEquals });
const streetViewFromAddressResource = resource({ params: address, ... });

Now streetViewFromAddressResource is only called when the address really changes.

This works with multiple schema libraries:

Zod
JSON Schema
ArkType
TypeBox
Valibot

It’s a clean solution that evolves with your schema without manual updates.

Note: Be aware that if your object/schema contains functions or dates, the way they are handled may be uncertain.

👉 If you found this article useful, don’t hesitate to leave a 👍 or share your thoughts in the comments — I’d love to hear your feedback!

If you don’t know me, I’m Romain Geffrault, and I regularly share Angular/TypeScript/RxJs/Signal content. Check out my other articles and follow me on LinkedIn Romain Geffrault

DEV Community: Romain Geffrault

@craft-ng: Associer l’art de la composition & du state management dans Angular

1) Une structure commune à toutes les primitives

2) Les primitives: fonctionnement + exemples concrets

state

mutation

query

asyncProcess

queryParam

Exemples de la doc qui m'ont inspiré

3) Exposer des méthodes et état dérivé avec les insertions (Method-based)

Method-based insertions

Source-based insertions (Event-based)

Créer de la logique réutilisable est très simple

4) Tour rapide de quelques insertions utiles

insertPaginationPlaceholderData (query)

insertReactOnMutation (query)

insertLocalStoragePersister (state/query/asyncProcess)

insertEntities (state)

insertSelect (state)

5) Pourquoi source$ est un vrai levier d'architecture

Cas 1: plusieurs states réagissent au même événement

Cas 2: state imbriqué + insertSelect

Cas 3: event-driven (et pont avec Observable)

6) La philosophie continue avec injectService

7) Et au-dessus: le store craft

Conclusion

Use Angular HostDirective for all of your component facades

What are HostDirectives ?

Simple Example

Share directive inputs/outputs

Create a component facade directive

How to implement the counter facade directive in a component

How to interact with a child component that use an host directive ?

Facade directive - Demo link

HostDirective facade pattern limitations

My point of view about Angular input/output

Conclusion

99% of Angular developers don’t know that Signals can be used this way.

Mastering Angular Signals: Understanding Angular Signal Recomputation Reactions (part 2)

Romain Geffrault ・ Dec 2

StoryTime Angular : mon blog, le SEO et le choc du SSR

Un backend simple, volontairement

Angular sans IA… et ça marchait quand même

Écrire du contenu : beaucoup plus dur que coder

Un outil maison pour publier mes articles

Le mur du SEO et du CSR

Angular Universal : la plus grosse galère de ma vie Angular

Déployer du SSR quand on n’a jamais touché à un serveur

Les meta tags dynamiques : autre combat

Avec le recul

Create Your Own TanStackQuery In Angular 🤝 RxJs

What resource$ will enable for server state management?

resource$ usage and implementation

resourceByGroup$ usage and implementation

Demo resource$ and resourceByGroup$

A small overview of my state management tool

Mastering Angular Signals: Understanding Angular Signal Recomputation Reactions (part 2)

How to Implement Signal Reactions

Recomputation‑Event‑Driven Architecture with Signal Reactions — Principles

How to Implement a Recomputation Event Mechanism Using Signals

Implementing a source Utility Function

A Practical Use Case for Signal Reaction Architecture

How to Implement Declarative State and Its Reactions Using linkedSignal?

How does it work?

What Are the Limitations of Signal Reactions?

1 - Reactions Are Not Fully Synchronous When a Signal Changes

Why Are Signal Reactions Not Fully Synchronous?

How the Pull Mechanism Works

2 - Reactions React Only to the Last Produced Value

How to Catch All Values That Are Set During the Push Phase?

3 - Multiple Reactions May Occur Within the Same Cycle

4 - The Order of Effects Matters

5 - Make Sure Your linkedSignal Is Read When Using It with Reactions

Where Should You Not Use Signal Reactions?

Take a Step Back from Signal Reactions

Some Community Feedback ⚠️

My Point of View About Signal Reactions

Signal Recomputation utilities toSource / computedSource / sourceFromEvent

toSource transforms a Signal into a source

7) Et au-dessus: le store `craft`

What `resource$` will enable for server state management?

`resource$` usage and implementation

`resourceByGroup$` usage and implementation

Demo `resource$` and `resourceByGroup$`

Implementing a `source` Utility Function

How to Implement Declarative State and Its Reactions Using `linkedSignal`?

5 - Make Sure Your `linkedSignal` Is Read When Using It with Reactions

Signal Recomputation utilities `toSource` / `computedSource` / `sourceFromEvent`

`toSource` transforms a Signal into a `source`

`computedSource` use it to derive a source

`sourceFromEvent` derive a DOM event into a Signal source

Implementing a `source` Utility Function

How to implement declarative state with `linkedSignal` that reacts to multiple signal events?

3 - Track all async processes like `Resources` do

4 - The `undefined` keyword is important

🚫 Preventing Useless Updates with `equal`

⚖️ Performance of `equal` with Deep Nested Objects

📦 `@traversable`: A Simple Solution for Deep Equality with Schema Validators

🚫 Preventing Useless Updates with `equal`

⚖️ Performance of `equal` with Deep Nested Objects

📦 `@traversable`: A Simple Solution for Deep Equality with Schema Validators