ngrx storemodule.forRoot not in app.module pattern

[momoadeli]

I have a question on #ngrx strategy regarding module federation. Although not publicized we can have StoreModule.forRoot defined in a module other than app module. See example:

https://stackblitz.com/edit/moadeli-ngrx-lzy-nonroot?file=src/app/app.component.ts

In other words, the notion of 'global store' is relative to where StoreModule.forRoot is declared in other.module.ts (lazy.module.ts here).

This way every sibling federated module inside a parent federated container (no store) has its own singular forRoot which keeps the federated container decoupled.

It seems this pattern (multiple roots at sibling module levels) isn't as publicized as the notion of features at each lazy module. Given in module federation the remote module is an application in itself, is this a prescribed pattern to follow to entirely decouple federated modules and have each with their own separate root store?

[kuldeepGDI]

I am curious for an answer to this question because after updating to NgRx 15 and Angular 15 this pattern breaks ! What works now is this solution here . Could this have been the reason of this behaviour not working anymore ?

[momoadeli]

Not necessary. Treat the federated module (FM) as a feature just like a regular module. Your FM can run as a store feature either under the main app forRoot global store or the dummy shell app forRoot global store. You don’t have to do anything special normally for your global store(s) under a federated context.

…

On Mon, Aug 28, 2023 at 4:30 AM kuldeepGDI ***@***.***> wrote: I am curious for an answer to this question because after updating to NgRx 15 and Angular 15 it does not work anymore ! — Reply to this email directly, view it on GitHub <#3193 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4I3DZNVBVWKXP2L3WEBQLXXRJLNANCNFSM5GJK4EPA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[kuldeepGDI]

What i meant is that earlier with Angular 13 and MF 14, we used StoreModule.forRoot in Module federated component as we did not want to expose ngrx store dependencies to shell UI. However, now with angular 15 the only solution that works is that we are now moving StoreModule.forRoot({}) inside the shell app module and then it works fine. We now use forFeature for effects and store in our module federated components while main app also uses forRoot in its own app module. Whereas earlier with angular 13, we did not need to share dependencies with shell UI and therefore no forRoot required in shell UI.

So, if i understood right the recommended practice is to indeed have forRoot({}) in the shell UI ?

[momoadeli]

Yes, if I understand you correctly. The FM runs under a fake shell app during development and subsequently under the main real shell during test and rollout. In either case the FM is a feature. In Botha cases the two shells are forRoot s. At the end, the FM behaves AND IS no different than a normal Angular NgModule.

…

On Mon, Aug 28, 2023 at 5:46 AM kuldeepGDI ***@***.***> wrote: What i meant is that earlier with Angular 13 and MF 14, we used StoreModule.forRoot in Module federated component as we did not want to expose ngrx store dependencies to shell UI. However, now with angular 15 the only solution that works is that we are now moving StoreModule.forRoot({}) inside the shell app module and then it works fine. We now use forFeature for effects and store in our module federated components while main app also uses forRoot in its own app module. Whereas earlier with angular 13, we did not need to share dependencies with shell UI and therefore no forRoot required in shell UI. So, if i understood right the recommended practice is to indeed have forRoot({}) in the shell UI ? — Reply to this email directly, view it on GitHub <#3193 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4I3D7EYERSNLTHTYYB5ELXXRSJDANCNFSM5GJK4EPA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[kuldeepGDI]

SO far we have been running individual hosted UIs on k8s that have some components but lets say they also expose modules via module federation plugin to a shell UI. THe shell UI basically can load any such MFEs. So far only one hosted UI is using ngrx store, so we did not share the store dependencies with shell UI. So we had StoreModule.forRoot({}) in our module federated component which is actually hosted on k8s on its own container (serving some other components that are not exposed to shell). This setup was working fine so far until angular 13. However, since upgrade to angular 15 we started getting NullInjectorError for the store, i have provided some links up in my earlier comments.

In general my understanding was not to have StoreModule.forROot({}) at all in the shell UI, especially if only one MFE is using ngrx store. But looks like the recommended practice is now a necessary step i fear since angular upgrade. I still need to a do a small POC to verify it so that i can create some sample repo for this