In one of our angular project, we defined some modules, like:
angular.module("services", [])....
angular.module("controllers", ['services'])....
angular.module("factories", [])....
Then make a main module depending on them:
angular.module("app", ['services', 'controllers', 'factories'])
Some colleague thinks this way is not good, he prefers to group modules by business features, like:
angular.module("login", [])....
angular.module("user-admin", [])....
angular.module("post-admin", [])....
Then combine them together:
angular.module("app", ['login', 'user-admin', 'post-admin'])
I think his approach is making sense, but I'm not sure the best practice to define modules.
What rules we should follow when defining modules?
Sometimes when we start to play with AngularJS we think is a good idea to create different modules, for example, for our controllers, services, directives, etc…but this may not be the best option. For example: let’s say we create a controller inside a module named ‘myapp.controllers’ and this component depends on a service that is inside the module ‘myapp.services’. When we want to use that controller in another application we will have to not only require the controller module but the service one too and any other module that is as a dependency. However, if we have a login module and we create controllers, services, directives, etc under the module ‘myapp.login’, then later on when we want to use that module we will have everything we need to use to it without needing other dependencies.
source
another way
Another method we can use to break up our app is to divide our modules by route. This breakdown
allows us to write isolated tests that focus on the functionality per route. Modularizing by route can
make more sense, depending upon the project; it allows us to divide our functionality efficiently
when we’re dealing with a lot of independent routes.
angular.module('myApp.home', []);
angular.module('myApp.login', []);
angular.module('myApp.account', []);
angular.module('myApp', [
'myApp.home',
'myApp.login',
'myApp.account'
]);
This modularization makes sense specifically when we’re dealing with large numbers of routes
and/or when we don’t have too much cross-over between routes.
Related
This is a question about AngularJS modules and services, and how to define them.
An app can be composed of multiple modules
A service allows commonly-used code to be factored out and used by multiple modules
A service is (commonly) defined with:
angular.module('module1').factory('serviceA', function() { ... } );
If the above are all true, then why does the definition of serviceA include a reference to module1? Shouldn't it be ignorant of any modules that want to use it?
If I was building a module2 and I referenced serviceA.js in order to access the above service, it would tell me that module1 is not defined.
I guess my question is how do I create a set of independent modules and have them all access a global service? In all the examples I've seen the service is tightly-coupled to a specific module.
The factory() method is a method on module, so you need a module instance to be able to call it. Essentially, that statement says that you want that factory to be defined on that specific module.
If you need module1 in something used in module2, then module2 should declare a dependency on module1:
angular.module('module2', ['module1']);
One thing that writing unit tests will teach you really quickly is that the more places something is used, the more important it is to put it in a module. If you try to treat it as "global" because it's used in a lot of places, that means you have to bootstrap the entire app just to use those services that are basically used everywhere.
I have an app module, want to register a controller for app module.
Is it ok to define a controller for the app module?
Regards,
ng-R
You can organize your components in modules the way you want. For a very small app, you can imagine using a single app module containing all the components. For larger applications, splitting components in technical and/or functional modules is a good idea.
In the end, at runtime, what matters is that the needed controller is part of the app module or of any of the modules it depends on, transitively.
I'm new to AngularJS and have created some services, however a lot of these require some 'standard' dependencies
e.g. Logging ($log),
a shared data service (pub/sub service for sending messages between controllers), an error handling service etc.
Is there a way to specify that all my services will have these 'standard' dependencies, to avoid having a very long list of dependencies for controllers like this:
["$scope", "$http", "$log", "SharedDataService", "SharedErrorBusService"...
If so is this even sensible - for example could it create difficulties for automated testing?
When your controller declares so many dependencies it is a sign that your controller has too many responsibilities. Angular has other mechanisms for cross cutting features like http interceptors or delegates that could be useful in your case.
I would like to have more theoretical understanding how angular modules work.
When I would create one module 'clientApp' and I 'register' controller, services, factories, scope etc..., inject other services, factories, scope into the controllers. What objects are known to the 'clientApp' module?
Angular Modules
An efficient, production-ready controllers by encapsulating our functionality in a single core unit called a module.
In Angular, a module is the main way to define an AngularJS app. The module of an app is where
we’ll contain all of our application code. An app can contain several modules, each one containing
code that pertains to specific functionality.
Using modules gives us a lot of advantages, such as:
• Keeping our global namespace clean
• Making tests easier to write and keeping them clean so as to more easily target isolated
functionality
• Making it easy to share code between applications
• Allowing our app to load different parts of the code in any order
The Angular module API allows us to declare a module using the angular.module() API method.
When declaring a module, we need to pass two parameters to the method. The first is the name of
the module we are creating. The second is the list of dependencies, otherwise known as injectables.
angular.module('myApp', []);
When writing large applications, we’ll create several different modules to contain our logic. Creating a module for each piece of functionality gives us the advantage of isolation in which to write and test large features.
Properties
Angular modules have properties that we can use to inspect the module.
name (string)
The name property on the modules gives us the name of the module as a string.
requires (array of strings)
The requires property contains a list of modules (as strings) that the injector loads before the
module itself is loaded.
Better Read
ng-book -
The Complete Book on AngularJS
Ari Lerner
Download ng-book
In AngularJS there is a short form to create controllers, so you do not have to use a module for this. This short form is to simply define a function
function FooController ($scope) {
// ...
}
and reference it from the HTML markup using ng-controller:
<div ng-controller="FooController">
...
</div>
Now, my question is, whether there is a similar "short form" to define services? In other words: Can you define (and use) a service without using a module?
Please note that I know that it perfectly makes sense to structure your applications using modules, and not doing so could / should be regarded as bad practice. It's just that I am explaining AngularJS to someone who's completely new to it, and the question arose today. So it's just for curiosity and completeness.
Quoted from the doc of Creating Services
To register a service, you must have a module that this service will
be part of.
So I guess the answer is no.
Since the ng module is always loaded, you could define your service on the ng module:
angular.module('ng')
.service('aService', function () {
// you really shouldn't do this
});
It works, but you shouldn't be messing with a module that you don't own.
If you're trying to explain to someone why using your own modules with .controller is good:
Talk to them about testing. It's a lot easier to mock things if you're using modules
If you need to have other modules as dependencies (like angular-ui)
If you want to decorate another service (e.g. $http)
If you need to register directives, filters, animations, etc.
It's a lot nicer to have modular code :)
It's an angular concept I don't understand at all, I always believed "separation" is good, so I dont get why we need to associate a service to a specified application.
Here what I am doing: you can declare your angularjs application as a global object:
window.markrApplication = angular.module('markrOptionsApp', ....)
And declare all your services like this:
markrApplication.service('data', ....
Of course you need to have all the dependencies set on all your angularjs application.