AngularJS project structure

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.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;johnpapa&#x2F;angular-styleguide&#x2F;blob&#x2F;master&#x2F;a1&#x2F;README.md#application-structure-lift-principle" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;johnpapa&#x2F;angular-styleguide&#x2F;blob&#x2F;master&#x2F;a...</a>

&gt;Enter problem two. What happens when my project has heaps of controllers&#x2F;services etc… I now have directories that could have a lot of files and none of them are particularly easy to find.<p>My team uses Angular 1.4.7 for a very large project (hundreds of JS files, dozens of views&#x2F;controllers&#x2F;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 &quot;service&quot; 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 &quot;CTRL + comma&quot; 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&#x27;t have a good suggestion for that circumstance.

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

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

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

I tend to favor organizing by feature...<p><pre><code> &#x2F;feature&#x2F;subfeature&#x2F;(constants|actions|reducers|api|controls) </code></pre> 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&#x2F;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.<p>Tends to work pretty well that way. Actions&#x2F;reducers may listen&#x2F;dispatch those defined under other features... again, it&#x27;s the shape of the data and application that defines these features and their structure.

Isn&#x27;t it redundant to prefix have a file in the foo directory called foo.controller.js ?<p>I sense a weakness in someone&#x27;s editor&#x2F;IDE. Personally I&#x27;d call it controller.js and expect my tools to not make that problemmatic

I&#x27;m working on an Angular app with a Java backend, so much of the directory structure is dictated by Maven. Also, for what it&#x27;s worth, we don&#x27;t have a &quot;single page app&quot; (with multiple controllers or whatever). We have a &quot;small number of pages app&quot;. 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.<p>That said, within the source directory for client side web files, we have the following:<p>* html&#x2F; - app pages (a small number of files) are within this directory.<p>-- html&#x2F;help&#x2F; - sundry help pages put together by analysts are stored here.<p>* css&#x2F; - probably overkill, but the main css file is here, and, so far, an alternate &quot;skin&quot; for a subsystem of the app.<p>* js&#x2F; - empty in the source, but we do concatenate js files and place them in this spot in the final deployment package (.war file)<p>-- js&#x2F;lib&#x2F; - 3rd party library scripts (e.g. - jQuery, Angular, moment, Ramda ...)<p>-- js&#x2F;&lt;&lt;app name&gt;&gt;&#x2F; - 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. - &quot;tags.js&quot; has the directives (&quot;tag libraries&quot;, although there are a few custom attributes as well); rest.js is a wrapper around $http and some error &#x2F; message handling code that does communication with the server.<p>I can&#x27;t stand the directory structure, which I attribute to JEE historically, that has hundreds (thousands?) of files, and grossly redundant &quot;MaryHartman&#x2F;MaryHartman&quot; &#x2F; &quot;Smurf&quot; &#x2F; &quot;Bat&quot; naming style (directory bat contains BatMobile.src; BatPhone.src; BatBelt.src; BatShit.src and so on)<p>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.

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