Support angular signals

[zip-fa]

Which @ngneat/elf-* package(s) are relevant/releated to the feature request?

store

Description

Recently, angular team announced new reactive primitive - signal. Is there any chances you could integrate them in your library?

Proposed solution

Alternatives considered

Do you want to create a pull request?

No

[LoaderB0T]

Signals seem to be the next major state mechanic in Angular, it would be great to have "native" support in elf.

[NetanelBasal]

What do you expect to see?

[pmartijena]

Maybe some way to create a signal store rather than an observable based store? I believe Ngrx has a RFC open doing something similar.

Would love to hear some thoughts regarding this.

[zip-fa]

What do you expect to see?

Full signal store instead of observable one

[NetanelBasal]

TBH, I don't know if we could do this. This library is framework agnostic.

[zip-fa]

What about making separate library like:
ngneat/signalo
ngneat/elf-angular

etc

[NetanelBasal]

I don't have time for this. If someone wants to do it, it'll be great.

[zip-fa]

But if we sponsor this?🤔

[NetanelBasal]

This library is based on observables and operators. We can't do what you suggest. The ngrx team created a new library. It's writing it from scratch or using the toSignal function.

[pmartijena]

Got it. Thanks for the explanation

[zip-fa]

Which library? Can you give us a link?

[NetanelBasal]

There is an RFC somewhere. You can search for it.

[hakimio]

https://github.com/markostanimirovic/ngrx-signal-store-playground
ngrx/platform#3796

[tegola]

EDIT: ↓ update in my reply below ↓

---

This is an easy fix: just convert the store state to a signal and build computed properties from there. See the example below: in my case, I'm using the repository pattern using an OOP approach:

import { toSignal } from '@angular/core/rxjs-interop';
import { createStore, withProps, select } from '@ngneat/elf';

type User {
  name: string;
};

type AuthProps = {
  token: string;
  user: User;
};

const store = createStore(
  { name: 'auth' },
  withProps<AuthProps>({
    token: '',
    user: null,
  }),
);

export class FieldsRepository {
  // convert the main observable to a signal
  private state = toSignal(store.pipe(select((state) => state)));

  // use computed values instead of rxjs's pipes
  token = computed(() => this.state().token);
  user = computed(() => this.state().user);

  // typical setters, no differences here
  setToken(token: AuthProps['token']) {
    store.update(setProp('token', token));
  }
  setUser(user: AuthProps['user']) {
    store.update(setProp('user', user));
  }
}

[tegola]

After a bit of testing, I realized my solution wasn't perfect. The computed() values would fire very often since the main state object was always getting a new reference, because setProp works with immutable objects.

In my example above, using setToken('value') would trigger both the token and the user values.

The updated solution (below) fixes this issue by using toSignal for every state property.

import { toSignal } from '@angular/core/rxjs-interop';
import { createStore, withProps, select } from '@ngneat/elf';

type User {
  name: string;
};

type AuthProps = {
  token: string;
  user: User;
};

const store = createStore(
  { name: 'auth' },
  withProps<AuthProps>({
    token: '',
    user: null,
  }),
);

export class FieldsRepository {
  // create signals for each state property
  token = toSignal(store.pipe(select((state) => state.token)));
  user = toSignal(store.pipe(select((state) => state.user)));

  // you can still use computed()
  userName = computed(() => this.user().name);

  // typical setters, no differences here
  setToken(token: AuthProps['token']) {
    store.update(setProp('token', token));
  }
  setUser(user: AuthProps['user']) {
    store.update(setProp('user', user));
  }
}

[NetanelBasal]

Please note that a drawback of this approach is that subscriptions are created eagerly. Moreover, if the store is injected at the root level, this subscription will remain active indefinitely.

[tegola]

Correct. I don't know the memory footprint for larger applications, but in my case (5/6 lazy-loaded modules containing 1/2 root-injected store and service each) memory usage stayed the same.