Project Restructuring - Discussion

[miggs125]

The code-base for dashboard, although functional, is somewhat convoluted and at times redundant. I propose a restructuring of the project (with the input of it's contributors of course) to make the code-base more readable and maintainable and eliminate redundancies before we continue adding more functionality and features to the project. Perhaps we should create a document detailing classes, functionality and structure agreed upon by all before beginning to implement the restructure. This would also make it easier for new RAs to get involved with the project and spare senior RAs from having to explain how the project functions by pointing them to the proposed documentation. We could take this opportunity to implement the ostep repo standards into the dashboard as well.

[scrust]

I remember when I first started digging into the dashboard codebase I had trouble understanding where xhr requests / data loading was happening, and where state was being stored for each component. Having components inherit from a base Container class was unexpected, especially since React recommends composition over inheritance.

I also think it would be beneficial to more clearly separate the "frontend" and "backend services". The current project structure looks like this:

.
├── DB1042
├── Dashboard
├── Github
├── Infrastructure
├── Lamp
├── Osteppy
├── RAPresenter
└── ...

which puts the supporting services like Osteppy and the GitHub proxy service together on the same level as the frontend React Dashboard.

We should look into ways to separate out data that changes (relatively) frequently and should really live in config files or environment variables not committed to the project (potentially related to #39 ?). This would save PRs like #68, #42, #58, #40, #41, #26, etc and keep this kind of configuration information out of the codebase.