Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Proposal] Refactoring of the frontend project structure #185

Open
l0ll098 opened this issue Feb 1, 2022 · 0 comments
Open

[Proposal] Refactoring of the frontend project structure #185

l0ll098 opened this issue Feb 1, 2022 · 0 comments

Comments

@l0ll098
Copy link
Contributor

l0ll098 commented Feb 1, 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:

  • 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:

components
configurations
features
globals
instances
logstream
pages
    dashboard
        detail
            logs
                pipes
    dapr-components
        dapr-component-detail
    configuration
        configuration-detail
    controlplane
scopes
services
shared
    editor
theme
types
websocket

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.

@l0ll098 l0ll098 changed the title Refactoring of the frontend project structure [Proposal] Refactoring of the frontend project structure Feb 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant