Because # in URLs starts a fragment identifier. So, in order to make that work, write %23 instead of #, that is the value of escaped # character.
Below is the sample folder structure for Nx with NestJS and Angular. Our principles are:
RegisterComponentwill have a corresponding
RegisterModule, we won’t declare
RegisterComponentas part of
libsfolder. 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
appsfolder. For example in an Angular, it contains the
. └── root ├── apps │ ├── api (nestjs) │ └── client (angular) └── libs (1) ├── api (dir) │ ├── core (dir) │ │ └── feature (nest:lib) (2) │ ├── feature-1 (dir) │ │ ├── data-access (nest:lib, service + entities) │ │ ├── feature (nest:lib, module + controller) │ │ └── utils (nest:lib, things like interceptors, guards, pipes etc...) │ └── feature-2 (dir) │ ├── data-access (nest:lib, service + entities) │ ├── feature (nest:lib, module + controller) │ └── utils (nest:lib, things like interceptors, guards, pipes etc...) ├── client (dir) │ ├── shell (dir) │ │ └── feature (angular:lib) (3) │ └── feature-1 (dir) │ ├── data-access (angular:lib, service, API calls, state management) │ ├── feature (4) │ │ ├── list (angular:lib e.g. ProductList) │ │ └── detail (angular:lib e.g. ProductDetail) │ ├── ui (dir) │ │ ├── comp-1 (angular:lib, SCAM for Component) │ │ └── pipe-1 (angular:lib, SCAM for Pipe) │ └── shared (dir) │ ├── data-access (angular:lib, any Service or State management to share across the Client app) │ ├── ui (dir, 5) │ └── utils (angular:lib, usually shared Guards, Interceptors, Validators...) └── shared (dir, most libs in here are buildable @nrwl/angular:lib) ├── data-access (my shared data-access is usually models, so it is a lib) ├── ui (optional dir, if I have multiple client apps) └── utils (optional dir, usually validation logic or shared utilities) ├── util1 (lib) └── util2 (lib)
(1) lib vs dir
api-core-feature: this is the CoreModule that will include all initial setups like Config and Database Connection etc… and importing other Modules. CoreModule will be imported by AppModule
client-shell-feature: Same idea as NestJS’s CoreModule. This Shell includes
client-feature-1-feature: This can either a dir or a lib.
└── feature ├── list (angular:lib e.g ProductList) └── detail (angular:lib e.g. ProductDetail)
feature usually contains the ContainerComponent and the RouterModule.forChild()
client-shared-ui is a little tricky. The general recommendation is to NOT grouped stuffs by type like
pipes etc… into a single module but because these are shared, it is easy to get quite messy if not grouped by type. This is your call. We prefer to have a Single Component Per Module (SCAM) for each angular library.
This structure is proposed by my friend Chau Tran and I am applying it for my latest project!
Following the above structure will bring three advantages:
data-accesscan import other
data-access. But never import its
feature. For example:
user/data-accesscan import from
product/data-accessbut it will never import from
feature: can only import its own
data-accessor the global
shared/data-access. For example:
user/featurecan import from
user/data-accessbut never from
util: Utils can be shared across