Date: 2023-05-16
Accepted
Our software project has a frontend that needs to be organized to facilitate maintenance, scalability, modularity, and ease of navigation. The current directory structure is outdated and hard to manage. As software engineers, we propose a new directory structure based on some criteria.
We studied Redux' documentation about common patterns for project structures.
Most of the discussion happened reviewing web/#1355.
We propose the following new directory structure for the frontend of our software project:
assets/js
├── app.js
├── common
│ ├── Banners
│ ├── Button
│ │ ├── Button.js
│ │ ├── Button.stories.js
│ │ ├── Button.test.js
│ │ └── index.js
│ ├── ListView
│ ├── Modal
│ ├── ObjectTree
│ ├── Table
│ ├── Tags
│ └── Tooltip
├── pages
│ ├── AboutPage
│ ├── ChecksCatalog
│ ├── ClusterDetails
│ ├── DatabaseDetails
│ ├── DatabasesOverview
│ ├── ExecutionResults
│ ├── Health
│ ├── HealthSummary
│ ├── Home
│ └── HostDetails
├── hooks
├── lib
├── state
│ ├── sagas
│ │ ├── clusters.js
│ │ ├── clusters.test.js
│ │ └── index.js
│ ├── selectors
│ │ ├── clusters.js
│ │ ├── clusters.test.js
│ │ └── index.js
│ ├── clusters.js
│ ├── clusters.test.js
└── trento.jsx
Note that /common contains truly generic and reusable utilities and components.
There may be some overhead associated with restructuring the frontend, such as updating dependencies, fixing references, or rewriting some parts of the application. However, in the long term, this new directory structure will ensure an organized and efficient system that can be easily maintained, scaled, and navigated. The new structure will also facilitate collaboration between developers as they will have a better understanding of where everything is located.
We have one drawback: action creators related to sagas now live along with slices and action creators generated by redux-toolkit. We found reasonable to have action creators all stuffed in one specific place, but it is well understood that it might not be the case for everyone.