Forem: Romain Geffrault

Angular DI Is Not Type-Safe, So I Fixed It

Romain Geffrault — Thu, 07 May 2026 14:49:08 +0000

According to a poll I ran on LinkedIn, there are two main ways people use Angular dependency injection.

Only creating root services, meaning services are singletons shared across the whole application.
Creating local services, meaning they are provided at the component, route, or module level. In that model, root services are only used when data truly needs to be shared across the app.

I also got other answers with slightly different, equally valid perspectives, but the poll was still interesting, even if it only reflects my audience, which is mostly experienced developers.

That leads to a few questions:

Why does the first group stick to root services only?
Why does the second group prefer local services?

From my own experience, even though I personally prefer the second approach, I also think it is currently dangerous.

If a service is not provided, Angular will fail at runtime and crash that part of the application.

And it is not always obvious, or practical, to cover every missing-provider case with tests whose only goal is to verify that services were provided correctly.

On top of that, some people from the first group told me they had never really gone deeper into the local-services approach.

Is that surprising? Not really.

How can we explain these different DI habits?

I do not know how comfortable you are with Angular's DI system, but I doubt you will be surprised if I say that it is not easy to fully understand once local services enter the picture.

Personally, I struggled with it for a while. Luckily, over time I found some excellent articles on the topic. Thanks to Thomas Laforge and his article How Angular Dependency Injection works under the hood.

Even with experience, I can still make mistakes and forget to provide a service.

Or I can assume it is already provided higher up in the tree, only to discover at runtime that it is not.

To me, that is not a skill issue. It is one of Angular's biggest weaknesses.

The core problem is simple: Angular dependency injection is not type-safe.

Dependencies used by services and components are implicit. They are not tracked.

When you import a component, nothing tells you which services it depends on, or which services those services depend on.

And that is something the second group has learned to live with.

Maybe that has always been part of Angular, but from my point of view it has barely evolved since I started using Angular 8.

I think that explains both why the first group prefers the safety of root services and why Angular DI is still hard to master.

The advantage of the local-services approach

The main benefit of local services is better separation of responsibilities.

They also fit feature-based architecture very well.

And because they follow the lifecycle of a component or a route, they can be very useful when you want cleanup to happen automatically.

Sometimes you want a service to be shared across one feature, but not across the whole application.

In that case, you do not need a global service. You need a feature-local service.

I would even push that idea further.

I prefer keeping things as local as possible.

Logic isolated inside a component => plain function.
Reusable shared logic that does not need DI => still a function.
Feature-specific logic that should be testable or shared with child components => component-local service.
Logic shared across a route scope => route-local service.
And only then => global service.

That gives me an approach where I provide exactly what I need, exactly where I need it, a bit like standalone components.

Personally, I find this approach healthier, even if it still comes with risk because the app can still fail at runtime.

Can Angular dependency injection be made type-safe? How do other tools do it?

The solution that felt obvious to me was to make Angular DI type-safe.

That way, forgetting to provide a service would become a compile-time error.

But how?

I have been reading the Effect documentation for a while, and Effect ships with a native type-safe DI system.

And honestly, it is extremely well designed.

How do they achieve type-safe DI?

They rely on TypeScript generator functions.

const myFn = function* () {
  const myService = yield* MyService; // ~ inject MyService
  const myOtherService = yield* MyOtherService; // ~ inject MyOtherService
  return myService.a + myOtherService.b;
};

In this example, if you look at the signature of myFn, you can clearly see MyService and MyOtherService.

And you can also see that the function returns a number.

So Effect uses this mechanism to track injected dependencies natively.

Those dependencies are preserved all the way until the program runs.

Then, when the app is executed, if all required services have not been explicitly provided, you get a compile-time error and the program cannot run.

const program = Effect.gen(function* () {
  const random = yield* Random;
  const randomNumber = yield* random.next;
  console.log(`random number: ${randomNumber}`);
});

// Providing the implementation
//
//      ┌─── Effect<void, never, never>
//      ▼
const runnable = Effect.provideService(program, Random, {
  next: Effect.sync(() => Math.random()),
});

The syntax may look unusual at first, but it is absolutely approachable for beginners. You do not need deep type-system knowledge to understand it.

That solution brings many other advantages and makes DI type-safe.

So I thought: why not do something similar for Angular?

And that is what I did. I made Angular dependency injection type-safe.

How can Angular dependency injection be made type-safe?

By taking inspiration from Effect, I quickly realized that injecting directly inside a component or service creates an implicit dependency.

And if the dependency is implicit, there is no reliable way to track it.

I split the problem into four steps. This work is still recent, so I have probably missed some edge cases, but the approach already feels solid for common scenarios.

1. Track service dependencies

To track service dependencies, I stopped using Angular decorators like @Injectable because they are too limited for this purpose and do not make it easy to track dependencies or scope.

With regular Angular services, you cannot tell from the type signature whether the service is providedIn: 'root' or not.

So I created a utility called craftService. It accepts a generator function that lets me track injected dependencies.

const { CounterToYield } = craftService(
  { name: "Counter", scope: "toProvide" },
  () =>
    state(0, ({ update }) => ({
      increment: () => update((value) => value + 1),
      decrement: () => update((value) => value - 1),
    })),
);

const { injectCounterExtended, provideCounterExtended } = craftService(
  { name: "CounterExtended", scope: "toProvide" },
  function* () {
    return yield* CounterToYield(undefined, ({ $self, increment }) => ({
      $self,
      incrementCounter: increment,
    }));
  },
);

With this approach, I can preserve and propagate a service's dependencies through injectCounterExtended and CounterToYield.

I can also preserve the scope, which tells me whether the service still needs to be provided.

Testing services created this way becomes much easier as well.

const { CounterToYield } = craftService(
  { name: "Counter", scope: "global" },
  () =>
    state(10, ({ update }) => ({
      increment: () => update((value) => value + 1),
    })),
);

const { injectCounterConsumer, provideCounterConsumer } = craftService(
  { name: "CounterConsumer", scope: "toProvide" },
  function* () {
    const counter = yield* CounterToYield();

    return {
      read: () => counter(),
      increment: () => counter.increment(),
    };
  },
);

const { sut, mocks } = setupCraftServiceTestingByRegister(
  injectCounterConsumer,
  {
    CounterConsumer: provideCounterConsumer(),
    Counter: {
      // type-safe Counter mock
      $self: vi.fn(() => 41),
      increment: vi.fn(),
    },
  },
);

expect(sut.read()).toBe(41);
sut.increment();
expect(mocks.Counter.increment).toHaveBeenCalledTimes(1);

setupCraftServiceTestingByRegister tells me which dependencies exist and which ones still need to be provided.

I can also choose to mock services. In that case, the dependencies of the mocked service no longer need to be provided or mocked again.

My test only declares exactly what it needs.

If a service evolves, the compiler tells me that I need to update the test.

There is still one limitation with this approach: external services that are not based on craftService, such as Angular services or services from third-party libraries. I use another utility called toCraftService to adapt them, but it is more tedious to set up and maintain. Still, that is already much better than nothing.

That was the easy part. You could probably rebuild something similar very quickly with AI.

Now let us move to the hard part: tracking component dependencies.

2. Track component dependencies

This is the real pain point.

Right now, Angular does not expose the dependencies of a component, directive, or pipe in a way that lets us track them natively.

And what counts as a component dependency, exactly?

There are the services injected directly into the component.

But there are also imported components, directives, pipes, and host directives declared in the @Component metadata.

Unfortunately, Angular does not expose all of that in a trackable form.

The ideal solution would be for Angular itself to support this, probably through a generator-based approach rather than decorators.

But that would require deeper changes in the compiler, language service, and framework internals.

So I chose a more pragmatic approach. It is not perfect, but it is quick to implement and reasonably effective: I reflect all those dependencies in an exported type that lives next to the component.

@Component({
  selector: "app-lazy-layout-child",
  changeDetection: ChangeDetectionStrategy.OnPush,
  imports: [OtherComponent],
  //...
})
export default class LazyLayoutChildComponent {
  readonly injectedParentRouteData = injectDemoCraftLazyLayoutTeamIdData();
  readonly injectedTeamId = injectDemoTeamIdParams();
}

export type GenDeps_LazyLayoutChildComponent = GetDeps<{
  deps: {
    GenDeps_OtherComponent: GenDeps_OtherComponent;
  };
  propertiesDeps: {
    injectedParentRouteData: {
      DemoCraftLazyLayoutTeamIdData: ReturnType<
        typeof injectDemoCraftLazyLayoutTeamIdData
      >;
    };
    injectedTeamId: {
      DemoTeamIdParams: ReturnType<typeof injectDemoTeamIdParams>;
    };
  };
  provided: {};
  publicProperties: GetPublicComponentProperties<LazyLayoutChildComponent>;
  missingProvider: {
    DemoCraftLazyLayoutTeamIdData: ReturnType<
      typeof injectDemoCraftLazyLayoutTeamIdData
    >;
    DemoTeamIdParams: ReturnType<typeof injectDemoTeamIdParams>;
  };
}>;

So I generate the GenDeps_LazyLayoutChildComponent type to reflect every dependency used by the component.

Do I write that by hand? No.

I use an ESLint rule to ensure GenDeps_LazyLayoutChildComponent stays synchronized with the component.

I also added a quick fix to regenerate it automatically.

That said, there is still a weak spot.

As long as GenDeps_LazyLayoutChildComponent is not synchronized with the component, the compiler cannot detect missing or incorrect dependencies.

To me, that is acceptable, because it is still better than the status quo, and linting will keep reporting an error until the type is fixed.

My script also pulls in the GenDeps_X types from imports so that all dependencies remain explicit.

In the future, Angular could support this natively and remove that human-maintained layer.

With this setup, GetDeps computes which services are still missing.

I also keep exposing the full list of services used by the component, which is useful for testing and more.

Once again, the main limitation is third-party components. They can still introduce blind spots. I also have not handled recursive dependency tracking for components yet, but I think that should be solved separately.

With that trick, we can track a component's dependencies and sub-dependencies. The next step is to move upward through the injection tree, all the way to the routes.

3. Track route dependencies

When I import a component, I also force the import of its dependency type GenDeps_X so I can propagate all required dependencies up to the route level.

For that, I created a utility called craftRoutes.

I chose this API because it lets me run type-level computations that simplify dependency management later on.

It also lets me expose route-related injectables such as params or data, which then become tracked dependencies too.

In the example below, I also tagged my routes with a demo scope. I find it useful for identifying where injectables come from, and I may use it later for observability as well, such as logs and traces.

export const {
  demoRoutes,
  injectDemoTeamIdParams,
  injectDemoCraftLazyLayoutTeamIdData,
  injectDemoUserIdParams,
} = craftRoutes("demo", [
  {
    path: "query/:userId",
    componentDeps:
      {} as import("./examples/primitives/query/query").GenDeps_GlobalQuery,
    loadComponent: () => import("./examples/primitives/query/query"),
  },
  // ...
  {
    path: "craft/lazy-layout/:teamId",
    data: {
      someParentRouteData: "foo",
    },
    loadComponent: () => import("./examples/craft/lazy-layout/lazy-layout"),
    componentDeps:
      {} as import("./examples/craft/lazy-layout/lazy-layout").GenDeps_LazyLayoutComponent,
    loadChildren: () =>
      import("./examples/craft/lazy-layout/lazy-layout.routes").then(
        (m) => m.lazyLayoutRoutes,
      ),
  },
]);

With this, demoRoutes carries all missing dependencies while taking providers declared at the route level into account.

For now, I deliberately chose not to preserve dependencies route by route, because TypeScript can saturate pretty quickly and start producing errors.

componentDeps is mandatory, which adds some boilerplate, but as soon as Angular can track component dependencies natively, that part can disappear.

We also should not forget dependencies coming from guards, such as canActivate, canMatch, or resolvers.

That leaves one final step: ensuring that everything required is actually provided when the app starts.

4. Ensure that all required services are actually provided at runtime

The last step is to account for services provided in app.config.ts as well as services provided at the AppComponent level.

I created another utility called craftAppConfig, which once again only surfaces services that are still missing.

export const appConfig = craftAppConfig({
  appStart: {
    AppStartLog: injectAppStartLog,
  },
  routingDeps: demoRoutes.META_DATA,
  providers: [
    provideHttpClient(),
    provideBrowserGlobalErrorListeners(),
    provideCraftRouter(demoRoutes.toRoutes(), withComponentInputBinding()),
  ],
});

The final resolution happens in main.ts, at bootstrapApplication time.

That is where I add the final piece that verifies everything is consistent.

bootstrapApplication(App, toApplicationConfig(appConfig)).catch((err) =>
  console.error(err),
);

type CheckAppDI = AppCheckedDI<GenDeps_App, AppRouteMetaDataForDi>;

type _CanRun = CanRun<CheckAppDI>;

I add AppCheckedDI and CanRun.

Right now, AppCheckedDI returns true when everything is valid, and CanRun expects that value to be true.

If a dependency is still missing, AppCheckedDI returns a list describing the missing services.

And CanRun produces a type error because it expects CheckAppDI to resolve to true.

That blocks compilation and shows an explicit error.

Example:

✘ [ERROR] TS2344: Type '["Injected Counter is not provided in path: \"craft-service/counter\""]' does not satisfy the constraint 'true'. [plugin angular-compiler]

    apps/demo/src/main.ts:16:22:
      16 │ type _CanRun = CanRun<CheckAppDI>;

I wanted a type-safe DI system, and this gets me there.

The limitations of this type-safe DI system

As mentioned earlier, we still need to create a type that reflects the dependencies of each component, pipe, or directive, and keep it synchronized through linting. So errors are still possible, even if they are much less likely to reach production.

Because lint errors, while clearly visible in the IDE, do not block the compiler by themselves.

Third-party services, components, directives, and pipes remain a likely source of mistakes. Even if they can be adapted into the tracking system, you still need to stay careful when they evolve.
On large projects, the system may hit limits. We may need intermediate strategies to keep the idea scalable. Faster linting tools such as Biome might also help compared to ESLint.
This system works very well in applications built around standalone components. In applications that rely heavily on large SharedModules, it is less effective, especially when those modules are large. I do not have that problem right now, but it will require a dedicated strategy.
I have not tested this with viewChildren or ViewChild, nor with contentChildren or contentChild yet, but I suspect this is mostly a matter of adjusting the ESLint quick-fix generation.

How can you integrate this system into your application?

Personally, I do not think you need to copy my code and utilities directly, except maybe as inspiration.

With AI, I think you could build something similar very quickly, and maybe even improve on what I did.

The code I showed is strongly coupled to my @craft-ng library, which gives me useful leverage to get the most out of the approach.

It is also still experimental, and I have only covered the cases I needed.

Still, if you want to look at it, here is the repository and branch where I implemented this type-safe DI system in an Angular project.

After that, I asked my AI to build a skill that could help someone else's AI set up this kind of system.

Here it is, although I cannot really say yet how good it is:

Skill to help implement a type-safe DI system for Angular

I also suspect it might help to temporarily bring my demo project into your repository while making the change, although I am not fully sure how effective that would be in practice.

Demo

Unfortunately, StackBlitz does not handle ESLint well, which makes the system harder to showcase properly. That is why I am not sharing a live demo link to test it directly.

Imagine a component that calls service A, and service A depends on service B.

Service A has a function scope, which lets me extract logic out of a component without having to provide the service.

Service B has a global scope.

As soon as I switch service B to toProvide, I immediately get a compile-time error telling me that I now need to provide it.

What are the benefits of tracking dependencies across the whole project?

There are many advantages to preserving and exposing the dependencies of your application.

It goes far beyond just detecting DI mistakes before runtime. It can improve the overall quality of the application in several areas.

Here are a few benefits that come to mind:

Testing: simpler setup for both component and service tests.
If a dependency is added, the compiler tells me that I need to update the test.
If a dependency is removed, the compiler also tells me to update the test.
It becomes easy to mock only the services that actually interact with the browser.
When I mock a service, I no longer need to provide the dependencies of that mocked service.
I can detect which services depend on the environment and write the right tests for them.
E2E testing: I can know precisely which API calls a page makes. That is useful for mocking data and avoiding real calls.
I can detect architecture anomalies in component coupling, like: why is this service being used from this route?
Refactoring becomes safer and encourages writing tests before changing code. If I forget something, the compiler helps me.
On a large and messy application, you could introduce this system without changing runtime behavior or business logic, add tests, and then refactor with much more confidence.
Architecture-wise, it encourages creating local services exactly where they belong, and widening their scope only when needed.
Confidence: your app evolves, which is normal, but if you forget to provide a service, you get a compile-time error instead of a nasty runtime surprise.
Observability: you can drive logging or tracing based on the services used by a route, component, or service. That can be extremely useful for monitoring and debugging.
You can track route inputs such as params and data in a type-safe way. If you get a name wrong, the compiler tells you.
It also opens the door to type-safe routing, with autocompletion and safer relative navigation.
Resolvers can become much more powerful at the route level: display the main component once data is ready, a loading component while it is pending, and an error component if something fails, all with strict typing.
Query params can be defined at the route level and injected into components in a type-safe way.
AI gets fast feedback if it breaks Angular's DI rules.
You can create abstract services during development and implement them later without the risk of forgetting to provide the real implementation.
You can make sure services meant to run through provideAppInitializer are actually provided, and avoid the errors that usually come with that.
The same idea helps in tests too: if a service must run during app startup, you can explicitly choose whether it should run before a test or be ignored.
Angular DI becomes easier to learn because feedback is immediate when an injection rule is broken.

I am probably forgetting many others. But even from this list, you can see how simply tracking application dependencies reveals much more of what Angular's DI system can offer.

Conclusion

Setting up a type-safe DI system for Angular means you no longer have to stay trapped in an architecture built only around global services, even if that choice is perfectly understandable without type safety.

As I already mentioned, it also makes Angular DI easier to learn and easier to adopt, even for less experienced developers who are afraid of making mistakes.

What I like most is that I added almost no runtime logic. Most of the work happens at the type level, which avoids bloating the final bundle.

And I really hope Angular will eventually offer a native solution for type-safe dependency injection, because that would remove all the boilerplate I currently need to add.

I would be curious to know what you think about all this, and whether you have already built a system to track the dependencies in your own app.

Or whether you are considering it.

I will repeat it one last time: even if you are not comfortable with advanced typing, this kind of system is surprisingly easy to put in place with AI, especially if your only goal is to track missing DI providers.

You could also keep using Angular's standard services and apply the same dependency-tracking technique only to component dependencies.

On my side, I am convinced this approach can genuinely improve the quality of Angular applications.

Even though I still have not seen or read any article on this specific topic, I hope this one can inspire others to explore the same path, and maybe even contribute to a native Angular solution someday.

It highlights all the work the Angular team has already done on DI, and it lets me get much more value from that system.

I still want to run more experiments before using this on production projects, but the foundation is now there.

If you have thoughts on it, feel free to tell me in the comments or contact me directly.

P.S. If you are up for it, should we attack the Angular compiler next and make component dependency tracking native? Want to talk about it?

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/

[Boost]

Romain Geffrault — Fri, 01 May 2026 16:03:27 +0000

Romain Geffrault

Apr 27

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

#angular #ngrx #typescript

Comments

11 min read

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

Forem: Romain Geffrault

Angular DI Is Not Type-Safe, So I Fixed It

How can we explain these different DI habits?

The advantage of the local-services approach

Can Angular dependency injection be made type-safe? How do other tools do it?

How can Angular dependency injection be made type-safe?

1. Track service dependencies

2. Track component dependencies

3. Track route dependencies

4. Ensure that all required services are actually provided at runtime

The limitations of this type-safe DI system

How can you integrate this system into your application?

Demo

What are the benefits of tracking dependencies across the whole project?

Conclusion

[Boost]

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

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

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?