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.
Related
I have an angular application that looks like such.
file1.js
var app = angular.module('app', ['third-party-stuff-A']
file2.js
var app = angular.module('app', ['third-party-stuff-B']
so essentially file1 and file2 represent two separate pages in my application.
I've registered all my controllers, services, and other injectables into the module app, so for example.
app.factory('thing', function ($scope) { ... });
the thing factory is available to both app in file1 and app in file2.
I've read that it's better practice to break things into modules. app in file1 and file2 should probably be their own separate module.
And to go even a step further, perhaps thing factory can go into a module MyFactories. and MyFactories would be injected into each of my apps.
But I'm not sure what the immediate benefit is of doing this.
Most applications have one main method and links to different parts of the application.
Angular apps don't have a main method. Instead modules specify how an application should be bootstrapped. advantages for creating modules are
You can package code as reusable modules. The modules can be loaded
in any order (or even in parallel) because modules delay execution.
see more at https://docs.angularjs.org/guide/module
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.
I'm creating a structure for a hybrid app built with ionic.
We use gulp to concat and minify the files.
So far i append every controller, service and directive to my main module defined in app.js.
Each of these components is defined in its own file which are then concatenated with gulp with app.js first and everything else last.
This is the way ionic does it for their 10k loc IonicModule.
Is there any reason why i should use the angular module system for more than the main apps module (e.g. app.directives, app.controllers etc.) besides the better structure (each component in one file) which i already have with ionics approach?
I could think of two things:
Testability: as far as i know i don't have to declare a module as angular.module , i should be able to mock controller modules (e.g. myApp.controller(x...) as well
Performance: there shouldn't be a performance gain as far as i know, am i wrong about that?
we are currently working on a big project in Marionette. We've based the architecture on http://www.backbonerails.com/. The project is divided in number of modules , every with its own responsibilities. It's important for the modules to be reusable, so they can be rendered in any region on the website. Right now the modules are initiated like this:
App.execute "module:name_of_the_module:action", #model, #layout.regionName
This worked good so far, but now we added Routers to the project. Every module should have responsibility for their routing, so they are in the modules. Now when the routers get the route and start routing, they are missing the region and model to work with. So we first have to save the region and models to the module to be used in the router later.
App.commands.setHandler "module:name_of_the_module:action", (model, region) ->
MyModule.region = region
MyModule.model = model
This is not really a good way to do it, because there is usually many actions on every widget (show, edit, create, ...) and we would have to duplicate a lot.
So I am asking - how do you initialize your modules and work with the routers? Is there some best practice?
I've create a marionette.js plugin which allows you do state based routing(much like angular.js ui-router). You can completely eliminate modules in code and reuse controllers.
Link: http://ajency.github.io/marionette.state/
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