I'm new to angular, so please bear with me. I was reading an article/documentation the other day that highlighted the best way to structure modules in your app, and can only remember it loosely.
App.controllers
App.services
....
angular.module('App', [App.controllers, App.services ...);
This code sample is very likely to be incorrect, but the point was to group controllers, services etc together in one namespace.
Could anyone expand upon this approach?
Enterprise project organization
The way I organize my angular project is:
/app
/img # application-level images
/css # application-level css styles
/js # application-level javascripts
/modules # application modules
/gallery # independent module with its own infrastructure
/controllers # gallery module's controllers
/css # gallery module's css styles
/directives # gallery module's directives
/img # gallery module's images
/filters # gallery module's filters
/services # gallery module's services
/views # gallery module's views (htmls)
/ ... # other gallery module component folders
galleryMod.js # the module itself
/user # independent module with its own infrastructure
/controllers # user module's controllers
/ ... # other user module component folders
userMod.js # the module itself
/ ... # other modules
/ ... # other application-level folders
index.html
Alternative enterprise project organization (simplified)
/app
/img # application-level images
/css # application-level css styles
/js # application-level javascripts
/modules # application modules
/gallery # independent module with its own infrastructure
/js # gallery module's javascripts (includes
# services.js, directives.js, filters.js, ...)
/css # gallery module's css styles
/img # gallery module's images
/views # gallery module's views (htmls, "partials")
/ ... # other gallery module component folders
galleryMod.js # the module itself
/user # independent module with its own infrastructure
/controllers # user module's controllers
/ ... # other user module component folders
userMod.js # the module itself
/ ... # other modules
/ ... # other application-level folders
index.html
Middle project organization (without modules)
/app
/img # application's images
/css # application's css styles
/controllers # application's controllers
/directives # application's directives
/filters # application's filters
/services # application's services
/views # application's views (htmls)
/ ... # other component folders
index.html
Simple project organization (just like a seed)
/app
/img # application's images
/css # application's css styles
/js # application's javascripts (includes
# services.js, directives.js, filters.js, ...)
/views # application's views (htmls), e.g. partials
/ ... # other component folders
index.html
Use the way your project needs to be organized and don't choose the way that will unnecessarily complicate your project.
This approach is provided by Angular Seed and Its just one of the ways to orginize app structure. It is useful for debugging: If you see bug in some service you go to services.js and catch It.
Brain Ford in his article Building Huuuuuge Apps with AngularJS wrote:
The only remaining question is how to subdivide controllers, directives, services, and filters into modules. The Angular Seed puts filters, services, and directives into separate modules, but that seems a bit silly to me. Depending on the app, I'd be more inclined to organize modules by page/route. From a performance perspective, it doesn't really matter how you organize your modules, so choose whatever method best suits your project.
He also propose different app structure where each directive or service is an one separate file (see article above).
From John Pappa's AngularJS Style Guide. This is becoming the 'Angular standard structure' for larger apps.
Folders-by-Feature Structure: Create folders named for the feature they represent. When a folder grows to contain more than 7 files, start to consider creating a folder for them. Your threshold may be different, so adjust as needed.
Why?: A developer can locate the code, identify what each file represents at a glance, the structure is flat as can be, and there is no repetitive nor redundant names.
Why?: The LIFT guidelines are all covered.
Why?: Helps reduce the app from becoming cluttered through organizing the content and keeping them aligned with the LIFT guidelines.
Why?: When there are a lot of files (10+) locating them is easier with a consistent folder structures and more difficult in flat structures.
/**
* recommended
*/
app/
app.module.js
app.config.js
app.routes.js
components/
calendar.directive.js
calendar.directive.html
user-profile.directive.js
user-profile.directive.html
layout/
shell.html
shell.controller.js
topnav.html
topnav.controller.js
people/
attendees.html
attendees.controller.js
speakers.html
speakers.controller.js
speaker-detail.html
speaker-detail.controller.js
services/
data.service.js
localstorage.service.js
logger.service.js
spinner.service.js
sessions/
sessions.html
sessions.controller.js
session-detail.html
session-detail.controller.js
This folder structure allows me to scale Angular and find every file quickly by understanding and grouping their overall functionality.
/app
/features
/product #one folder per entity
/get-products component
/create-product component
/update-product component
/delete-product component
/state #ngrx state
/actions
/effects
/reducers
/selector
index
/models
auth
user
product
# additional.model.ts
/services
backend service
api service
auth service
firebase service
auth-guard service
# additional.service.ts
/store
/actions
/effects
/reducers
app-store
index
/utilities
router.animation
customAngularMaterial module
uuid
validator
pipe
directive
# additional utilities
/views
/admin component
/auth component
/header component
/footer component
/navbar component
/profiles component
/home component
/contactus component
#additional views
app-routing.module
app.component
app.module
/assets
/css #custom styles.css
/icons #svg files
/favicon.ico
/images
#additional assets
main
index #material icons
styles #angular material prebuilt theme
