How does inheritance and dependency injection work with angular modules?

Question

I'm a little confused about how angular modules are intended to work and what would be the best way to use them. I read in a book that services are globally available no matter which module includes them. Filters and directives are obviously also available throughout the template files of the whole app.

A brief example:

angular.module('main',[
   'one',
   'two',
   'three'
]);


angular.module('one',[]).service('oneService', ...);
angular.module('two',[
    // angular-module 'one' does not have to be passed here
]).controller(function(oneService){
    // available here
    oneService.do();

});

angular.module('three',[]);


// not a good idea
angular.module('three').service('oneService', ...);

Which actually results in a couple of questions for me:

• What is a good way to 'think' about angular modules if there is no real closure?
• Apart from the semantics and the resulting folder structure (which could be done without using modules) - what are the benifits of splitting up one app into different modules?
• Is there any inheritance automagic going on when using a dot-notation for modules, e.g. angular.module('main') and angular.mopdule('main.customers')?
• Is splitting up an app into different apps (not modules) a possible alternative, e.g. one app per route and if so, what would be a good way to go about it, as apps cannot contain other apps?

Answer 1

Miško Hevery discusses it here:

https://www.youtube.com/watch?v=ZhfUv0spHCY&t=34m19s

Then there is the post by Naomi Black:

http://blog.angularjs.org/2014/02/an-angularjs-style-guide-and-best.html

Which references these documents:

https://google-styleguide.googlecode.com/svn/trunk/angularjs-google-style.html https://docs.google.com/document/d/1XXMvReO8-Awi1EZXAXS4PzDzdNvV6pGcuaF4Q9821Es/pub

Also the latest version of angular documentation states:

... we recommend that you break your application to multiple modules like this:

• A module for each feature
• A module for each reusable component (especially directives and filters)
• And an application level module which depends on the above modules and contains any initialization code.

Summary:

• modules are just a way to configure the DI subsystem (at least so far)
• if you do want to use modules split your application by feature, not by type
• it is actually recommended now to structure your application with one module per feature
• modules do not provide much benefits right now, but they may in the near future when lazy loading for views is implemented