Giters

angular-architects / module-federation-plugin

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

provider in config of a remote is not working

asollberger opened this issue · comments

commented

Dear Angular Architects

I'm using native federation 17.1.7 with the Angular 17.3.5

I found an issue with a provider on the level of a remote.

If I only provide the library provider in the remote, then connecting to the remote will work, connecting to the shell (that loads the remote) will not work and it will complain about the missing provider:

_angular_core-17_3_5-dev.js:3806 ERROR NullInjectorError: R3InjectorError(Standalone[_NavigationComponent])[SignalStore -> SignalStore -> SignalStore -> _RequestStoreService -> InjectionToken request-config -> InjectionToken request-config]: 
  NullInjectorError: No provider for InjectionToken request-config!
    at NullInjector.get (_angular_core-17_3_5-dev.js:930:21)

Here's a reproduction of the issue (main branch):
https://github.com/asollberger/nx-nested-native-federation

nx run-many -t serve --parallel 5

Shell

  • open localhost:4200
  • click request
    expected: the configuration (app.config.ts) was properly loaded before the remote was started
    arrived: the provider was not loaded and thus the loading fails

Request

  • open localhost:4202
    expected and arrived: the configuration is loaded

Workaround

If I add the provider at the shell level it works again.
I think the reason why it doesn't work is that the application config is not loaded before the remote get instantiated.

Thank you for looking into it.
Best regards
Alain Sollberger

commented

Hi,

it's like with lazy loading. If you have a service you need in the eager part and in lazy parts, you need to register it in the eager part which is the shell in your case.

Best wishes,
Manfred

commented

Hi Manfred

I get that and don't disagree in the case where both need the service. But in my case I neither want nor need this library in the shell. That dependency is purely one of the remote and right now I have to add the dependency to the shell to make it work.

Think of the scenario where you have to provide something from a remote that the shell does not even know of since it only exists in the remote.

The current behavior completely defeats the purpose of the separation. It breaks the separation of concerns to have to configure a library in the shell that is only needed in the remote.

Please reconsider this
Kind regards
Alain

commented

Hi Alain,

I feel you. Using Federation that way is just like lazy loading from Angular's perspective. On the one hand, this is great because we can use Angular without any tricks, workarounds, or meta frameworks. On the other hand, this also brings the restrictions of lazy loading. For this reason, this is more an Angular thing than a federation thing.

You can try registering the lib in question in a lazy module or route located in the remote. But some Angular libs really demand us to register stuff at the root level.

Another option is to bootstrap the remote as a further Angular app on your page. In this case, you have a self-contained Micro Frontend. It's a bit more complicated but doable. I'm describing such an architecture here [1].

Best wishes,
Manfred

[1] https://www.angulararchitects.io/blog/micro-frontends-with-modern-angular-part-2-multi-version-and-multi-framework-solutions-with-angular-elements-and-web-components/

commented

Hi Manfred

I'll have to digest that and see whether I can make it work in our environment, thank you for the link.

Alain