When learning, I think it would be helpful for people to see a variety of approaches. Perhaps we can point to similar angular repos for people to get a feel for the language.

Examples like:

• starter-kit
• angular-ngrx-material-starter
• angular-starter
• Angular-Full-Stack

The child routes for the /dashboard/* route are defined using an empty path, no component, several children and no default. This means when you visit /dashboard/ you get a blank page. Wouldn't it be better to express these as either non-child routes with a default, or as child roots but with a root component at the top level?

export const routes: Routes = [ { path: '', children: [ { path: 'home', component: HomeComponent }, { path: 'projects/:id', component: ProjectDetailsComponent, resolve: { project: ProjectResolver } } ] }, ];

In order to separate the docs from the application and to provide a clean branch for readthedocs.org I need @mathisGarberg to do the following

• Create an account at readthedocs.org (not .com) and post your username to this thread so I can add you as an administrator to https://angular-folder-structure.readthedocs.io/en/latest/

• Delete these branches from the repository: develop, version-2, revert-18-feature/singular-directory-names (unnecessary and should not exist on this 'master' copy of the repository)

  git push origin --delete develop  
  git push origin --delete version-2  
  git push origin --delete revert-18-feature/singular-directory-names  

• Create a new empty branch called docs with just a README.md in it as a placeholder. I'll then be able to submit a PR to that branch with the docs. Here's a script for that

  git checkout --orphan docs

Wait while git removes all the files to create the empty branch

  touch README.md
  git add README.md
  git commit -m "Initial Commit"
  git push origin docs

• After you have been added as a readthedocs.org administrator please add the github commit hooks detailed here: https://docs.readthedocs.io/en/stable/webhooks.html

from readthedocs.org:

  You can use the following address to manually configure this webhook.
  readthedocs.org/api/v2/webhook/angular-folder-structure/94055/

Maybe we can add @ngrx/store as it becomes a must-have for large angular apps?

The features in this commit should be part of the documentation:

6f99d47#diff-23949df756e1e1316d52098dcf8383f0

You can disable these in the settings: https://github.com/mathisGarberg/angular-folder-structure/settings

The application running at github pages is a great idea. https://mathisgarberg.github.io/angular-folder-structure/#/dashboard/home ; I really like it. But we can't run the JSON server on github pages.

I'd like to propose we remove the JSON server requirement from the application and instead move the JSON data into json-api.service.ts

After merging #46 please see https://readthedocs.org/projects/angular-folder-structure-dev/builds/ to ensure a build started. If not please investigate the webhook config.

The project downloaded from Github has been compiled and runs fine at local except one thing,

The Card layout not get updated after card flipped. All the cards just stay at the previous position and not moving vertically to take hold the extra space. However the project in action at

https://mathisgarberg.github.io/angular-folder-structure/#/auth/login

works fine and the card below the flipped card will move vertically to take space.

What is the difference between Project code and the code of live demo? There must be some difference.

The link to the documentation in the module folder does not exist. /module.html is missing an s (/modules.html).

File:
https://github.com/mathisGarberg/angular-folder-structure/blob/master/src/app/modules/README.md

Wrong link:
https://angular-folder-structure.readthedocs.io/en/latest/module.html

Good link:
https://angular-folder-structure.readthedocs.io/en/latest/modules.html

Hi mathis,
i am digging into your code and found one thing which is not clear to me.
When i click login spinner moving for long time approx 6 sec which is really high for static data authentication . It should not take too much time as uid and password is hardcoded we are not making any api request here. can you share why it is happening in your code.

I recommend changing the height of the image on README.md to half of its current height. This will allow mobile to show the whole readme file instead of using 'read more' when we really don't have much text in the readme.

I always want to ensure we're on the same page whenever a legal issue comes up.

Right now the copyright on the docs says
"© Copyright 2019 Mathis Garberg and contributors"

I'd like to change this to
"© Copyright 2019 Mathis Garberg, Tom H Anderson, and contributors"

Give me a go-ahead and I'll submit a PR

• Compile a better list of alternative repositories and include why they are different from this repo.

• Invite other repos to contribute to include alt directory structures.

• Move description and link to original blog article to bottom of README.md The blog article is a long ways away from the repository now and I think should not be promoted before this new project

• Move application screenshot below Demonstration Application in README.md This would open up the README and push the link to the docs higher in the page.

• Fix webhook for readthedocs integration

• Get docs from @mathisGarberg for #24

In this architecture you have created model inside core. if i have created 10 modules should we create model for each module inside core or at module level. please suggest.

Everything is fine just one thing , can you add lazy loading and add some demo modules like about page or contact page , so it will be easy to understand the pattern.

Thanks.

Should update the project to the newest version of Angular.

https://github.com/mathisGarberg/angular-folder-structure/blob/master/.documentation/theme.rst needs documentation about what main.scss does and how it's included in the app.

@dougal83 suggested flattening the modules. We probably have different ideas for what that means, but here's some brainstorming output that may be useful to the conversation.

I come from a PHP Zend Framework (1 & 2) background. In Zend Framework the app is part of the modules directory. Here we have a core directory because the app is the project source root because ng creates all its files in ~/src/app.

Any module can be the starting point of an application. The configured module is bootstrapped (and ran?) in the ~/src/main.ts file.

Even when you change ~/angular.json projects.appname.sourceRoot value ng will still add the app suffix. (note the angular.json property prefix refers to the code prefix for selectors, etc. and does not apply to this naming).

I would like to explore the idea of this directory structure:

.
├── e2e
│   └── src
├── media
└── src
    ├── app -> . (symlink; added to .gitignore)
    ├── assets
    ├── environments
    ├── module
    │   ├── app
    │   │   └── layout
    │   ├── data
    │   └── shared
    └── styles

Setting up this directory structure

mkdir media
mkdir src/module
mkdir src/styles
mv src/app src/module
mkdir src/module/app/layout
cd src && ln -s . app & cd .
sed -i .bak 's/.\/app/.\/module\/app/g' src/main.ts
ng generate module module/Shared
ng generate module module/Data
json --version || npm install -g json
json -f tsconfig.json -I -e "this.compilerOptions.paths = {}"
json -f tsconfig.json -I -e "this.compilerOptions.paths['@app/*'] = ['module/app/*']"
json -f tsconfig.json -I -e "this.compilerOptions.paths['@shared/*'] = ['module/shared/*']"
json -f tsconfig.json -I -e "this.compilerOptions.paths['@env/*'] = ['environment/*']"
json -f tsconfig.json -I -e "this.compilerOptions.paths['@data/*'] = ['module/data/*']"

Although a little bit of file moving around is necessary this structure has these advantages:

• All modules are stored inside the module directory
• All modules are on the same level (flat?)
• The special directory app is no longer the home of the app.module and the new home of the app.module can have subdirectories thereby removing the core module

Thanks for reading! Please leave feedback

Like a "Fork me on github" ribbon or a nav item to take you back to github.

This is for the /dashboard/home page.

To avoid having to manually do all the work required to add publish the application to GitHub pages, I suggest implementing Continuous Integration with TravisCI to deploy our Angular app. automatically.

The term core does not exist in many top-level applications. The term lib does. I've been rolling around the idea of using lib instead of core.

Angular is oddly structured. For instance Zend Framework 2 uses this structure:

.
├── config
│   └── autoload
├── data
│   └── cache
├── module
│   └── Application
│       ├── config
│       ├── src
│       │   └── Controller
│       ├── test
│       │   └── Controller
│       └── view
│           ├── application
│           │   └── index
│           ├── error
│           └── layout
└── public
    ├── css
    ├── fonts
    ├── img
    └── js

The homolog to Angular's app.module is stored inside the module directory and is therefore a module equal to the rest of the modules in the application.

Angular does not work this way and this is the root of the reason this project exists. Any new module we create e.g. ~/src/app/module/about comes with a built-in subdirectory. App doesn't have this and using ~/src/app/app/code-here is just silly. And that's why we use ~/src/app/core/code-here.

So I'm thinking about ~/src/app/lib/code-here

The use of lib is more geeky and "low-level". I think the term will be accepted in the community. The term core is not as "computer science"ey.

When I came on to this project there was a discussion of aliasing core to @app and that's not an idea I've ignored. Should we change core to lib then aliasing lib to @app would be necessary and we would document how to do that as part of the install section of the lib documentation.

I'm sorry if I'm only just realizing the real use of @app while you've known it all along.

I'd like feedback on this idea please.

Hi @mathisGarberg, I have found this project to be very useful. Thanks for all your efforts.

Quick question: how are you switching themes? So far I could only find the onThemeChange method in content-layout.component.ts, but as far as I can tell, it is responsible for changing only the overlayContainer theme. So where is the theme for the entire app changed? Is the technique documented somewhere?

Thanks in advance.

I'd like to propose changing the title for the application title in the README.md from

Highly Scalable Angular Folder Structure

to

Angular Folder Structure - Highly Scalable

or my personal preference:

Angular Folder Structure

Modules generally each have their own layout. The app module does not have a layout since it's a super-layout. If the layout directory is removed from the app/core module then each module with a layout can have its own layout directory. This still allows modular loading of modules and does not load all modules to navigate the app/core module.

I propose we change the recommendation to use a subdir of layout inside each module which has its own layout and remove the recommendation of a single layout directory to hold all layouts for all modules.

There is no description on this project right now. I suggest adding one such as

"The project is based on best practices from the community, other github Angular projects and developer experience from production Angular projects."

Roadmap

Because when I submit a pull request the changes are a surprise, I'd like to keep a roadmap so we can expect changes.

Where are we now?

Through the course of documenting the application I've made changes like
plurality and removing aliases. I needed to remove these in order to
understand and then document why these existed in the application. Now that
I've groked the code I have documented the reason for aliases
and other parts I didn't understand before.

Check out the analytics on google :) The average docs session duration
is > 7:00! That means people are taking the time to read them. Since I came on
the project we've had 8 new stars and 2 forks.

Future Changes

• Merge refactor #2 and path-alias docs

• Add aliases back into code
  With the documentaion understanding how these work means we can use them

• Reintroduce plurality for modules

• Rename Directory Structures to Directory Structure Parts because they are all
  optional

• Consider multiple directory tree structures. The default and recommended
  structure will be that of the application. But I've seen other good structures
  which use the same building blocks of media, core, data, layout, module, shared,
  and sytles/themes. In Additional Resources we could have pages for each tree
  structure as alternatives. It is my hope we can pull in some of the other
  repositories which also define a directory structure and include that structure
  as part of angular-folder-structure

I am not able to log in with Username: Mathis \ Password: 12345

Hi Mathis,
Thanks for replying. I am trying to use 2 layout one for admin module and one for client module. please suggest how to achieve this. it will be helpful for me if you update code. it must be helpful for others also.

Originally posted by @mrinalkumarjha in #5 (comment)

i am trying to use this structure for my app where i need admin part where admin can manage client. i dont understand how to separate admin module from client. i have created a new admin module inside modules. now how to route admin dashboard and their subsequent pages like add user.
it will be helpful if you add admin section in your code.

From my experience, I always need enum files in the core folder I created a PR for it hope it's good to be merged soon

Hi Mathis

I really appreciate your repo here. I was wondering how you would approach integration of a generated api such as openapi-generator-cli. I was wondering about your thoughts on where to locate the generated module and if to include via the core module? Example Code

Looking forward to hearing your approach.

Kind regards
Doug

Hello,

In the demo application for Angular there isn't a notion of a 'page' directory. In the case of 'page' in this application it is a made up term. I propose we move all 'page' directories into 'component' directories.

A common error developers make is treating themselves like their own vendor. Such as building an application in the vendors which is dependent on the actual application built at the same time.

In your use of @app to alias the core module I do not see any benefit. Including index.ts files to simplify includes inside the application is just more work to maintain.

I propose we remove the @app alias and directly include core files using the same relative path.

While I appreciate the artistic quality of using @app I do not believe it offers any engineering benefit. Please comment.

Please look into the commit hook to repair the errors it throws.

Hello, thanks for this great repo and comments, this is always a big issue to tackle when creating an angular application from scratch and trying to find the most appropriated project structure.

I like this template, however there is one thing that is confusing me.

You defined a Login module which only has a dependency on the SharedModule. So far so good, but the login page inside the Login module is importing a service from the Core module. Login modules does not have a dependency on the Core module (this would create a dependency cycle). Correct me if I'm wrong but you are using a path alias "@app".

import { AuthService } from '@app/core';

Can we assume this is "good enough" because Core module always gets loaded ? Should we move this service to the SharedModule ? If not how should we decide whether a service should be in the core or the shared module if it has basically no dependencies ?

Feedbacks would be much appreciated ! Thanks !

By default the main.scss file in a brand new Angular installation is called styles.scss. Instead of creating our own convention for this main.scss I propose we move ~/src/theme to ~/src/styles to be used by the existing and default styles.scss.

I am a firm proponent of using singular nouns throughout my application. This prevents nonsense words like mooses and I believe it is easier for non-native english speaking developers.

What this means for this project is I want to change all plural nouns in the directory structure to singular. Such as

• app
  • core
    • guard
    • interceptor
    • service
  • layout
  • module
  • shared (not shareds)

This repository is used by a LOT of developers as the source of truth. I believe this change will benefit them all. It adds clarity and removes disambiguation. Please comment.

You can email me at <removed> instead of posting your email here if you prefer.

I have a (hopefully) simple question.

Reading ITNext article, I see the following:

The CoreModule should contain singleton services (which is usually the case), universal components and other features where there’s only once instance per application.

When I look at the sample project, core.module.ts does not contain auth.service.ts or theme.service.ts and I was wondering why?

I don't see a code responsible for setting and retrieving a theme preference from let's say a localstorage. So now, when the user refresh the app, he always sees the light theme. I think it would be great to have that kind of functionality.