feat($injector): allow loading of modules to an existing injector

[justmoon]

When working on larger applications it is desirable to have individual parts loaded on demand, rather than loading everything at once in the beginning.

Unfortunately, there is no way to load a new module to an existing injector after the injector has been instantiated. And we also can't create a new injector because we would have a separate $rootScope and separate instances of services etc.

As far as I understand dynamically loading modules is planned for Angular 2.x, but our project needs the functionality now.

This patch exposes the module loading functionality in the injector. With access to this low-level function, applications can implement their own loading behavior.

I'm happy to add docs and tests to this pull request, but I wanted to get a reaction from the Angular devs first.

Related discussion:
https://groups.google.com/d/topic/angular/rs1dj097oHA/discussion

[gonzaloruizdevilla]

Loading lazy controllers is quite easy to do, however, lazy loading modules or lazy adding services, directives or filter is what I found most problematic.

Until now what I've done in this cases, is to register all the services before the bootstrap with empty logic, and using lazy mechanisms I'm filling the services when they are needed.

It would be great to simplify this things, and allow loading of new modules dynamically (I would use it inside route.resolve, http://docs.angularjs.org/api/ng.$routeProvider)

[coli]

+1 We are likely to need this as well

[petebacondarwin]

If your module were to add a directive that matches an element already in the DOM, how would you update the DOM to account for this? Recompile the whole thing again?

[justmoon]

If your module were to add a directive that matches an element already in the DOM, how would you update the DOM to account for this?

Ah, I see. Perhaps this is why the injector is designed the way it is.

Here is my response:

I wouldn't update the DOM. Let the rule be: When compiling a piece of HTML, that piece can use any directives that are loaded at that point.

If we can come up with an efficient and reliable scheme to update the existing DOM, great, but that would be a separate and rather complex feature. (And I'm not sure there is a compelling use case for it.)

Our use case is that we want to load parts of our application when they are needed. The application that is already running need not have any knowledge about the new bits we're loading, but we do want the new bits to have knowledge about the existing application (it's services, scope, etc.). Acquiring that knowledge is what this patch is designed to allow.

If there is a better solution I'm all for it. This injector patch is merely what I came up with.

[mhevery]

I am sorry, but we can't accept this change. :-(

The issue is that injector can not change its configuration at runtime, or you can get to some very unpredictable behaviors. For example a new module may chose to override the current instance, but the instance is already instantiated and thus it fails, but if we use the app a different way the instance may not be instantiated and the loading will succeed in override. This will give the app different behavior based on how it is used.

The proper way to do this is to have hierarchical injectors. A child injector of the current injector, and load the module into the child injector. This way the behavior is consistant no matter which path the user takes. I have already implemented this here and we are working on getting in into angular. https://github.com/mhevery/angular.js/blob/dte/src/auto/injector.js

[alexandermontgomery]

@mhevery Any update on when the dynamically loading of child modules might make it into master? I need this now and am hacking around it. I am just starting to incorporate angular into my application and having to make new injectors (and consequently new $rootScopes) for each module is not the end of the world however this seems like a much cleaner solution.

[bjconlan]

@mhervey Any estimated version/date for the integration of the hierarchical injector into the mainline? (evaluating personal mainline with dte module/injector additions vs sitting on hands and waiting for someone who has a better idea of the code to do it)

[webuniverseio]

@mhevery ping, 9 months passed

[eahutchins]

@IgorMinar, @mhevery is there a place where this nested/child injection feature discussion is happening? I could really use this in a project I'm working on and would like to understand the intended semantics and approximate release timeframe.

[nprbst]

+1 Does @mhevery's work on child injectors make the Roadmap for 1.4 or 2.0?