Skip to main content

Folder structure

The folder structure of the generated angular app skeleton is a result of best practices tips gathered online. There is no strict structure to follow, every structure depends on the size and the type of the project. Chosen structure allows for applications to scale more easily and enables a familiarity between different NS front-end applications.

space-app-angular
├── src
. ├── app
│ ├── core
│ ├── shared
│ ├── translation
│ ├── products
│ . ├── components
│ ├── constants
│ ├── directives
│ ├── features
│ ├── guards
│ ├── models
│ ├── pages
│ ├── pipes
│ ├── resolvers
│ ├── services
│ .
├── assets
├── config
├── environment
├── styles
. ├── abstracts
├── base
├── components
├── layout
├── pages
├── themes
└── vendors

Root

Contains src folder and application configuration files, e.g. package.json, angular.json, ...

App

As Angular is most commonly used to create Single Page Applications or SPAs, that is why we have a prominent app folder. At this spot a root module and component reside that act as an entrypoint in the application. It is the first component to load and the container for the other components. The app module is the module that Angular uses to bootstrap the application.

Core

The core module acts as root module and contains generally only files that need to be loaded once, in other words singletons. Examples are static header and footer components, universal models, enums, constants, or root-scoped services. For the generated core folder we use the same subfolders as a FeatureModule. This makes a module easy to comprehend and forces a project structure.

  • components: Contains angular components.
  • constants: Contains enums and other static variables (like configuration).
  • directives: Contains angular directives.
  • features: Can be used when you want to subdivide the module more. (only for FeatureModules)
  • guards: Type of service: e.g. router guards.
  • models: Contains data model representation that can be used in the application, e.g. input and output models for REST calls.
  • pages: Contains components that represent a single view in the application.
  • pipes: Contains angular pipes.
  • resolvers: Type of service used to pre-fetch data, this way you don't need spinners or loaders.
  • services: Contains angular services.

Shared

The shared module contains components, pipes, directives, services, ... that can be reused in other modules.

danger

Entries in the shared module cannot depend on any other modules!

Translation

A module is a grouping of related code based on functionality. In this case the functionality is translation. At this location some files are expanded that handle the translation of the application.

FeatureModule

A good thing to do is to split up the application in different modules based on features or functionality. Each module contains related pages, components, services and routing configuration. This makes it easier to maintain the project and improves separation of concerns.

Auth

Depending on the usage of the options angular.basicAuth.enable and angular.oidcAuth.enable on the AngularApp a module concerning authentication is expanded.

Assets

The asset folder is used for static files that need to persist during build time and be served with the application. For example, images and translation files.

Config

The config folder contains two files: config.js and config.template.js. Here, you can fill in environment variables that need to be changed using the docker env. The normal environment files from angular are static per environment that needs to be deployed. However, information like baseUrl needs to be changed via docker, because we only make one image with our CI/CD (Jenkins), not an image for every environment.

config.js can be used for local development and gets replaced by a filled in config.template.js after envsubst during docker deploy.

Environment

The angular environment folder is used a bit different from normal, namely to differentiate between development and production builds. Booleans that trigger certain logging or other information that is related to the type of build that will be made, can reside here.

Styles

We follow a certain hierarchy in our styles folder. The architecture known as the 7–1 pattern (7 folders, 1 file), is a widely-adopted structure that serves as a basis for large projects. You have all your partials organised into 7 different folders, and a single file sits at the root level (usually named main.scss) to handle the imports — which is the file you compile into CSS.

Here’s a sample 7–1 directory structure, some examples of files that would reside in each folder are provided:

Naming

Partials should lead with an underscore, followed by its name.

├── styles
. ├── abstracts
│ ├── _variables.scss // Sass Variables
│ ├── _functions.scss // Sass Functions
│ ├── _mixins.scss // Sass Mixins
│ .
├── base
│ ├── _reset.scss // Reset/normalize
│ ├── _typography.scss // Typography rules
│ .
├── components
│ ├── _buttons.scss // Buttons
│ ├── _carousel.scss // Carousel
│ .
├── layout
│ ├── _grid.scss // Grid system
│ ├── _header.scss // Header
│ ├── _footer.scss // Footer
│ .
├── pages
│ ├── _home.scss // Home specific styles
│ ├── _contact.scss // Contact specific styles
│ .
├── themes
│ ├── _theme.scss // Default theme
│ .
├── vendors
│ ├── _bootstrap.scss // Bootstrap
│ ├── _jquery-ui.scss // jQuery UI
│ .
└── main.scss // Main Sass file
  • Abstracts (or utilities): Contains Sass tools, helper files, variables, functions, mixins and other config files. These files are meant to be just helpers which don’t output any CSS when compiled.

  • Base: Contains the boilerplate code for the project. Including standard styles such as resets and typographic rules, which are commonly used throughout your project.

  • Components (or modules): Contains all of your styles for buttons, carousels, sliders, and similar page components (think widgets). Your project will typically contain a lot of component files — as the whole site/app should be mostly composed of small modules.

note

Because this is an Angular project this folder will probably be sparsely used. Angular has a style encapsulation implementation that prevents component styles from affecting other components.

  • Layout: Contains all styles involved with the layout of your project. Such as styles for your header, footer, navigation and the grid system.
note

Layout is also declared as Angular components meaning these can be encapsulated with the component itself.

  • Pages: Any styles specific to individual pages will sit here. For example, it’s not uncommon for the home page of your site to require page specific styles that no other page receives.
note

Pages are also components in Angular.

  • Themes: It holds files that create project specific themes. For example if sections of your site contain alternate color schemes.

  • Vendors: Contains all third party code from external libraries and frameworks — such as Normalize, Bootstrap, jQueryUI, etc. When extensions or adaptions need to be done to the vendor specific css, you should create a separate extension file and not do it in the vendor css directly.

  • Main.scss: This file should only contain your imports!

@use 'abstracts/variables';
@use 'abstracts/functions';
@use 'abstracts/mixins';

@use 'base/reset';
@use 'base/typography';

@use 'components/buttons';
@use 'components/carousel';
@use 'components/slider';

@use 'layout/navigation';
@use 'layout/grid';
@use 'layout/header';
@use 'layout/footer';
@use 'layout/sidebar';
@use 'layout/forms';

@use 'pages/home';
@use 'pages/about';
@use 'pages/contact';

@use 'themes/theme';
@use 'themes/admin';

@use 'vendors/bootstrap';
@use 'vendors/jquery-ui';
note

There’s no need to include the _ or .scss file extension when importing.