Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AngularJS Style Guide

gocardless.com

Post reply on HN
Print view View original

31–40 of 41 posts

Re: AngularJS Style Guide

#31

Post by Kiro »

Bahamut wrote: post #8
mck- wrote: post #5

Todd Motto's angular style guide [1] has been one of the most helpful to me. It's always good to read multiple style guides and cherry-pick what works best for you :) [1]: https://github.com/toddmotto/angularjs-styleguide

The recommendations in the module section are pretty awful - I'd avoid doing so, and every other expert in the community I've spoken to also disagree with that suggestion of using global functions wrapped in an IIFE to prevent it from being published on window, which seems to exclusively come out of Google.

What's so bad about it?

Re: AngularJS Style Guide

#32

Post by creatio »

Bahamut wrote: post #8
mck- wrote: post #5

Todd Motto's angular style guide [1] has been one of the most helpful to me. It's always good to read multiple style guides and cherry-pick what works best for you :) [1]: https://github.com/toddmotto/angularjs-styleguide

The recommendations in the module section are pretty awful - I'd avoid doing so, and every other expert in the community I've spoken to also disagree with that suggestion of using global functions wrapped in an IIFE to prevent it from being published on window, which seems to exclusively come out of Google.

What should be used instead?

Re: AngularJS Style Guide

#33

Post by danielbarla »

vorador wrote: post #30
cageface wrote: post #29

Earlier quoted context omitted.

That's reassuring. I look at some of the code examples and all the $vars and it looks very obscure. I guess the forthcoming 2.0 version is supposed to simplify things a lot and make it play nicely with web components though so maybe it's worth getting on board now.

To contrast with what the OP said, I found Angular pretty cool at the beginning but got more and more annoyed as I progressed. If you're okay with interacting with a black box, go for it otherwise choose react.

This is a distinct possibility, and I did run into one or two of these situations already. In my case, digging slightly into Angular's internals for workarounds was relatively successful.

An example is Angular's treatment of HTML forms and input elements, w.r.t. things that you'd expect, such as name / id interpolation (namely: Angular doesn't interpolate dynamic form names as you'd expect - [1] and [2]). In cases like this, digging into the internals to resolve the initial surprise and later solve the problem was slightly frustrating.

[1] https://github.com/angular/angular.js/issues/1404

[2] http://jsfiddle.net/Thinkscape/23RPt/

Re: AngularJS Style Guide

#36

Post by Keats »

awinder wrote: post #21

Anyone have experience one way or the other with the pattern of including test files with the features as opposed to under an alternate directory structure? I usually put tests and application code in parallel directories so that the tests are all in one place, but curious if anyone has seen big advantages one way or the other

I do the same, mainly because I don't want to go through all the possible features folders to find the tests (I also put templates in a separate directory). The advantage of grouping everything is you can just copy paste a feature and have everything needed in one go but I still find having separate directories simpler for me.

Re: AngularJS Style Guide

#37

Post by imjoshholloway »

prima-facie wrote: post #35

Is this article an ad?

Isn't every blog post an ad of some description? Company blogs are designed to drum up interest in the product / service being offered. However, I'd say this post been written to advertise the style-guide they've open-sourced more than anything.

Re: AngularJS Style Guide

#38

Post by MaybiusStrip »

I still don't understand why everyone recommends different folders at the project root for controllers, directives, services, etc... You end up with closely related code being far apart. It's a thoughtless way of dividing up your files based on the most obvious feature rather than how things actually fit together.

My idea of a good modular file structure is that you could delete any random directory and delete it and it would lop off that feature as cleanly as possible. Each directory should represent an angular module, and each module should contain the routing, controllers, services, directives, and tests that it uses. If some of these are used across the app then you can have a "common" module.

Re: AngularJS Style Guide

#39

Post by olov »

mushishi wrote: post #34
theflubba wrote: post #14

Meh. NgAnnotate is way better than duplicating code. Be DRY, not pedantic.

I have heard that it has trouble working in a complex build/development environment, e.g. when watching live file changes* with gulp/browserify. *) https://www.npmjs.org/package/gulp-watchify/

Hmm. There are no open bugs for that on the gulp-ng-annotate or browserify-ngannotate repos. https://github.com/Kagami/gulp-ng-annotate/issues and https://github.com/omsmith/browserify-ngannotate/issues

Feel free to open issues and I'm sure it will be addressed.

ng-annotate itself just produces output for input (stdin/stdout or via files) so it does not at all have any trouble participating in a "complex build environment".

Re: AngularJS Style Guide

#40

Post by RangerScience »

MaybiusStrip wrote: post #38

I still don't understand why everyone recommends different folders at the project root for controllers, directives, services, etc... You end up with closely related code being far apart. It's a thoughtless way of dividing up your files based on the most obvious feature rather than how things actually fit together. My idea of a good modular file structure is that you could delete any random directory and delete it and…

Compare Rails and Django. Note that Django apps, which are meant to be made of stand-alone "apps", generally aren't - the apps end up relying on each other too much.

This seems to be because certain of what makes up each set of functionality "bleed" together - models, in particular, all seem to end up relying on each other.

I think the MVC / CDS, etc organizational structures are less about grouping things by feature and more about grouping things by common "bleed" factors (or, more likely, some deeper commonality that then causes the shared amount of "bleed"). Views pretty much never share anything. Controllers share utility functions. Models just go spaghetti.

You can also think of it like a toolbox; I keep all the screws together, rather than keeping all the flat-head screws with the flat-head screwdrivers.

That all said - Yeah, that's an excellent ideal, but it's not one that seems to occur in practice.

Post reply on HN