

Opinionated AngularJS styleguide for teams - uptown
http://toddmotto.com/opinionated-angular-js-styleguide-for-teams/

======
aikah
.

> Resolve promises in router, defer controllers

Absolutely not,you want to display something while you query the server.using
resolve will block the router and not display the next view up until the
promise is fullfield or rejected.It's perfectly fine to limit the router to
routing and not stuffing it with business logic.

> Project/file structure

Wrong again, group files by modules/features ,dont put 1 service per file or
one controller per file.We are not writing java packages here, but javascript
modules.

At least you admit it is opinionated ,but at lest half of your opinions
shouldnt even be followed.

~~~
john2go1
Using resolve is by far the best option, the creator of Angular wanted a way
to do this and the feature landed:
[http://stackoverflow.com/questions/11972026/delaying-
angular...](http://stackoverflow.com/questions/11972026/delaying-angularjs-
route-change-until-model-loaded-to-prevent-flicker)

Structuring files/folders is debatable based on code base size/estimation, no
opinion is "wrong".

~~~
kyllo
_Structuring files /folders is debatable based on code base size/estimation,
no opinion is "wrong"._

Yep, that's why he labeled both ways as "good".

------
tzaman
Finally, someone with opinion, so far most articles on the topic have been too
_soft_ in terms how an Angular app should be written and organised.

However there is one point I disagree with: files and folders should be
organised per-feature/functionality, not Rails-like. When you have 40+
services, and 100+ of directives, it can become tedious to work on these
separate files. That's why I recommend to put files that do common stuff
together. For example we have _auth_ folder that holds the service, a couple
of directives (like for password inputs), all possible states (we use ui-
Router) and controllers, in total 8 files:
[http://cl.ly/image/2o0Q1n1m2M32](http://cl.ly/image/2o0Q1n1m2M32)

~~~
acconrad
It depends on the size of your codebase. For small codebases, I separate
folders by object type (e.g. apps/, /controllers, /directives), but as
codebases grow in size, we have adapted to the style you mention, separating
by functionality.

~~~
joekrill
But then you have to go and rearrange everything as your codebase gets larger.
Assuming it will get larger, that is.

~~~
john2go1
Good estimates will help decide logical codebase size guesses! :)

------
Cthulhu_
Re: module method definitions: is the IIFE still required if you'd just put a
named function in the call to .controller()? I try to avoid boilerplate (like
IIFE's) whenever possible; vanilla AngularJS doesn't seem to require IIFE's in
most cases when defining controllers as anonymous functions.

Similarly, this approach seems to require adding a block of comment-
boilerplate so ng-annotate doesn't get confused; inlining it would avoid this.

I can see that particular method for module definitions taking up seven lines
of extra boilerplate code vs just inlining the (named) function in the call to
.controller(), and I'm not seeing any definitive advantages.

~~~
robbs
Came here to make a similar comment. I'd rather inline the function than wrap
every file in an IIFE.

~~~
john2go1
Wrap the entire app in an IIFE, not every file.

------
collyw
Style guides are nice for making code look consistent and pretty on the
outside, but I think far too much emphasis is placed on them (maybe because I
use Python), compared to app design. Style guidelines won't make the slightest
difference if your data model is crap.

~~~
joekrill
True, but I think app design benefits from a solid style guide. A great data
model with no consistent coding style is going to be much more difficult to
work with than one backed by a well thought out style guide.

------
pyritschard
``Angular modules can be declared in various ways, either stored in a variable
or using the getter syntax. Use the getter syntax at all times.''

It would have been nice to know the reasoning behind this. It does make
minification marginally easier (but later on in the document, the DI notation
is not used for $routeProvider which prevents minification from hapening
anyhow), apart from that I fail to see any advantage to that approach.

------
Bahamut
I pretty much agree with all of these opinions in this styleguide. There are
some subtle points unsaid in the formation of some these opinions which make
them preferable in general.

