You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi everyone, looking at the frontend codebase I've realized that it does not follow the Angular guidelines.
To be honest this is nothing new, it has been in this way for a long time (since the beginning of the project?).
Nevertheless I've think that a refactor of the project inside the web folder, may be benefitial to many people in several ways:
adopting a well-known project structure should facilitate new contributors in adding and/or improving features
it would help existing contributors, boosting productivity. Having a more organized project means that you simply have to waste less time searching for files around the various folders
Official guidelines can be found in the documentation and you may find many more posts around the internet that advocate for having a better structured Angular application.
Current Setup
Currently the client side project is structured as follows:
As you can see, everything is kinda mixed up.
For example you have some scss files in the theme folder, whereas a more appropriate place would be a folder called themes alongside the src, assets and environments folders.
All the above folders (except for the pages one) include only a single service file that gets injected wherever they need to be injected.
The pages folder has too many children directories that make it difficult to understand where stuff is declared.
For example, to find the pipes used by the log viewer page, you would have to reach for this path app/pages/dashboard/detail/logs/pipes.
Proposed Setup
A more widely adopted project structure could look like this:
core <-- Bootstrapping stuff
components
pages.component.{ts|scss|html} <-- Application shell
services
interceptor.service.ts <-- Adjusts HTTP requests if dashboard is behind a reverse proxy
globals.service.ts <-- Used to quey version and platform from APIs
scopes.service.ts <-- Used to query scopes such as K8S namespaces
shared
components
editor <-- Monaco editor
services
components.service.ts
configurations.service.ts
features.service.ts
instances.service.ts
logstream.service.ts
theme.service.ts
websockets.service.ts
models
types.ts <-- API response typings
modules <-- One folder per dashboard area/section
control-plane <-- Each folder can have subdirectories for specific components, services, ...
components
models
services
pipes
configurations
components
overview
You would have a core folder containing all those files required in order to bootstrap the application and to show the user something, even a basic page with a simple menu.
In this case it would contain the required stuff that is used to render the toolbar and the sidenav with the menu, plus some services used to adjust HTTP requests and to query some basic information used throughout the entire application.
The shared folder would contain all those components, services and similar stuffs used by other components/pages that do not belong to a specific page and that could become useful in the future.
For example the editor component could be used by several pages and components, so it makes sense to have it as a shared element.
The models folder could contain some type definition files (e.g. API response typings).
The modules folder would contain a folder for each feature of the dashboard.
Essentially you would have a folder for each dashboard route.
Each of these folder could than contain a folder for components, models, services and so on.
Those are strictly related to that page and they will not used by other pages (because not applicable, they would make no sense, ...).
Additionally, each child of the modules folder could contain more folders for each sub feature of that module.
If this seems reasonable and something benefitial to project, let me know so that I can take on this work and open a pull request.
The text was updated successfully, but these errors were encountered:
l0ll098
changed the title
Refactoring of the frontend project structure
[Proposal] Refactoring of the frontend project structure
Feb 3, 2022
Refactoring of the frontend project structure
Hi everyone, looking at the frontend codebase I've realized that it does not follow the Angular guidelines.
To be honest this is nothing new, it has been in this way for a long time (since the beginning of the project?).
Nevertheless I've think that a refactor of the project inside the
web
folder, may be benefitial to many people in several ways:Official guidelines can be found in the documentation and you may find many more posts around the internet that advocate for having a better structured Angular application.
Current Setup
Currently the client side project is structured as follows:
As you can see, everything is kinda mixed up.
For example you have some scss files in the
theme
folder, whereas a more appropriate place would be a folder calledthemes
alongside thesrc
,assets
andenvironments
folders.All the above folders (except for the
pages
one) include only a single service file that gets injected wherever they need to be injected.The
pages
folder has too many children directories that make it difficult to understand where stuff is declared.For example, to find the pipes used by the log viewer page, you would have to reach for this path
app/pages/dashboard/detail/logs/pipes
.Proposed Setup
A more widely adopted project structure could look like this:
You would have a
core
folder containing all those files required in order to bootstrap the application and to show the user something, even a basic page with a simple menu.In this case it would contain the required stuff that is used to render the toolbar and the sidenav with the menu, plus some services used to adjust HTTP requests and to query some basic information used throughout the entire application.
The
shared
folder would contain all those components, services and similar stuffs used by other components/pages that do not belong to a specific page and that could become useful in the future.For example the editor component could be used by several pages and components, so it makes sense to have it as a shared element.
The
models
folder could contain some type definition files (e.g. API response typings).The
modules
folder would contain a folder for each feature of the dashboard.Essentially you would have a folder for each dashboard route.
Each of these folder could than contain a folder for components, models, services and so on.
Those are strictly related to that page and they will not used by other pages (because not applicable, they would make no sense, ...).
Additionally, each child of the
modules
folder could contain more folders for each sub feature of that module.If this seems reasonable and something benefitial to project, let me know so that I can take on this work and open a pull request.
The text was updated successfully, but these errors were encountered: