Repository navigation
Feature Request: Support Dynamic, At-Runtime Lazy-Loading #22243
Description
I'm submitting a...
[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report
[x] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question
Current behavior
Currently, lazy loading is tightly-coupled to the Angular Router and also requires static declarations of the lazy-loaded routes in the primary Angular application. Furthermore, the primary method of compilation of Angular applications (via webpack) requires the application to compile all parts of the application, including external dependencies such as npm libraries (which can be specified in the Angular Package Format).
This scenario does not work well in an Enterprise environment unless all teams/applications are setup to be in one mono-repository (as recommended by Nrwl). Unfortunately, this is not a realistic setup for many Enterprise environments, due to various issues. The parent/host application should not be required to know much about the child application/module, and it should not have to compile the child application.
Expected behavior
The child module needs to be compiled in a way that it can be dynamically loaded into the parent/host application at runtime. The child module could have its own set of routes, which could be added to the parent/host application's routing table and the parent/host application could discover the child dynamically (e.g. via a web service, a file, etc).
The parent/host application should not be required to compile the child modules. While this may result in less code optimization and some repeated code, it is a necessary trade-off in an Enterprise environment that could have hundreds of applications, each in different repositories, scattered around the globe.
Minimal reproduction of the problem with instructions
With the current tooling and Angular documentation:
- Create two Angular applications using the Angular-CLI:
- App-A - The child module to be lazy-loaded
- Platform - The parent/host application that
- Use ng-packagr to turn App-A into a module that adheres to the Angular Package Format
- Host AppA in npm (or just fake it - move it over to the node_modules directory of the host application)
- Setup a simplerouting table of the Platform application (note this has to be declared statically):
const routes: Routes = [
{ path: "", component: HomeComponent },
{ path: "app-a", loadChildren: "../../node_modules/app-a" }
];
@NgModule({
imports: [
RouterModule.forRoot(
routes
)
],
exports: [
RouterModule
]
})
- Observe that the Angular-Cli (or Webpack on its own) will compile the child application code with the parent/host application. The child code will be separate from the parent code, but the webpack references will be heavily intertwined. Furthermore, the parent/host module has to statically declare the existence of the child module before compilation.
What is the motivation / use case for changing the behavior?
The above scenario is fairly easy to implement in AngularJS. This is because the child modules could be loaded in script tags, and could register themselves with Angular without tightly coupling themselves to the parent/host module. Therefore, Additional tooling, API-support, and/or walk-throughs for this scenario in Angular would really help Enterprise clients move from AngularJS to Angular.
Environment
Angular version: 5.*
Angular-CLI version: 1.6.8
Activity
trotyl commentedon Feb 15, 2018
Duplicate of #13218, #16387, #17287, #18053, #18093, #19264, #21352 and #21583.
It's always possible in Angular, so cannot actually be a feature request (if not for API simplification). For better Angular CLI support should be raised there.
bmbell commentedon Feb 16, 2018
It seems to me like it is a feature request: this issue either needs better documentation (since it is a very common Enterprise scenario) or a better "compiled JavaScript" format/decorators that allows for dynamic loading without having to compile all the sub-projects in the system.
I don’t see why there isn’t something similar to .dll files in the .NET world:
Team A builds library A (libA.dll in .NET, libA.js in NG)
Team B builds library B (libB.dll in .NET, libB.js in NG)
Team Platform should be able to dynamically load each library into the platform system (all examples show dynamically loading a module to get to a component, but it is unclear to me if the module is "registered" in the system and if the routing would pick it up). There should also be a programmatic way to add any routes found in libA or libB (I think there is a poorly documented way, but I have seen several issues that it is currently buggy).
Granted, some of the super-awesome AOT optimizations probably can’t work in this scenario (how could you optimize out things in the platform if you don’t know if libA or libB depend on something?), but this seems like a very common scenario, especially in Enterprise markets.
mlc-mlapis commentedon Feb 16, 2018
@bmbell ... it is true that especially adding additional routes from ad-hoc programmatically loaded modules (which have no route definitions in the main app till the moment of their loading) is the area which has very poor / or none documentation and there are many unsolved/unclear points = very time consuming for anybody who wants to use that.
The comparison to .NET world would be fine except the moment when you need .NET Framework to be installed to run these *.dll. And that is the area, in Angular world, which is actually solvable either as
super optimized AOT tree-shakeableprocess which is unique for each compilation build of the whole app or using just native shareable UMDs Angular libs (even with advantages of browsers caches) ... prepared for running of any NgModule.sminnikantiosius commentedon May 10, 2018
Along with AOT issue, we should consider properly lazy initialization of providers, services, modules like ngrx store of particular lazy loading module. It would be great if there is a separate defined way to satify all the above.
mstratiev commentedon Jul 3, 2019
It is very nice that it is fixed by Ivy, however Ivy is still not properly here, and that is a year later. It is, as I understand, still a "preview" and AOT is only with angular-cli. However, there are rather large applications that are not easily migrated to the cli, since there is a large number of custom webpack configs and/or plugins. AOT with @ngtools/webpack is quite a viable option still, however it is rather an unfortunate situation that the choice falls between - keeping the JIT version of an existing app, as slow as it might be, or using AOT, while either causing a massive breaking change or simply losing the ability to register modules dynamically. I do believe that this (and the related loading ngmodule at runtime) should be doable even at the cost of a nasty-looking hack in the context ot AOT, but I guess that this is only my opinion. Updating to the cli is a rather poor option still, since any build problems would be nearly impossible to debug in the black box that is the cli, and not all applications are "Hello world" AND Ivy is still not properly here.
hulyapelinobek commentedon Nov 21, 2019
@trotyl You mentioned that it is possible in angular. However we are facing same problem and could not find a proper way to solve this. We are using angular 8. Could you suggest any example to load libraries(seperate modules) in runtime without knowing them during compile time of the parent/host application.
Disane87 commentedon Nov 26, 2019
Same here @hulyapelinobek, cracking my head about this the last few days, even with assistance of @mlc-mlapis to load the libraries lazy at runtime with their routes defined in them (to show them in the main app navigation)
jessicajaniuk commentedon Sep 15, 2022
Thanks for reporting this issue. This issue is now obsolete due to changes in the recent releases. Please update to the most recent Angular version.
If the problem still exists in your application, please open a new issue and follow the instructions in the issue template.
steve-todorov commentedon Oct 5, 2022
Hey @jessicajaniuk,
I was wondering if there any updates in the Angular Docs that reflect and explain how to do this with the newer versions of Angular?
angular-automatic-lock-bot commentedon Nov 5, 2022
This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
This action has been performed automatically by a bot.