To be able to lazy-load sub states at runtime

[artbat]

Description

Currently we can lazy-load "root" states at runtime and we can add sub-states at compile time, but we can't lazy-load sub-states at runtime.

Describe the problem you are trying to solve

We might design a store graph for a set of applications (micro frontends or separate SPAs that might eventually become MFs) where each one would manage only a given graph subset if loaded.

In order to avoid MFs collisions and to reduce cognitive load, it'd be very convenient to design the applications graph and the Store's graph in parallel:

// States tree

global
├─ insurance
│  ├─ global-position
│  ├─ motor
│  │  ├─ policy
│  │  ├─ receipts
│  │  ├─ claims
│  ├─ life
│  │  ├─ policy
│  │  ├─ receipts
├─ finance
   ├─ stocks
   ├─ pension-plans

// Apps tree

Home (SPA, managing 'global' state)
├─ Insurance (Lazy Route managing global.insurance & global.insurance.global-position)
│  ├─ Cars/Bikes insurance (MF managing global.insurance.motor.*)
│  ├─ Life insurance (MF managing global.insurance.life.*)
├─ Financial Assets (Lazy Route managing global.finance)
   ├─ Stocks (MF managing global.finance.stocks.*)
   ├─ Pensions (MF managing global.finance.pensions.*)

But this isn't possible currently, as we can only lazy load "root" states. When loading the "Cars & Bikes Insurance" and "Life Insurance" MFs, the store graph would be, at best:

global
├─ insurance
│  ├─ global-position
├─ finance
motor
├─ policy
├─ receipts
├─ claims
life
├─ policy
├─ receipts

Describe the solution you'd like

When registering a lazy-loaded state, to be able to provide a parent state, in order to become its sub state.

Option 1

• In the NgxsModule.forFeature() (or provideStates() standalone function) we might provide the parent's state reference.
• Please note it can't be the parent's state class, that most likely will be unknown for a lazy-loaded MF.
• As state ids are not unique, a state path might be also provided (the sources show that there would be already utilities to manage the state graph in such a way)
• Should the parent state not to be found, it would be registered as new "root" child state, just like now.

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

// The lazy-loaded mammals.module.ts
@NgModule({
  imports: [NgxsModule.forFeature([{state: MammalsState, parent: 'animals'}])]
})
export class MammalsModule {}

@State<string[]>({
  name: 'mammals',
  defaults: []
})
@Injectable()
export class MammalsState {}

Option 2

• To add a parent property to the State decorator options.
• When lazy loaded the State with NgxsModule.forFeature() it would be registered as sub state.
• A path of ids might also be provided, as state ids are not unique keys.

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

// The lazy-loaded mammals.module.ts
@NgModule({
  imports: [NgxsModule.forFeature([MammalsState])]
})
export class MammalsModule {}

@State<string[]>({
  name: 'mammals',
  defaults: [],
  parent: 'animals'
})
@Injectable()
export class MammalsState {}

[Akshat111111]

There are also some other options too like Dynamically loading of parent state, Dependency injections and state path resolution.

[artbat]

Thanks for clue, but could you please elaborate on that a little bit further?

The forFeature() module method (or provideStates() standalone function) seems the only way to lazyload substates and it only admits an array of State classes, adding them to the store's root. I fail to see another way to add them as children of an existing state.

[Akshat111111]

My proposed approach is that in order to achieve the hierarchical structure, you can do by defining an initial state object for the parent state
And this will include the properties for lazy loading states (userprofile,usersettings etc)

[artbat]

But future children states can't be know at the present. For a truly extendable system based on a single store and using micro frontends it's necessary to be able to extend the original schema at runtime.