
AngularJS project structure - gurgus
http://www.davecooper.org/angular-project-structure
======
buckbova
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/a...](https://github.com/johnpapa/angular-
styleguide/blob/master/a1/README.md#application-structure-lift-principle)

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

------
rileyteige
>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
CTRL + what?

~~~
rileyteige
What user crabl said. Edited for clarity.

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

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

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

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

~~~
ZoeZoeBee
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 :)

~~~
Roboprog
Why would I use Angular 2 instead of React?

I hope "somebody" forks Angular 1. The 2 way binding (ng-model) makes CRUD
apps very simple to write, even if digest/watch type operations are somewhat
slow. As far as I can tell, the ng-model feature is OUT of Angular 2, and some
kind of React style event communication must be set up instead.

I don't know React yet, but Angular 2 sounds like they are chasing the same
design goals: be efficient at gluing huge mounds of similar crap to a never
ending page (e.g. - a la Facebook). I am more interested in quickly grinding
out code for huge CRUD forms with a large number of distinct fields.

~~~
ZoeZoeBee
Yes both are ways to deal with single page applications...

2 way data-binding is still in Angular2, as well as oneWay Binding to the
input and one way binding from output. I've heard others make the claim ng-
model and 2 way binding are gone, which is wrong.
[https://egghead.io/lessons/angular-2-using-ng-model-for-
two-...](https://egghead.io/lessons/angular-2-using-ng-model-for-two-way-
binding)

There are giant performance benefits on the horizon with Angular2 in terms of
server side rendering with Angular Universal and state management with
ngrx/store.

In Angular2 http is handled as an observable, no longer a promise, so there is
a difference in syntax but that falls in line with ES7 format

~~~
Roboprog
Thanks for the update. As far as I could piece together (admittedly dubious
connections), ngModel was re-implemented in the Jan 2016 release of Angular
2??? ("Angular 2.0.1 beta" from a Stack Overflow discussion assumed to mean
2.0.0-beta.1 on [https://code.angularjs.org/](https://code.angularjs.org/))

Sounds like somebody beat some sense into the Angular 2 team - "don't remove
the single feature that differentiates your library and makes prototyping an
app easy"

Now if I can only find examples in good old Javascript, instead of fugly,
Java-esque, Typescript.

Re: types/Typescript - loved this quote:

"Better type-checks interestingly found only just a few bugs"

[https://jaxenter.com/angularjs-interview-
angular-2-typescrip...](https://jaxenter.com/angularjs-interview-
angular-2-typescript-and-a-release-date-123674.html)

Rant for another day: insisting on static typing, but ignoring the mayhem
caused by operators and operator precedence (to say nothing of user created
operators)

------
Roboprog
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
See #21 - [http://blog.codinghorror.com/new-programming-
jargon/](http://blog.codinghorror.com/new-programming-jargon/)

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

