RFC - NGXS Local/Component state

[markwhitfeld]

A recent improvement in Angular opens the door for us to be able to introduce a locally scoped state concept in NGXS.
The specific improvement that enables this is the inject function. This would allow a selector to be able to access a store in the context of a component.

If we provide a mechanism to specify one or many States that are provided in just one part of the component tree (and override the Store with a store that checks these local states before looking up the component tree), then we could have a locally scoped state(s).
The key of a State is actually just syntax sugar for how it might be rendered on an imaginary global state object, but this does not mean that this key cannot be available only for a specific part (or parts) of the component tree.

A few ideas are being bounced around on what this could look like.
We are seeking proposals of ideas from the community.

---

Initial Proposal

For the purpose of this example let's say that we have the following API for providing a state at the component level:

provideNgxsComponentState(states: StateClass[])

Here is an example usage:

import { Component, OnInit } from '@angular/core';
import { Store, provideNgxsComponentState } from '@ngxs/store';
// Example state, action and selector:
import { TodosState, LoadTodos, allTodos } from './todos.state';

@Component({
  selector: 'my-todos', 
  providers: [ provideNgxsComponentState([ TodosState ]) ]
  template: `
    <p *ngIf="todos$ as todos">Todo count: {{ todos.length }}</p>
  `,
})
export class TodosComponent implements OnInit {
  todos$ = this._store.select(allTodos);

  constructor(private _store: Store) { }

  ngOnInit() {
    this._store.dispatch(new LoadTodos("Personal"));
  }
}

Here are some details on how this Component State would be treated

• This would be used to provide state that is scoped to the current component and its children.
• This state is not accessible to a Store injected into a parent or sibling component. It is only accessible by a Store injected at this component or at any child component.
• If the same state is provided in another part of the application then these states would be independent and not have any affect on each other.
• If the same state is provided in a child component then the child component state would override this state for all selectors at the level of the child component and its descendants. The parent component state would still be accessible outside that child component.

How would actions be treated?

• All actions dispatched by any Store would be accessible by any state in the application, no matter if they are at a root, feature or component level. There are no "scoped" actions as a part of this proposal.
• In future we may need to investigate the option of scoping actions to a specific component, but this will need to be discussed an proposed in a separate RFC (if needed)

How would selectors be treated?

• Any store.select(...) at the level of this component or its children would have access to the component state.
• Any store.select(...) outside of this component or its children would not have access to the component state.
• The state class or token can be used when creating a selector and the selector has no special knowledge or scoping to a root, feature or component state at the time of creation. This is only resolved at runtime when queried through a Store instance.

Now that we have defined the basics of the way that this would behave, we need to define what this API would look like.
We have a few options here, and welcome additional proposals from the community.

Here are some options for consideration (this list may grow as other proposals are made):

Component state provider function naming

A provider function is used to declare and scope a State to the component

@Component({ 
  // ...  
  providers: [ provideNgxsComponentState([ TodosState ]) ]  
})

Within this option there are a few options for names:

1. provideNgxsComponentState(states: StateClass[])
2. or plural provideNgxsComponentStates(states: StateClass[])
3. provideNgxsLocalState(states: StateClass[])
4. or plural provideNgxsLocalStates(states: StateClass[])

Alternative - Scope isolation concept

The idea here is that at the component level, an isolated scope can be declared, resulting in all states added at this component or below to be isolated from the parent store scope. NOTE: This concept in itself could be its own RFC, but this is just a seeding of the idea and how it could relate to component level state.

There are a few options for how this could be defined:

1. Provide the isolated scope and the states together

@Component({ 
  // ...  
  providers: [ 
    provideNgxsScope([ TodoState ]),
  ]  
})

2. Provide the isolated scope and the states separately

@Component({ 
  // ...  
  providers: [ 
    provideNgxsScope(),
    provideNgxsStates([ TodoState ]),
  ]  
})

5. Provide the isolated scope and then provide the states as the State classes directly

@Component({ 
  // ...  
  providers: [ 
    provideNgxsScope(),
    TodoState,
  ]  
})

There are actually a number of ways that this idea can extend. For example:

• We could provide a way to "Name" a scope and a way to set applicable scopes for States and Actions. This could allow for isolation of Actions and corresponding States.
  • Actions could be scoped using some sort of scopes Symbol in their definition (or through a ScopedAction base class).
    • This could allow for a pattern like: store.dispatch([ new LoadTodos("MyScope") ])
  • or Actions could be scoped at the point of dispatch store.dispatch("MyScope", [new LoadTodos()] )

The ideas with this could go on and on, but we would need to decide if this would belong in the core library, what level of complexity it adds, and what the specific use cases are.

---

If you would like to submit your own proposal

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.

[profanis]

By reading the RFC and by trying to further understand that, I tried to answer these questions:

• Why should I use a local state?
  I would go with this approach to completely replace the "service with a subject" pattern

• Can I query the global states
  Why not!

If these answers are correct, how about having an API something like this:

@Component({
  selector: 'my-todos', 
  providers: [TodosState],
  ...
})
export class TodosComponent implements OnInit {
  // The todosState should be responsible to query the `todos`
  todos$ = this._todosState.todos$;

  constructor(private _todosState: TodosState, private _store: Store) { 
     // I would use the _store to interact with the global state
  }

  ngOnInit() {
    // The `todosState` should load the `todos` and update the local state as well. 
    this._todosState.loadTodos('Personal');
  }
}

I feel that the API todos$ = this._store.select(allTodos) or this._store.dispatch(new LoadTodos("Personal")) is not prominent that the interaction will happen with the local state, and in the long term, a component that uses both the global state and local state could become harder to maintain.

[markwhitfeld]

The idea here is that you would interact with your state using the exact same mechanisms that you would normally do for a global state in NGXS. Following the command query separation that is prevalent for interacting with other NGXS states in the app.
This RFC is about how we would specify that a state is scoped or localised to a particular branch of the component tree. The intention here is not to create a new state interaction paradigm within the same library (That is why a service-based approach would be implemented in a separate library with its own API and conventions 😉 )

[dmitry-stepanenko]

I agree with @profanis on this one, having local and global states mixed under the same API appears to be confusing. I'd rather have a separate service instance, that is completely isolated from the rest of the app. If this requires a certain amount of reusable logic, we can present a base class that services can extend. I my opinion, the concept that should work well is something similar to ngrx's component store.

[profanis]

Based on my comment above, I created this stackblitz where it has more or less the same code. Please note that this is a Typescript and not an Angular project. The purpose of that is to share a suggestion.

Let me know what you think

[joaqcid]

i like the provide states approach

provideNgxsComponentStates()

regarding scope, although is a nice idea i think might be a bit too much overhead for a developer to use it,

my unanswered question here are:

• can i provide the same State in a component and a feature?
• in the case of siblings components, when dispatching an action, would both siblings react to that dispatch?

[va-stefanek]

Without scoped actions we would reload all of the "local state" instances Todos by dispatching this._store.dispatch(new LoadTodos("Personal")); - if that is the true than I don't know whether we can consider it somehow local. It's local use case is for read only purpose in more expanded use cases (multiple instances in one time). Maybe that should create isolated instance of the store with that specific slice for that dedicated provider?

If I understand something wrong - I am sorry 👍

[koo9]

This lib (https://github.com/microsoft/redux-micro-frontend) has the notion of global state and isolation that play nicely for MFE, wonder if the idea can be ported over.

[dhutaryan]

Hello, I have some ideas about this feature.

• Why should I use a local state?
  Some time ago I wanted to use component with store. This component was the same for a few pages. There was only one difference - api call. I used injection token and provided a new service for each module. But it didn't work because state is singleton. I have even example https://stackblitz.com/edit/ngxs-inject-service 🙂

So, what about if we will use @ComponentState to create a new state? We will use a usual state or component state.

@ComponentState<string[]>({
  name: 'animals',
  defaults: []
})
@Injectable()
export class AnimalsState {}

I reckon it might be better solution because:

• we won't depend on current functionality (not sure)
• we cannot use component state as globals
• we will be able to provide it on component level only.
• we don't care (or almost) about backwards compatibility because it will be a new feature

I like this options more:

@Component({ 
  // ...  
  providers: [ ngxsComponentState([ TodosState ]) ]  
})

or even better

@Component({ 
  // ...  
  providers: [ TodosState ]  
})