[Closed] RFC: NgRx SignalStore

[markostanimirovic]

NgRx Signals

Main goals:

• Providing unidirectional and predictable data flow with signals.
• Keeping a declarative approach instead of "imperative reactivity" that is possible with signals.
• Separating side effects from the state to avoid unpredictable data flows.

Key principles:

• Simple and intuitive
• Declarative
• Flexible
• Modular
• Scalable
• Performant and tree-shakeable
• Strongly typed

GitHub Repo

StackBlitz Playground

Contents

• signalState
  • $update Method
• selectSignal
• signalStore
  • DI Config
  • Defining Stores as Classes
  • Custom Store Features
• rxMethod
• Entity Management

---

signalState

The signalState function creates nested signals for the provided initial state.

import { signalState } from '@ngrx/signals';

const state = signalState({
  user: {
    firstName: 'John',
    lastName: 'Smith',
  },
  foo: 'bar',
  numbers: [1, 2, 3],
});

console.log(state()); // { user: { firstName: 'John', lastName: 'Smith' }, foo: 'bar' }
console.log(state.user()); // { firstName: 'John', lastName: 'Smith' }
console.log(state.user.firstName()); // 'John'

All nested signals are created lazily as requested. Besides that, the signalState will cache created signals, so they'll be created only the first time when requested.

const lastName1 = state.user.lastName; // Signal<string>
const lastName2 = state.user.lastName; // Signal<string>

console.log(lastName1 === lastName2); // true

$update Method

The signalState instance provides the $update method for updating the state. It accepts a sequence of partial state objects or updater functions that partially update the state.

// passing a partial state object
state.$update({ foo: 'baz', numbers: [10, 20, 30] });

// passing an updater function
state.$update((state) => ({
  user: { ...state.user, firstName: 'Peter' },
  foo: 'bar',
}));

// passing a sequence of partial state objects and/or updater functions
state.$update(
  (state) => ({
    numbers: [...state.numbers, 4],
    user: { ...state.user, lastName: 'Ryan' }
  }),
  { foo: 'bar' },
);

This provides the ability to define reusable updater functions that can be used for any signalState instance that has a specific state slice.

import { signalState, SignalStateUpdater } from '@ngrx/signals';

function setFirstName(firstName: string): SignalStateUpdater<{ user: User }> {
  return (state) => ({ user: { ...state.user, firstName } });
}

function addNumber(num: number): SignalStateUpdater<{ numbers: number[] }> {
  return (state) => ({ numbers: [...state.numbers, num] });
}

// usage:
const state1 = signalState({
  user: { firstName: 'John', lastName: 'Ryan' },
  numbers: [10, 20, 30],
  label: 'ngrx',
});

const state2 = signalState({
  user: { firstName: 'Peter', lastName: 'Smith' },
  numbers: [1, 2, 3],
});

state1.$update(setFirstName('Marko'), addNumber(40), { label: 'signals' });
state2.$update(setFirstName('Alex'), addNumber(4));

Unlike the default behavior of Angular signals, all signals created by the signalState function use equality check for reference types, not only for primitives. Therefore, the $update method only supports immutable updates. To perform immutable updates in a mutable way, use the immer library:

// immer-updater.ts
import { SignalStateUpdater } from '@ngrx/signals';
import { produce } from 'immer';

export function immerUpdater<State extends Record<string, unknown>>(
  updater: (state: State) => void
): SignalStateUpdater<State> {
  return (state) => produce(state, (draft) => updater(draft as State));
}

The immerUpdater function can be used in the following way:

import { immerUpdater } from './immer-updater';

state.$update(
  immerUpdater((state) => {
    state.user.firstName = 'Alex';
    state.numbers.push(100);
  })
);

---

selectSignal

The selectSignal function is used to create computed (derived) signals. Unlike computed function from the @angular/core package, the selectSignal function applies an equality check for reference types by default. It has the same signature as computed.

import { selectSignal, signalState } from '@ngrx/signals';

type UsersState = { users: User[]; query: string };

const usersState = signalState<UsersState>({
  users: [],
  query: '',
});

const filteredUsers = selectSignal(() =>
  usersState.users().filter(({ name }) => name.includes(usersState.query()))
);

It also has another signature similar to createSelector and ComponentStore.select:

const filteredUsers = selectSignal(
  usersState.users,
  usersState.query,
  (users, query) => users.filter(({ name }) => name.includes(query))
);

---

signalStore

The signalStore function acts as a pipe that accepts a sequence of store features. By combining various store features, we can add state slices, computed signals, methods, and hooks to the signal store.

There are 4 base features that can be used to create signal stores or custom signal store features: withState, withSignals, withMethods, and withHooks.

The withState feature accepts a dictionary of state slices, and converts each slice into a nested signal. All nested signals are created lazily as requested.

import { signalStore, withState } from '@ngrx/signals';

type Filter = { query: string; pageSize: number };
type UsersState = { users: User[]; filter: Filter };

const initialState: UsersState = {
  users: [],
  filter: { query: '', pageSize: 10 },
};

const UsersStore = signalStore(
  withState(initialState)
);

The signalStore function returns a class/token that can be further provided and injected where needed. Similar to signalState, signalStore also provides the $update method for updating the state.

@Component({
  providers: [UsersStore],
})
export class UsersComponent {
  readonly usersStore = inject(UsersStore);
  // available state signals:
  // - usersStore.users: Signal<User[]>
  // - usersStore.filter: Signal<{ query: string; pageSize: number }>
  // - usersStore.filter.query: Signal<string>
  // - usersStore.filter.pageSize: Signal<number>
  
  onAddUser(user: User): void {
    this.usersStore.$update((state) => ({
      users: [...state.users, user]
    }));
  }
  
  onUpdateFilter(filter: Filter): void {
    this.usersStore.$update({ filter });
  }
}

The withState feature also has a signature that accepts the initial state factory as an input argument.

import { signalStore, withState } from '@ngrx/signals';

type UsersState = { users: User[]; query: string };

const USERS_INITIAL_STATE = new InjectionToken<UsersState>('Users Initial State', {
   factory() {
     return { users: [], query: '' };
   }, 
});

const UsersStore = signalStore(
  withState(() => inject(USERS_INITIAL_STATE))
);

The withSignals feature accepts the computed signals factory as an input argument. Its factory accepts a dictionary of previously defined state and computed signals as an input argument.

import { selectSignal, signalStore, withState, withSignals } from '@ngrx/signals';

type UsersState = { users: User[]; query: string };

const UsersStore = signalStore(
  withState<UsersState>({ users: [], query: '' }),
  // we can access previously created state signals via factory input
  withSignals(({ users, query }) => ({
    filteredUsers: selectSignal(() =>
      users().filter(({ name }) => name.includes(query()))
    ),
  }))
);

@Component({
  providers: [UsersStore],
})
export class UsersComponent {
  readonly usersStore = inject(UsersStore);
  // available state signals:
  // - usersStore.users: Signal<User[]>
  // - usersStore.query: Signal<string>
  // available computed signals:
  // - usersStore.filteredUsers: Signal<User[]>
}

The withMethods feature provides the ability to add methods to the signal store. Its factory accepts a dictionary of previously defined state signals, computed signals, methods, and $update method as an input argument and returns a dictionary of methods.

The last base feature of SignalStore is withHooks. It provides the ability to add custom logic on SignalStore init and/or destroy.

import { signalStore, withState, withMethods, withHooks } from '@ngrx/signals';

type UsersState = { users: User[]; loading: boolean };

const UsersStore = signalStore(
  withState<UsersState>({ users: [], loading: false }),
  // we can access the '$update' method via factory input
  withMethods(({ $update, users }) => {
    // services/tokens can be injected here
    const usersService = inject(UsersService);

    return {
      addUser(user: User): void {
        $update((state) => ({
          users: [...state.users, user],
        }));
      },
      async loadUsers(): Promise<void> {
        $update({ loading: true });
        const users = await usersService.getAll();
        $update({ users, loading: false });
      },  
    };
  }),
  withHooks({
    onInit({ loadUsers }) {
      loadUsers();
    },
    onDestroy({ users }) {
      console.log('users on destroy', users());
    },
  })
);

@Component({
  providers: [UsersStore],
})
export class UsersComponent {
  readonly usersStore = inject(UsersStore);
  // available signals and methods:
  // - usersStore.$update
  // - usersStore.users: Signal<User[]>
  // - usersStore.loading: Signal<boolean>
  // - usersStore.addUser: (user: User) => void
  // - usersStore.loadUsers: () => Promise<void>
}

DI Config

In the previous examples, we saw the default behavior - signalStore returns a class/token that can be further provided where needed. However, we can also provide a SignalStore at the root level by using the { providedIn: 'root' } config:

import { signalStore, withState } from '@ngrx/signals';

type UsersState = { users: User[] };

const UsersStore = signalStore(
  { providedIn: 'root' },
  withState<UsersState>({ users: [] })
);

@Component({ /* ... */ })
export class UsersComponent {
  // all consumers will inject the same instance of UsersStore
  readonly usersStore = inject(UsersStore);
}

Defining Stores as Classes

Besides the functional approach, we can also define a store as class in the following way:

import { selectSignal, signalStore, withState } from '@ngrx/signals';

type CounterState = { count: number };

const initialState: CounterState = { count: 0 };

@Injectable({ providedIn: 'root' })
export class CounterStore extends signalStore(withState(initialState)) {
  // this.count signal is available from the base class
  readonly doubleCount = selectSignal(() => this.count() * 2);
  
  increment(): void {
    // this.$update method is available from the base class
    this.$update({ count: this.count() + 1 });
  }
  
  decrement(): void {
    this.$update({ count: this.count() - 1 });
  }
}

Custom Store Features

The @ngrx/signals package provides the signalStoreFeature function that can be used to create custom SignalStore features.

// call-state.feature.ts
import { selectSignal, signalStoreFeature, withState, withSignals } from '@ngrx/signals';

export type CallState = 'init' | 'loading' | 'loaded' | { error: string };

export function withCallState() {
  return signalStoreFeature(
    withState<{ callState: CallState }>({ callState: 'init' }),
    withSignals(({ callState }) => ({
      loading: selectSignal(() => callState() === 'loading'),
      loaded: selectSignal(() => callState() === 'loaded'),
      error: selectSignal(callState, (callState) =>
        typeof callState === 'object' ? callState.error : null
      ),
    }))
  );
}

export function setLoading(): { callState: CallState } {
  return { callState: 'loading' };
}

export function setLoaded(): { callState: CallState } {
  return { callState: 'loaded' };
}

export function setError(error: string): { callState: CallState } {
  return { callState: { error } };
}

The withCallState feature can be further used in any signal store as follows:

import { signalStore, withState, withMethods } from '@ngrx/signals';
import { withCallState, setLoaded } from './call-state.feature';

type UsersState = { users: User[] };

const UsersStore = signalStore(
  { providedIn: 'root' },
  withState<UsersState>({ users: [] }),
  withCallState(),
  withMethods((store, usersService = inject(UsersService)) => ({
    async loadUsers() {
      // updating the state:
      store.$update({ callState: 'loading' });
      const users = await usersService.getAll();
      // or we can use reusable updater:
      store.$update({ users }, setLoaded());
    }
  }))
);

@Component({ /* ... */})
export class UsersComponent implements OnInit {
  readonly usersStore = inject(UsersStore);
  // available signals:
  // - usersStore.users: Signal<User[]>
  // - usersStore.callState: Signal<CallState>
  // - usersStore.loading: Signal<boolean>
  // - usersStore.loaded: Signal<boolean>
  // - usersStore.error: Signal<string | null>

  ngOnInit(): void {
    this.usersStore.loadUsers();
  }
}

The signalStoreFeature function also provides the ability to specify which state slices, computed signals, and/or methods are required in a store that uses the feature. This can be done using the type helper function.

// selected-entity.feature.ts
import { selectSignal, signalStoreFeature, type, withState, withSignals } from '@ngrx/signals';

type SelectedEntityState = { selectedEntityId: string | number | null };

export function withSelectedEntity<T extends { id: string | number }>() {
  return signalStoreFeature(
    // a store that uses 'withSelectedEntity' feature must have the 'entityMap' state slice
    { state: type<{ entityMap: Dictionary<T> }>() },
    withState<SelectedEntityState>({ selectedEntityId: null }),
    withSignals(({ selectedEntityId, entityMap }) => ({
      selectedEntity: selectSignal(
        selectedEntityId,
        entityMap,
        (selectedEntityId, entityMap) => selectedEntityId
          ? entityMap[selectedEntityId]
          : null
      )
    }))
  );
}

If we try to use the withSelectedEntity feature in the store that doesn't contain entityMap state slice, the compilation error will be thrown.

import { signalStore, type, withState } from '@ngrx/signals';
import { withSelectedEntity } from './selected-entity.feature';

const UsersStoreWithoutEntityMap = signalStore(
  withState<{ query: string }>({ query: '' }),
  withSelectedEntity() // ❌ compilation error
);

const UsersStoreWithEntityMap = signalStore(
  withState<{ query: string; entityMap: Dictionary<User> }>({
    query: '',
    entityMap: {},
  }),
  withSelectedEntity(), // ✅
);

Besides state, we can also add constraints for computed signals and/or methods in the following way:

import { signalStoreFeature, type } from '@ngrx/signals';

export function withMyFeature() {
  return signalStoreFeature(
    {
      // a store that uses 'withMyFeature' must have the 'foo' state slice,
      state: type<{ foo: string }>(),
      // 'bar' computed signal,
      signals: type<{ bar: Signal<number> }>(),
      // and 'loadBaz' method
      methods: type<{ loadBaz: () => Promise<void> }>(),
    },
    /* ... */
  );
}

More examples of custom SignalStore features:

• withImmerUpdate
• withStorageSync
• withLoadEntities

withImmerUpdate and withStorageSync features can be developed as community plugins in the future.

import { signalStore, withState } from '@ngrx/signals';
import { withLocalStorageSync } from '../shared/local-storage-sync.feature';
import { withImmerUpdate } from '../shared/immer-update.feature';

@Injectable({ providedIn: 'root' })
export class TodosStore extends signalStore(
  withState<{ todos: string[] }>({ todos: [] }),
  // synchronize todos state with localStorage item with key 'todos'
  withStorageSync('todos'),
  // override $update method to use `immerUpdater` under the hood by default
  withImmerUpdate()
) {
  addTodo(todo: string): void {
    this.$update((state) => {
      state.todos.push(todo);
    });
  }

  removeTodo(index: number): void {
    this.$update((state) => {
      state.todos.splice(index, 1);
    });
  }
}

---

rxMethod

The rxMethod function is inspired by the ComponentStore.effect method. It provides the ability to create reactive methods by using RxJS operators. It returns a function that accepts a static value, signal, or observable as an input argument.

The rxMethod function can be used in the following way:

import { rxMethod } from '@ngrx/signals/rxjs-interop';
import { signal } from '@angular/core';

@Component({ /* ... */ })
export class UsersComponent implements OnInit {
  private readonly usersService = inject(UsersService);

  readonly users = signal<User[]>([]);
  readonly loading = signal(false);
  readonly query = signal('');

  readonly loadUsersByQuery = rxMethod<string>(
    pipe(
      tap(() => this.loading.set(true)),
      switchMap((query) => this.usersService.getByQuery(query)),
      tap((users) => {
        this.users.set(users);
        this.loading.set(false);
      })
    )
  );

  ngOnInit(): void {
    // The method will be executed every time when query signal changes.
    // It will clean up supscription when 'UsersComponent' is destroyed.
    this.loadUsersByQuery(this.query);
    // If it's called with static value (loadUsers('ngrx')), the method
    // will be executed only once.
    // If it's called with observable (loadUsers(query$)), the method
    // will be executed every time when 'query$' observable emits a new
    // value.
  }
}

It can be also used to define SignalStore methods:

import { signalStore, withState, withMethods, withHooks } from '@ngrx/signals';
import { rxMethod } from '@ngrx/signals/rxjs-interop';

type UsersState = { users: User[]; loading: boolean; query: string };

const UsersStore = signalStore(
  withState<UsersState>({ users: [], query: '' }),
  withMethods((store, usersService = inject(UsersService)) => ({
    loadUsersByQuery: rxMethod<string>(
      pipe(
        tap(() => store.$update({ loading: true })),
        switchMap((query) => usersService.getByQuery(query)),
        tap((users) => store.$update({ users, loading: false }))
      )
    ),
  })),
  withHooks({
    onInit({ loadUsersByQuery, query }) {
      // re-fetch users every time when query signal changes
      loadUsersByQuery(query);
    },
  })
);

---

Entity Management

This package should provide the following APIs:

• withEntities feature that will add entityMap and ids as state slices, and entities (entity list) as computed signal
• tree-shakeable updater functions: setOne, setAll, deleteOne, deleteMany, etc.

import { signalStore, withMethods } from '@ngrx/signals';
import { withEntities, setAll, deleteOne } from '@ngrx/signals/entities';
import { rxMethod } from '@ngrx/signals/rxjs-interop';
import { withCallState, setLoading, setLoaded } from './call-state.feature';

const UsersStore = signalStore(
  withEntities<User>(),
  withCallState(),
  withMethods((store, usersService = inject(UsersService)) => ({
    loadUsers: rxMethod<void>(
      pipe(
        tap(() => store.$update(setLoading())),
        exhaustMap(() => usersService.getAll()),
        tap((users) => store.$update(setAll(users), setLoaded()))
      )
    ),
  }))
);

@Component({
  template: `
    <p>Users: {{ usersStore.entities() | json }}</p>
    <p *ngIf="usersStore.loading()">Loading ...</p>
    <button (click)="onDeleteOne()">Delete One</button>
  `,
  providers: [UsersStore],
})
export class UsersComponent implements OnInit {
  readonly usersStore = inject(UsersStore);

  ngOnInit(): void {
    this.usersStore.loadUsers();
  }

  onDeleteOne(): void {
    this.usersStore.$update(deleteOne(1));
  }
}

withEntities function can be also used multiple times for the same store if we want to have multiple collections within the same store:

import { signalStore } from '@ngrx/signals';
import { withEntities, addOne, deleteOne } from '@ngrx/signals/entities';

const BooksStore = signalStore(
  withEntities<Book>({ collection: 'book' }),
  withEntities<Author>({ collection: 'author' })
);

const booksStore = inject(BooksStore);
// booksStore contains the following signals:
// - booksStore.bookEntityMap: Signal<Dictionary<Book>>;
// - booksStore.bookIds: Signal<Array<string | number>>;
// - (computed) booksStore.bookEntities: Signal<Book[]>;
// - booksStore.authorEntityMap: Signal<Dictionary<Author>>;
// - booksStore.authorIds: Signal<Array<string | number>>;
// - (computed) booksStore.authorEntities: Signal<Author[]>;

// updating multiple collections:
booksStore.$update(addOne({ id: 10, title: 'Book 1' }, { collection: 'book' }));
booksStore.$update(deleteOne(100, { collection: 'author' }));

[SimonPrammer]

Looks absolutely amazing. Would love to try it out in a project I'm working on.
Any specific things you need feedback on?

[CharlieGreenman]

This looks incredible and beyond my understanding of signals at the moment. With that in mind just a quick question, if I may(I fully recognize might not be the right place for this).

1. Would the intent be a simplified interface for ngrx/store?
   If it is, could this take place of ngrx/store instead.

2. If it’s for performance, will it be behind the scenes for ngrx/store?

I’m just thinking of the need/want to now move over existing ngrx store to ngrx signals and how difficult that might be. Both questions above are related to this concern. The while sounds fantastic nonetheless does bring up that concern. Thank you for your time.

[mikezks]

I would clearly vote for an integrated solution. A third state management approach beside @ngrx/store and @ngrx/component-store will definitely confuse people and I do not see any benefit of having the @ngrx/component-store with Signal APIs and an additional Signal-Store.

[siva636]

The NgRx Team can not publish code in the official @angular namespace. 😉

It is a good catch.

But the main point here is not to have the prefix name @angular, instead, not to have the prefix @ngrx because it may confuse with the existing NgRx package. :-)

[mikezks]

As the reason for creating the NgRx namespace has always been supporting reactive programming for Angular, it is still a good fit IMO.
In the past, RxJS was the main reactive concept for Angular, now - at least in some areas - Signals will play an important role as reactive primitive.

[mikezks]

... but I fully agree that we need to find a way to not introduce different implementations for the same purpose. The community should have a clear guidance within the @ngrx namespace and if alternatives are intended then I agree that a different namespace would be better.

[markostanimirovic]

If the signalStore is an independent package, then we need not confuse it with the terminology ngrx, it may be called @angular/signal-store

The first association to the NgRx is the @ngrx/store package and packages around it (@ngrx/router-store, @ngrx/effects, @ngrx/store-devtools, etc). However, as @mikezks said, NgRx is a group of libraries for building reactive Angular applications. There are NgRx packages that are completely independent of the @ngrx/store, such as @ngrx/component or @ngrx/component-store. The SignalStore will be also one of them.

[KevTale]

Awesome!

1- is there any plan to make the updaters immutable while writing mutable code, like immer?
2- does it have integration with redux devtool?
3- do you guys see signal store as a replacement of component/store or even ngrx/store? As it seems to be intented to be used for components and also globally, it seems to be the equivalent of ngrx/store in terms of features.

Anyway, the API looks amazing, congrats and thank you 😍

[csutorasr]

1. You could provide a custom implementation for withUpdaters like withImmerUpdaters. It would be nice to have the common part of the implementation in a common place.
2. withDevTools({ key: 'MyBestStore' }) should work. If you look at the withEntities these keywords are composable.
3. If you provide them in the AppModule then you can use them everywhere.

[markostanimirovic]

Thanks, @KevTale! Great questions, we also had a discussion on this (1st and 2nd).

As @csutorasr said, we can create a feature withImmerUpdate that would add the immerUpdate method or replace the default update method. Its usage would look like this:

const [provideTodosStore, injectTodosStore] = signalStore(
  withState<TodosState>({ todos: [] }),
  withImmerUpdate(),
  withUpdaters({ immerUpdate }) => ({
    addTodo(todo: string) {
      immerUpdate((state) => state.todos.push(todo));
    }
  })
);

It should be also possible to implement the withDevtools feature, I need to check how it would work for component-level stores. 👀

---

Regarding the third question, the signal store seems more like an alternative to me. SignalStore solves the same problem as ComponentStore but in a different way. ComponentStore is primarily used for local state management but can be used for global as well similar to SignalStore.

On the other hand, SignalStore would have first-class support for signals, without internal observable - signal conversions. RxJS would be optional, even for asynchronous effects. Also, it provides functional developer experience and the ability to solve some limitations that we have with class-based state management solutions such as modularity (composability) and tree-shakeability.

NgRx Store and ComponentStore will most likely have their own signal-based APIs, but there will be no breaking changes. In other words, they'll still provide RxJS APIs and use RxJS as their internal reactive mechanism, at least for now.

[e-oz]

Thank you so much for such a detailed RFC! I guess it took a lot of time to create it (at least it would take a couple of eternities for me).
From this RFC it looks like a must-have library for those who used to work with ngrx and want to use Angular Signals with the controlled level of chaos ;)

A few questions below, none of them are criticism:

---

I used to keep stores and components in separate files.
Here you write:

const [provideUsersStore, injectUsersStore] = signalStore(...

and then:

@Component({
  providers: [provideUsersStore()],
})
export class UsersComponent {
  readonly usersStore = injectUsersStore();

it means that both provideUsersStore and injectUsersStore should be exported and imported if we want to keep a store and a component in separate files. Maybe it's just me, but it's a bit repetitive.

To workaround this, the only way is to use { providedIn: 'root' }, but it's an absolutely different thing (most of the stores should not be singletons).

---

rxEffect - is it a dirty function? I mean, does it have an internal state? ComponentStore.effect uses an internal observable (origin$), will rxEffect use something similar? If yes, then how will it be tied to the component's lifecycle?

---

After adding updaters, you have this comment:

// available properties and methods:
  // - usersStore.update method
  // - usersStore.users: Signal<User[]>
  // - usersStore.query: Signal<string>
  // - usersStore.filteredUsers: Signal<User[]>
  // - usersStore.addUsers: (users: User[]) => void

Will they be available because of TS types?

---

Again, there is zero hostility in questions, just some curiosity.
Thank you for working on it!

[markostanimirovic]

Thanks for the feedback @e-oz!

---

it means that both provideUsersStore and injectUsersStore should be exported and imported if we want to keep a store and a component in separate files. Maybe it's just me, but it's a bit repetitive.

Another way could be to return a class with @Injectable applied:

// UsersStore is a class
const UsersStore = signalStore(/* ... */);

@Component({
  providers: [UsersStore],
})
export class UsersComponent {
  readonly usersStore = inject(UsersStore);
}

But using a function to create a class can be confusing. 🤔 The solution with the [provide, inject] tuple seems clearer and more logical to me. It's also in accordance with the "functional" style of the signal store. What do you think?

rxEffect - is it a dirty function? I mean, does it have an internal state? ComponentStore.effect uses an internal observable (origin$), will rxEffect use something similar? If yes, then how will it be tied to the component's lifecycle?

Yes, it works in the same way as ComponentStore.effect. It cleans up a subscription on destroy by using the DestroyRef token. You can check its implementation here.

Will they be available because of TS types?

Yeah! The signalStore result is strongly typed.

[e-oz]

But using a function to create a class can be confusing. 🤔 The solution with the [provide, inject] tuple seems clearer and more logical to me

"inject()" does that and everyone is happy:)
Tuples look like a hacky way to return results from function, and it will require more exports/imports.

[e-oz]

It cleans up a subscription on destroy by using the DestroyRef token

I was afraid of that answer. So it means that rxEffect() can only be called during “construction” cycle.

[markostanimirovic]

rxEffect can be used out of the injection context, but in that case, unsubscribing will never happen.

[e-oz]

I understand, but it might not be so obvious for the users.

[csutorasr]

I would pass every parameter to the function as an array in the first argument. It is easier to add more parameters later if needed without a breaking change. E.g.

const [provideUsersStore, injectUsersStore] = signalStore([
  withState<UsersState>({ users: [], query: '' }),
  withComputed(({ users, query }) => ({
    filteredUsers: computed(() =>
      users().filter(({ name }) => name.includes(query()))
    ),
  }))
]);

[nartc]

Thanks for the detailed RFC. I have some points:

1. I personally think NgRx should just expose a single createSignalStore() function and leave the DI/Provider/Injector part to the consumers. There are folks that still prefer Constructor DI. If folks want to have const [provider, injector] = createSignalStore(), they can always abstract that themselves and make it fit for their projects. When it comes to testing, it's essential to have useFactory, useClass, and useValue to mock the Signal Store as needed as well. If NgRx provides this functionality, then it also takes on more responsibility that doesn't have anything to do with the (Signal) Store itself.
2. I didn't see a way to provide default values/extra default values with withEntities(). Is that not intended or just didn't show?
3. Is there an API to watch for state changes that makes use of Signal's effect()?

[markostanimirovic]

Thanks for the feedback @nartc!

I personally think NgRx should just expose a single createSignalStore() function and leave the DI/Provider/Injector part to the consumers.

What should be the result of the createSignalStore function? I guess the signal store instance 👀

Leaving the DI part to the consumers will introduce additional boilerplate for almost every store. Consumers would need to manually create tokens. Example for the signal store that is provided at the component level:

function usersStoreFactory() {
  return signalStore(
    withState(/* ... */);
  );
}

const USERS_STORE = new InjectionToken<ReturnType<typeof usersStoreFactory>>('Users Store');

@Component({
  providers: [
    { provide: USERS_STORE, useFactory: usersStoreFactory },
  ],
})
class UsersComponent {
  usersStore = inject(USERS_STORE);
}

Doesn't look very nice to me. 😑 The configuration will be simpler for root-level stores:

const USERS_STORE = new InjectionToken('Users Store', {
  // providedIn: 'root' is applied by default
  factory: () => signalStore(
    withState(/* ... */)
  ),
});

@Component({})
class UsersComponent {
  usersStore = inject(USERS_STORE);
}

But still, I think it's better to provide DI functionalities out of the box to reduce boilerplate.

There are folks that still prefer Constructor DI.

This is a valid point. There is also an option that I mentioned here to return a class as a signal store factory result, but I'm not sure if that's a good idea. 😅 On the other hand, it seems there will be fewer chances to use constructor-based DI in the future (class-based guards and interceptors are already deprecated).

By the way, There is the ability to use the current version of the signal store with constructor-based DI by using { useInjection: false } + InjectionToken:

function usersStoreFactory() {
  return signalStore(
    // 👇 with this config, `signalStore` fn will return the signal store instance
    { useInjection: false },
    withState(/* ... */)
  ),
}

const USERS_STORE = new InjectionToken('Users Store', {
  factory: usersStoreFactory,
});

type UsersStore = ReturnType<typeof usersStoreFactory>;

@Component({})
class UsersComponent {
  constructor(@Inject(USERS_STORE) readonly usersStore: UsersStore) {}
}

Doesn't look very nice, but it's possible.

When it comes to testing, it's essential to have useFactory, useClass, and useValue to mock the Signal Store as needed as well. If NgRx provides this functionality, then it also takes on more responsibility that doesn't have anything to do with the (Signal) Store itself.

Currently, we can mock the signal store in a simpler way without any TestBed config:

import * as fromUsersStore from './users.store';

// test
jest.spyOn(fromUsersStore, 'injectUsersStore').mockReturnValue({ /* fake users store */ });

---

2. I didn't see a way to provide default values/extra default values with withEntities(). Is that not intended or just didn't show?

It's not intended. Entity state should be managed via predefined updater functions (similar to @ngrx/entity) to avoid setting invalid ids and/or entity dictionaries.

---

3. Is there an API to watch for state changes that makes use of Signal's effect()?

There is no need to create additional API for this because we can use the effect function directly. Take a look at this example.

[nartc]

1. It's just my 2 cents but if you're sticking with [provider, injector] API, then please also expose the TOKEN as [provider, injector, TOKEN] so that folks can utilize that TOKEN in anyway they want.

re:Testing: They can use that TOKEN in tests if they want to use TestBed.

2. 💪
3. As I wrote down the comment, I realized we could use effect(). All's good then

[marko-jobcloud]

1. Yeah, that's possible. In that case, I'd go with dictionary instead of tuple:

const usersStore = signalStore(/* ... */);

usersStore.provide();
usersStore.inject();
usersStore.TOKEN

or 👀

const {
  provideUsersStore,
  injectUsersStore,
  USERS_STORE_TOKEN,
} = signalStore({ name: 'users' }, /* ... */);

[nartc]

Yeah I don't mind a dictionary at all

[timsar2]

[brandonroberts]

Thanks Timsar. Let's try to stay on topic. I'm sure there will be something with Signals from the StateAdapt folks also

[gabrielguerrero]

@markostanimirovic looks amazing, about the Custom Store Features I wanted to have something like this in ngrx for so long Im so glad to see it, I did something similar in a library I build called ngrx-traits (link at the end if you want to have a look ), for the functions that return the SignalStoreFeature (those I call traits in my library), it will be very useful if there was a way to know what other SignalStoreFeature features are present to make them smarter, for example, if I create a withLoadEntities that receives an effect that simply calls the backend as param, and it creates a load method that calls the backend and uses withCallState and withEntities to set to loading when the call starts and call setAll and change the status to loaded when is done.
The way I did is a bit complicated to explain here but it is essentially providing a context in the factory function, and in that context, you need to add something that you can use in the factory function to know if other features are present like an array ids or similar
Will love to help with this, I have a few ideas of possible SignalStoreFeature that will be great if they come out of the box, like pagination etc
This is an intro ngrx-traits in case you want to have a look
https://medium.com/@gabrieldavidguerrero/introduction-to-ngrx-traits-c8c2a4edab4d,

[gabrielguerrero]

Cool, thanks @markostanimirovic 👍, looking forward to play with it

[markostanimirovic]

@gabrielguerrero I created several snippets inspired by your comment: https://twitter.com/MarkoStDev/status/1634204313357516801 😎

In the example from Twitter, if we apply the withLoadAllEntities feature to the SignalStore that doesn't contain the withCallState and withEntities features, the compilation error will be thrown.

[gabrielguerrero]

I just looked at it looks fantastic thanks, there are so many common patterns that could be added like that I'll probably create a package of them :), and the compile error if the dependencies are not there is the cherry on the top, I tried many ways and could not get that to error in at compile time in ngrx-traits, so I had to leave it at only at runtime. Anyway great job

[gabrielguerrero]

Hey @markostanimirovic, I finally have time to play with your playground, I noticed that the createSignalStoreFeature method is not there. Will you mind adding it if you have the code around? Not sure if you made up your mind on providing it, but I think it will ease creating custom signal store features because it will allow you to use withState, withEffects, etc inside making it consistent with how you use the signalstore method, I think I have an idea how to create it, I imagine is similar to signalstore method but if you have already done it better :)

[gabrielguerrero]

Hey @markostanimirovic , no worries I created the function myself, called it signalStoreFeature to follow the naming you have there with signalStore, I been playing with it and forked your repo, I used it to reimplement the withLoadEntities and withCallState to use the function I think it makes creating the store features way easier because it allows to use the withState, withEffects etc to create them, seems to work well, happy to contribute it if you have not create it already or in case anyone wants to play with creating custom store features, the repo is:
https://github.com/gabrielguerrero/ngrx-signal-store-playground/blob/main/src/app/users/load-entities.ts

[markostanimirovic]

👆 RFC and the playground project are updated. Summary:

• The signalStore function is renamed to createSignalStore.
• The createSignalStore result is a token that can be further provided/injected where needed.
• Config with { useInjection: false } is removed.

Thanks everyone for the very helpful feedback! 🙌

[mikezks]

Nested Signals

Currently the Angular team does not offer an official API for nested signals and I assume it could be out of scope for them.

I see a perfect fit to include this into a state management solution like the two NgRx concepts.

Is this something you plan for this lib, @markostanimirovic?

[e-oz]

Converting objects recursively is an expensive operation (performance-wise).
Not every field contains numbers and booleans.
If every field will be recursively converted into signals, then users will have to worry about what values they store - if a value will be some big object, then it will hit the performance.

[mikezks]

@e-oz exactly thats is the issue. I will add a post with more context soon.
Findings so far:

• Immutability still helps although in contrast to Redux for Signals not required.
• Real fine-grained change detection makes nested Signals/Computed necessary.
• But, runtime overhead is comparable to the current default dirty-checking, if nested Signals need to be created/updated during runtime.
• The earlier we can track fine-grained state changes through Signals, the better it is related to overhead.

[manfredsteyer]

Some additional thoughts here:

• The SolidStore uses a lazy approach for nested signals. There, Signals are always nested. As @mikezks said, it seems like nested signals are a prerequisite for real fine-grained CD
• Computed does not really help here because we have Immutables (see example below)
• First simple performance tests show that the performance impact can be neglected (I guess Solid would have an issue otherwise)
• I'd love to find a good way to calculate nested signals only where needed. However, as outlined below, this seems to be difficult.

Let's say we have this state:

const state = signal({ a: { b: 1, c: { d: 2}}});

And this computed to get a nested signal for d:

const nested = computed(() => state().a.c.d)

Let's also assume an equal function for Immutables: (a, b) => a === b;

Now the issue:
As the structure is immutable, every time b changes, a changes too, and hence nested is recalculated (as well as everything else calculated using a).

This is the behavior that way ok in the past with Observables + Immutables, b/c we always went through the component tree in a top/down manner. However, with Signals we want to have fine-grained reactivity.

[e-oz]

The only way is to store them in individual signals, not in a single object.

[manfredsteyer]

+1 this is also the conclusion I came to after doing some experiments. I would really be happy to be proven wrong here.

[Harpush]

First of all the idea looks really good!
A few points I really liked:

1. "Component store oriented" approach
2. Ability to use as global and local
3. Reusability in state parts (so called features)

One thing I didn't like is the naming of rxEffect - how about calling it createAsyncFunction? As effect exists now in the signals land and at the end this is an async function. Might be confusing what effect means.

Concerning the idea of store vs feature I would like also to see the ability to use features inside other features in order to reuse smaller parts. So feature could use with like a regular store can. In addition the ability to use withWhatever twice seems needed too. A good example for it is grid state - it has sorting filters maybe even effects and I want two identical grids like that - how do I do that?

Generally the with convention - it means there is an inherent difference between store and feature. How about using DI to create both and just use DI composition? That way each store is potentially a feature and you can mix and match however you want. For example if I want a counter reusable store with two instances (Guess can be functional too... using some "magic" helper functions in this example):

export interface CounterParams {
  initialCount: number;
}

export class CounterStore {
  private state = signal(this.params.initialCount);

  public count = computed(() => this.state());
  public doubleCount = computed(() => this.count() * 2);

  constructor(private params: CounterParams) {}

  public increment() {
    this.state.update(s => s + 1);
  }

  public decrement() {
    this.state.update(s => s - 1);
  }
}

export function provideCounterStore(
  provideAs: ProvideAs<CounterStore>,
  params: CounterParams
): Provider[] {
  const [paramsToken, paramsProvider] = createStoreParams(params);

  const counterStoreProvider = createStoreProvider(provideAs, CounterStore, [
    paramsToken
  ]);

  return [paramsProvider, counterStoreProvider];
}

// Usage
export const [firstCounterToken, firstCounterProviders] = createStoreInstance(
  provideCounterStore,
  { initialCount: 0 }
);

export const [secondCounterToken, secondCounterProviders] = createStoreInstance(
  provideCounterStore,
  { initialCount: 1 }
);

This way you can create multiple instances and because each "feature" is a store you can inject it in other stores and create a "fractal" store graph.

Another option is taking the good from both - features will be small reusable parts which are not standalone - like async state or pagination while stores can be created multiple times in the way I mentioned.

[markostanimirovic]

Thanks for your feedback @Harpush!

Regarding the example that you provided, it's also possible with the current implementation to create the same store with different initial states:

function createCounterStore(initialCount: number) {
  return createSignalStore(
    withState({ count: initialCount }),
    withComputed(({ count }) => ({
      doubleCount: computed(() => count() * 2),
    })
  );
}

const CounterStore1 = createCounterStore(0);  // CounterStore with initialCount: 0
const CounterStore2 = createCounterStore(1);  // CounterStore with initialCount: 1

There is also an idea to add a helper function createSignalStoreFeature for combining multiple features:

export function withCounterFeatures(initialCount: number) {
  return createSignalStoreFeature(
    withState({ count: initialCount }),
    withComputed(({ count }) => ({
      doubleCount: computed(() => count() * 2),
    })
  );
}

const CounterStore1 = createSignalStore(withCounterFeatures(0));
const CounterStore2 = createSignalStore(withCounterFeatures(1));

[Harpush]

@markostanimirovic Indeed that's a good idea!

A few other questions:

1. Will there be a class based approach for those who still prefer it?
2. Considering I can create a feature twice in a store with different names (like your entity example) and I can create a store twice too - is there a benefit to one approach compared to the other?
3. Will you either provide an option or by default encourage immutability? Signals can be improved if passed an equality function that assumes immutability and there are those nice checks in the global store now which can be added here too.
4. A bit connected to point 2 but will there be a helper to create features which can be added multiple times with different names?
5. Will there be some kind of support for router-store? Many global stores in our app are route driven so it can be really helpful
6. How will you describe events here? One store wants to listen to other store event (for example a general grid store and many other stores that want to know when a new row has been selected and the grid shouldn't know them all by reference - classic event scenario)
7. Please do add tapResponse here too :)
8. Lastly, any thought about allowing dynamic stores creation? Say I want to create and destroy a list of stores dynamically

[Harpush]

And one more thing - how would you type https://github.com/markostanimirovic/ngrx-signal-store-playground/blob/main/src/app/users/users.store.ts#L46 if you needed the filter computed signal for the effect? Because the types are built dynamically it might be tough type wise to extract context related effects for example out of the main "pipeline".

[BruceWeng]

I really like this RFC! Move state management into next level in signal world.
A quick question. Why is async/await is available here? I thought in Angular we can not use async/await because of zone.js. If I use signal store in my Angular app that currently still depends on zone.js for change detection, can I also use async/await without a problem?

[kbrilla]

That's the magic of signals. Signal will still notify all consumers about it's change and view will update.

[hadrien-toma]

Info Hadrien

…

On Mon, Mar 13, 2023, 10:28 Evgeniy OZ ***@***.***> wrote: Converting objects recursively is an expensive operation (performance-wise). Not every field contains numbers and booleans. If every field will be recursively converted into signals, then users will have to worry about what values they store - if a value will be some big object, then it will hit the performance. — Reply to this email directly, view it on GitHub <#3796 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABPAM3S42ISEIG6UBDEMADTW33SDDANCNFSM6AAAAAAVQ2P2CM> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[samuelfernandez]

TL;DR provide mutate function as well to mutate state

This RFC looks great! I'd like to offer some feedback on what could be a simplification over previous requirements on immutability for the store.

Background

Until now, NgRx nicely enforced state immutability. This was because of two main reasons:

1. Ensuring unidirectional data flow. Changes should be applied through actions.
2. Integrate with Angular change detection. It currently builds on top of comparing past and new values when using the suggested OnPush strategy. That is why using immutable state worked well when used like: items$ = this.store.select(selectItems) and then items$ | async in the template.

The Future

Looking into the future, these reasons are loosing weight because:

• Signals already enforce unidirectional data flow by design. New signal store, as component store already did, simplifies the use of actions by update methods, which are imperative and reflect nicely the intent of the change.
• Change detection in the future will no longer be based on comparison of values, but rather with signal's effects/notifications. As explained in signal's docs, their value can be mutated in place, like for example adding values to an array, and still notify about an update. In other words, a "reducer" function could use items.push(newItem) instead of [...items, newItem].

Proposal

Having this said, I'd propose that the API also provides a mutate function. This will help on reducing the well known "spread hell". Simple example following up the one in the RFC:

// Proposal in RFC
usersStore.update((state) => ({
  users: [...state.users, 'u3']
}));

// Enhancement
usersStore.mutate((state) => (state.users.push('u3'));

This example might be trivial, but with deeply nested states it could simplify a lot partial updates, as the one exemplified in this article.

Performance with big collections could also be enhanced, since updating the state would not involve recreating arrays. Other approaches that relied on Immer or similar wouldn't also be needed.

Bottom line, since Angular is exposing the mutate function in the public API of settable signals, having the same in the signal store will allow implementers to also have full control of it.

Having this said, lots of appreciation on the big effort behind this new design and features! 😄

[mikezks]

Yes, definitely - there is currently a big questionmark related to how the new "fine-grained change detection" will work. Anyways, my remark to object references was not directly related to change detection, but on how to compare different values in general. One also needs that, if a more detailed Signal should be updated actively. The alternative would be Computed as mentioned above, but the creation of new computed Signals lead to runtime overhead and memory footprint as well.

[e-oz]

Sorry for the bitter feedback, but immutability and unidirectional data flow are things that distinguish the Redux pattern from a global object with writeable fields. It's not only about change detection in the templates. Without these protections, there will be a data race and chaos.

[samuelfernandez]

Sorry for the bitter feedback, but immutability and unidirectional data flow are things that distinguish the Redux pattern from a global object with writeable fields

Completely agree with that, the principles are still there with my proposal. Let me elaborate a bit more.

"Original" store implemented this through dispatching actions. Component store/signal store reduce that boilerplate offering public update methods to the application. My feedback does not pretend to change any of that, the application should always use those methods for updates, not directly modifying the state or any derived state.

Regarding immutability, agreed that the exposed values should still be like that, for example using Readonly<> types to ensure that consumers don't mutate them. This is something that NgRx's Store as of today does not enforce in types yet, but does with run time checks. Something similar could be done with signal store as well.

However, I don't think we should necessarily close mutability to the class that will implement the signal store. Store authors could benefit from using mutate, while exposing the action through an update method or similar. To exemplify:

class UsersService {
  addUser(newUser: User) {
    this.usersStore.mutate((state) => (state.users.push(newUser));
  }

  get users(): Signal<ReadonlyArray<User>> {
    return this.usersStore.users;
  }
}

Unidirectional data flow is respected, and so immutability for consumers. Yet makes it easier when implementing the store. Can't see anything in the proposal that would result in chaos or race conditions.

Hope I made my point clear now, maybe another perspective on the matter. Happy to see all this nice discussion!

[e-oz]

Thank you for the clarification. I misunderstood you, sorry. Yes, non-exposed methods for mutating the data are safe, in my opinion. Agree.

[mikezks]

Thanks for the example.
This exactly shows the issues with Signals on collections of objects.
With the userService.users access you get a Signal returned that fires on any mutate() call (even with no change at all). Nevertheless, you can not easily figure out which user changed.
It works, but for any change detection built on top of that, it would mean a comparision function needs to check nested props on all levels.

[murindwaz]

This RFC is incredible -- thanks for the work.

There is this section of createSignalStore() that uses both withEffects() (specific to signal) together with rxEffect() for rxjs effects. Both signals and rxjs provide reactivity(in a complimentary way), I suspect the closeness in name and nature may confuse newcomers ~ what do you think of using a more specific name, for instance: withRxjsEffect()?

The portion of the code I was referring to is:

,
  withEffects(({ addUsers }) => {
    const usersService = inject(UsersService);
    // read more about 'rxEffect' in the section below
    const loadUsers = rxEffect<void>(
      pipe(
        exhaustMap(() => usersService.getAll()),
        tap((users) => addUsers(users))
      )
    );

    return { loadUsers };
  }),

Signals are still new to me, the next suggestion may be limited to my understanding of this new concept

Another thing that came to mind:

• *.forFeature() plays a key organizational role in state management at scale. Will const UsersStore = createSignalStore( ... ) have an equivalent(feature parity to) of .forFeature()?
• A quick notation that I can think of would look like const UsersStore = createSignalStoreFor('users', ....)
• In event that is not possible, or immediately needed, what do you think of a utility to merge multiple individual stores into larger one large store to manage at the app level, while keeping feature stores independent? An example that pops into my mind would look like const appStore = mergeSignalStores(UsersStore, ProductsStore, ....)?

One more time, thank you for this well thought RFC 👍🏾🙏

[markostanimirovic]

Thanks for the feedback @murindwaz! There will be a function signalStoreFeatureFactory/createSignalStoreFeature that will provide the ability to create derived features by merging multiple features into one, so derived features can be included in any SignalStore without repetition.

[BruceWeng]

As signal integration with store and component store will release in v16. Will signal store also have chance in v16 release? Looking forward to it!

[mikezks]

I like the new interface, but would love to see a new component store version supporting both in a compatible way: the new createStore and the Signal support for Selectors, which should support current Selectors as well.

[markostanimirovic]

Will signal store also have chance in v16 release? Looking forward to it!

Yes, the SignalStore will be released in developer preview in a next few months.

[gabrielguerrero]

One comment about the collection for the withEntities I think the generated computed signals will be better if it removes the Entity or Entities from the generated property naming if the collection is added

import { withEntities, addOne, deleteOne } from '@ngrx/signals/entity';

const BooksStore = createSignalStore(
  withEntities<Book>({ collection: 'book' }),
  withEntities<Author>({ collection: 'author' })
);

const booksStore = inject(BooksStore);
// booksStore contains following properties:  
///  ----   SUGGESTED NAMES  ------
// - booksStore.bookMap: Signal<Dictionary<Book>>; 
// - booksStore.bookIds: Signal<Array<string | number>>;
// - (computed) booksStore.bookList: Signal<Book[]>;
// - booksStore.authorMap: Signal<Dictionary<Author>>;
// - booksStore.authorIds: Signal<Array<string | number>>;
// - (computed) booksStore.authorList: Signal<Author[]>;

// updating multiple collections:
booksStore.update(addOne({ id: 10, title: 'Book 1' }, { collection: 'book' }));
booksStore.update(deleteOne(100, { collection: 'author' }));

[markostanimirovic]

Hey everyone 👋

I've updated the SignalStore playground project.

Changes:

• The state update method is renamed to $update to avoid naming collision if there is a property/method with the name update.
• To simplify the SignalStore creation, withUpdaters and withEffects features are merged into withMethods.
• withComputed feature is renamed to withSignals.

Features:

• The signalStore now creates nested signals for state slices that are dictionaries. It's important to mention that they're created lazily (on demand).
• Provided a new API for creating custom store features. Examples:
  • withCallState
  • withFilter
  • withLoadEntities

If we apply custom features to the UsersStore from the example, it will look like this:

export const UsersStore = signalStore(
  { providedIn: 'root' },
  withState({ entities: [] as User[] }),
  withCallState(),
  withFilter(),
  withLoadEntities(UsersService),
  withHooks({
    // re-fetch users every time when filter signal changes
    onInit: ({ loadEntitiesByFilter, filter }) => loadEntitiesByFilter(filter),
  })
);

• There is a new lightweight API called signalState that can be used for creating nested signals in the component/service:

const state = signalState({ m: { s: { t: 10 } }, foo: 'bar' });

console.log(state()); // { m: { s: { t: 10 } }, foo: 'bar' }
console.log(state.m()); // { s: { t: 10 } }
console.log(state.m.s()); // { t: 10 }
console.log(state.m.s.t()); // 10

The signalState also provides the $update function for updating the state:

state.$update({ foo: 'baz' });

• There is a new function selectSignal that, unlike computed, applies an equality check for reference types by default. Its first signature is the same signature as computed:

const CounterStore = signalStore(
  withState({ count: 0 }),
  withSignals(({ count }) => ({
    doubleCount: selectSignal(() => count() * 2),
  })),
);

But it also has another signature inspired by createSelector/ComponentStore.select:

type UsersState = { users: string[]; query: string };

const UsersStore = signalStore(
  withState<UsersState>({ users: [], query: '' }),
  withSignals(({ users, query }) => ({
    filteredUsers: selectSignal(
      users,
      query,
      (users, query) => users.filter((user) => user.includes(query))
    ),
  })),
);

I'll update the documentation soon.

[markostanimirovic]

The withLoadEntitiesEffect doesn't have to depend on the filter state slice in this example if it doesn't contain the withHooks feature:

export function withLoadEntitiesByFilter<T>(
  entityServiceToken: Type<{ getByFilter: GetByFilter<T> }>
) {
  const loadEntitiesByFilterFeature = signalStoreFeatureFactory<{
    // add only state slices that are updated by the `loadByFilter` effect
    state: { entities: T[]; callState: CallState };
  }>();

  return loadEntitiesByFilterFeature(
    withMethods(({ $update }, entityService = inject(entityServiceToken)) => ({
      loadByFilter: rxEffect<Filter>(
        pipe(
          tap(() => $update(setLoading())),
          switchMap((filter) => entityService.getByFilter(filter)),
          tap((entities) => $update({ entities }, setLoaded()))
        )
      ),
    })),
  );
}

// usage:
const UsersStore = signalStore(
  withState<{ entities: User[] }>({ entities: [] }),
  withCallState(),
  withLoadEntitiesByFilter(UsersService),
);

class UsersComponent {
  readonly usersStore = inject(UsersStore);

  onSearch(filter: Filter) {
    this.usersStore.loadByFilter(filter);
  }
}

Anyway, feel free to suggest the signalStoreFeatureFactory implementation that would cover your case too!

[gabrielguerrero]

Hey @markostanimirovic , maybe if I explain why I want that will help , see this case:

export const Users3Store = signalStore(
  { providedIn: 'root' },
  withLoadEntities<User>(),
  withEntitiesRemoteFilter<User, { name?: string }>({
    defaultFilter: {},
  }),
  withEntitiesRemotePagination<User>({ pageSize: 5 }),
  withEntitiesRemoteSort<User>({ defaultSort: 'name' }),
  withLoadEntitiesEffect(({filter, entitiesPagedRequest, sort}) => from(inject(UsersService).getAll({
    filterName: filter()?.name,
    page: entitiesPagedRequest()?.page,
    pageSize: entitiesPagedRequest()?.pageSize,
    sortColumn: sort.column,
    sortDirection: sort.direction
    }))
);

I have these three custom features, withEntitiesRemoteFilter, withEntitiesRemotePagination, withEntitiesRemoteSort , they all add state and methods for filtering, paginating, and sorting, respectively; they are all optional so you could add one or all three or none; the withLoadEntitiesEffect should be able to use what's available; that's why I don't go with the withLoadEntitiesFilter way because the filter is optional I will need to do all the permutations which I don't think its nice DX, and it could be you need your own state like the departmentId which maybe is not part of the filter, this is the kind of thing that you can do with ngrx-traits, which is probably an advance use case I know , most people might not be doing that.

In terms of suggesting an implementation, I will create one for your latest code, but meanwhile, in case you want to check, I have a rough version of what I want based on the old version of your playground.
It uses the same technique you used in old version of signalStore to join features, I refactored the signalStore function to extract the function joinFeatures, which I used in signalStoreFeature (name of my old version of the signalStoreFeatureFactory)
https://github.com/gabrielguerrero/ngrx-signal-store-playground/blob/7abe4e066335fbbf5351678e693647a0c93dfc9d/src/lib/signal-store.ts#L849

then withLoadEntitiesEffect becomes
https://github.com/gabrielguerrero/ngrx-signal-store-playground/blob/7abe4e066335fbbf5351678e693647a0c93dfc9d/src/lib/features/entities/with-load-entities.ts#L92

notice I make the custom feature return a function so it can receive the input of previous custom features and when is called will execute signalStoreFeature(.......)(input)

That also solves the flattening issue you currently have because essentially signalStoreFeature is joining the store features internally when it is called.
Again thanks for paying attention to this. I think it will be a nice case to solve that will allow very powerful things to be built with signal store

[markostanimirovic]

I like the idea with signalStoreFeature! Compared to signalStoreFeatureFactory, it looks simpler and more intuitive to me! Something like this came to my mind:

export function withFeatureX() {
  return signalStoreFeature(
    {
      // specifying feature input
      input: {
        state: type<{ y: number }>(),
        signals: type<{ z: Signal<number> }>(),
      },
    },
    withState({ x: 0 }),
    withSignals(({ x, y, z }) => ({
      w: selectSignal(() => x() + y() + z()),
    })),
    withMethods(({ $update, x, y }) => ({
      increment() {
        $update({ x: x() + 1, y: y() + 1 });
      }
    }))
  );
}

[gabrielguerrero]

Thanks glad you liked it :), I liked the input idea ill give it a go, I already started doing the changes.

[gabrielguerrero]

Hey @markostanimirovic , below are the changes we chat before, but based on your latest code, it has the new signaStoreFeature, I also left the old signalStoreFeatureFactory but implemented it using the joinFeature, which solved the flattening issue it had and changed most of your examples and mine examples to use the new signaStoreFeature , but left and old version of the method so is easy to compare it, let me know if you like the implementation, and I'll do a PR to your playground, for that PR it will be just the new signaStoreFeature and remove the old signalStoreFeatureFactory method and Ill remove my examples/experiments as well, but let me know if you want me to leave some of them in.

The most important bit in the implementation is the refactored signal store again to extract a joinFeature method used in signalStore signaStoreFeature and signalStoreFeatureFactory; I marked it as internal so it doesn't get exported. You can see that here
https://github.com/gabrielguerrero/ngrx-signal-store-playground/blob/38a4d2cb41237d4b1940d0e3d5c756f18104a0ca/src/lib/signal-store.ts#L474C15-L474C15
And here is the implementation of the new signaStoreFeature. I manage to reuse some of the types of signalStoreFeatureFactory
https://github.com/gabrielguerrero/ngrx-signal-store-playground/blob/38a4d2cb41237d4b1940d0e3d5c756f18104a0ca/src/lib/signal-store-feature.ts#L308

In terms of the input param, I think I got it working as you wanted. It can be used like

signalStoreFeature(
    {
      input: {
        state: type<EntityState<Entity>>(),
        signals: type<{ setLoading: Signal<boolean> }>(),
      },
    },
    withState<{ filter: Filter }>({ filter: defaultFilter }),
    withMethods(({ $update, setLoading, filter }) => ({

Or another way which is a bit simpler to use I think, where the type function receives the entire SignalStoreFeature

signalStoreFeature(
    {
       input: type<{
         state: EntityState<Entity>;
         signals: { setLoading: Signal<boolean> };
      }>(),
    },
    withState<{ filter: Filter }>({ filter: defaultFilter }),
    withMethods(({ $update, setLoading, filter }) => ({

Or also not sure Im super happy with this, but I think it will avoid creating some complex types that are part of another customer store feature, you can pass directly the factory function of a custom feature store. It's only used to get its type.

signalStoreFeature(
    {
      input: withLoadEntities<Entity>(),
    },
    withState<{ filter: Filter }>({ filter: defaultFilter }),
    withMethods(({ $update, setLoading, filter }) => ({

So the input can receive the type in any of those three shapes. The last one has an extra benefit for the case with withLoadEntitiesEffect (the custom store feature that needs to use the previous features in its params) that it is easy to pass the inputFeature type to the signalStoreFeature , see the code here
https://github.com/gabrielguerrero/ngrx-signal-store-playground/blob/38a4d2cb41237d4b1940d0e3d5c756f18104a0ca/src/lib/features/entities/with-load-entities.ts#L68

Let me know what you think.

[juri-sinitson]

Thank you for the RFC!

In the current documentation of NGRX and also here I'm missing the example for a preloading of most frequently used data.

Use case:

1. I have one million users in the database and lets say 200 of them are most frequently used in the app.
2. I want to preload the most frequently used ones from the network.
3. If a user queried in the app is not found in the list of the preloaded ones, I want to make an additional network request.

Questions:

1. What's the most elegant way to solve this?
2. Would it be possible to put the solution to the documentation?

Confusions:

1. How to proceed the approach below exactly? Should I somehow add the find method to the selectedEntity property?
2. Is the RFC missing something or not obvious enough?

IMHO:
The most elegant way would be to (I'll stick with the example in the Playground for the sake of simplicity)

1. Preload them in the constructor of the user service:

  constructor() {
    this.usersPreloaded = [
      { id: 1, name: 'Alex' },
      { id: 2, name: 'Brandon' },
      { id: 3, name: 'Marko' },
    ];
  }

2. Add the method find to the user service like this:

  find(name: string): Observable<User | null> {
    return from(usersPreloaded).pipe(
      find((user: User): boolean => user.name === name),
      // Do the network request here if empty. No, search in usersMock
      // instead of course to stick with the current example of the playground
    );
  }

But now I'm confused how to proceed exactly, see the confusions above.

[markostanimirovic]

Hey everyone 👋

I've updated the prototype again. Changes this time:

• API for creating custom store features is changed: signalStoreFeatureFactory is replaced with the signalStoreFeature function:

Before:

export function withX() {
  // specify the feature input type if needed
  const xFeature = signalStoreFeatureFactory<{
    state: { y: number }
  }>();

  return xFeature(
    withState({ x: 0 }),
    withSignals(({ x, y }) => ({
      z: selectSignal(() => x() + y())
    }))
  );
}

After:

export function withX() {
  return signalStoreFeature(
    { state: type<{ y: number }>() }, // inspired by props<>()
    withState({ x: 0 }),
    withSignals(({ x, y }) => ({
      z: selectSignal(() => x() + y())
    }))
  );
}

Thanks @gabrielguerrero for this suggestion!

• The $state signal/internal is introduced. It provides the ability to listen to changes of the whole state where needed. For example:

export function withStorageSync(
  key: string,
  storageFactory = () => localStorage
) {
  return signalStoreFeature(
    withHooks({
      onInit({ $state, $update }) {
        const storage = storageFactory();

        const initialState = storage.getItem(key);
        if (initialState) {
          $update(JSON.parse(initialState));
        }

        effect(() => {
          const state = $state();
          storage.setItem(key, JSON.stringify(state));
        });
      },
    })
  );
}

• The rxEffect function is renamed to rxMethod for two reasons:
  • To avoid potential confusion with Angular's effect function. This API basically creates a reactive function/method and unlike effect, it doesn't watch/subscribe immediately when executed.
  • It also looks nicer when used within the withMethods feature.

type UsersState = { users: User[]; loading: boolean };

const UsersStore = signalStore(
  withState<UsersState>({ users: [], loading: false }),
  withMethods((store, usersService = inject(UsersService)) => ({
    loadUsers: rxMethod<void>(
      pipe(
        tap(() => store.$update({ loading: true })),
        exhaustMap(() => usersService.getAll()),
        tap((users) => store.$update({ users, loading: false }))
      )
    ),
  }))
);

@Component({
  template: `
    <h1>Users</h1>

    <p *ngIf="usersStore.loading()">Loading...</p>

    <ul>
      <li *ngFor="let user of usersStore.users()">
        {{ user }}
      </li>
    </ul>
  `
})
export class UsersComponent implements OnInit {
  readonly usersStore = inject(UsersStore);

  ngOnInit(): void {
    this.usersStore.loadUsers();
  }
}

[gabrielguerrero]

Hey @markostanimirovic, this is looking better and better thanks for taking some of my feedback :), I have some more feedback about the latest version, I love the new $state and the rxMethod name.

I think I liked it better when the inputFeature param is in an object as you suggested in another message,
just because the prop input name made it more obvious what it is for, plus its easier to add extra properties in the future if it was required for extra functionality

signalStoreFeature(
    {
        input: type<{ state: { entities: T[]; callState: CallState } }>(),
    },
    withMethods(({ $update }, entityService = inject(entityServiceClass)) => ({
// We can use `rxEffect` to create side effects by using RxJS APIs.

I still have a problem with the fact that signalStoreFeature returns an array of SignalStoreFeature instead of a SignalStoreFeatureFactory like withState , withMethods etc, just because it blocks the case of being able to use signalStoreFeature for custom features functions that, like withMethods or similar, need the previousFeature as a parameter.
One of the custom features I will like to implement is withCalls (don't confuse with withCallState), withCalls is similar to react-query given a fetch call, it will generate the necessary methods and signals for status and result of the call, and example

signalStore(
    { providedIn: 'root' },
    withState({ filter: {productId: string} }), 
    withCalls(({ filter }) => ({
            loadProductDetail: () => inject(ProductService).getProductDetail(filter.productId),
            loadBranchAvailabilityOfProduct: () => inject(BranchService).getProductAvailability(filter.productId),
        })),
);

That will generate signals loadProductDetailStatus, loadBranchAvailabilityOfProductStatus, used to track progress, signals loadProductDetailResult, loadBranchAvailabilityOfProductResult to store the result of the call , and methods loadProductDetail, loadBranchAvailabilityOfProduct that will call the fetch functions and set the signals status and result automatically.

The withCalls implementation can be done by combining withState, withSignals and withMethods , so it will be great use of signalStoreFeature, but to get access to the previousFeatures param, its implementation can not return an array of SignalStoreFeature, because like in withMethods it needs to return a SignalStoreFeatureFactory so the implementation can get access to the previousFeature param needed by callsFactory param, but the return of SignalStoreFeatureFactory is SignalStoreFeature not a SignalStoreFeature[] return by signalStoreFeature so the arrays needs to merge to one SignalStoreFeature, which is why in my implementation of signalStoreFeature (posted it in another message not sure if you manage to look at it ) it always returns a single SignalStoreFeature instead of an array by using the joinFeature function I mentioned in another message.

import {Observable} from "rxjs";

withCalls(callsFactory:(input: SignalStoreFeatureInput) => Record <string, (...args: any[]) => Promise<any>>
)
{
    return (previousFeature): SignalStoreFeature => {
        // ... logic that executes callsFactory(previousFeature) and returns SignalStoreFeature
    }
}

[Harpush]

A few questions I asked before but got lost here so I will ask again:

1. How about making rxMethod and tapResponse as a different package of utils as both are relevant to signal store and component store and are not strictly related to signals.
2. How can I add a feature twice? Say I have two call states in the same store.
3. Can $update enforce immutability as a runtime check too? Seems you must use immutability and a check can improve DX like in global store.
4. Are there thoughts of some adaptation of router store? Or router methods like rxRouterNavigatedMethod for example?
5. Will there be support for adding features as a list? So I have dynamic amount of call states features based on configuration (advanced usage)

[Harpush]

@markostanimirovic thanks for replying! Sounds good except a few points:
2. Isn't it a better idea to nest instead of generate dynamic name? I mean it will be easier to create a feature without knowing it can be used twice in a store. So the usage can be usersStore.load.status. that way you don't require every feature to build itself with supporting multiple instances in mind. Maybe something like { load: withRequestStatus() }.
4. Ideally I think signal store shouldn't require ngrx global store. I don't think it should save the router state but maybe wrap router events and state with signals until angular does so?
5. I meant truly dynamic. I get from server a list and for every item I want a filters feature state for example. Something that is not known at compile time. Like an entity of features.

Anyway many thanks for this RFC! Looking great!

[markostanimirovic]

Thanks!

2. Oh got it - { load: withRequestStatus } would allow the creation of nested "stores" within the SignalStore. This would be very hard to achieve in terms of strong typing and managing the state. For example, what if we want to add custom methods that update the state:

export function withRequestStatus() {
  return signalStoreFeature(
    withState<State>({ status: 'init' }),
    withMethods(({ $update }) => {
      setPending() {
        // this would update the status property that is added at the root state level
        $update({ status: 'pending' });
      }
    })
  );
}

const UsersStore = signalStore(withRequestStatus());
const FooStore = signalStore({ load: withRequestStatus() });

In the case of UsersStore, setPending should update the root state. In the case of FooStore, setPending should update the nested state. This would be the expected behavior, right? So, how can we "tell" the $update method to update the state differently based on the root/nested usage? Also, what if we want to update another root state slice within the nested feature? That won't be possible if $update points to the nested state in that case. Last but not least, how to provide strong typing for this behavior? 👀

---

Nested features would make sense IMO only if they provide state and signals, but not methods. On the other hand, we want to provide a generic and flexible API that supports all the cases. So, features that can be used multiple times within the store must be aware of that.

4. That is definitely possible and could be developed as a community plugin! :)
5. I'm not sure that I understand this. Can you provide the example (code) of what you want to achieve?

[Harpush]

@markostanimirovic
2. I guess you are correct it will be tough creating it type wise and generally. I think this is the tradeoff (or maybe we need both) between features as an integrated part of the main state (like this RFC) and features as mini stores which are disconnected from the main store. Such implementation as pseudo code:

interface CounterState {
  readonly count: number;
  readonly isLoading: boolean;
}

export interface CounterParams {
  readonly initialCount: number;
}

export class CounterStore implements OnDestroy {
  private readonly cancelGenerate$ = new Subject<void>();

  private readonly state = signal<CounterState>({
    count: this.params.initialCount,
    isLoading: false,
  });

  public readonly count = computed(() => this.state().count);
  public readonly isLoading = computed(() => this.state().isLoading);

  constructor(
    private readonly params: CounterParams,
    private readonly backendService: BackendService
  ) {}

  public readonly generate = createAsyncFn<void>(
    pipe(
      tap(() => this.updateIsLoading(true)),
      switchMap(() =>
        this.backendService.generateCount().pipe(
          tap({
            next: (count) => this.updateCount(count),
            error: () => console.log('Error!'),
            complete: () => this.updateIsLoading(false),
          }),
          takeUntil(this.cancelGenerate$)
        )
      )
    )
  );

  public cancelGeneration() {
    this.cancelGenerate$.next();
    this.updateIsLoading(false);
  }

  private updateIsLoading(isLoading: boolean) {
    this.state.update((state): CounterState => ({ ...state, isLoading }));
  }

  private updateCount(count: number) {
    this.state.update((state): CounterState => ({ ...state, count }));
  }
}

export const createCounterStore = createStoreCeationFn(
  CounterStore,
  (params: CounterParams) => [provideStoreParams(params), BackendService]
);

@Injectable()
export class PairCountersStore {
  public readonly counterOne = createCounterStore({ initialCount: 0 });
  public readonly counterTwo = createCounterStore({ initialCount: 0 });
}

The main difference (putting aside that's class based approach) is whether the features build the main state but abstract parts of it away - or are features actually a different entity.
5. If you take my above example of pair counters - think about a case where I need not only two counters known at compile time - but the ability to add and remove counters dynamically. Each being a full fledged feature rendered later with ngFor.

[abhijit-chikane]

getting this error
am I missing something? @markostanimirovic

[abhijit-chikane]

got it working by replaceing

withSignals => withComputed
selectSignal =>import { computed } from '@angular/core';

Anyways this is really cool😎
loving this feature
may be we should consider showcasing this in the ngrx/signals feature docs
Thanks @markostanimirovic

[jerryorta-dev]

I played around with creating a "signal component store" with the Entity Adaptor. I just want to provide a functional prototype of the current state of signals ( in preview ) integrating with current NgRx functionality to provide food for thought.

• Singals Entity Store
• Used in component
• A facade wrapping a global store with signals
• Demo site

[markostanimirovic]

You can use selectSignal instead of toSignal(store.select()):

-  todos: Signal<Todo[]> = toSignal(this.store.select(selectAllTodos), {
-    initialValue: []
-  });
+ todos = this.store.selectSignal(selectAllTodos);

[GuillaumeNury]

I played with the proposed code and it feels good: signal where we need it and RxJS where it excels!

• A first implementation with all I need in the same place
• An aggressive split into features

Two things that bugged me:

• you cannot use interfaces, you have to use types everywhere

  • when using interface in withState, it throws:

    interface PokeState {
      search: string;
    }
    
    export const PokeStore = signalStore(
      withState<PokeState>({ search: '' })
      // Throw error:
      // Type 'PokeState' does not satisfy the constraint 'Record<string, unknown>'.
      // Index signature is missing in type 'PokeState'.ts(2344)
    );

  • when using an interface inside the state, it is more subtile:

    interface PokemonCollection {
      count: number
      items: { id: number; name: string }[];
    }
    
    type PokeState = {
      collection: PokemonCollection;
    }
    
    export const PokeStore = signalStore(
      withState<PokeState>({ collection: { count: 0, items: [] } }),
    );
    
    @Component({
      selector: 'app-test',
      standalone: true,
      template: '',
      providers: [PokeStore],
    })
    export class TestComponent {
      #store = inject(PokeStore);
      public constructor() {
        console.log(`
          Works        : ${this.#store.collection().count}
          Does not work: ${this.#store.collection.count()}
        `);
      }
    }

    But it would have worked if PokemonCollection was a type.

• I cannot find a way of having private effects and private methods. Maybe I should stick to class, but it feels weird to mix functional and class. (ex: class PokeStore extends signalStore(...)).

I learned the difference between type and interface the hard way (more info in this Typescript issue):

type TypeEntity = {
  id: number;
  name: string;
}

interface InterfaceEntity {
  id: number;
  name: string;
}

type IsRecord<T> = T extends Record<string, unknown> ? true : false;

type TypeEntityIsRecord = IsRecord<TypeEntity>; // true
type InterfaceEntityIsRecord = IsRecord<InterfaceEntity>; // false

[sonphnt]

Hi, I still see a complexity of ngrx to work with it. Is it possible to have something like this store in VueJS with angular signal. https://pinia.vuejs.org/ .For me we dont really need all parts such as Action, Selector, Effect, Reducer. these things are unnecessary in my opinion

[fancyDevelopment]

Dynamic Data Structures

Tanks for your work.

In the meantime I also had some time to play around with the current state the implementation. Since I am a frind of using the power of dynamic data structures and since the the state has to extend Record<string, unkown> wich also expresses an object which can add and remove key over time, I wonder why the implementation of toDeepSignal only works for keys which are available at the moment the store was created.

I would be quite easy to adjust this in a way, that we can also create nested signals for keys which are added/removed at runtime. All we have to do is to get the current value of a signal within the proxy again. This way we can also create signals for key which are added after initialization of the store. A very easy solution for this could look like the following:

export function toDeepSignal<T>(signal: Signal<T>): DeepSignal<T> {
    const value = untracked(() => signal());
    if (!isRecord(value)) {
      return signal as DeepSignal<T>;
    }
  
    return new Proxy(signal, {
      get(target: any, prop) {
        // Get the value again to check against the current value not only against the value at the time the proxy was created !!!!!!!!
        const valueInner: any = untracked(() => signal());

        if (!(prop in valueInner)) {
          return target[prop];
        }
  
        if (!target[prop]) {
          target[prop] = selectSignal(() => target()[prop]);
        }
  
        return toDeepSignal(target[prop]);
      },
    });
  }

With this small modification we can ...

• ...utilize the full power of Record<string, unkown>
• ...create nested signals lazily for dynamically added keys
• ...use the signal state with dynamic data structures at all

I am looking forward to some feedback

[markostanimirovic]

I'm going to close this RFC because @ngrx/signals already landed. For any additional questions, feel free to open new discussions.

[rajanunagar]

if we are using signalstore in our angular applicatio for state management then how to use singal instace of signalstore in multiple components?

[e-oz]

See https://medium.com/@eugeniyoz/advanced-usage-of-angular-dependency-injection-399d0a67a938