Learn how we structured the code of Angular Admin Template
If you are new to Angular development I suggest you read our article Angular Tutorial: Learn Angular from scratch step by step.
angular admin template code structure
In the root of the project we have some important files and folders:
- Where all the npm packages are installed when you run the
- The most important folder. Here we have all the files that make our Angular app and is the location where we will spend most of our time.
- Main configuration file for the Angular CLI.
- As every modern web application, we need a package system and package manager to handle all the third-party libraries and modules our app uses. Inside this file you will find all the dependencies and some other handy stuff like the npm scripts that will help us a lot to orchestrate the development (bundling/compiling) workflow.
- A super simple yet complete Node.js Express server to serve your Angular app with server side rendering support.
- A list of routes used in your project so the Express server can properly handle 404 errors.
- Main configuration file, it needs to be in the root path as it’s where the typescript compiler will look for it.
- Default webpack config used by the Angular CLI build/bundling workflow.
We have already talked about the configuration for the workflow enough, now let's dive in the details of the
Inside of the
/srcdirectory we find our raw, uncompiled code. This is where most of the work for your Angular app will take place.
Under this folder you will find the following important folders and files:
- Has all the components, modules, pages, services and styles you will use to build your app.
- In this folder you will find images, sample-data json’s, and any other asset you may require in your app.
- Under this folder are configuration files used by the Angular CLI to manage the different environment variables.
- For example we could have a local database for our development environment and a product database for production environment.
- When we run
ng serveit will use by default the dev environment.
- Has the files needed to bootstrap the app.
- You won’t be modifying this file often, as in our case it only serves as a placeholder. All the scripts and styles needed to make the app work are gonna be injected automatically by the webpack bundling process, so you don’t have to do this manually.
- The only thing that comes to my mind now that you may include in this file are some meta tags (but you can also handle these through Angular as well).
- This file extends
tsconfig.jsonmain file and adds some specific configuration for the app. It’s then used in
- This file extends
tsconfig.jsonmain file and adds some specific configuration for the server. It’s then used in
This is the core of the project. Let’s have a look at the structure of this folder so you get an idea where to find things and where to add your own modules to adapt this project to your particular needs.
The SharedModule that lives in this folder exists to hold the common components, directives, and pipes and share them with the modules that need them.
It imports the CommonModule because its component needs common directives. You will notice that It re-exports other modules. If you review the application, you may notice that many components requiring SharedModule directives also use NgIf and NgFor from CommonModule and bind to component properties with [(ngModel)], a directive in the FormsModule. Modules that declare these components would have to import CommonModule, FormsModule, and SharedModule.
You can reduce the repetition by having SharedModule re-export CommonModule and FormsModule so that importers of SharedModule get CommonModule and FormsModule for free.
SharedModule can still export FormsModule without listing it among its imports.
In the Shared folder of this Angular Template you will find:
- Alerts Component
- Notifications Component
- Preload image Component
- File Uploader Directive
This folder contains the CoreModule. Unlike the SharedModule, this module gather all single-use classes and components hiding their details inside a CoreModule that you import once when the app starts and never import anywhere else. A simplified root AppModule imports CoreModule in its capacity as orchestrator of the application as a whole.
Under this module you should for example place singleton services like an AuthenticationService or other single-use components (such as breadcrumbs, 404, navbars) that appear only in the AppComponent template. You don't import them elsewhere so they're not shared in that sense.
Only the root AppModule should import the CoreModule. Bad things happen if a lazy-loaded module imports it.
Here you will find all the variables, mixins, shared styles, etc, that will make your app customizable and extendable.
Here is where you will change the main colors of the app to match your styles.
Maybe you don’t know Sass? Briefly, it is a superset of css that will ease and speed your development cycles incredibly.
To gain in code modularity, and get the benefits of lazy loading modules, we’ve created a lazy module for each major section of the app. Within those module folders you will find every related file for the pages included in that module. This includes the html for the layout, sass for the styles and the main page component.
- This serves as the skeleton of the app. Typically has a <router-outlet> to render the routes and their content. It can also be wrapped with content that you want to be in every page (for example a footer).
- It’s the Angular component that provides functionality to the html file I just mentioned about.
- Here we define the main routes. Child routes of other lazy modules are defined inside those modules. These routes are registered to the Angular RouterModule in the AppModule.
- This is the main module of the project.
- Similar to the previous one, this one wraps the main AppModule with stuff you want only in the server versión of your app.