RFC - Signals in NGXS

[markwhitfeld]

A few ideas are being bounced around on what this could look like.
We are seeking proposals of ideas from the community.
Please create an 'Answer' to this discussion with your proposal which can then be discussed in the thread for it.

Please ensure that it clearly states the following aspects of your proposal:

• What are the changes to the public API?
• What are the advantages?
• What are the potential drawbacks?
• How would backwards compatibility be considered (and if it introduces a breaking change)?

Please also take the time to look at other proposals and engage in respectful discussion.
We will consider every proposal. Please do not be offended if yours is not accepted.
We want to keep the core of NGXS as simple and maintainable as possible, and sometimes bigger ideas are better as plugins.

---

I would like to mention that observables and signals are not mutually exclusive.
They each have their strengths and weaknesses.

Some points on Signals

• They are a fantastic way to communicate the current value of some state to the view and to keep it synchronised with the view.
• They do not require explicit subscription or unsubscription.
• They are specifically optimised for communicating changes to the view.
• They are not a good "state container":
  • Value changes to Signals are naturally "debounced" by the way that they are bound to the change detection cycle.
  • Changes made before the next change detection cycle are essentially "batched" together and you only get the most recent state.
  • If you are interested in seeing every small change made to the state in order to execute business logic then Signals are not a good fit.
    • Observables are better for this use case.

Some points on Observables:

• They are great as a declarative pipeline for receiving a curated stream of updates from the state.
• They are more difficult to teach and understand.
• The conceptual model of a "stream of updates" is hard to master because it requires a paradigm shift in the way that a developer views data. It can often lead to unnecessary complexity and hard-to-debug problems.
• In my view, only 10% of state problems are made simpler by RxJs and the other 90% can more elegantly and maintainably be solved without RxJs.
  • We would not want to lose the power offered by RxJs for that 10% of state problems, so we should not abandon it entirely as a reactive API.
• The paradigm mismatch between Observables and the view has been something that has been an ongoing issue to solve in angular.
  • The async pipe is often used to make this simpler
  • When data outside of the observable needs to be combined with data from an observable, this can lead to tricky state synchronisation issues or overly complex data synchronisation logic.
  • Signals were introduced as a simple solution to this problem

Part of the intention with this RFC is to define what these APIs look like, and how they can seamlessly co-exist and intuitively lead the developer to success for each use case.

---

Initial Proposal

Over the past few months, we have been working closely with the Angular team, giving feedback and driving the Signals API to be a useful, and well-thought-out addition to Angular. This has been part of an internal working group with other open-source authors (NgRx, RXAngularm and others) and we have had great discussions as part of this process.

So now, to add my thoughts on what the API for signals could look like...

There are a few prospective API surfaces to cover.

1. Accessing the state through an injected property initializer/constructor (similar to the signal, computed, etc. APIs exposed in Angular)
2. Accessing the state through an instance of the Store (eg. store.select(...) )
3. Decorated class properties (ie. the @Select decorator).
   • These APIs will be DEPRECATED in v4 and will not form part of the Signals API proposal
   • Typescript Decorators lack the ability to define or infer types for the field that they decorate and therefore do not promote good type safety. Hence the drive to deprecate them.
   • The new API proposed in this RFC will form part of the recommendation for migrating existing code from the @Select decorators.

As mentioned above the 3rd API will be deprecated and will not form part of this discussion, so let's look at the first 2.

1) Property Initializer API

• This type of API is the primary way that signals are surfaced by Angular and definitely falls directly in line with the newer developer ergonomics for Views in Angular.
• We would want to expose this as our first-class Signals API in NGXS.
• An intuitive, descriptive and sort name for this API would be best.

The ideal API signature here would be:

function select<T>(selector: NgxsSelector<T>) : Signal<T>

And the usage in a component would look like the following:

import { select } from '@ngxs/store';
import { allTodos } from './todo.selectors.ts';

@Component({
  selector: 'my-app',  
  template: `
    <p>Todo count: {{ todos().length }}</p>
  `,
})
export class App {
  todos = select(allTodos);
}

In my mind, this would be the ideal, but there are some points for consideration:

• select(...) would return a Signal, but store.select(...) would return an observable.
  • Is this potentially confusing for a developer because they have the same name?
• Potentially there is a clear enough difference in the API with respect to how and where they are called and our messaging would be:
  • "If you initialise a property in a view then you should use a Signal and if you are accessing through the Store then you are doing something more custom (and not view specific) and you would get an Observable"

If we provide this sort of property initializer for Signals, then should we also create one for Observables?

• If this did exist, it would be a "drop-in" replacement for the @Select decorator.
• It could also use the DestroyRef from Angular 16 to automatically unsubscribe when the service or component is destroyed.
• This could be select$(...), where the $ on the end mirrors the convention of observable properties. For example:

todos$ = select$(allTodos)

Alternatives

Let's look at this API vs some alternative namings. It would be great if any commenters on this mentioned their thoughts on these:

Option	Signal	Observable	Motivation
A	select(MySelector)	select$(MySelector)	Short and signals-first approach
B	selectSignal(MySelector)	select(MySelector)	Least disruptive and potentially mirrors store. Possibly an "Observables-first" approach in the view, which could lead developers in the wrong direction
C	toSignal(MySelector)	toObservable(MySelector)	Aligns with but potentially conflicts with interop from @angular/core/rxjs-interop
D	select(MySelector)	this.store.select(MySelector)	Initializer only available for Signals. Store used for Observables.
E	select(MySelector)	select(MySelector)	Same function for both. Returns an NgxsSignal that supports both the Signal and Observable APIs. Some conceptual reservations here, but if there is interest in what this would look like, then I can add another proposal comment to the RFC.
F	select(MySelector)	select(MySelector, { observable: true })	Change in return type implied by the option supplied
G	select(MySelector)	selectObservable(MySelector)	(no comment)
H	selectSignal(MySelector)	select$(MySelector)	(no comment)
I	selectSignal(MySelector)	selectObservable(MySelector)	(no comment)

2) Store instance API

Depending on the property initializer chosen above, we would need to decide how the store instance API needs to grow or evolve.

Currently store.select(MySelector) returns an Observable.

There are a few options with what we do:

1. The store API remains the Observable-first API and does not receive any signals based functions.
   • 🤔This could encourage developers to use this API in more application-logic type scenarios and to use the property initializer for views? The assumption here is that a developer might be surprised by the lack of a Signal based function and would then need to learn the difference between when each are ideally used... forced developer education 😉 .
2. We add a new Signals specific function to the store: store.selectSignal(MySelector)
   • PS. This is the approach and naming that NgRx used. While our decisions shouldn't be guided by another library, it is worth mentioning because the large familiarity that developers have with NgRx could benefit developers as they move between NgRx and NGXS based projects.
3. We look to migrating store.select to be the Signal based API by some point in the future.
   • This would require that we deprecate store.select in the interim and create a new Observable based function like store.select$(MySelector). Then at some point in the future, we reintroduce the store.select(MySelector) function as a signal based API.
   • PS. I think that this is WAY too disruptive for a slight semantic gain.

My preference is option 2.2 here.

[hmica]

Hi,
Nice proposal!
I like option A or F
Thanks again for all you amazing work

[dmitry-stepanenko]

In my opinion, it should be the best to keep same names for both APIs. This will be intuitive and won't lead to any confusion if both are used across the app. Thus I'd be against having signal-based select and observable-based store.select.

The cleanest solution is to add selectSignal method both for the Store and property initializer API along with exposing select that mimics the store.select method. We can consider select$, but again, it feels better to have consistent names.

Going with option 2.3 by deprecating store.select in favour of store.select$ does not seem reasonable to me because:

• it's a big breaking change indeed without significant gains
• it will also require us to have store.selectSignal for the transition, that will be deprecated later once we are able to reintroduce store.select that returns signals

[Carniatto]

Thanks for the great proposal Mark.

In my opinion, it is best to introduce signals explicitly like shown on the solution 2.2
This sounds better to me, since the adoption of signals might be gradual and will take some time to become the standard usage.

In a future release we can, maybe with the help of a migration script, do a API change to make it cleaner.

[homj]

Great to see signals coming to NGXS!
And thanks for this RFC, to let us collaborate on how this integration will look.

1) Property Initializer API

I really like Option A, F and G. I think signals are the right way to go in the future and there's no current select-function for observables that this would collide with. So for a signal-first approach, select should return a signal.

I'm not yet sure which of those three options I prefer for observables though. I know and understand the $ suffix well, but to other developers, especially juniors, this could be confusing. Both F and G have the benefit to be substantially longer to write than the signal counterpart. And yes, to me that's a benefit, since it discourages the use of observables.

Another proposal: Composables

I've only recently come across the pattern of composables, used e.g. in Vue. They're a design-pattern that lets us add ("compose") functionality to e.g. components with simple function calls. They have a common naming pattern: the function-name is prefixed with use. You could think of a composable that lets us read and write the title of a browser tab. This could be called useTitle and return a signal that allows us to interact with the browser title.

Similarly, instead of a select-method, a composable for selecting NGXS state could be called useState or useSelect.

2) Store instance API

Option 2 seems like the obvious option right now, but in the long run, I think this store.select should return a signal.

Have you considered something like 1) F here? So adding a second argument, where we have to explicitly specify that we want an observable:

store.select(MySelector); // returns a signal
store.select(MySelector, { observable: true }); // returns an observable

After all, it would be best to keep both API's similar.

Further thoughts

Are there any plans to add signal support to other parts of NGXS yet? Like dispatching actions, receiving a stream of actions, or even deeper support for signals in selectors

[markwhitfeld]

Thank you so much for your thoughts. Interesting idea with the composables naming. It might just be not as familiar for Angular devs though.
With respect to integrating signals is for the actions stream, I'm not sure what the use case would be there. Potentially an observable is the best there? What do you think?
What were you thinking regarding the dispatching of actions?
For deeper support in selectors, it is not necessary to do anything more there because selectors are already optimised and are fundamentally the same as calculated signals in the way that they are only calculated when they are read. Selectors also have a further advantage due to the immutable nature of the states that we have in NGXS. The select property initialiser would give you everything you need.

[homj]

First of all, sorry for taking so long to reply. I had it on my list, but couldn't really find time to get back to you.

I agree that the composables naming is not something you'd be familiar with from Angular. But signals in general are a new thing, right? So I think that'd make it easier to also introduce a naming that other frameworks with signal-like APIs use.

And with further thought I agree on your point regarding actions as well. I think they're better off with observables.
I didn't have a fleshed out idea on that topic yet, I just wanted to throw it into the discussion and though we could explore use cases of signals in that regard as well. But in hindsight I think signals would not be beneficial for actions.

Regarding selectors, the similarity of current selectors in NGXS and signals makes me question whether we still need the current selectors in a signal based future. I'm lacking a deep understanding of them like you, but maybe replacing them with signals is feasible and could reduce some complexity and cost in maintaining a custom implementation

[va-stefanek]

@markwhitfeld For me option E seems interesting. Can you explain your concerns regarding that one a little bit? Is there a possibility that we could use single property (created from select(MySelector)) to play with it as observable and as signal based on our needs?

[dinbtechit]

My vote is for option E (🎯). It looks clean! Ofcourse it would be nice to know the conceptual reservations there.

[luishcastroc]

I think option A aligns better with the kind of intuitive separation Angular wants between observables and signals.

[estrellajm]

I like option A as it maintains a separation, but I also like option F.

@markwhitfeld, where are you expecting this to be released?

[vslipchenko]

According to this article Episode 23/26: New Control Flow, Angular 17, AnalogJS, "Developer Preview" signal-based components will be available as a developer preview in Angular 17.
So not earlier than that I assume. Also, it may take some time to adopt those new changes.

[manikoli]

Hi there! I'm curious if there are any recent updates or specific plans for the future? It would be great to get some insights into what's coming next. Thanks!

[markwhitfeld]

After much discussion, we have found that there were some topics that were difficult to come to a consensus on and therefore we will take a smaller incremental approach that adds the definites that were easy to agree on.

These are is the initial proposed API additions for signals:

• Add store.selectSignal which is the signal equivalent of store.select
  • This matches the chosen API naming found in NgRx, so matching this will make transition and learning easier for devs.
  • The return type is clear from the function name and it is discoverable.
• Add only one property initializer: selectSignal
  • This name is nice and explicit
  • If a team wants to use a cleaner name like select then they can export an alias of it from a utility in that team's own codebase.
  • We are not adding a property initialiser for observables because
    • the Property Initialisers should be used in component or view specific code and we want to promote signals over observables there
    • the naming of an observable returning property initialiser was not clear (too many options and trade-offs)
    • users that want to use observables should just reach for store.select(...), which is available and familiar anyway.
      • The equivalent initialiser code for an observable would be Inject(Store).select(...), which anyone can write if they really want it.

PS. The topics that are difficult to come to a consensus on, due to the vast array of Angular user views that may exist:

• The naming of an observable returning property initialiser: select$, selectObservable
• What a property initialiser called select should return. Should it match the store API, or should it promote a signals-first approach?
• Deprecating store.select in order to eventually replace it with a signals equivalent. This also had the issue of what we should name its replacement for selector observables on the store API.

[mchlroy]

What about having different import paths. It seems like we want to guide devs to use the signal first approach. In that case we could have an import that uses the legacy Store / select (observable first). In that case, the breaking change that would be introduced would simply be to change the import paths (a "find all and replace").

import { Store, select } from '@ngxs/store'; // signal first
import { Store as ObservableStore, select as selectObservable } from '@ngxs/store/observable'; // observable first

[Applicafroguy]

F or G. But I think F is good for me.