proposed: implicit namespacing

[geddski]

Building large Angular apps often means making a "main" app and many "sub" apps that the main app depends on.

angular.module('main', ['appone', 'apptwo', 'appthree']);

Now you have to namespace everything in your app to avoid collisions. For example, if appone had a CoolCtrl and apptwo had a CoolCtrl, the second would overwrite the first. The current solution is to name them ap1CoolCtrl and ap2CoolCtrl respectively. This manual namespacing is tedious, error prone, and reduces portability.

I propose we tighten up the injector, so that the only components (services, filters, etc.) available for dependency injection are those that are either declared in the module itself or one of its dependencies. So in our example, if appone had a NeatService that service could only be injected into appone and main, but not in apptwo since apptwo does not explicitly depend on appone. Now you don't have to namespace all of your own Angular components.

The other piece is how to disambiguate which app you're using in your templates. I propose a new directive named ng-use:

<div ng-use="appone">
  <div ng-controller="CoolCtrl"/>
</div>

<div ng-use="apptwo">
  <div ng-controller="CoolCtrl"/>
</div>

Any ng-includes etc. would propagate the currently used module.

If no ng-use is specified, it implicitly uses the module declared by the bootstrapping (ng-app) which is the main app.

Angular should then throw if a component is defined more than once.

And finally, for the sake of the main app, Angular could automatically namespace the components with their module name:

angular.module('main').controller('Router', function(apponeCoolCtrl, apptwoCoolCtrl){
  //yay automatic namespacing
});

Thoughts/feedback welcome.

[joeeames]

The namespacing issue really needs to be solved. This solution seems viable.

[iammerrick]

Yeah this is a serious problem. I wonder if we could take a queue from the "as" syntax for controllers.

angular.module('App', ['appone as ao']);

Now all appone dependencies are prefixed with ao for the consuming modules, excepting those within appone.

[geddski]

@iammerrick good call, I like the "as" syntax. Could be optional, falling back to the full name of the module.

[IgorMinar]

This is a known feature request. We will need to find a way to address it in the dependency injector.

I'm experimenting with a possible solution in my di.js project:

https://github.com/IgorMinar/di.js/blob/master/spec/injector.spec.js#L197-L204
https://github.com/IgorMinar/di.js/blob/master/spec/injector.spec.js#L323-L325

[IgorMinar]

In other words, I don't think that the template should have a special construct to avoid collisions. the DI system should make collision prevention possible at its core.

[blittle]

+1 for this change. I really think this is one of the more non-intuitive things about Angular's module system and dependency injection. Why would apptwo have access to services (or really anything declared) within appthree without explicitly defining apptwo as depending on appthree?

[groner]

It would be nice if the injector could use module dependencies to resolve unqualified names. We could use a symbol, such as $ to separate the namespace from the local name. This makes it clear whether a symbol in fully qualified or not.

// This registers "foo$schemas".
angular.module('foo', [])
  .factory('schemas', ...);

// And this registers "bar$schemas".
angular.module('bar', [])
  .factory('schemas', ...);

angular.module('main', ['foo'])
  .controller('MainCtrl', function(schemas) {
    // Because the "main" module depends on the "foo" module, the unqualified 
    // name "schemas" resolves to "foo$schemas".  Even if the "bar" module
    // was loaded indirectly, components in "main" would not see them.
  });

angular.module('integrated', ['foo', 'bar'])
  .controller('FooCtrl', function(foo$schemas) {
    // The "integrated" module depends on both "foo" and "bar" modules, so we
    // have to specify which module we want now.
  });

The $ syntax is pretty ugly, but you would only use it in unambiguous cases. I think a lot of code would work without changes.

Since directives already do name mangling, that could be used to make foo:my-directive or foo-my-directive resolve to foo$myDirective.

There are some cases where we don't know what namespace to use:

• $compile
• $controller ($route invokes $controller, but not from the module the controller was specified in)

I think ng-use would be good to have for templates. I don't know if it should link new modules, but it could control how $compile resolves directives, filters, and maybe controllers.

An unqualified namespace could provide current behavior as a fallback for these cases.

[rgullhaug]

This is a really important feature for everyone doing large applications (with many developers) in angular. I hope someone on the team can say something about when or if this will get implemented?

[ThomasWeiser]

+1

[lord2800]

+1

[troygoode]

👍

[sudhakar]

+1

[CWSpear]

+1

[marcelaraujo]

+1