Duplicate entry component rendering for standalone ng component served as independent frontend

[4javier]

Current Behavior

When generating angular standalone component as remote, the entry component is listed inside entry.routes for root path ''.
That's fine when module is lazy loaded by shell app, but gives a problem when served as independent microfrontend.
In that case the entry component is declared into index.html too, so if a router-outlet gets added somewhere in the tree, the component will be rendered twice.

Expected Behavior

When served as independent app, entry.routes should be ignored, and inner routes should be defined into remote's app.routes directly.

Github Repo

https://github.com/4javier/monotest

Steps to Reproduce

1. nx serve shell
2. on localhost:4200 click on "remote" link: a blue square is rendered
3. on localhost:4201: two squares get rendered

Nx Report

Node : 14.20.0
   OS   : linux x64
   npm  : 6.14.17
   
   nx : 15.5.1
   @nrwl/angular : 15.5.1
   @nrwl/cypress : 15.5.1
   @nrwl/detox : Not Found
   @nrwl/devkit : 15.5.1
   @nrwl/esbuild : Not Found
   @nrwl/eslint-plugin-nx : 15.5.1
   @nrwl/expo : Not Found
   @nrwl/express : Not Found
   @nrwl/jest : 15.5.1
   @nrwl/js : 15.5.1
   @nrwl/linter : 15.5.1
   @nrwl/nest : Not Found
   @nrwl/next : Not Found
   @nrwl/node : Not Found
   @nrwl/nx-cloud : Not Found
   @nrwl/nx-plugin : Not Found
   @nrwl/react : Not Found
   @nrwl/react-native : Not Found
   @nrwl/rollup : Not Found
   @nrwl/schematics : Not Found
   @nrwl/storybook : Not Found
   @nrwl/web : Not Found
   @nrwl/webpack : 15.5.1
   @nrwl/workspace : 15.5.1
   @nrwl/vite : Not Found
   typescript : 4.8.4
   ---------------------------------------
   Local workspace plugins:
   ---------------------------------------
   Community plugins:

Failure Logs

No response

Additional Information

I explained extensively the issue and my suggested solution here.
https://dev.to/this-is-angular/nx-module-federation-bad-angular-routing-1ac9

[Coly010]

When served as independent app, the app should act like a standard Angular application, following the same expected patterns and structures.

main -> app component -> app.routes -> entry.routes -> entry.component

The reason this wasn’t the case during generation is because Module Federation !== Micro Frontends. The remote apps do not NEED to be independently operable.

Module Federation’s core concept is to allow JS modules to be fetched at runtime from a different location than the host. It just enables Micro Frontends.

With Nx, we focus purely on the Module Federation aspect, as Micro Frontends themselves come with their own slew of issues.

A more correct solution will be to have the remote apps generate a closer structure to a normal angular app.

We don’t do it by default, because in most cases of Module Federation, we do not care about having a full app, and rather just the Entry Component that is exposed by Module Federation.

If we’re to add this more independent app setup, we should probably place it behind a flag.

[4javier]

I thought MFE was took in account looking at the non-standalone generator.
I think the flag could even not be necessary, considering that what it takes to have a canonical bootstrap, is just to replicate NgModule version remote generation, replacing AppModule with a standalone AppComponent providing routing.
Let me know if the idea sounds nice, because I noticed webpack app files generation is a bit tricky, so I'll avoid going full-throttle towards it.
Anyway, I learned a lot, so time well spent.
Thanks for your replies.

[Coly010]

If you're willing to give it a go, where we:

1. keep AppComponent
2. AppComponent bootstrapped by the main.ts file
3. Correct routing to EntryComponent from AppComponent
4. Nothing changes to EntryComponent, or entry.routes.ts
5. Nothing changes to what is shared by webpack.config.js
6. index.html points to app-component selector

Then feel free to submit a new PR.

But if it's too much work and you don't have the time, I can do it :)

Just let me know

[4javier]

Yes, I'm fine with the flow.
My concern was about the creation of index.html, that inspecting the code looks to me is delegated to web/webpack generators, with root component selector set by placeholder.
That's why I thought there was something to tune up in there.
But now I looked at angular specific generators again, and find gist is mostly here
https://github.com/nrwl/nx/blob/master/packages/angular/src/generators/setup-mf/lib/remove-dead-code-from-remote.ts#L37

If you're ok I could give it a shot.
(I'm trying to issue some PRs for resumé)

[Coly010]

Yeah no problem 🙂 If you need any help feel free to reach out to me again.

[4javier]

Not my proudest string manipulation, but I didn't find any removeTsImport nor removeStandaloneImport utility among the libs.

The ideal solution would have been to avoid the import and projection of NxWelcomeComponent from the beginning, but unfortunately its logic is part of generic applicationGenerator, so I think that simply deleting them from template would break creation of non-remote apps.
It should be be branched by something like if (isRemote)

[Coly010]

Not really, the application should be independent of the remote generator.

Remote depends on application
Application shouldn’t need to know what uses it.

theres a PR that might help with it, to add a minimal flag that skips the generation of the NxComponentTemplate, so it might be worth waiting until that gets merged, then you can rebase your branch and use that

[4javier]

If that flag can be passed as Schema property to applicationGenerator, and you're fine with me using it when it calls convertToStandaloneApp, that would solve every issue.

[4javier]

@Coly010
I suppose this is the PR you were referring to
#14268
I'll give it a look tonight or tomorrow.

[Coly010]

There has been no movement on this for over a month now, so I'm going to close this issue for now.

If this is something that you still feel strongly about, feel free to tag me and we can re-evaluate it.

[github-actions]

This issue has been closed for more than 30 days. If this issue is still occuring, please open a new issue with more recent context.