RFC: Integration with Angular Signals and NgRx packages

[brandonroberts]

Purpose

This document serves to lay out the potential options for using Signals in Angular with NgRx libraries.

The RFCs for Angular Signals can be found here

Opportunities

Signals in Angular introduce a primitive for reactivity that's not built on top of RxJS. There is interoperability with RxJS observables and Signals through bridge functions such as toSignal and toObservable.

Discussions

If you have feedback on the RFC, feel free to post a comment here, or join our Discord and join the #rfcs channel for semi-realtime longer discussions.

NgRx Store

The Redux pattern with NgRx Store serves as a type of reactive primitive in Angular. With NgRx libraries being built on top of observables, we can still immediately take advantage of Signals in Angular by using the bridge function to go between Signal and Observable. This will allow developers to transform and consume observables from the NgRx Store and associated libraries as Signals.

import { Component } from '@angular/core';
import { NgFor } from '@angular/common';
import { toSignal } from '@angular/core/rxjs-interop';
import { Store } from '@ngrx/store';

import { MoviesActions } from './store/movies/actions';
import { selectAllMovies } from './store/movies';

@Component({
  standalone: true,
  imports: [NgFor],
  template: `
    <ul>
      <li *ngFor="let movie of movies()">
        {{ movie.name }}
      </li>
    </ul>
  `
})
export class MoviesComponent {
  store = inject(Store);
  movies = toSignal(this.store.select(selectAllMovies));
  
  ngOnInit() {
    this.store.dispatch(MoviesActions.enter());
  }
}

We improve this experience by adding a selectSignal method to the Store that takes a selector and returns a Signal of its value.

import { Component } from '@angular/core';
import { NgFor } from '@angular/common';
import { Store } from '@ngrx/store';

import { MoviesActions } from './store/movies/actions';
import { selectAllMovies } from './store/movies';

@Component({
  standalone: true,
  imports: [NgFor],
  template: `
    <ul>
      <li *ngFor="let movie of movies()">
        {{ movie.name }}
      </li>
    </ul>
  `
})
export class MoviesComponent {
  store = inject(Store);
  movies = this.store.selectSignal(selectAllMovies);
  
  ngOnInit() {
    this.store.dispatch(MoviesActions.enter());
  }
}

NgRx ComponentStore

NgRx ComponentStore provides reactivity for local component state and side effects using observables. Integrating with Signals would provide interoperability with ComponentStore APIs.

As with NgRx Store, a selecSignal method would be added to the ComponentStore API.

import { Injectable } from '@angular/core';
import { ComponentStore } from '@ngrx/component-store';

export interface MoviesState {
  movies: Movie[];
}

@Injectable()
export class MoviesStore extends ComponentStore<MoviesState> {
  
  constructor() {
    super({movies:[]});
  }

  readonly movies: Signal<Movie[]> = this.selectSignal(state => state.movies);
}

import { Injectable } from '@angular/core';
import { ComponentStore } from '@ngrx/component-store';

export interface State {
  users: User[];
  query: string | null;
}

@Injectable()
export class UsersStore extends ComponentStore<State> {

  constructor() {
    super({users:[], query: '' });
  }

  readonly users = this.selectSignal((s) => s.users);
  readonly query = this.selectSignal((s) => s.query);

  readonly filteredUsers = this.selectSignal(
    this.users,
    this.query,
    (users, query) => users.filter((user) => user.name.includes(query))
  );
}

There would also be a state property added to the ComponentStore API to provide reading from the ComponentStore state using the computed function.

import { Injectable } from '@angular/core';
import { ComponentStore } from '@ngrx/component-store';
import { computed } from '@angular/core';

export interface MoviesState {
  movies: Movie[];
}

@Injectable()
export class MoviesStore extends ComponentStore<MoviesState> {
  
  constructor() {
    super({movies:[]});
  }

  readonly movies: Signal<Movie[]> = computed(() => this.state().movies);
}

NOTE: Using lazy initialization of state would result in an error when reading a signal before the state is defined.

ComponentStore Effects are designed to extract any side-effects (such as Network calls) from components and handle potential race conditions.

In addition to static values, and observables, a ComponentStore effect would also support receiving a Signal as an input.

@Injectable()
export class MoviesStore extends ComponentStore<MoviesState> {
  
  constructor(private readonly moviesService: MoviesService) {
    super({movies: []});
  }

  // Each new call of getMovie(id) pushed that id into movieId signal.
  readonly getMovie = this.effect<string>((movieId$) => {
    return movieId$.pipe(
      // 👇 Handle race condition with the proper choice of the flattening operator.
      switchMap((id) => this.moviesService.fetchMovie(id).pipe(
        //👇 Act on the result within inner pipe.
        tap({
          next: (movie) => this.addMovie(movie),
          error: (e) => this.logError(e),
        }),
        // 👇 Handle potential error within inner pipe.
        catchError(() => EMPTY),
      )),
    );
  });
  
  readonly addMovie = this.updater((state, movie: Movie) => ({
    movies: [...state.movies, movie],
  }));
 
  selectMovie(movieId: string) {
    return this.select((state) => state.movies.find(m => m.id === movieId));
  }
}

As with observables, the effect function would execute every time the signal produces a value.

Impact on other NgRx packages

@ngrx/entity

• No impact
• Adapters can be created/used outside of Store

@ngrx/store-devtools

• No impact

@ngrx/router-store

• No impact

@ngrx/component

• No immediate impact
• May introduce fine-grained support for Signals in the future

[Armenvardanyan95]

This all sounds really nice and simple, nothing complicated, and would be easy to migrate I think. I would like to raise one point though:

In the eslint-plugin, we consider as one of the rules using map (and similar operators) ij the components when selecting from store to be a bad practice. So this would be considered bad:

@Component({...})
export class MyComponent {
  store = inject(Store);
  list$ = this.store.select(data).pipe(
    map(data => data.list)
  );
}

and should be moved to a selector, with which I 100% agree, but here are some questions:

1. Will the same logic apply to using computed properties where signals from the store are selected? Like "do not use a computed property for this, write that logic in the selector".
2. What if we want to compute something based on a signal from the store and a local, component signal? Will it still be considered a bad practice?
3. Will it be possible to enforce with the linter plugin?
4. If it is possible, will it be possible to exclude cases like in the second bullet point?
5. Are there other cases where this change will impact existing best/bad practices? Can't think of any at this moment, but surely they must exist, would love to discuss

Otherwise, this is great, I'm super excited

[brandonroberts]

1. Based on feedback, we'll most likely evolve some of the recommendations around this usage. Currently, if your pieces of state are within the Store, use a selector to compose them all, and use the method to expose it to the template as a signal.
2. I don't see this as bad practice, as the two should work ok together
3. Yes, I can see where we would have some lint rules to ensure best practices as they surface
4. We'll see based on usage
5. Too early to say as we're figuring out how some of the patterns work together also. NgRx Store provides a type of reactivity already, so making the two worlds exist together smoothly is definitely a conversation we'll continue to have.

[e-oz]

Perfect, great-looking API!

[yharaskrik]

Is there going to be any guidance around if we should be using computed or select now to combine selectors into some publicly exposed value?

[brandonroberts]

If you want to combine selectors, the recommended pattern right now is to still use createSelector. We will revisit usage of selectors in the future based on usage with computed, but we could see a future where computed becomes more primary.

[mfp22]

How about this.computed(selectThing) and this.store.computed(selectThing)? Just a thought. Might be confusing, but might be cool.

[brandonroberts]

You'll get a computed or read-only signal from selectSignal either way

angular/angular#49802

[nicholas-ochoa]

This looks great, although this.store.selectSignal() seems a bit long, would this.store.signal() make more sense instead?

export class MoviesComponent {
  store = inject(Store);
  movies = this.store.signal(selectAllMovies);
  
  ngOnInit() {
    this.store.dispatch(MoviesActions.enter());
  }
}

[e-oz]

let me respectively disagree - since it creates a selector, it should have "select" prefix.

[brandonroberts]

We discussed some different method names here, such as selectAsSignal or select(selector).asSignal() and the one we landed on was a good balance. It also gives us some flexibility there if a Signal becomes the primary way to consume a value from the Store. That's a ways off though

[jmarlow4]

Also I think the semantics matter on that for sure.... selector-->signal => selectSignal

[jits]

Great work so far on integrating signals into the existing NgRx store libraries.

I'm finding it difficult to settle on whether to access state (or slices of state) via signals or observables, within a ComponentStore. And when to convert from one to the other, especially when combining with derived state. I suppose this is the nature of the sync vs async complexities, and will be an ongoing discussion (with emerging patterns).

A step that could help, for ComponentStore specifically, is to allow reuse of observable-based "selectors" with signal-based "selectors". I.e. allow the selectSignal method to take in observables as an input (if feasible, under the hood).

To give a concrete example, what I'd like to achieve is something like:

// Note: in the "real thing" I model the state using TS discriminated unions, but the type below is enough for this demonstration.
type AuthState = {
  status: 'disconnected' | 'connecting' | 'connected' | 'error',
  user: User | null,
  error: null,
};

type AuthViewModel = AuthState & { isAuthenticated: boolean };

const initialState: AuthState = {
  status: 'disconnected',
  user: null,
  error: null,
};

@Injectable()
export class AuthStore extends ComponentStore<AuthState> implements OnStateInit {
  readonly #authService = inject(AuthService);

  // I _could_ do this, but I'd prefer to have an observable (which I can then use in the `waitUntilAuthConnected` helper, below).
  // isAuthenticated = computed(() => {
  //   const state = this.state();
  //   return Boolean(state.user);
  // });
  readonly #isAuthenticated$ = this.select((state) => Boolean(state.user));
  readonly isAuthenticated = toSignal(this.#isAuthenticated$, { initialValue: false });

  // --> This is not possible right now as you can't combine signals and observables in `selectSignal`
  readonly vm: Signal<AuthViewModel> = this.selectSignal(
    this.state,
    this.#isAuthenticated$,
    (state, isAuthenticated) => ({
      ...state,
      isAuthenticated,
    }),
    { debounce: true },
  );

  // Helper function for use in guards, and anywhere else where it's essential for auth to be connected
  waitUntilAuthConnected = () =>
    this.state$.pipe(
      filter(({ status }) => status === 'connected'),
      switchMap(() => this.#isAuthenticated$),
      take(1),
    );

  constructor() {
    super(initialState);
    console.log('AuthStore loaded');
  }

  ngrxOnStateInit(): void {
    […]
  }
}

Is this a reasonable ask? Or perhaps there's a better of achieving the same thing (i.e. a consolidated view model) whilst still having the flexibility of moving between signals and observables at will?

[jits]

Update:

For now, I've settled on an approach that favours a bit of duplication in selectors, rather than trying to convert between the signals and observables from selector outputs:

// Note: in the "real thing" I model the state using TS discriminated unions, but the type below is enough for this demonstration.
type AuthState = {
  status: 'disconnected' | 'connecting' | 'connected' | 'error',
  user: User | null,
  error: null,
};

type AuthViewModel = AuthState & { isAuthenticated: boolean };

const initialState: AuthState = {
  status: 'disconnected',
  user: null,
  error: null,
};

@Injectable()
export class AuthStore extends ComponentStore<AuthState> implements OnStateInit {
  readonly #authService = inject(AuthService);

  readonly #isAuthenticated$ = this.select((state) => Boolean(state.user));
  readonly isAuthenticated = this.selectSignal((state) => Boolean(state.user));

  readonly vm: Signal<AuthViewModel> = this.selectSignal(
    this.state,
    this.isAuthenticated,
    (state, isAuthenticated) => ({
      ...state,
      isAuthenticated,
    }),
  );

  // Helper function for use in guards, and anywhere else where it's essential for auth to be connected
  waitUntilAuthConnected = () =>
    this.state$.pipe(
      filter(({ status }) => status === 'connected'),
      switchMap(() => this.#isAuthenticated$),
      take(1),
    );

  constructor() {
    super(initialState);
    console.log('AuthStore loaded');
  }

  ngrxOnStateInit(): void {
    […]
  }
}

[jits]

[For inspiration] This post by @eneajaho (in collaboration with @nartc) captures this tension between signals and observables nicely, with a proposed solution – a custom computedFrom function that can take in both signals and observables, allowing you to .pipe and use RxJS operators on the combination and return a single signal:

https://itnext.io/a-sweet-spot-between-signals-and-observables-a3c9620768f1

A variation of this specifically for selectors would be really useful (i.e.: the reverse: selectSignal taking in observables and managing the conversion/combination).

[markostanimirovic]

I don't think that we should allow mixing derived state and side effects together, because it can lead to unpredictable data flows, especially in more complex scenarios. Both @ngrx/store and @ngrx/component-store packages are designed to separate these two concepts and there is a reason behind this architectural decision.

I like how it looks in simpler scenarios:

class MyComponent {
  private route = inject(ActivatedRoute);
  private myStore = inject(MyStore);
  private myService = inject(MyService);

  id$ = this.route.paramMap.pipe(map(p => p.get('id')!));
  showStars = signal(false);

  @Input({ required: true }) set showStars(x: boolean) {
      this.showStars.set(x);
  }

  data = computedFrom(
      [this.myStore.filters, this.showStars, this.id$],
      [], // initial value
      pipe(
          switchMap(([filters, showStars, id]) =>
            this.myService.get(id, filters, showStars)
          )
      )
  );
}

However, imagine that we want to introduce a loading flag and handle the error case as well. Then, data will look like this:

  data = computedFrom(
      [this.myStore.filters, this.showStars, this.id$],
      [], // initial value
      pipe(
          // side effect 1
          tap(() => this.loading.set(true)),
          switchMap(([filters, showStars, id]) =>
            // side effect 2
            this.myService.get(id, filters, showStars).pipe(
              // side effect 3
              tap(() => this.loading.set(false)),
              catchError((err) => {
                // side effects
                this.loading.set(false);
                this.alertService.show(err.message);
                
                return EMPTY;
              })
            )
          )
      )
  );

If I understood correctly, the problem that computedFrom solves is to provide the ability to combine signals and observables that hold state (e.g. observable returned by ActivatedRoute.params) together. In one of the upcoming versions, Angular will introduce signal inputs and integrate the @angular/router package with signals. Then, we'll be able to hold all state slices into signals by default.

I'd implement this scenario in the following way (by using rxMethod/ComponentStore.effect that explicitly separates side effects from the state):

type Payload = { filters: Filters, showStars: boolean; id: string };

class MyComponent implements OnInit {
  // dependencies
  private route = inject(ActivatedRoute);
  private myStore = inject(MyStore);
  private myService = inject(MyService);

  // state
  showStars = input(false, { required: true });
  
  data = signal<Item[]>([]);
  loading = signal(false);
  
  id = computed(() => this.route.params()['id']);
  payload = computed(() => ({
    filters: this.myStore.filters(),
    showStars: this.showStars(),
    id: this.id(),
  }));

  // effects
  private loadData = rxMethod<Payload>(
    pipe(
      tap(() => this.loading.set(true)),
      switchMap(({ filters, showStars, id }) =>
        this.myService.get(id, filters, showStars).pipe(
          tapResponse({
            next: (data) => this.data.set(data),
            error: (err) => this.alertService.show(err.message),
            finalize: () => this.loading.set(false),
          })
        )
      )
    )
  );

  ngOnInit(): void {
    this.loadData(this.payload);
  }
}

Btw, this can be further simplified by using signalState or signalStore.

Until better integration with signals across the Angular packages, we can use the toSignal helper to temporarily convert the remaining observables that hold the state without breaking the rule of separating the state from side effects and keeping data flow in our application predictable.

And yeah, unlike rxMethod/ComponentStore.effect, computedFrom doesn't require 'manual' triggering. On the other hand, rxMethod provides more flexibility here, because it can be executed on demand, but also multiple times if needed.

---

Note: This is my own opinion/preference. I don't think that computedFrom API is bad. On the contrary, it can be very useful in scenarios that are described in the mentioned article!

[e-oz]

Agree with @markostanimirovic on this. Data streams should be either pure, without side effects, or should be named side effects, not data streams.

[jits]

@markostanimirovic – thank you for that detailed and well-thought out response. I completely agree with your viewpoint there.

I didn't make it clear enough in my last post that the computedFrom idea (from the article mentioned) was just an analogy I was using to help illustrate/inspire my original request, which is to allow combining signals and observable selectors in one go (so nothing specifically about side effects). My request/suggestion boils down to "just" allowing observables to be passed in to selectSignal, so we can build an aggregated view models etc. using a combination of both (as in original example), to avoid having to sometimes declare essentially same this.select and this.selectSignal slices of state.

I realise it's possible for someone to have an observable that has side effects and then use it in a selector aggregation (side note: I wonder if there's a way to warn about this using ESLint?), but that would be a "sharp knife" issue.