Qad Inc. Mono repository(https://qad.com).
![Tech logos][stack]
- Angular 12
- [Nx Workspace][nx]
- ngrx and ngrx/component-store
- TailwindCSS - See this video Everything you need to know about TailwindCSS and Angular applications by [@nartc][nartc] for integration TailwindCSS with Angular
- Angular Material (UI components)
#Nx We use an Nx [Nx]-based workspace to implement the defined architecture. This workspace is an extension for Angular CLI, which helps to break down a solution into different applications and libraries
#EQMS
All components are following:
- OnPush Change Detection and async pipes: all components use observable and async pipe for rendering data without any manual subscribe.
- SCAMs (single component Angular modules) for tree-shakable components, meaning each component will have a respective module. For example, a LoginComponent will have a corresponding LoginModule. We won't declare LoginComponent as part of AuthModule, for instance.
- Mostly, everything will stay in the
libs
folder. New modules, new models, new configurations, new components etc... are in libs. libs should be separated into different directories based on existing apps. We won't put them inside the apps folder.
The solution shown here puts all applications into one apps folder, while grouping all the reusable libraries by the respective domain name in the libs folder:
.
└── root
├── apps
│ ├── eqms
├── └── eqms-e2e (cypress end to end testin)
└── libs
├── eqms (dir) - eqms specific components and services
│ │ └── ui
│ ├── shell (dir)
│ │ └── layout (angular:lib)
│ │ ├── feature (angular:lib) - for configure any forRoot modules
│ ├── settings (dir)
│ │ ├── feature (angular:lib) - for configure and persist all settings
│ │ └── data-access (workspace:lib) - store and services for settings module
│ ├── playlist (dir)
│ │ ├── data-access (angular:lib, service, state management)
│ │ ├── features
│ │ │ ├── list (angular:lib PlaylistsComponent)
│ │ │ └── detail (angular:lib PlaylistDetailComopnent)
│ │ └── ui (dir)
│ │ └── playlist-track (angular:lib, SCAM for Component)
│ ├── visualizer (dir)
│ │ ├── data-access (angular:lib)
│ │ ├── feature
│ │ └── ui (angular:lib)
│ ├── home (dir)
│ │ ├── data-access (angular:lib)
│ │ ├── feature (angular:lib)
│ │ └── ui (dir)
│ │ ├── featured-playlists (angular:lib, SCAM for Component)
│ │ ├── greeting (angular:lib, SCAM for Component)
│ │ └── recent-played (angular:lib, SCAM for Component)
└── shared (dir) - cross domain components and services
├── app-config (injection token for environment)
├── data-access (angular:lib, API call, Service or State management to share across the Client app)
├── ui (dir)
├── pipes (dir)
├── directives (dir)
└── utils (angular:lib, usually shared Guards, Interceptors, Validators...)
- Feature Libraries
- UI Libraries
- Data-access Libraries
A feature library contains a set of files that configure a business use case. Most of the components in such a library are smart components that interact with data sources. This type of library also contains most of the UI logic, form validation code, etc. Feature libraries are almost always app-specific and are often lazy-loaded.
A UI library is a collection of related presentational components. There are generally no services injected into these components (all of the data they need should come from Inputs).
Data-access libraries contain code that function as client-side delegate layers to server tier APIs. All NgRx related entities (such as actions, reducers, effects or selectors) resides in this libraries
Nx provides an [dependency graph][dep-graph-nx] out of the box. To view it on your browser run:
npm run dep-graph
Nx will generate a dependency graph, similar to the following:
yarn
To install use this command
npm i yarn
git clone https://github.com/mparsin/qad-nx.git
cd qad-nx
yarn start
for starting Angular web application- The app should run on
http://localhost:5200/
To manage state EQMS can use either full NgRx store or local ComponentStore. When deciding which one to use this rule:
- use NgRx Store when managing global state (state shared between group of components)
- use ComponentStore for managing smaller, more local state.
Commits MUST be prefixed with a type, which consists of a noun, feat, fix, etc., followed by the OPTIONAL scope, OPTIONAL !, and REQUIRED terminal colon and space.
More Examples:
feat
: (new feature for the user, not a new feature for build script)fix
: (bug fix for the user, not a fix to a build script)docs
: (changes to the documentation)style
: (formatting, missing semi colons, etc; no production code change)refactor
: (refactoring production code, eg. renaming a variable)test
: (adding missing tests, refactoring tests; no production code change)chore
: (updating grunt tasks etc; no production code change)
References: