Great article by John Papa on Angular App Structuring guidelines and it also applies to all applications using the LIFT Guidlines.
Regarding all Application Projects, this is a good snippet of the article.
----
App Structure
I find it extremely helpful to have an idea of what is important to me and my team in structuring my app instead of focusing on the actual structure.
You have to find your own path that is comfortable for you and your team. Instead of just picking a structure, it’s helpful to think about the “why”, so I’ll walk you through the guidelines I follow and my thought process on why I choose how I do. This is a follow up to my post onAngular Structure.
How you organize your structure is up to you. There are many right ways of doing this, and consistency in your project is key.
These are my guidelines. I’m sharing them as one possible path you can take but the main point of this post is to share how I think about structuring my Angular apps. There is a reason for the madness and if you take anything from this post it’s to be sure to have a set of guidelines and conventions of your own.
Thanks to my friend Ward Bell for helping review these and in many cases, contributing to the content quality over the several projects with me.
The LIFT Guidelines
The structure should follow these 4 basic guidelines. When I find my structure is not feeling comfortable, I go back and revisit these LIFT guidelines
- Locating our code is easy
- Identify code at a glance
- Flat structure as long as we can
- Try to stay DRY (Don’t Repeat Yourself) or T-DRY
Another way to check your app structure is to ask yourself …
How quickly can you open and work in all of the related files for a feature?
I find placing related files for a feature in the same drawer really helps me be more efficient.
Locating
I find this to be super important for a project. If the team cannot find the files they need to work on quickly, that needs to change. I’ve been on projects where this has been an issue and it wastes time.
Locating code needs to be untuitive, simple and fast. You may not know the file name or where its related files are, so putting them in the most intuitive locations and near each other saves a ton of time.
Identify
When I look at a file I expect to know what it contains and represents. If this means you want longer file names, then so be it. For me its more about being descriptive with file names and keeping that contents of the file to exactly 1 thing. No files with multiple controllers, multiple services, or a mixture.
There are deviations of the 1 per file rule when I have a set of very small directives or filters that are all related to each other, they are still easily idnetifiable. If not, 1 per file.
Flat
Nobody wants to search 7 levels of folders to find a file. Think about menus on web sites … anything deeper than 2 should take serious consideration. In a folder structure there is no hard and fast number rule, but when a folder has 10 files, that may be time to create subfolders (or drawers as I like to call them).
The general guidelines here is base on your comfort level. I prefer a flatter structure until I see a specific value (to help the rest of LIFT) in creating a new folder.
T-DRY
Being DRY is important, but not crucial if it sacrifices the others in LIFT, which is why I call it T-DRY. I don’t want to type session-view.html for a view because, well, it’s obviously a view. If it is not obvious or by convention, then I name it.
I don’t name my controllers with “controller” in their file name nor their registered name with Angular. I differ from others on this point, but it feels so un-DRY for me. I may have 30 controllers and continually typing “controller” everywhere (in file names and in code) and its obvious that it is a controller felt completely un-DRY.
-----
There is a lot more there going on and in regards with AngularJS the source article is a great read.
