DEV Community: Romain Geffrault

Stop using SignalStore for everything: hype fades, debt remains.

Romain Geffrault — Mon, 27 Apr 2026 09:20:40 +0000

Let’s be serious for a moment. This probably won’t please everyone, but at some point we need to put the hype aside and focus on facts.

We need to stop treating the NgRx team’s signalStore as the one sacred tool for state management in Angular.

Yes, as we’ll see, signalStore has major strengths. But in practice, and with the way it is often promoted, things can go in the wrong direction.

Why am I criticizing it?

As the stats show, it keeps getting more popular, so more and more developers are using it and discovering it.
There are lots of conference talks promoting it, which is great, but we also need to talk about its limits.
signalStore has left very little room for new signal-based patterns to emerge, especially patterns that leverage the reactive nature of Signals and their deep integration with Angular. It has almost become “the right way” to work with Signals, and that is unfortunate.
It is marketed as an all-purpose Swiss Army knife, but what if it is not?

When you use a tool, you need to understand both its strengths and its limits. Otherwise, you risk building technical debt hidden behind the fact that the tool is “cool” or “trendy.”

With that in mind, I will also highlight some Signal-based patterns that are still not very popular, but that signalStore largely misses.

This article is for people who already use signalStore or want to use it, but who do not yet see how things can go wrong (hopefully before it is too late).

Before anything else, I want to congratulate the NgRx team for their work. It is a very powerful tool with major advantages, and it opens the door to a new style of state management in Angular.

I have taken a lot of inspiration from it to build my own state-management tools, and I think that is great for the Angular community.

Where to start? Do you like Angular resources?

Let me tell you a story about a young Angular enthusiast, Simon.

At work, signalStore is implemented everywhere, and we ended up talking about resources and how to use them.

Personally, I had stopped using signalStore for a while in favor of other patterns. That created some misunderstandings in our discussion, but not in the way you might think.

The goal was to build a page that displays User details based on a URL parameter (id).

My view of the solution:

The id is read by the component/page through an input (using withComponentInputBindings).
We use a resource and pass this id signal as params. Whenever it changes, it triggers an API call for that new id.

Nothing complicated. This is a very standard use of resources.

// component/page
@Component()
class UserDetails {
  id = input.required<string>();

  userService = inject(UserService);

  userDetailsResource = resource({
    params: this.id,
    loader: (id) => this.userService.getUserDetails(id),
  });
}

Simon wanted to avoid handling the logic directly in the component to “separate responsibilities,” and that fit better with the rest of the project.

In short, we would go through signalStore for the API call.

Have you seen signalStore examples for API calls? 😅

Have you noticed how server state is handled in signalStore when following official NgRx examples?

We’ll come back to that. For now, the expected behavior is still simple: the id in my URL changes, so I need to call the API to fetch the new User details.

Here is one possible solution (many variations exist, but the issue is the same):

On the signalStore side, we can imagine an implementation like this. It seems to match what we need.
Id changes => API call to fetch new User details.

const userDetailsStore = signalStore(
  withState({ id: undefined as string | undefined }),
  withProps(({ id }, userService = inject(UserService)) => ({
    userDetails: resource({
      params: id,
      loader: ({ params: id }) => userService.getUserDetails(id),
    }),
  })),
);

Then I told him: now pass the id from your component into your signalStore.

And it took me a while to understand why he struggled so much with that step.

How do you pass an input to signalStore?

Honestly, how do you pass an input to signalStore? It is a very simple question, but the answer is too complicated for what we need.

If I am not mistaken, one solution looks like this, where we expose a method to update id.

const UserDetailsStore = signalStore(
  withState({ id: undefined as string | undefined }),
  withProps(({ id }, userService = inject(UserService)) => ({
    userDetails: resource({
      params: id,
      loader: ({ params: id }) => userService.getUserDetails(id),
    }),
  })),
  withMethods((store) => ({
    setId: (id: string) => patchStore(store, { id }), // method to update id in signalStore state
  })),
);

On the component side, we need an effect to call this method each time id changes.

@Component({ providers: [UserDetailsStore] }) // create a store instance for this component, destroyed with the component
class UserDetails {
  id = input.required<string>();
  userDetailsStore = inject(UserDetailsStore);

  _syncIdWithStore = effect(() => {
    this.userDetailsStore.setId(this.id());
  });
}

That is still pretty heavy just to extract logic from our component, don’t you think?

PS: This is an appropriate use of effect for this solution.

We have to provide the store, inject it, create an effect to synchronize component id with store id, and expose a store method to update id.

After that, I told him: wait, I’ll show you an alternative to extract component logic, and it will be insanely simple.

Extracting component logic in the Signals era

function userDetailsResource(id: Signal<string>) {
  const userService = inject(UserService);

  return resource({
    params: id,
    loader: ({ params: id }) => userService.getUserDetails(id),
  });
}

@Component()
class UserDetails {
  id = input.required<string>();

  userDetails = userDetailsResource(this.id);
}

And that is it. Yes, this is not a 1:1 port because we cannot inject userDetails into child components. But at no point was it difficult to write a function that extracts logic from our component.

And we barely see this pattern, even though it has become much simpler since inputs became signals.

If you really want to go through dependency injection so you can use it in child components, you can also do that thanks to tools I built (craft-ng).

export const { injectUserDetailsQuery, provideUserDetailsQuery } = craftService(
  { name: "UserDetailsQuery", scope: "toProvid" },
  (id: Signal<string>) => {
    const userService = inject(UserService);

    return resource({
      params: id,
      loader: (id) => userService.getUserDetails(id),
    });
  },
);

@Component({ providers: [provideUserDetailsQuery()] })
class UserDetails {
  id = input.required<string>();

  userDetailsQuery = injectUserDetailsQuery(this.id);
}

There is barely any extra complexity.

3 major limitations of signalStore from this example

1 - Passing inputs to signalStore is complex and adds mental overhead

As we saw, you need a lot of boilerplate to connect an input to signalStore.

That adds cognitive overhead to understand data flow and what is happening in the app.

You can build a helper utility to make input-to-signalStore binding easier. I have shared different versions in my posts.

2 - signalStore is not suited for server states

I was generous: I used resources to manage server state (user details) inside signalStore.
But what value did signalStore add? None, except making API triggers harder to manage.

If we take the official example, which directly handles server state with signalStore:

export const BookSearchStore = signalStore(
  withState(initialState),
  withMethods((store, booksService = inject(BooksService)) => ({
    /* ... */
    // 👇 Defining a method to load all books.
    async loadAll(): Promise<void> {
      patchState(store, { isLoading: true });

      const books = await booksService.getAll();
      patchState(store, { books, isLoading: false });
    },
  })),
);

Without a utility similar to a resource, we end up manually handling loading state, errors, and so on, which is heavy and tedious.

And in web apps, that is very common.

Why does it “work badly”? Because signalStore treats client state (its withState) as the source of truth. It cannot be derived from a resource, or from URL state. So it is forced into manual synchronization between external sources and internal state.

Some people like this pattern. I do not. I find the signalStore abstraction neither appropriate nor adaptable here.

That is not worthy of a Swiss Army knife. It has value, as we will see later, but not as a do-everything tool.

If you still doubt it, look at examples across articles. You will see they are very heavy for a pattern that has already been solved for a while by tools like resources, TanStack Query, and so on.

In my tools, I have a query utility that lets me treat the equivalent of a resource as the source of truth, and attach methods/computed values to interact with fetched state.

I use the same mechanism for query params with queryParam.

And from a DX perspective, it works much better.

But what about the next point?

3 - Testability and dependency tracking

On testability, signalStore is tested like any other service. So it has the same strengths and weaknesses as classic Angular services.

Another issue I did not mention, but that still bothers me even if the community accepts it:

Dependencies (injected services) are not tracked in signalStore.

Current Angular services share that weakness, and signalStore does not compensate for it.

Yet dependency tracking greatly simplifies testability (ensuring dependencies are properly provided or mocked).

Like standalone components where we import only what is needed, dependency tracking lets us provide and mock only what is necessary.

Remove a dependency? TypeScript throws an error in tests, because we are trying to provide/mock something that no longer exists.

That ensures tests fail for the right reasons, not because provider/mock configuration drifted.

I solved this in my tools too. If you are interested, check craftService.

The Swiss Army knife is starting to show some weaknesses...

Should we throw signalStore in the trash? No

Client state management

After exposing some limits, here is what it is good at, even very good at compared to most Angular state-management solutions.

It is very well suited to managing one client state.

I did say: one client state.

One:
So not several, but one single state.

Client:
So not server state, not state coming from a resource, not URL state.

Why not server state? Even though signalStore can be adapted to manage server state (API data), it introduces a lot of boilerplate in common cases, and it is easy to forget error handling. On top of that, with both Observables and Promises, errors are not typed, which makes business-error handling harder. Errors can come from lost connection, forbidden resource access, and so on. And if we look at the vast majority of API call examples, error handling is catastrophic (not to say the author just does not care). I think this comes from the fact that NgRx does not provide tools that truly help with API/async handling, and delegates that responsibility to users.

Why is it good for client states?

The value is that we start from a typed initial state.

That means the shape stays consistent, while properties can be updated.

And how are they updated?

Through methods that patch signalStore state.

Or via reactions to events.

And that is great: inside signalStore itself, we can see exactly how state evolves.

Exposing methods is practical, and it is just as easy to move to event-driven reactions, or a mix of both.

It can be a good compromise between a method-based approach and an event-based approach (Redux principle).

Another strength is exposing derived state directly through computed values.

Everything is in one place, which helps, in my view, to drive logic and visualize the different state evolutions.

Now let us talk about another “problem” signalStore solved compared to its predecessor (global store).

Global or local scope, but not quite...

A limitation of the global store is that it was mostly designed for global state. And it did that fairly well.

But when architecting an application, we need more than global state. We also need feature-local state, or even component-local state.

(I may be wrong on this point, feel free to correct me in the comments.)

Because signalStore can have either global or more local scope, it seems better suited to application architecture.

And that is to its credit.

But again, it does not do better than Angular services.

You can still forget to provide it and get a runtime error, which conceptually could be avoided.

Another criticism on this topic, where I think the NgRx team could adapt, is that it is not possible to use signalStore inline in a component the way we can with resources.

Yet that would give us a kind of enhanced signal where everything is declared explicitly about how the component interacts with it.

It would also remove issues around passing inputs and the requirement to provide the store.

It would greatly simplify creating one signalStore per state, rather than composing several states that are not necessarily related.

In my opinion, that should be the default mode.

And what about composition, which is often highlighted?

signalStore composition: top or flop?

In reality, I find it very interesting.

And it enables logic reuse in a very simple way.

However (yes, I have things to say here too 😂), allowing a store to be composed with features that each contain states, methods, computed values, and reactions is nice, but...

This choice can be very interesting for logic sharing, but it can also distort the purpose of the store.

We end up seeing signalStores used as facades.

Where signalStore adds no real value and even makes things more complicated.

As we can see in this example, the facade is handled by a classic service, which could also be a function (thanks to @lucas Garcia on LinkedIn for his critique of signalStore composition on the Bonjour Angular Discord, which inspired me).

@Service()
class MyFacade() {
    public readonly state1 = inject(State1); // State1 created via signalStore
    public readonly state2 = inject(State2); // State2 created via signalStore

    public readonly derivedState = computed(() => {
        // derivation logic based on state1 and state2
    });

}

Where is the complexity? At what point does signalStore really add value when composing several different states?

Very little value.

My rule: signalStore manages one state, not several.

And we do not use it as a facade, or anything close to that.

Personally, to avoid these drifts, I prefer composing a state only through logic composition and derived states (no additional state added through composition). See my state primitive.

That keeps a clear responsibility for what our state-management “container” should do.

And I apply this principle to my other primitives too: query, mutation, queryParam, which, like Signal Form, derive logic from source state.

By the way, if you think the event system compensates for the other weak points, I also have one criticism there.

signalStore events are not that declarative

I clearly struggle with NgRx events, and the signalStore approach, while probably better than its parent, still has this major flaw.

We cannot derive an event (with official utilities). No, we must give it a description of what it represents.

That event is either dispatched after a user action, or from an effect that computes and then emits an event.

And these latter events are what bothers me.

Instead of going through a description, we could directly write the code that triggers the event at declaration time.

That gives us a much more declarative event, and avoids an effect that has to be provided to be active.

And on top of that, if it is not used, it can be tree-shaken by the compiler, which is not the case for a classic event.

After saying all this, I want to clarify that an event-based approach is still one of the most interesting approaches for managing state and business logic.

And it is harmful not to do event-based in a project just because events are not declarative.

Typing side

I will not go too deep into details, but even if the signalStore pattern is very interesting, and likely ahead of its time, it also has limits.

I have worked with it a lot. I rebuilt this whole accumulation mechanism because I found it fascinating.

Then I built server-state management tools dedicated to signalStore, and I can tell you: it is very, very complicated.

Personally, I think there is one layer too many in typing, which makes creating custom patterns extremely difficult.

And when we want to work with generic features based on the main withX pattern, if I remember correctly, it is not possible without using two utilities.

I had proposed a simplification for withFeature, but it was rejected because it does not handle generic-parameterized features better than their current mechanism.

Link to one of my articles on creating custom signalStore features with good DX.

I wanted to mention this point because it is part of signalStore’s limitations.

But it is not really the main problem.

Conclusion

signalStore enabled the discovery of a very interesting composition pattern.

It is king for managing one client state, where it offers good DX, and that is already valuable.

But as we saw, it is not a Swiss Army knife.

It does not replace a specialized tool for URL-related state or server states (current resources are not flawless either).

(craft-ng does all of this 🤫)

If you keep using it, my advice would be to always use it for one client state, and nothing more.

Avoid doing injections inside it as much as possible (still okay when interacting with the browser, for example API calls, local storage, etc.).

And do not use it for facades or composition/orchestration of several states.

That way, you keep the best parts of signalStore and can benefit from other patterns that are often more appropriate.

I am Romain Geffrault.
Angular developer and creator of @craft-ng
Follow me for more Angular content

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

Arrête d’utiliser SignalStore pour tout : la hype passe, la dette reste

Romain Geffrault — Mon, 27 Apr 2026 09:18:57 +0000

On va parler sérieusement, ça ne va sans doute pas plaire à beaucoup de monde, mais à un moment il faut mettre un peu de côté la hype et se concentrer sur les faits.

Il faut arrêter de voir le signalStore de la team NgRx comme le sacro-saint outil de la gestion d'état dans Angular.

Alors oui, comme on va le voir, le signalStore a de gros avantages, mais en pratique et de la façon dont il est mis en avant, ça va dans le mauvais sens.

Pourquoi je le critique ?

Comme on peut le voir d'après les stats, il est de plus en plus populaire, donc de plus en plus de devs l'utilisent et le découvrent
Il y a énormément de conférences pour le promouvoir, et c'est très bien, mais il faut aussi parler de ses limites
Le signalStore n'a pas laissé beaucoup de place à l'émergence de nouveaux patterns liés aux signals avec leur aspect réactif et leur forte intégration dans Angular. Et il s'est presque imposé comme la bonne façon de travailler avec les signaux, ce qui est dommage.
Mis en avant pour son côté qui s'adapte à tout tel un bon couteau suisse, mais si ce n'était pas le cas ?

Quand on utilise un outil, il faut être conscient de ses avantages et de ses limites (sinon le risque est de se retrouver avec une dette technique dissimulée par le fait que l'outil est "cool" ou "à la mode").

Dans ce sens, je vais aussi mettre en avant des patterns basés sur les Signals très peu populaires, mais dont le signalStore passe à côté.

Cet article s'adresse à tous ceux qui l'utilisent ou souhaitent l'utiliser, et qui ne voient pas encore comment ça peut mal tourner (en espérant que ce ne soit pas trop tard).

Mais avant toute chose, je tiens à féliciter l'équipe de NgRx pour le travail qu'ils ont fait, c'est un outil très puissant qui a d'énormes avantages, et qui ouvre la voie à un nouveau style de gestion d'état dans Angular.

Je m'en suis énormément inspiré pour faire mes propres outils de gestion d'état, et je pense que c'est une très bonne chose pour la communauté Angular.

Par où commencer ? Vous aimez les ressources d'Angular ?

Eh bien, je vais vous raconter une anecdote avec un jeune passionné d'Angular, Simon.

À son travail, le signal store est implémenté partout, et on en vient à parler des ressources et de comment les utiliser.

Personnellement, ça faisait un moment que je n'utilisais plus le signal store au profit d'autres patterns, ce qui a engendré des incompréhensions dans notre discussion, mais sans doute pas comme vous l'imaginez.

L'objectif était d'avoir une page où on affiche les détails d'un User en fonction d'un paramètre (id) venant de l'URL.

Ma vision de la solution :

l'id est récupéré par le component/page via un input (et l'utilisation de withComponentInputBindings)
On utilise une resource en lui passant en params cet id sous forme de signal (dès qu'il change, cela va déclencher un appel API associé à ce nouvel id)

Rien de compliqué, c'est une utilisation très classique des ressources.

// component/page
@Component()
class UserDetails {
  id = input.required<string>();

  userService = inject(UserService);

  userDetailsResource = resource({
    params: this.id,
    loader: (id) => this.userService.getUserDetails(id),
  });
}

Simon voulait éviter de gérer la logique dans le composant directement pour "découper les responsabilités" et ça collait mieux au reste du projet.

Traduction, on va passer par un signalStore pour faire l'appel API.

Vous avez déjà vu les exemples du signalStore pour faire des appels API ? 😅

Vous avez déjà remarqué la façon dont sont gérés les server-state dans le signalStore en suivant les exemples officiels de NgRx ?

On y reviendra, pour l'instant, l'idée reste que le comportement attendu est : l'id dans mon URL change / il faut que j'appelle l'API pour récupérer les nouveaux détails du User.

Voici une potentielle solution (plein de variantes existent mais le problème reste le même) :

Côté signalStore, on peut imaginer une implémentation comme celle-ci. Elle semble correspondre à ce qui est attendu.
L'id change => appel API pour récupérer les nouveaux détails du User.

const userDetailsStore = signalStore(
  withState({ id: undefined as string | undefined }),
  withProps(({ id }, userService = inject(UserService)) => ({
    userDetails: resource({
      params: id,
      loader: ({ params: id }) => userService.getUserDetails(id),
    }),
  })),
);

Puis je lui dis : maintenant, tu passes l'id récupéré par ton composant à ton signalStore.

Et là, j'ai mis du temps à comprendre pourquoi il galérait autant à faire cette étape.

Comment passer un input à un signalStore ?

En vrai, comment on fait pour passer un input à un signalStore ? C'est une question très simple, mais la réponse est trop compliquée pour ce qui est attendu.

Si je ne dis pas de bêtises, une solution pour le faire ressemble à ça, où on expose une méthode pour mettre à jour l'id.

const UserDetailsStore = signalStore(
  withState({ id: undefined as string | undefined }),
  withProps(({ id }, userService = inject(UserService)) => ({
    userDetails: resource({
      params: id,
      loader: ({ params: id }) => userService.getUserDetails(id),
    }),
  })),
  withMethods((store) => ({
    setId: (id: string) => patchStore(store, { id }), // méthode pour mettre à jour l'id dans le state du signalStore
  })),
);

Côté composant, on va devoir faire un effect pour appeler cette méthode à chaque fois que l'id change.

@Component({ providers: [UserDetailsStore] }) // créer une instance du store pour ce composant, qui se détruira à la destruction du composant
class UserDetails {
  id = input.required<string>();
  userDetailsStore = inject(UserDetailsStore);

  _syncIdWithStore = effect(() => {
    this.userDetailsStore.setId(this.id());
  });
}

C'est quand même lourd comme implémentation pour extraire la logique de notre composant, vous ne trouvez pas ?

Ps: C'est une utilisation d'un effect approprié pour cette solution

On doit provider le store, l'injecter, faire un effect pour synchroniser l'id du composant avec le store, et faire en sorte d'exposer une méthode du store pour faire la mise à jour de l'id.

Suite à ça, je lui ai dit : attends, je vais te montrer une alternative pour extraire la logique du composant et ça va être follement simple.

Extraire la logique d'un composant à l'ère des Signals

function userDetailsResource(id: Signal<string>) {
  const userService = inject(UserService);

  return resource({
    params: id,
    loader: ({ params: id }) => userService.getUserDetails(id),
  });
}

@Component()
class UserDetails {
  id = input.required<string>();

  userDetails = userDetailsResource(this.id);
}

Et voilà. Alors oui, ce n'est pas un portage 1 pour 1, car on ne peut pas injecter userDetails dans des composants enfants. Mais à aucun moment ça n'a été difficile d'écrire une fonction qui extrait la logique de notre composant.

Et ça, on ne le voit que très peu, car c'est un pattern qui est très simplifié depuis le passage des inputs en signal.

Si tu tiens vraiment à passer par le système d'injection pour le récupérer dans des composants enfants, tu peux aussi faire ça grâce aux outils que j'ai mis en place (craft-ng)

export const { injectUserDetailsQuery, provideUserDetailsQuery } = craftService(
  { name: "UserDetailsQuery", scope: "toProvid" },
  (id: Signal<string>) => {
    const userService = inject(UserService);

    return resource({
      params: id,
      loader: (id) => userService.getUserDetails(id),
    });
  },
);

@Component({ providers: [provideUserDetailsQuery()] })
class UserDetails {
  id = input.required<string>();

  userDetailsQuery = injectUserDetailsQuery(this.id);
}

Voilà, il n'y a presque pas de complexité ajoutée.

3 grosses limites du signalStore venant de notre exemple

1 - Le passage d'inputs à un signalStore est compliqué / ajout de charge mentale

Comme on l'a vu, il faut ajouter beaucoup de boilerplate pour faire le lien entre un input et un signalStore.

Cela ajoute une charge mentale pour comprendre le flow de données, et ce qui se passe dans notre app.

Il est possible de créer un utilitaire pour faciliter la liaison entre un input et un signalStore, j'en ai partagé différentes versions dans mes posts.

2 - Le signalStore n'est pas adapté pour gérer les server states

J'ai été gentil, j'ai utilisé les resources pour gérer le server state (user details) dans le signal store.
Mais quel a été l'intérêt du signal store, sa plus-value ? Rien si ce n'est que ça nous a compliqué la vie pour déclencher les appels API.

Si on reprend l'exemple officiel, qui met directement la gestion d'un server state avec l'utilisation du signalStore:

export const BookSearchStore = signalStore(
  withState(initialState),
  withMethods((store, booksService = inject(BooksService)) => ({
    /* ... */
    // 👇 Defining a method to load all books.
    async loadAll(): Promise<void> {
      patchState(store, { isLoading: true });

      const books = await booksService.getAll();
      patchState(store, { books, isLoading: false });
    },
  })),
);

Sans un utilitaire similaire à une resource, on se retrouve à devoir gérer manuellement l'état de chargement, les erreurs, etc., ce qui est lourd et fastidieux.

Et qui dans le web est très courant...

Et pourquoi ça fonctionne "mal", c'est que le signalStore considère l'état client (son withState) comme source de vérité, il ne peut pas être dérivé à partir d'une resource, ou d'un state venant de l'URL. Ce qui le contraint à devoir faire des synchronisations forcées entre des sources et son state interne.

Certains apprécient ce pattern, moi je trouve que l'abstraction du signalStore n'est ni appropriée ni adaptable.

Ce n'est pas digne d'un couteau suisse, ça a un intérêt comme on va le voir après, mais pas pour un outil à tout faire.

Si t'as encore un doute, regarde un peu les exemples que tu peux trouver sur les différents articles, tu verras que c'est très lourd pour un pattern qui a été résolu depuis un moment grâce à des outils comme les ressources, TanStack Query, etc.

Dans mes outils, j'ai un utilitaire query qui me permet de considérer l'équivalent d'une resource comme source de vérité, et d'y associer des méthodes/computed pour interagir avec l'état récupéré.

J'ai le même mécanisme pour les query params avec queryParam.

Et ça marche bien mieux d'un point de vue DX.

Mais qu'en est-il du point suivant ?

3 - Testabilité & tracking des dépendances

Côté testabilité, le signalStore se teste comme n'importe quel autre service. Il a donc les mêmes avantages et les mêmes inconvénients que les services d'Angular classiques.

Un autre problème que je n'ai pas signalé, mais qui me pose problème bien que ce soit accepté par la communauté.

C'est le fait que l'on ne tracke pas les dépendances (services injectés) dans le signalStore.

Les services d'Angular actuels présentent cette même faiblesse, mais on voit que le signalStore ne la compense pas.

Pourtant, tracker les dépendances simplifie grandement la testabilité (s'assurer que les dépendances sont bien provider, ou mocker).

À l'instar des composants standalone où on importe juste ce qu'il faut pour le composant, le tracking des dépendances permet de provider et mocker uniquement ce qu'il faut.

On retire une dépendance ? Une erreur TS apparaît dans les tests, car on essaye de provider ou mocker une dépendance qui n'existe plus.

Ça assure que le test rate pour les bonnes raisons et pas à cause de problème de configuration provider/mock.

J'ai aussi résolu ce problème avec mes outils, je te laisse aller voir si ça t'intéresse via craftService

Le couteau suisse commence à présenter quelques faiblesses...

Faut-il jeter le signalStore à la poubelle ? Non

Gestion des client states

Après avoir exposé quelques limites, voici ce sur quoi il est bon, même très bon par rapport à la plupart des solutions de gestion d'état dans Angular.

Il est très adapté pour gérer 1 état client.

J'ai bien dit : 1 état client.

1 :
Donc pas plusieurs, mais 1 seul.

Client:
Donc pas un server state, pas un état venant d'une resource, pas un état venant de l'url.

Pourquoi pas de server state ? Bien que le signalStore puisse être adapté pour gérer du server state (des données venant d'une API), cela entraîne beaucoup de boilerplate pour des cas courants, où il est facile d'oublier la gestion des erreurs. D'autant plus que, côté gestion des erreurs, que ce soit avec les Observables ou les Promises, les erreurs ne sont pas typées, ce qui rend la gestion des erreurs métier plus compliquée. Ces erreurs peuvent venir d'une perte de connexion, ou d'un accès refusé à une ressource, etc. Et si on regarde la très grande majorité des exemples d'appels API, la gestion des erreurs est catastrophique (pour ne pas dire que l'auteur s'en bat les couilles). Et je pense que ça vient du fait que NgRx n'apporte aucun outil qui aide réellement à gérer les appels API/asynchrones, en déléguant cette responsabilité à l'utilisateur.

Pourquoi il est bon à gérer les états clients ?

L'intérêt c'est qu'on part d'un état initial typé.

Cela veut dire qu'il aura toujours la même forme, mais que ces propriétés pourront être mises à jour.

Et comment vont-elles être mises à jour ?

Par des méthodes qui vont faire des patchs sur le state du signalStore.

Ou encore via des réactions à des events.

Et c'est trop bien, dans le signalStore lui-même on peut voir exactement comment va évoluer notre state.

L'exposition de méthodes est pratique et il est tout aussi simple de passer sur des réactions à des events ou un mix des deux.

Ça peut être utilisé comme un bon compromis entre une approche method-based et event-based (principe lié à Redux).

L'autre intérêt est qu'on peut aussi exposer des états dérivés directement liés via les computed.

On a tout en même endroit, ce qui aide, je trouve, à piloter la logique et à visualiser les différentes évolutions de notre état.

Maintenant, parlons d'un autre "problème" qu'a résolu le signalStore, par rapport à son prédécesseur (global store) ?

Scope global ou local mais pas trop...

Une limitation du global store, c'est qu'il était surtout fait pour gérer des états globaux. Et il le faisait plutôt bien.

Toutefois, quand on architecture une application, on n'a pas que besoin d'états globaux, mais aussi d'états locaux à une feature, ou même à un composant.

(J'avoue ne pas être sûr de ne pas dire de bêtises sur ce point, n'hésitez pas à me corriger dans les commentaires).

Le signalStore pouvant avoir une portée globale ou plus locale, il semble plus adapté pour architecturer une application.

Et c'est tout à son honneur.

Mais encore une fois, il ne fait pas mieux que les services d'Angular.

On peut oublier de le provider et avoir une erreur au runtime, qui conceptuellement pourrait être évitée.

Un autre reproche lié à ce sujet, mais dont je pense que l'équipe NgRx peut s'adapter, c'est qu'il n'est pas possible d'utiliser le signalStore en inline dans un composant comme on peut le faire avec les ressources.

Pourtant, ça permettrait d'avoir une sorte de signal amélioré où tout est déclaré explicitement sur la façon dont le composant interagit avec.

Cela lèverait aussi les problèmes du passage d'inputs, d'obligation de devoir le provider...

Ça simplifierait grandement la création d'un signalStore par état, plutôt qu'il soit composé de plusieurs pas forcément liés.

Ça devrait, selon moi, être son mode par défaut.

Et si on en parlait de la composition souvent mise en avant ?

La composition du signalStore top ou flop ?

Eh bien, en réalité, je la trouve très intéressante.

Et elle permet la réutilisation de logique de manière très simple.

Toutefois (oui, j'ai des trucs à dire aussi à ce sujet 😂), le choix de pouvoir composer un store avec des features qui, elles, contiennent des states, méthodes, computed et réactions, c'est très bien, mais...

C'est un choix qui peut être très intéressant pour faire du partage de logique, mais qui peut aussi amener à dénaturer l'intérêt du store.

On en arrive à voir des signalStore qui vont servir de façade.

Où le signalStore n'a juste aucune plus-value et rend même les choses plus compliquées.

Comme on peut le voir dans cet exemple, la façade est gérée par un service classique, qui pourrait aussi être une fonction (merci à @lucas Garcia sur Linkedin pour sa critique de la composition du signal store sur le Discord > Bonjour Angular, qui m'a inspiré).

@Service()
class MyFacade() {
    public readonly state1 = inject(State1); // State1 créé via signalStore
    public readonly state2 = inject(State2); // State2 créé via signalStore

    public readonly derivedState = computed(() => {
        // logique de dérivation à partir de state1 et state2
    });

}

Elle est où la complexité ? À quel moment le signalStore a vraiment un intérêt à composer plusieurs states différents ?

Presque pas d'intérêt.

Ma règle : le signalStore gère un state, pas plusieurs.

Et on ne s'en sert pas pour faire une façade, ou tout ce qui peut s'en approcher.

Et personnellement, pour éviter d'en arriver à ces dérives, je préfère composer un state uniquement via de la composition de logique et d'états dérivés (pas de state ajouté via la composition). Cf. ma primitive state.

Ça permet de garder une responsabilité claire de ce que doit faire notre "conteneur" de gestion d'état.

Et ce principe, je l'applique aussi à mes autres primitives query, mutation, queryParam qui, à l'instar du Signal Form, dérivent la logique à partir de l'état de la source.

D'ailleurs, si tu penses que le système d'events compense les autres points faibles, j'ai aussi un point à critiquer.

Les events du signalStore ne sont pas si déclaratifs que ça...

J'ai clairement du mal avec les events de NgRx, et l'approche avec le signalStore, bien qu'il fasse sans doute mieux que son papa, a toujours ce gros défaut.

On ne peut pas dériver un event (avec des utilitaires officiels). Non, on doit lui donner une description pour dire ce que ça représente.

Cet event est soit dispatché suite à une action d'un utilisateur, soit depuis un effect qui fait des calculs puis émet un event.

Et ce sont ces derniers évents qui me posent problème.

Plutôt que de devoir passer par une description, on pourrait directement écrire le code qui déclenche l'event au moment de sa déclaration.

Ça permet d'avoir un event beaucoup plus déclaratif, et d'éviter un effect qui doit être provider pour être actif.

Et en plus, si ce n'est pas utilisé, c'est tree-shaké par le compilateur, ce qui n'est pas le cas d'un event classique.

Après avoir dit tout ça, je tiens à préciser que l'approche event-based est toujours une des approches les plus intéressantes pour gérer un état et la logique métier.

Et qu'il est préjudiciable de ne pas faire d'event-based dans un projet parce que les events ne sont pas déclaratifs.

Côté typage

Je ne vais pas trop entrer dans les détails, mais même si le pattern utilisé par le signal store est très intéressant, et sans doute précurseur, il a aussi des limites.

J'ai énormément travaillé avec. J'avais recréé tout ce mécanisme d'accumulation, car je le trouvais fascinant.

J'ai ensuite créé des outils de gestion de server state dédiés au signal store, et je peux vous dire que c'est très, très compliqué.

Personnellement, je trouve qu'il y a une couche en trop dans le typage, ce qui rend extrêmement difficile la création de patterns custom.

Et quand on souhaite travailler avec des features génériques basées sur le pattern principal withX, de mémoire, ce n'est pas possible sans utiliser deux utilitaires.

J'avais fait une proposition pour simplifier withFeature, mais elle a été rejetée, car elle ne gère pas mieux que leur mécanisme actuel les features avec un paramètre générique.

Lien vers un de mes articles, pour créer des features personnalisées avec une bonne DX avec le signalStore.

Je tenais à mentionner ce point, car il fait partie des limites de ce que permet de faire le signalStore.

Mais ce n'est pas vraiment lui qui pose vraiment problème.

Conclusion

Le signalStore a permis la découverte d'un pattern très intéressant autour de la composition.

Il est roi pour gérer un état client où il offre une bonne DX, et c'est déjà pas mal.

Mais comme on l'a vu, ce n'est pas un couteau suisse.

Il ne remplace pas un outil spécialisé pour gérer les états liés à l'URL ou encore pour gérer les server states (les resources actuelles ne sont pas sans défaut non plus).

(craft-ng fait tout ça 🤫)

Si tu devais continuer à l'utiliser, je te conseillerais de toujours l'utiliser pour gérer un état client, pas plus.

D'éviter le plus possible de faire des injections dedans (ça reste ok, si c'est pour intéragir avec le navigateur, ex: appel api, stockage local, etc.).

Et de ne pas l'utiliser pour faire des façades ou des compositions/orchestrateurs de plusieurs states.

De cette façon, tu garderas toujours les bons côtés de celui-ci et tu pourras profiter d'autres patterns souvent plus appropriés.

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/

This One Change Would Transform Angular Forever

Romain Geffrault — Sat, 25 Apr 2026 16:50:09 +0000

Like it or not, building a component this way would let Angular go full Super Saiyan.

Why?

Because unlike decorators, functions give you full control over typing.

And why does that matter?

With this approach, I can understand all of a component’s dependencies just by looking at its type.

I can clearly see that ApiService and Router are direct dependencies of the component.

But there can also be indirect dependencies coming from things like JsonPipe or StatusComponent.

And why is that interesting?

Because it massively simplifies test setup—especially in large, messy applications.

This change would also enable strongly typed routes (which already exist), along with type-safe inputs bound to route parameters.

It would even allow you to catch missing service injections at compile time.

And that would be incredible.

Angular’s DI system is already excellent—this would take it to the next level.

And the best part? All of these benefits would only require minimal changes.

We’d still write almost the same code as before: metadata as the first argument (equivalent to the decorator),

and a function as the second argument that receives inputs and returns what’s used in the template.

And no—decorators simply can’t go that far.

This approach has already shown its limits with TypeScript.

Angular has always been seen as a professional framework for serious projects.

it’s time to fix its biggest weakness.

Follow me on LinkedIn for an Angular content.
👉 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

DEV Community: Romain Geffrault

Stop using SignalStore for everything: hype fades, debt remains.

Where to start? Do you like Angular resources?

How do you pass an input to signalStore?

Extracting component logic in the Signals era

3 major limitations of signalStore from this example

1 - Passing inputs to signalStore is complex and adds mental overhead

2 - signalStore is not suited for server states

3 - Testability and dependency tracking

Should we throw signalStore in the trash? No

Client state management

Global or local scope, but not quite...

signalStore composition: top or flop?

signalStore events are not that declarative

Typing side

Conclusion

Arrête d’utiliser SignalStore pour tout : la hype passe, la dette reste

Par où commencer ? Vous aimez les ressources d'Angular ?

Comment passer un input à un signalStore ?

Extraire la logique d'un composant à l'ère des Signals

3 grosses limites du signalStore venant de notre exemple

1 - Le passage d'inputs à un signalStore est compliqué / ajout de charge mentale

2 - Le signalStore n'est pas adapté pour gérer les server states

3 - Testabilité & tracking des dépendances

Faut-il jeter le signalStore à la poubelle ? Non

Gestion des client states

Scope global ou local mais pas trop...

La composition du signalStore top ou flop ?

Les events du signalStore ne sont pas si déclaratifs que ça...

Côté typage

Conclusion

This One Change Would Transform Angular Forever

@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

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