ERAS ‐ FRONTEND STRUCTURE PROJECT - JU-DEV-Bootcamps/ERAS GitHub Wiki
- Folders Structure
- Main Folders description
- Path Aliases
- Follow Angular LIFT principle
- Benefits
- Takeaway
Folders Structure
Following Folders-by-feature structure, with some modifications according our needs.
At source level
└── 📁src
└── 📁app
└── 📁environments
└── 📁styles
├── index.html
└── main.ts
At application level
└── 📁app
└── 📁core
└── 📁modules
└── 📁shared
├── app.component.html
├── app.component.spec.ts
├── app.component.ts
├── app.config.ts
└── app.routes.ts
Deep core - modules - shared
└── 📁src
└── 📁app
└── 📁core
└── 📁auth
└── 📁guards
└── 📁constants
└── 📁interceptors
└── 📁layout
└── 📁models
└── 📁services
└── 📁utils
└── 📁modules
└── 📁home
└── 📁summary-details
├── home.component.html
├── home.component.scss
├── home.component.ts
└── 📁imports
└── 📁components
└── 📁models
└── 📁resolvers
└── 📁services
└── 📁utils
└── 📁lists
└── 📁components
└── 📁models
└── 📁resolvers
└── 📁services
└── 📁utils
└── 📁reports
└── 📁components
└── 📁models
└── 📁resolvers
└── 📁services
└── 📁utils
└── 📁risk-students
└── 📁components
└── 📁models
└── 📁resolvers
└── 📁services
└── 📁utils
└── 📁settings
└── 📁components
└── 📁models
└── 📁resolvers
└── 📁services
└── 📁utils
└── 📁student-monitoring
└── 📁components
└── 📁models
└── 📁resolvers
└── 📁services
└── 📁utils
└── 📁supports-referrals
└── 📁components
└── 📁models
└── 📁resolvers
└── 📁services
└── 📁utils
└── 📁shared
└── 📁components
└── 📁directives
└── 📁pipes
├── app.component.html
├── app.component.spec.ts
├── app.component.ts
├── app.config.ts
├── app.routes.ts
└── 📁environments
├── environment.development.ts
├── environment.production.ts
└── 📁styles
├── index.html
└── main.ts
Main Folders description
Core folder, holds services, components, and utilities that should exist exactly once on our application, things like singletons or fundamental features. This is the backbone of our application.
| SubFolders | Description |
|---|---|
| auth | Our authentication and authorization logic. e.g. guards, interceptors related to auth. |
| constants | Our global constants or configuration values used across our application. |
| interceptors | Our HTTP interceptors (Keycloak tokens, error handling, etc.). |
| layout | Our root-level layout components such as HeaderComponent, SidebarComponent. |
| models | Our global data models or interfaces used throughout our entire application. |
| services | Our singleton services that are used throughout our entire application. |
| utils | Our general-purpose helper functions or utility classes. |
Modules folder, contains application modules or features areas, each representing a distinct section, and each one of them will be lazy-loaded via our angular routes.
| SubFolders | Description |
|---|---|
| components | Specific UI components, belongs to its module. |
| models | Interfaces or models specific, belongs to its module. |
| resolvers | Route resolvers to preload data before navigation, belongs to its module. |
| services | Business logic and API calls, belongs to its module. |
| utils | Utilities or helper functions used only in this module. |
Shared folder, holds reusable components, directives and pipes, things that can be used in multiple modules.
| SubFolders | Description |
|---|---|
| components | Reusable UI widgets - e.g., ButtonComponent, ModalComponent, etc. |
| directives | Reusable attribute or structural directives. |
| pipes | Reusable pipes - e.g., DateFormatPipe, CapitalizePipe, FilterPipe. |
Path Aliases
Keeping in mind that core, modules and shared folders are the main layers of our aplication, we enable the followng alias at our tsconfig.json file.
"compilerOptions": {
"paths": {
"@shared/*": ["src/app/shared/*"],
"@core/*": ["src/app/core/*"],
"@modules/*": ["src/app/modules/*"],
},
}
Follow Angular LIFT principle
Keep in mind and follow LIFT principle.
Do structure the application such that you can Locate code quickly, Identify the code at a glance, keep the Flattest structure you can, and Try to be DRY.
- L ocate
- Do make locating code intuitive and fast.
- I dentify
- Do name the file such that you instantly know what it contains and represents.
- Do descriptive with file names and keep the contents of the file to exactly one component.
- F lat
- Do keep a flat folder structure as long as possible.
- T ry to be DRY
- Do DRY mode (Don't Repeat Yourself).
- Avoid being so DRY that you sacrifice readability.
Why? - LIFT provides a consistent structure that scales well, is modular, and makes it easier to increase developer efficiency by finding code quickly.
Benefits
Clean architecture > Enforces separation of concerns.
Scalable > Easy to grow and maintain when it grows.
Reusable > Shared code is centralized and consistent.
Singleton-safe > Core ensures only one instance of global services.
Modular > Enables lazy loading and parallel development.
Collaborative > Predictable structure helps team workflow.
Testable > Modules and services are isolated and easier to test.
Takeaway
This structure was designed for clarity, scalability, and maintainability. It was separated into three clear layers:
core → Application infrastructure
shared → Reusable UI and utilities
modules → Domain-specific features modules