It appears that the when multiple modules have factories with the same name, the last one wins. jsfiddle
I've seen posts suggesting the conventions for naming the factories with fooBar, foo2Bar or foo.bar foo2.bar to avoid naming conflicts
However, prefixing each factory with module name seems pretty ugly to me. Is there any other better way, or is there any way to have private services that's only local to the module?
You don't like foobar? Seems like a pretty good convention to me.
However you can 'namespace' your javascript code if you'd like.
http://enterprisejquery.com/2010/10/how-good-c-habits-can-encourage-bad-javascript-habits-part-1/
Related
I've seen both of the following methods to use a filter in a controller/service:
$filter('myFilter')('myStuffToFilter', myFilterArgument)
myFilterFilter('myStuffToFilter', myFilterArgument)
They work equally well. Which method constitutes best practice?
While this is not a ground-breaking issue, I believe there is a difference and it's worth sharing (as did pkozlowski.opensource in his answer to a related question). Option 2 is better for the following reasons:
Cleaner syntax: It's a little cleaner, more straight forward and avoids the sequential parentheses syntax which is less common.
Provided solution: The myFilterFilter object is not available for code injection by accident. The AngularJS creates these <filtername>Filter objects for all filters (pre-defined and custom) and makes them available to the injector.
Documented solution: The AngularJS documentation recommends this solution in their documentation here.
I have joined a team where we are using AngularJS. I have good amount of experience in Javascript however have just started on AnjularJS. We are following John Papa's guideline as a general approach. We are using Controller as syntax everywhere. As part of the team discussion one point was raised in the context of keeping Controllers thin. And some of the members are of the view that all the methods should be defined as part of Controller's prototype instead of instance methods(attached to this).
I searched a lot but i didn't get any particular advantage/disadvantage of using this approach over instance methods other than
1) of having shared memory for the functions.
2) Inheritance can be used to share/reuse functionality in a controller hierarchy(I doubt if this is a common scenario in AngularJS controllers and if having hierarchy of controllers is good idea.)
What we have decided is
1) all methods should be added to prototype of controller
2) dependencies injected should be exposed by attaching them to "this" variable so that they are available to proptotype methods.
Would like to know any clear advantages and disadvantages from AngularJS perspective.
I have received a concrete answer from John Papa whose guideline we follow and it matches with what I was thinking.
https://github.com/johnpapa/angular-styleguide/issues/524
However I would still like any other reasons with advantage/disadvantage. This is because the main issues here is keeping the controller(specifically controller constructor function) thin. Without moving methods to prototype is there generic ways to achieve this?
of having shared memory for the functions
Why do you want to share functions ? I do not see any advantage.
This is because the main issues here is keeping the controller(specifically controller constructor function) thin.
If this is the problem, instead of thinking that shared object functions, will solve this.Try to refactor you controllers : as their name tells, they must have a simple task => Control. They do not do the stuff, they just ask.
Extract logic in services.
Do not manipulate dom in controllers, use directives (are you injecting $document ?).
Extract simple formatting/presentation manipulations in filters.
I'm working on a a large scale angular project with a team of devs.
the problem we run into is if you have several files for a component, say a directive.
some-directive.js
some-directive-controller.js
in the definition of both files you would have to attach them to a module, however one file must create the module with []. If the developer forgets to poke around they will add [] in the second file called will actually overwrite the module. so now it becomes a memory game. Each developer has to remember to only declare the module in one file []
some-directive.js
angular.module('some-module',['some-dependencies']).directive('some-directive',function(){});
some-controller.js
angular.module('some-module',[]).controller('some-controller',function(){});
we have been using the following approach. Is there a better way?
some-directive.js
some-directive-module.js
some-directive-controller.js
where some-directive-module only contains the module creation, includes any dependencies, and does any .config needed. Still the dev needs to remember to
angular.module('some-directive') in all the other files without the square brackets.
some-directive-module.js
angular.module('some-directive',[])
.config(//someconfig stuff);
some-directive-module.js
angular.module('some-directive).directive(//declare directive);
some-directive-controller.js
angular.module('some-directive).controller(//declare contrller used by directive);
I suggested that instead we should do the following, it eliminates the issue of overwriting modules, but I received some negative feedback from one of the other devs
some-directive-module.js
angular.module('some-directive',['some-directive.directive','some-directive.controller'])
.config(//someconfig stuff);
some-directive-module.js
angular.module('some-directive.directive',[]).directive(//declare directive);
some-directive-controller.js
angular.module('some-directive.controller',[]).controller(//declare contrller used by directive);
Is there a better way? Or is one of the above options correct?
The recommended way (by multiple competent people) is to use the setter-getter-syntax (creating once with angular.module("someModule",[]) and accessing with angular.module("someModule") from there on). Putting the module definition and configuration into one file seems very clean and is common practice between a lot of developers. But make sure not to create a module for every single directive - group services, directives, constants and so on into reasonable functionality-modules instead.
Making clear what a file contains by its name is also a good idea in my opinion, so your some-directive-module.js approach seems fine to me. If developers "poke around" and "wildly add []", they should get a slap on the wrist follwoed by an explanation how modules work in angular, so they stop doing it ;-)
Traditionally I have managed my Angular code like this
//File 1
angular.module('name',[])
//File 2
function TestController(){
}
TestController.prototype.// inherited stuff
angular.module('name').controller('testController',TestController);
This worked great and allowed me to partition my files easily. Now I try to upgrade to 1.3 and get the infamous...
Error: [ng:areq] Argument 'TestController' is not a function, got undefined
Of course this is due to this change which claims a desire to clean up the way people write code. What about this pattern is more complex? Is there a way to maintain this pattern without changing the global settings?
There is actually a comment on the page you linked to that had a fairly solid explanation.
Global controllers refer to your controllers being defined as function
on the window object. This means that they are openly available to
conflict with any other bit of JavaScript that happens to define a
function with the same name. Admittedly, if you post-fix your
controllers with ...Controller then this could well not happen but
there is always the chance, especially if you were to use a number of
3rd party libraries. It is much safer to put these controller
functions inside the safety of a module. You then have more control
over when and where this module gets loaded. Unfortunately controller
names are global across an individual Angular app and so you still
have the potential for conflict but at least you can't clash with
completely different code in the JavaScript global namespace.
So the idea is that global controller functions could conflict with any other global function in any javascript you use. So to eliminate the chance of a conflict with your own code or a third-party script, not using global controllers makes your code safer and more consistent.
As mentioned in the comments by #Brett, you can use IIFE around your prototyping. Here is an update of your plunk that uses that. The main change just looks like this.
(function() {
TestController.prototype.name = 'World'
})();
What comes to my mind is 2 things:
1) in that way functions wont be kept in memory more than they should.
2) if you minify your code, minifyer will have to generate new names for all global objects, which is sfine when you have small project, but will be a problem when it's not.
Also it should prevent tests to modify unnecessary data.
I am new to Backbone, and I have found myself writing views which rely on values of the options object to function properly. In other words, my options are mandatory. That doesn't sound right, so I'm wondering if perhaps I'm misusing the options parameter, and if so, what's a better way of doing things?
Dependency injection is a not bad practice at all. It's actually common practice especially dealing with Views. It also makes it easier to unit test your view. So using the options to get some required attributes to build your View is completely OK. Maybe a you could share some examples of what you think is wrong?