7 ms·

AngularJS project structure

93 points by gurgus 11y ago

paulojreis 11y ago
"AngularJS for the front end allows someone who sucks at front end work to be able to produce some pretty useful interfaces". That's actually a nice way to explain its success, for better and for worst. Spot on, IMO.
rileyteige 11y ago
>Enter problem two. What happens when my project has heaps of controllers/services etc… I now have directories that could have a lot of files and none of them are particularly easy to find. My team uses Angular 1.4.7 for a very large project (hundreds of JS files, dozens of views/controllers/services). We have in our JS folder a services folder, controllers, directives, etc. No subfolders except in our directives folder which has some directives which are only applicable to a specific area of the application. Services by convention are just the name of the topic at hand, no "service" suffix (i.e. alert.js, user.js). We have had no issues as far as file navigation goes. I grant that convenience to our development environment. We run a primarily .NET stack and leverage Visual Studio 2015 so the "CTRL + comma" keyboard shortcut makes it very easy to work with these relatively large folders. My main point being I think the development environment plays a very large role in whether structure A or structure B will be more optimal for your team. If a CLI were going to be our means of navigation, this structure would be much more challenging to work with and I don't have a good suggestion for that circumstance.
- neals 11y ago
  CTRL + what?
  - crabl 11y ago
    CTRL + comma
  - rileyteige 11y ago
    What user crabl said. Edited for clarity.
maaaats 11y ago
Both in our Angular and React codebases, we group things by functionality. Ideally, we should be able to take a folder (and its subfolders) and make them a separate npm-package. In the past, we have actually done so successfully, and can share and reuse these modules through our internal npm (Nexus).
buckbova 11y ago
As far as I know this is a solved problem. I used this guide when starting out with angular. Helped a lot to start and keep everything organized. https://github.com/johnpapa/angular-styleguide/blob/master/a1/README.md#application-structure-lift-principle https://github.com/johnpapa/angular-styleguide/blob/master/a...
- wavefunction 11y ago
  We've adopted this style guide at my work-place. I created a few AngularJS apps before running into this great resource and every thing it proposes matches my experiences and intuition from poking and prodding the library.
- sotojuan 11y ago
  Isn't Papa a big deal in the Angular community? Wish the big React people would do something similar. Every project I see has a different structure.
- ErikAugust 11y ago
  Great guide. All sorts of good ways to organize your modules and code - not just for files. Big improvements in readability in a lot of cases.
andybak 11y ago
Isn't it redundant to prefix have a file in the foo directory called foo.controller.js ? I sense a weakness in someone's editor/IDE. Personally I'd call it controller.js and expect my tools to not make that problemmatic
- maaaats 11y ago
  What would you name the controller in the code in that case? It's annoying to have mismatch between a file's content and the name, and having all controllers in the app be named "controller" makes debugging hard.
- buckbova 11y ago
  Sure, but it feels natural to me. File is foo.controller.js and is named FooController within.
  - wavefunction 11y ago
    From back-end to front-end, my experience both from my own work and other's code is that file names and classes or objects should match. FooController defined by FooController.js or FooController.java or whatever your language and extensions might be.
- ZoeZoeBee 11y ago
  foo.controller.js foo.service.js foo.directive.js would all be in different folders, one for controllers, one for services one for directives etc. if you have multiple tabs open in your ide like Webstorm you'd only see foo.js three times over, if you did not prefix it, and be hard pressed to know which is which at first glance. With that said Angular 1 is dead long live Angular 2 :)
  - maaaats 11y ago
    No, the point is to not have separate folders for controllers, directives etc.
    - 11y ago
yegle 11y ago
> I’ve been programming professionally for about 6-7 years now This is an odd statement to me. If you are in tech, do you count how many years you've been programming professionally? I can't, and honestly I don't know if I'm programming professionally in my daily job.
- allannienhuis 11y ago
  Perhaps you're just trying to make a joke - but what's so odd about it? He means that he's been paid to do it for 6-7 years, and suggests that he was doing it unpaid (hobby, school) for longer.
Roboprog 11y ago
I'm working on an Angular app with a Java backend, so much of the directory structure is dictated by Maven. Also, for what it's worth, we don't have a "single page app" (with multiple controllers or whatever). We have a "small number of pages app". This allows for limiting the scope of what is done in each page a bit. Also, while we are not constantly reloading pages like the legacy app this replaces, we occasionally load a new page, which hopefully deals with any resource leaks our imperfect code may have had. That said, within the source directory for client side web files, we have the following: * html/ - app pages (a small number of files) are within this directory. -- html/help/ - sundry help pages put together by analysts are stored here. * css/ - probably overkill, but the main css file is here, and, so far, an alternate "skin" for a subsystem of the app. * js/ - empty in the source, but we do concatenate js files and place them in this spot in the final deployment package (.war file) -- js/lib/ - 3rd party library scripts (e.g. - jQuery, Angular, moment, Ramda ...) -- js/<<app name>>/ - in house scripts. There is a (short-ish) controller script for each page, and perhaps 6 to 10 shared utility scripts. The utility scripts tend to be somewhat long, rather than having hundreds of files, which really bothers me. E.g. - "tags.js" has the directives ("tag libraries", although there are a few custom attributes as well); rest.js is a wrapper around $http and some error / message handling code that does communication with the server. I can't stand the directory structure, which I attribute to JEE historically, that has hundreds (thousands?) of files, and grossly redundant "MaryHartman/MaryHartman" / "Smurf" / "Bat" naming style (directory bat contains BatMobile.src; BatPhone.src; BatBelt.src; BatShit.src and so on) Also, much of what is in the utility files are just single functions (within a namespace object), rather than classes. Currying goes a long way to inject dependencies into a chunk of code, rather than making a bunch of one-trick-pony (single action method) classes.
- Roboprog 11y ago
  See #21 - http://blog.codinghorror.com/new-programming-jargon/ http://blog.codinghorror.com/new-programming-jargon/
zesteh 11y ago
In all our new projects we've started using redux with a smart + dumb component architecture and have had some great success. Redux makes keeping track of everything that's going on in large apps much easier. It also allows for only needing a few "smart" / container components that actually know about redux and global application state that then pass down only what's needed to simpler / "dumb" components. We like this approach so much we've even built out various starter projects. Link to angular 2 project: https://github.com/rangle/angular2-redux-starter https://github.com/rangle/angular2-redux-starter Link to angular 1 project: https://github.com/rangle/angular-redux-starter https://github.com/rangle/angular-redux-starter
- tracker1 11y ago
  I go a minor step further, and pull out the components/actions/reducer by feature... additionally I'll separate out api into a separate file, for interactions with outside pieces (cors/xhr, etc), this way action creators don't have the logic for xhr requests (fetch or axios), and it's pretty clean... I use redux-thunk and redux-actions too. Even for angular, it's a pretty nice workflow... I really don't care as much for angular as react. When the workflow is mostly the same, the quirkiness of angular (1 & 2) just stand out more imho.
tracker1 11y ago
I tend to favor organizing by feature... /feature/subfeature/(constants|actions|reducers|api|controls) This way features can be N layers deep, a given feature may not have all of those pieces, some may be data only, some may have actions that are called from other features... in the end, the data/controls etc are closer to the feature that binds them. Api is to abstract any foreign system integration (api calls), where actions (action creators) may use it, and the reducers manage the result... Redux workflow, variance on structure. Tends to work pretty well that way. Actions/reducers may listen/dispatch those defined under other features... again, it's the shape of the data and application that defines these features and their structure.
deleted 11y ago
[deleted]

93 points by gurgus 11y ago

"AngularJS for the front end allows someone who sucks at front end work to be able to produce some pretty useful interfaces". That's actually a nice way to explain its success, for better and for worst. Spot on, IMO.

rileyteige 11y ago

>Enter problem two. What happens when my project has heaps of controllers/services etc… I now have directories that could have a lot of files and none of them are particularly easy to find. My team uses Angular 1.4.7 for a very large project (hundreds of JS files, dozens of views/controllers/services). We have in our JS folder a services folder, controllers, directives, etc. No subfolders except in our directives folder which has some directives which are only applicable to a specific area of the application. Services by convention are just the name of the topic at hand, no "service" suffix (i.e. alert.js, user.js). We have had no issues as far as file navigation goes. I grant that convenience to our development environment. We run a primarily .NET stack and leverage Visual Studio 2015 so the "CTRL + comma" keyboard shortcut makes it very easy to work with these relatively large folders. My main point being I think the development environment plays a very large role in whether structure A or structure B will be more optimal for your team. If a CLI were going to be our means of navigation, this structure would be much more challenging to work with and I don't have a good suggestion for that circumstance.

neals 11y ago
CTRL + what?
- crabl 11y ago
  CTRL + comma
- rileyteige 11y ago
  What user crabl said. Edited for clarity.

maaaats 11y ago

Both in our Angular and React codebases, we group things by functionality. Ideally, we should be able to take a folder (and its subfolders) and make them a separate npm-package. In the past, we have actually done so successfully, and can share and reuse these modules through our internal npm (Nexus).

buckbova 11y ago

As far as I know this is a solved problem. I used this guide when starting out with angular. Helped a lot to start and keep everything organized. https://github.com/johnpapa/angular-styleguide/blob/master/a1/README.md#application-structure-lift-principle https://github.com/johnpapa/angular-styleguide/blob/master/a...

wavefunction 11y ago
We've adopted this style guide at my work-place. I created a few AngularJS apps before running into this great resource and every thing it proposes matches my experiences and intuition from poking and prodding the library.
sotojuan 11y ago
Isn't Papa a big deal in the Angular community? Wish the big React people would do something similar. Every project I see has a different structure.
ErikAugust 11y ago
Great guide. All sorts of good ways to organize your modules and code - not just for files. Big improvements in readability in a lot of cases.

andybak 11y ago

Isn't it redundant to prefix have a file in the foo directory called foo.controller.js ? I sense a weakness in someone's editor/IDE. Personally I'd call it controller.js and expect my tools to not make that problemmatic

maaaats 11y ago
What would you name the controller in the code in that case? It's annoying to have mismatch between a file's content and the name, and having all controllers in the app be named "controller" makes debugging hard.
buckbova 11y ago
Sure, but it feels natural to me. File is foo.controller.js and is named FooController within.
- wavefunction 11y ago
  From back-end to front-end, my experience both from my own work and other's code is that file names and classes or objects should match. FooController defined by FooController.js or FooController.java or whatever your language and extensions might be.
ZoeZoeBee 11y ago
foo.controller.js foo.service.js foo.directive.js would all be in different folders, one for controllers, one for services one for directives etc. if you have multiple tabs open in your ide like Webstorm you'd only see foo.js three times over, if you did not prefix it, and be hard pressed to know which is which at first glance. With that said Angular 1 is dead long live Angular 2 :)
- maaaats 11y ago
  No, the point is to not have separate folders for controllers, directives etc.
  - 11y ago

yegle 11y ago

> I’ve been programming professionally for about 6-7 years now This is an odd statement to me. If you are in tech, do you count how many years you've been programming professionally? I can't, and honestly I don't know if I'm programming professionally in my daily job.

allannienhuis 11y ago
Perhaps you're just trying to make a joke - but what's so odd about it? He means that he's been paid to do it for 6-7 years, and suggests that he was doing it unpaid (hobby, school) for longer.

Roboprog 11y ago

I'm working on an Angular app with a Java backend, so much of the directory structure is dictated by Maven. Also, for what it's worth, we don't have a "single page app" (with multiple controllers or whatever). We have a "small number of pages app". This allows for limiting the scope of what is done in each page a bit. Also, while we are not constantly reloading pages like the legacy app this replaces, we occasionally load a new page, which hopefully deals with any resource leaks our imperfect code may have had. That said, within the source directory for client side web files, we have the following: * html/ - app pages (a small number of files) are within this directory. -- html/help/ - sundry help pages put together by analysts are stored here. * css/ - probably overkill, but the main css file is here, and, so far, an alternate "skin" for a subsystem of the app. * js/ - empty in the source, but we do concatenate js files and place them in this spot in the final deployment package (.war file) -- js/lib/ - 3rd party library scripts (e.g. - jQuery, Angular, moment, Ramda ...) -- js/<<app name>>/ - in house scripts. There is a (short-ish) controller script for each page, and perhaps 6 to 10 shared utility scripts. The utility scripts tend to be somewhat long, rather than having hundreds of files, which really bothers me. E.g. - "tags.js" has the directives ("tag libraries", although there are a few custom attributes as well); rest.js is a wrapper around $http and some error / message handling code that does communication with the server. I can't stand the directory structure, which I attribute to JEE historically, that has hundreds (thousands?) of files, and grossly redundant "MaryHartman/MaryHartman" / "Smurf" / "Bat" naming style (directory bat contains BatMobile.src; BatPhone.src; BatBelt.src; BatShit.src and so on) Also, much of what is in the utility files are just single functions (within a namespace object), rather than classes. Currying goes a long way to inject dependencies into a chunk of code, rather than making a bunch of one-trick-pony (single action method) classes.

Roboprog 11y ago
See #21 - http://blog.codinghorror.com/new-programming-jargon/ http://blog.codinghorror.com/new-programming-jargon/

zesteh 11y ago

In all our new projects we've started using redux with a smart + dumb component architecture and have had some great success. Redux makes keeping track of everything that's going on in large apps much easier. It also allows for only needing a few "smart" / container components that actually know about redux and global application state that then pass down only what's needed to simpler / "dumb" components. We like this approach so much we've even built out various starter projects. Link to angular 2 project: https://github.com/rangle/angular2-redux-starter https://github.com/rangle/angular2-redux-starter Link to angular 1 project: https://github.com/rangle/angular-redux-starter https://github.com/rangle/angular-redux-starter

tracker1 11y ago
I go a minor step further, and pull out the components/actions/reducer by feature... additionally I'll separate out api into a separate file, for interactions with outside pieces (cors/xhr, etc), this way action creators don't have the logic for xhr requests (fetch or axios), and it's pretty clean... I use redux-thunk and redux-actions too. Even for angular, it's a pretty nice workflow... I really don't care as much for angular as react. When the workflow is mostly the same, the quirkiness of angular (1 & 2) just stand out more imho.

tracker1 11y ago

I tend to favor organizing by feature... /feature/subfeature/(constants|actions|reducers|api|controls) This way features can be N layers deep, a given feature may not have all of those pieces, some may be data only, some may have actions that are called from other features... in the end, the data/controls etc are closer to the feature that binds them. Api is to abstract any foreign system integration (api calls), where actions (action creators) may use it, and the reducers manage the result... Redux workflow, variance on structure. Tends to work pretty well that way. Actions/reducers may listen/dispatch those defined under other features... again, it's the shape of the data and application that defines these features and their structure.

deleted 11y ago

[deleted]