4 ms·

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, wit

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.

ilovecomputers 13y ago
> 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.
snikch 13y ago
What do you do for directives that are shared across your whole app?
- WalterSear 13y ago
  Since they won't be used by the main application (ie - app.js, routing, etc, etc), just by features, they bubble up to the root 'features' directory that is contained in the scripts directory. 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.
- deleted 13y ago
  [deleted]
- astral303 13y ago
  I agree with WalterSear that organizing by feature is best. For things that are shared, I like to have a shared/util directory for the miscellania, grouped by purpose (as needed). So, say, if you end up with a few directives used for form validation, you might end up with a util/validation directory somewhere. 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.
tdumitrescu 13y ago
> The 'controllers/directives/services' grouping is straight up moronic 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...
marknutter 13y ago
I do it both ways. Major features I pull out into a features folder, but the main skeleton of the app I keep in monolithic controller/directive/services files (or folders if necessary). It encourages me to keep my controllers skinny while providing a place for shared logic to live. It's a good compromise.
- WalterSear 13y ago
  I missed out a part of what I do - in order to properly encapsulate and test functionalities within services, they are built out of smaller services that I can test individually, and these get their own directory folders and trees, so long as they are dependencies of an individual service.

ilovecomputers 13y ago

> 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.

snikch 13y ago

What do you do for directives that are shared across your whole app?

WalterSear 13y ago
Since they won't be used by the main application (ie - app.js, routing, etc, etc), just by features, they bubble up to the root 'features' directory that is contained in the scripts directory. 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.
deleted 13y ago
[deleted]
astral303 13y ago
I agree with WalterSear that organizing by feature is best. For things that are shared, I like to have a shared/util directory for the miscellania, grouped by purpose (as needed). So, say, if you end up with a few directives used for form validation, you might end up with a util/validation directory somewhere. 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.

tdumitrescu 13y ago

> The 'controllers/directives/services' grouping is straight up moronic 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...

marknutter 13y ago

I do it both ways. Major features I pull out into a features folder, but the main skeleton of the app I keep in monolithic controller/directive/services files (or folders if necessary). It encourages me to keep my controllers skinny while providing a place for shared logic to live. It's a good compromise.

WalterSear 13y ago
I missed out a part of what I do - in order to properly encapsulate and test functionalities within services, they are built out of smaller services that I can test individually, and these get their own directory folders and trees, so long as they are dependencies of an individual service.