5 ms·

The Angular Seed's way of organizing a project does not scale well as it organizes javascript files by type instead of grouping the types into different modules

The Angular Seed's way of organizing a project does not scale well as it organizes javascript files by type instead of grouping the types into different modules [1]. My team has found it successful, especially among new devs, to organize our controllers/services/whatevers in terms of features or areas of concern. This way a new programmer will find the part of the web app she only needs to worry about and ignore the rest. Its a great way of establishing clarity and conforming your code base to the way programmers think about your project. Another gripe I must bring up with Angular is the lack of proper tools. Batarang has not updated for 7 months and it leaves so much to be desired for debugging with the Angular framework (especially when viewing bindings). Irregardless, these small pains I feel toward Angular are worth trading in the greater pain I feel from Vanilla/Jquery JS development. [1] http://cliffmeyers.com/blog/2013/4/21/code-organization-angularjs-javascript http://cliffmeyers.com/blog/2013/4/21/code-organization-angu...

WalterSear 13y ago
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.
xonecasacenox 13y ago
Wow, this is great. Thank you for sharing this with me!
tomelders 13y ago
We're keeping our code as discreet components, each component has it's own folder in which you'll find the js, html and _scss file for that component only. The js file contains the directive and the controller, and the html is pulled in using require.js' text plugin. Then the controllers.js file only handles the routing controllers, and the html for each route is built solely out of components. I resisted using require at first because it seemed like clunky cruft on top of Angular's cruftless dependency injection, but I was wrong and this way of working has been a lot of fun, relatively stress free and great for new devs since they just need to get their head around the way a component is put together and they never have to worry about other parts of the app.
- ilovecomputers 13y ago
  Care to share how you use Require with Angular? I know it requires you (hehe) to manually bootstrap Angular.
  - tomelders 13y ago
    I used this tutorial as a starting point. http://www.startersquad.com/blog/angularjs-requirejs/ http://www.startersquad.com/blog/angularjs-requirejs/
  - tomelders 13y ago
    FYI: I just started a new project and decided to go with a slightly different setup that achieves the same thing. I would recommend using the angular-require-seed as a starting point as opposed to the tutorial I suggested earlier. The credit for this stuff has to go to a guy called Tim Kendrick whom I work with. He set up the project that my project is based on. He figured out the project structure and I've basically copied it with a few minor adjustments. https://github.com/tnajdek/angular-requirejs-seed https://github.com/tnajdek/angular-requirejs-seed You can structure the app however you want, but I would suggest having a component directory which is structured like this... --------- src/js/components |- myComponent |- myComponent.js |- myComponent.html |- _myComponent.scss --------- Then you need an extra module that you inject when you're defining your app. This module is responsible for injecting all the components you want to include, here's a Gist https://gist.github.com/gargantuan/8902061 https://gist.github.com/gargantuan/8902061 So every time you create a new component, you have to require it in components.js AND you have to include the sass partial in your main .scss file. On the subject of sass, you'll need to prevent sass files being included more than once. Fortunately 'courtismas' has a solution for that https://gist.github.com/courtsimas/1167053 https://gist.github.com/courtsimas/1167053 Other notes: I'm using Gulp for my build tasks. I can't recommend it enough. I'm looking into creating a Gulp task that will generate a JSON manifest of components so new components are automagically included in the app. That way there's no need to manually maintain the sass and components.js files.
vladgur 13y ago
This is essentially an ng-boilerplate[1] way of organizing things. [1] https://github.com/ngbp/ngbp#readme https://github.com/ngbp/ngbp#readme
vladgur 13y ago
A very usefull hint I got from a MV AngularJS meetup few months ago: if you select an element in DOM inspector in Chrome, its scope will be accessible via $scope in the console Another trick that I use daily: to get a reference to some service(or anything injectable for that matter) from the console: angular.element(document).injector().get('myService')
- fantastical 13y ago
  The first trick requires having the Angular Batarang installed, right? Still cool, I didn't know about that. I've been manually typing angular.element($0).scope() like a sucker.
krsunny 13y ago
I wish I could find a company to work for that gave even the slightest concern for new developers and/or helping them get up to speed.
- ilovecomputers 13y ago
  Even experienced developers don't want to wad through unnecessary crap when they first get started with a project ;)
thomasvarney723 13y ago
Am I the only one going to point out that "irregardless" is not a word?

WalterSear 13y ago

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.

xonecasacenox 13y ago

Wow, this is great. Thank you for sharing this with me!

tomelders 13y ago

We're keeping our code as discreet components, each component has it's own folder in which you'll find the js, html and _scss file for that component only. The js file contains the directive and the controller, and the html is pulled in using require.js' text plugin. Then the controllers.js file only handles the routing controllers, and the html for each route is built solely out of components. I resisted using require at first because it seemed like clunky cruft on top of Angular's cruftless dependency injection, but I was wrong and this way of working has been a lot of fun, relatively stress free and great for new devs since they just need to get their head around the way a component is put together and they never have to worry about other parts of the app.

ilovecomputers 13y ago
Care to share how you use Require with Angular? I know it requires you (hehe) to manually bootstrap Angular.
- tomelders 13y ago
  I used this tutorial as a starting point. http://www.startersquad.com/blog/angularjs-requirejs/ http://www.startersquad.com/blog/angularjs-requirejs/
- tomelders 13y ago
  FYI: I just started a new project and decided to go with a slightly different setup that achieves the same thing. I would recommend using the angular-require-seed as a starting point as opposed to the tutorial I suggested earlier. The credit for this stuff has to go to a guy called Tim Kendrick whom I work with. He set up the project that my project is based on. He figured out the project structure and I've basically copied it with a few minor adjustments. https://github.com/tnajdek/angular-requirejs-seed https://github.com/tnajdek/angular-requirejs-seed You can structure the app however you want, but I would suggest having a component directory which is structured like this... --------- src/js/components |- myComponent |- myComponent.js |- myComponent.html |- _myComponent.scss --------- Then you need an extra module that you inject when you're defining your app. This module is responsible for injecting all the components you want to include, here's a Gist https://gist.github.com/gargantuan/8902061 https://gist.github.com/gargantuan/8902061 So every time you create a new component, you have to require it in components.js AND you have to include the sass partial in your main .scss file. On the subject of sass, you'll need to prevent sass files being included more than once. Fortunately 'courtismas' has a solution for that https://gist.github.com/courtsimas/1167053 https://gist.github.com/courtsimas/1167053 Other notes: I'm using Gulp for my build tasks. I can't recommend it enough. I'm looking into creating a Gulp task that will generate a JSON manifest of components so new components are automagically included in the app. That way there's no need to manually maintain the sass and components.js files.

vladgur 13y ago

This is essentially an ng-boilerplate[1] way of organizing things. [1] https://github.com/ngbp/ngbp#readme https://github.com/ngbp/ngbp#readme

vladgur 13y ago

A very usefull hint I got from a MV AngularJS meetup few months ago: if you select an element in DOM inspector in Chrome, its scope will be accessible via $scope in the console Another trick that I use daily: to get a reference to some service(or anything injectable for that matter) from the console: angular.element(document).injector().get('myService')

fantastical 13y ago
The first trick requires having the Angular Batarang installed, right? Still cool, I didn't know about that. I've been manually typing angular.element($0).scope() like a sucker.

krsunny 13y ago

I wish I could find a company to work for that gave even the slightest concern for new developers and/or helping them get up to speed.

ilovecomputers 13y ago
Even experienced developers don't want to wad through unnecessary crap when they first get started with a project ;)

thomasvarney723 13y ago

Am I the only one going to point out that "irregardless" is not a word?