This is an example code project for my AngularJS-ORM talk at NGConf 2014.
Slides: Slid.es/ProLoser/AngularJS-ORM
Original Code (Coffeescript + Sockets): coffee-sockets
In today's code, it's sensible keep modules together and small. HTML, JS and CSS are closely tied together, so we should organize projects that way.
A lot of people will create what I refer to as 'one-off' directives. They should usually just be sub-states.
Even though you have an Auth service, or something else, you should always have them bubble their results up to the top of the promise chain. Alway do URL / state jumping from controllers or state definitions, otherwise people have to go diving through a deeply nested chain of service callbacks to figure out why they keep getting an infinite redirect loop. Your services should be implementation agnostic.
Your controllers should be implementation agnostic. Occasionally people use the ui-boostrap/modal
service which lets you specify a controller and template and resolves. Inside that controller, you have access to $modalInstance
, which is actually very bad practice. This means if your boss decides one day to no longer use a modal, you have to refactor the controller too (albeit trivially). Instead, have the $modalInstance
resolve in a state definition, and use the onEnter()
and onExit()
callbacks to clean up implementation-specific logic. This leaves the controller free to just focus on it's internal view-related matters. Example
I use ES6 because it gives me easy-to-code classes and because the last line is always returned in arrow functions (which is great for promise chaining). You do not have to use ES6, and should not refactor into it 'just because'.
Javascript:
function( x, y, z ){
return z
}
function x(z) {
// constructor
this.y = z;
}
x.prototype.method = function(){}
ES6
( x, y, z ) => {
this.whatever // `this` is bound to OUTER scope
z // last line of functions are always returned
}
class x {
constructor(z) {
this.y = z;
}
method(z) {}
}