The 'controllers/directives/services' grouping is straight up moronic.
I build based on features, with all the code and tests of a feature placed together, with any shared dependencies lower down in the directory structure.
I build based on features, with all the code and tests of a feature placed together, with any shared dependencies lower down in the directory structure.
Heh, I'm just imagining code bubble up :P
Though that's definitely a wrong way to think of it since it's a call tree, but it always bugged me that in JS, you'd have to download dependency code you might not use (hence important code "bubbles up"). That's why I'm intrigued to try Dart for it's "tree-shaking" compiler that removes unused code from dependent libraries.
I tend to agree, and this is how I'd organize a larger Angular app, but to be honest I don't think it makes a huge impact in the long run. Rails apps are divided into dirs for models/controllers/views/etc and while I would rather have them organized by feature, they're still easy enough to navigate with modern code editing tools. It's certainly not one of the main contributing factors to how horrible big Rails apps get...
The most important question is "can I quickly guess what directory this directory lives in?"
When you come across directives that clearly feel "utility", you will be tempted to look in a utility folder. When a directive is something tightly coupled to a feature, you might be tempted to first look in the directory related to that feature.
I forgot to add, I will also create a directory tree for singular service dependencies, so that a service can have multiple, non-shared, dependencies that are each considered a 'feature' and consequently have their own folder containing their code and tests.
I need to blog this, but node is fighting with osX on my macbook right now. I am not a happy camper.