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.
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
I agree. And this is pretty important, I think. I struggled with various ways to handle file structure when I first started with Angular because most example/guides used the type of structure Todd shows as "Good". But I found things became very cluttered very quickly that way.
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.
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.
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.
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.
``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.
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.
> 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.