Feature Request: Support Dynamic, At-Runtime Lazy-Loading
See original GitHub issueI’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
Issue Analytics
- State:
- Created 6 years ago
- Reactions:34
- Comments:10 (3 by maintainers)
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.
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.