I have been reading these two links 1 and enter link description here. The idea is to have clean and module code.
The modular approach explained in the links above suggest to a file for the function, and another file for injecting the functions into angular's directive, controller, ... .
As an example:
/* app.js */
define([
'/path/to/controller',
'/path/to/service1'
], function(MyController, MyService1))
{
"use strict";
angular
.module('myApp', [])
.controller('MyController', MyController)
.factory('MyService1', MyService1);
});
/* controller */
define(function()
{
"use strict";
return ['$scope', 'MyService1', MyController];
function MyController($scope, MyService1)
{
/* Now do your coding here */
}
});
/* service */
// Identical to controller
Notice here how the function is implemented in one file, and then injected into the angular.
Now, I can see a potential problem is your service custom depends on another custom service. Say MyService2 also uses MyService1. My two services now look like:
/* MyService1 */
define(function() {
return MyService1;
function MyService1() {
/* Code Here */
}
});
/* MyService2 */
define(function() {
return ['MyService1', MyService2];
function MyService2(MyService1) {
/* This uses MyService1 here */
}
});
If your app uses both, then all is well, however, if it only uses one, then we have a problem:
/* This will work fine */
angular
.module('myApp')
.controller('MyController', MyController)
.factory('MyService1', MyService1)
.factory('MyService2', MyService2);
/* This will NOT */
angular
.module('myApp')
.controller('MyController', MyController)
.factory('MyService2', MyService2); <-- This guy internally requires MyServce1
I don't see how to solve this problem while still keeping this kind of approach. Can you help?
RequireJS and AngularJS have two non-overlapping dependency resolution mechanisms. If you're really going to use both, as suggested in the linked guide (I'm hard-pressed to imagine a scenario where this would be useful enough), you need to keep in mind, that the individual "service files" don't really contain services at all. They contain just their constructors/factories. To put it all together, your module definition needs to solve both of the separate concerns:
load all files with the constructors/factories needed for service/controller/... definitions, and
define all things that you don't want to leave as external dependencies.
In other words, if you define a module containing just service2, which has a service1 dependency, and don't define service1, then service1 becomes an external dependency of your module (it cannot be used in an environment where no service1 is defined).
In other words, the two DI frameworks do NOT complement each other so that you could load a file containing a service only when you need to inject it (in Angular) for the first time. You could find a way to use RequireJS to load something (most likely whole separate Angular applications) on demand. But you cannot load a service/controller/... on demand (at runtime), because such things can only be defined in the configuration phase of AngularJS application construction. Once the run phase starts, no more configuration (e.g. service definition) can be done.
If you just want to create a single application with modular code, I'd suggest that you leave RequireJS be for now and focus on simply creating modular code, as the style guide suggests.
i see you use requirejs there so you got 2 dependencies frameworks in parallel (angular and requirejs)
when you define a file that has a dependency on MyService2, than MyService2 needs to define a dependency to MyService1 (requirejs dependency) so both files are loaded and available.
that closes the issue for requirejs file loading.
now angular: in MyService1 you do
angular.factory('MyService1', function () {....});
than angular knows of that service and can inject it to anyone who needs it.
for MyService2 you do,
angular.factory('MyService2', ['MyService1', function(MyService1) {...}]).
and now angular injected MyService1 into MyService2 and you can use it in service 1.
than in some controller you need service 2 you just do
angular.controller('MyController', ['MyService2', function(MyService2){...}]);
and angular injects service 2 that has already service 1 injected into it.
I am having problem while using Require.js to load dependencies for my module. Basically I have following module in which I define extension of Backbone Model.
define(["models/services/ProjectServices"],
function (ProjectServices) {
var SomeModel = Backbone.Model.extend({
sample: function () {
var servicesFromDependency = ProjectServices; //undefined
var projectServices = window.require.s.contexts._.defined["models/services/ProjectServices"]; //defined and Ok
}
});
return SomeModel;
}
);
In this module I want to use already defined ProjectServices module. In order to do that I add it as a dependency. The thing is that within defined sample function ProjectServices is showing as undefined. But if I look directly into require defined modules it is showing there correctly and I can use it (although I do not want as I don't like to hack it this way). To add more context, I am also using this ProjectServices dependency on other module and there it is loaded properly through define function.
Any suggestions on why module would not be loaded?
Try this inside a module:
var ProjectServices = require('models/services/ProjectServices');
I think in many situations, there is no need for window global assignment and I try to avoid while using requirjs.
The only thing I can come up with is a possible circular reference, meaning that two modules require each other (which should not be the case).
As you say that the require works well in other modules, it should not be due to a missing return statement in the required module, or a wrong path. (You might check this anyway).
I would like to have few global variables that are UI related (i.e. open menu state). I decided to put these in $rootScope so they're always accessible.
This is the code I've written:
(function (angular) {
angular
.module("App", [])
.run(["$rootScope", function ($rootScope) {
angular.extend($rootScope, {
ui: {
menu: false,
...
}
});
}]);
})(angular);
I've deliberately used angular.extend, to make sure that consecutive manipulations to the same object are retained. And I think it's also more clean and safe than adding several properties to any object one by one.
Problem
Upper code doesn't do anything though. When I run my application and check root scope by calling:
$("body").scope().$root.ui
I get undefined until some property within ui gets manipulated by ng-click directives on my application. Only then my ui gets a reference... But it's still not the one I've defined in the run() function but rather angular generated object property that ng-click directive generated as per expression.
What am I doing wrong?
Resolved - module got overwritten
Ia managed to resolve it myself. Code contained in the upper question isn't sufficient to show the actual problem in my application. The problem was the way I was loading module requirements and file ordering.
I'm loading files in this order:
app.js
routing.js
service.something.js
...
filter.something.js
...
So I thought to add module requirements to my app module in subsequent files (make ti actually modularized). This would make it simple to either include or exclude particular files without any runtime errors. It would also allow loading additional files dynamically as application runs.
The problem with my code was that I've overridden my original module in subsequent files. When I added all module requirements into app.js everything everything started working.
Possible workaround
I can see that I'm not the only person that would like this kind of functionality. Lasy module requirements loading is possible as per this Google groups' post.
What it does is it creates a new injector function
instanceInjector.loadNewModules = function (mods) {
forEach(loadModules(mods), function(fn) { instanceInjector.invoke(fn || noop); });
};
that can later be used by individual modules to add themselves as requirement to the main application module by doing this:
$injector.loadNewModules(["Module1", "Module2", ...]);
Although it would be much better (my opinion) if there was an additional function on Module type called requires() so one could do this instead:
angular.module("MainModule").requires(["AdditionalModule", "OtherModule", ...]);
I think that would make it more concise and easy to use and understand.
How can I create a directive without linking it to a specific module which can be used in any module, such as the build-in directives.
A directive or service has to belong to a module. What you can do is create separate modules for your directives and then inject them into your main application module. Here's my set up:
window.app = angular.module('app', ['ngRoute', 'app.system', 'app.animations', 'app.cart']);
angular.module('app.system', []);
angular.module('app.animations', []);
angular.module('app.cart', []);
Now your Service can be in its own module and called from within the app module. This is essentially what Ajay said.
angular.module('app.cart').factory("Cart", ['$resource', function($resource) {}]);
Short answer: no, it is not possible. All directives must be part of a module.
The Angular docs say
Much like controllers, directives are registered on modules. To register a directive, you use the module.directive API. module.directive
There isn't a way to define a directive outside of a module.
The Angular built-in directives themseves are defined on a module called ng - see the source code.
This module is created using the Angular internal method setUpModuleLoader (see AngularPublic.js and loader.js).
This function is not part of the Angular public API, so you can't access it yourself. You need to define your directives in your own module. Any app module which depends on this module will be able to use your directives.
It's a very Angular way of looking at things - avoid public objects, but make things injectable wherever possible.
I think I understand what the OP means. Similar to libraries like Angular UI for Bootstrap. The OP would like to create directives, etc. that can be used in other apps without having to know the main app name.
You can do this like so:
angular.module("hello.world", [])
.directive('hello', function() {
return {
template: '<p>Hello, world!</p>',
restrict: 'E',
link: function (scope, element, attrs) {}
};
});
Saved as 'hello-world.js' for example.
Make sure you include that JS in your page. Then inside your main Angular app:
var app = angular.module("myApp", ['hello.world']);
Then anywhere in your HTML under the app scope, you can insert:
<hello></hello>
And that directive will take over rendering a paragraph tag with the words "Hello, world!" within.
My understanding is that you can do this with all Angular objects - services, factories, providers, etc.
If I m not mistaken even the built-in directives belong to a module (ng module). It just that you don't have to explicitly declare a dependency on it as it is done by the framework for you. That's why you will always have to declare a module, add directive(s) to this module and depend of this module in other modules. Something like that :
// Reusable module with directive(s)
angular.module('directives', [])
.directive('rating', function () {
...
}
// other module that rely on teh first one
angular.module('MyApp', [
'directives',
...
]);
//Module 2
angular.module('MyModuleWithDependency', [
'directives'
]);
I have a bunch of Angular modules declared in my app. I originally started declaring them using the "chained" syntax like this:
angular.module('mymodule', [])
.controller('myctrl', ['dep1', function(dep1){ ... }])
.service('myservice', ['dep2', function(dep2){ ... }])
... // more here
But I decided that wasn't very easy to read, so I started declaring them using a module variable like this:
var mod = angular.module('mymodule', []);
mod.controller('myctrl', ['dep1', function(dep1){ ... }]);
mod.service('myservice', ['dep2', function(dep2){ ... }]);
...
The second syntax seems a lot more readable to me, but my only complaint is that this syntax leaves the mod variable out in the global scope. If I ever have some other variable named mod, it would be overridden with this next one (and other issues associated with global variables).
So my question is, is this the best way? Or would it be better to do something like this?:
(function(){
var mod = angular.module('mymod', []);
mod.controller('myctrl', ['dep1', function(dep1){ ... }]);
mod.service('myservice', ['dep2', function(dep2){ ... }]);
...
})();
Or does it even matter enough to care? Just curious to know what the "best practices" are for module declaration.
'Best' way to declare a module
As angular is on the global scope itself and modules are saved to its variable you can access modules via angular.module('mymod'):
// one file
// NOTE: the immediately invoked function expression
// is used to exemplify different files and is not required
(function(){
// declaring the module in one file / anonymous function
// (only pass a second parameter THIS ONE TIME as a redecleration creates bugs
// which are very hard to dedect)
angular.module('mymod', []);
})();
// another file and/or another anonymous function
(function(){
// using the function form of use-strict...
"use strict";
// accessing the module in another.
// this can be done by calling angular.module without the []-brackets
angular.module('mymod')
.controller('myctrl', ['dep1', function(dep1){
//..
}])
// appending another service/controller/filter etc to the same module-call inside the same file
.service('myservice', ['dep2', function(dep2){
//...
}]);
// you can of course use angular.module('mymod') here as well
angular.module('mymod').controller('anothermyctrl', ['dep1', function(dep1){
//..
}])
})();
No other global variables are required.
Of course it depends all on preferences, but I think this is kind of the best practise, as
you don't have to pollute the global scope
you can access your modules everywhere and sort them and their functions into different files at will
you can use the function-form of "use strict";
the loading order of files does not matter as much
Options for sorting your modules and files
This way of declaring and accessing modules makes you very flexible. You can sort modules via function-type (like described in another answer) or via route, e.g.:
/******** sorting by route **********/
angular.module('home')...
angular.module('another-route')...
angular.module('shared')...
How you sort it in the end is a matter of personal taste and the scale and type of the project. I personally like to group all files of a module inside of the same folder (ordered into sub-folders of directives, controllers, services and filters), including all different test-files, as it makes your modules more reusable. Thus in middle-sized projects I end up with a base-module, which includes all basic routes and their controllers, services, directives and more or less complex sub-modules, when I think they could be useful for other projects as well,e.g.:
/******** modularizing feature-sets **********/
/controllers
/directives
/filters
/services
/my-map-sub-module
/my-map-sub-module/controllers
/my-map-sub-module/services
app.js
...
angular.module('app', [
'app.directives',
'app.filters',
'app.controllers',
'app.services',
'myMapSubModule'
]);
angular.module('myMapSubModule',[
'myMapSubModule.controllers',
'myMapSubModule.services',
// only if they are specific to the module
'myMapSubModule.directives',
'myMapSubModule.filters'
]);
For very big projects, I sometimes end up grouping modules by routes, as described above or by some selected main routes or a even a combination of routes and some selected components, but it really depends.
EDIT:
Just because it is related and I ran into that very recently again: Take good care that you create a module only once (by adding a second parameter to the angular.module-function). This will mess up your application and can be very hard to detect.
2015 EDIT on sorting modules:
One and a half year of angular-experience later, I can add that the benefits from using differently named modules within your app are somewhat limited as AMD still does not really work well with Angular and services, directives and filters are globally available inside the angular context anyway (as exemplified here). There is still a semantic and structural benefit though and it might be helpful being able to include/ exclude a module with a single line of code commented in or out.
It also almost never makes much sense to separate sub-modules by type (eg. 'myMapSubModule.controllers') as they usually depend on each other.
I love the angular-styleguide by Johnpapa, and here are some rules that related to this question:
Rule: Named vs Anonymous Functions
Avoid using anonymous functions:
// dashboard.js
angular
.module('app')
.controller('Dashboard', function() { })
Instead, use named functions:
// dashboard.js
angular
.module('app')
.controller('Dashboard', Dashboard);
function Dashboard() { }
As the author says: This produces more readable code, is much easier to debug, and reduces the amount of nested callback code.
Rule : Define 1 component per file.
Avoid multiple components in one file:
angular
.module('app', ['ngRoute'])
.controller('SomeController', SomeController)
.factory('someFactory', someFactory);
function SomeController() { }
function someFactory() { }
Intead, use one file to define the module:
// app.module.js
angular
.module('app', ['ngRoute']);
one file just uses the module to define a component
// someController.js
angular
.module('app')
.controller('SomeController', SomeController);
function SomeController() { }
and another file to define another component
// someFactory.js
angular
.module('app')
.factory('someFactory', someFactory);
function someFactory() { }
Of course, there are many other rules for modules, controllers and services that are quite useful and worth reading.
And thanks to comment of ya_dimon, the above code should be wrapped in IIFE, for example:
(function (window, angular) {
angular.module('app')
.controller('Dashboard', function () { });
})(window, window.angular);
I recently had this conundrum as well. I had started off just like you using the chained syntax, but in the long run it becomes unwieldy with large projects. Normally I'd create a controllers module, a services module and so on in separate files and inject them into my main application module found in another file. For Example:
// My Controllers File
angular.module('my-controllers',[])
.controller('oneCtrl',[...])
.controller('twoCtrl',[...]);
// My Services File
angular.module('my-services',[])
.factory('oneSrc',[...])
.facotry('twoSrc',[...]);
// My Directives File
angular.module('my-directives',[])
.directive('oneDrct',[...])
.directive('twoDrct',[...]);
// My Main Application File
angular.module('my-app',['my-controllers','my-services','my-directives',...]);
But each one of these files was getting way to large as the project grew. So I decided to break them up into separate files based on each controller or service. I found that using angular.module('mod-name'). without the injection array, is what you need for this to work. Declaring a global variable in one file and expecting that to be readily available in another just doesn't work or could have unexpected results.
So in short my application looked something like this:
// Main Controller File
angular.module('my-controllers',[]);
// Controller One File
angular.module('my-controllers').controller('oneCtrl',[...]);
//Controller Two File
angular.module('my-controllers').controller('twoCtrl',[...]);
I did this to the services file as well, no need to change the main application module file you'd still be injecting the same modules into that.
One other practice is to stuff controllers, directives, etc in their own modules and inject those modules into your "main" one:
angular.module('app.controllers', [])
.controller('controller1', ['$scope', function (scope) {
scope.name = "USER!";
}]);
angular.module('app.directives', [])
.directive('myDirective', [function () {
return {
restrict: 'A',
template: '<div>my directive!</div>'
}
}]);
angular.module('app', [
'app.controllers',
'app.directives'
]);
Nothing is left in the global scope.
http://plnkr.co/edit/EtzzPRyxWT1MkhK7KcLo?p=preview
I like to divide my files and my modules.
Something like this:
app.js
var myApp = angular.module('myApp', ['myApp.controllers', 'myApp.directives', 'myApp.services']);
myApp.config(['$routeProvider', function($routeProvider) {
/* routes configs */
$routeProvider.when(/*...*/);
}]);
directives.js
var myDirectives = angular.module('myApp.directives', []);
myDirectives.directive( /* ... */ );
service.js
var myServices = angular.module('myApp.services', []);
myServices.factory( /* ... */ );
Im not a big fan of the "chained style", so I prefer to write down my variable always.
I suggest to follow Angularjs Style Guide.
They handle all concept from naming convention, to modularize your app and so on.
For angular 2, you can check Angular 2 Style Guide
For me, chaining is the most compact way:
angular.module("mod1",["mod1.submod1"])
.value("myValues", {
...
})
.factory("myFactory", function(myValues){
...
})
.controller("MainCtrl", function($scope){
// when using "Ctrl as" syntax
var MC = this;
MC.data = ...;
})
;
That way I can easily move components between modules, never need to declare the same module twice, never need any global variables.
And if the file gets too long, solution is simple - split into two files, each declaring its own module at the top. For more transparency, I try to keep one unique module per file and name it resembling the full path of the file. This way also I never need to write a module without [], which is a common pain point.