Lazy Loading Store into a standalone component.

[necronflux101]

Currently the documentation on Lazy Loading (v3.8.2) describes the process for Lazy Loaded modules:

@NgModule({
  imports: [NgxsModule.forFeature([LazyState])]
})
export class LazyModule {}

I am looking for something similar for a lazy loaded standalone component (Angular V17), because currently if i do something like this

@Component({
  selector: 'test',
  templateUrl: './test.component.html',
  styleUrls: ['./test.component.scss'],
  standalone: true,
  imports: [
    CommonModule,
    NgxsModule.forFeature([LazyState])
  ],
})

I get the error:

Type 'ModuleWithProviders<NgxsFeatureModule>' is not assignable to type 'readonly any[] | Type<any>'

Component imports contains a ModuleWithProviders value, likely the result of a 'Module.forRoot()'-style call. 

These calls are not used to configure components and are not valid in standalone component imports - consider importing them in the application bootstrap instead.(-992012)

Is there a way to achieve this, without adding the same state to the NgxsModule.forRoot ? This is for a component that needs access to the global store but is dynamically created with createComponent

[hakimio]

It doesn't seem to be possible now. Theoretically getFeatureProviders() could be used for this but it's neither exported for public use, nor any of the standalone features like provideStore are released yet.
Maybe @arturovt could tell us how this could be tackled in the near future.

[arturovt]

The provideStore and provideStates (standalone features available under the dev version) will also not allow providing states on components since they return environment providers. That would be possible to use on the ApplicationConfig when bootstrapping the app and Route providers.

In your case, you can have a separate module that imports the NGXS feature module, and then you import this module into the component:

@NgModule({
  imports: [NgxsModule.forFeature([LazyState])]
})
export class LazyModule {}

@Component({
  selector: 'test',
  templateUrl: './test.component.html',
  styleUrls: ['./test.component.scss'],
  standalone: true,
  imports: [
    CommonModule,
    LazyModule // <----- not `NgxsModule.forFeature`
  ],
})

[necronflux101]

Oh I think this could work for now.

In future releases, is provideStore meant to help with this ?

[arturovt]

No, provideStore is meant to replace the NgxsModule.forRoot as thus you can do the following:

bootstrapApplication(AppComponent, {
  providers: [ provideStore(....) ]
})

// instead of
bootstrapApplication(AppComponent, {
  providers: [ importProvidersFrom( NgxsModule.forRoot(...) ) ]
})

[arturovt]

In one of my apps, we still use the approach of importing a module into components that have NgxsModule.forFeature. For example, consider a data-access type Nx library called @my-library/data-access-search-assistant, which includes states, actions, and selectors. In this scenario, you would globally expose a module:

@NgModule({
  imports: [NgxsModule.forFeature([SearchAssistantState])],
})
export class SearchAssistantDataAccessModule {}

And then we do in components:

imports: [ SearchAssistantDataAccessModule ]

This can be also done multiple times if this state is required in different places since NGXS states are not duplicated even if you call forFeature with the same state many times.

[arturovt]

We considered providing states on components. However, this would entail having a local state at the component level rather than a global one. There is no technical option to provide global states at the component level, as we need to register those states within the global "states registry.". Additionally, when there's anything in the component providers: [], they are eagerly initialized only when something is "injected". Environment providers allow for registering global states due to the ENVIRONMENT_INITIALIZER feature, as Angular calls it. Therefore, we register the state globally before the app is bootstrapped or the route is navigated.

[hakimio]

Would be nice to have local component state as well. I know that there is a RFC for that, but still just wondering: is it a big task to add this functionality and do you have any approximate timeline for when it might be added?

[arturovt]

We already have a Proof of Concept (PoC) implementation for the local state that is framework agnostic. It can be used with any state management system or implementation. However, progress on this project is dependent on our availability, as those of us working on the local state are primarily busy with our regular jobs. Open source contributions, including this project, often take a backseat as they are pursued alongside our regular jobs. Every time we discuss the local state, its release gets postponed due to someone becoming busy at that moment. Unfortunately, this is the reality of open source development.