AngularJS Style Guide
gocardless.com
gocardless.com
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.
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.
Should I invest the time and learn Angular or go with React instead? Web components seem likely to change the whole web development landscape but my impression is that they're not quite ready for prime time yet.
It doesn't provide a complete opinionated framework like Angular. You have to pair it with the right 3rd party components to get a full SPA kit, but I like that better. I don't always need a full SPA either.
Having recently picked up Angular, I can perhaps comment on this. Once you're past a few questions of where to put what, development with Angular is fairly straightforward. If you've dealt with two-way data binding before, it's even simpler.
I suspect you should be able to pick it up to a reasonable degree (one where you can decide if you'd like to stick with it) within a week or two at most, even in your spare time. In retrospect, I'm not sure I'd call it complicated any more.
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.
...It seems easy enough (given that I haven't actually taken something through what I'm about to suggest...) to go from zero independent JS - only using existing directives - smoothly and gradually into a full browser-side MVC. Start with directives, add some controllers, now a service or two and eventually some routing....
I also recently finished my first big feature using Angular, and am now ripping out most of the guts because I've realized that The Angular Way would let me do things drastically simpler. So I think there's some actual simplicity in how you can use it that may be hard to spot at first, or may not be apparent when you're coming from a different cognitive toolset (not that I know of anything other than Angular that I can for sure say has the same or a similar toolset...). As I grok it more, I like it more, but some stuff still gives me issue. I just don't use those parts until I understand, and then I delete the two-thirds of my code I don't actually need.
Also: I don't know ReactJS, so don't take this as a comparison to it in any way.
One thing I'm hesitant about is their advice to use directives instead of ng-controller="MyCtrl". Since controllers really are app specific glue code I rarely find myself wanting to reuse them - what advantages are directives supposed to give here?
You can also define a controller and have the directive consume it via named reference - here is one example that makes use of this: https://github.com/driftyco/ionic/blob/master/js/angular/dir...
Controllers should be consumed this way, so that they become easier to test. Testing directives can get complicated.
This makes it easy to work with data that doesn't change, promises, or large amounts of data that rarely changes.
Karl Seamon did a great talk about performance this past January at ng-conf as well, https://www.youtube.com/watch?v=zyYpHIOrk_Y
As to newer stuff, I believe Karl is specifically talking about 1.2 (might of been a release candidate or beta at the time) so his talk should be applicable to the newest stable version, and I've found that to be true so far.
As an aside, and I haven't objectively measured it or even really investigated it, it seems angular's 1.x stable versions aren't coming out as fast as they once did (it feels like 1.3 has been in rc/beta forever and 2.0 doesn't even seem to be out of the planning stages). So at this point I think 1.3 stable will be released in the next few months and hopefully they will have an updated talk on performance at the next ng-conf in March.
Normally if I'm working on eg a directive I jump across all of it's files, so having them in a single folder makes it much easier.
From a grunt/karma POV, it should be easy to flag specs as: \*.spec.js
That said, this style guide definitely has the strongest (almost convincing) argument I've seen for using controllerAs and does not have the inconsistencies I've found in other guides (`this` is not bound to `$scope` as a couple popular guides claim). Good stuff.
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".
I disagree. We have a mixin heavy product (about 100k LOC) and the mixins, if designed judiciously, help ensure that we have good reuse of code. So I'd like to see some examples to support the case of "verbose over DRY", I haven't yet found that to be a "good thing(tm)", but some concrete examples could help.