Restructure frontend files into component-based folders

Context

Currently, the frontend code of our app is organized in a way in which most components contain a single .tsx file with all of the component’s logic, styles, and rendered HTML markup in one place. The file structure is also organized in a way in which most components sit at the root of the dashboard or other subfolder preventing the components and their related files from being grouped in the most intuitive way.

As we begin to design out a new potential dashboard for the recommendations feature and further expand the app’s UI, we should refactor and organize our frontend in a way that groups a component and its related assets/subcomponents into a single folder for better navigation, organization of concerns, and maintainability.

Example:

CarbonIntensityMap
├── __snapshots__
│   └── CarbonIntensityMap.test.tsx.snap
├── AWSMap.svg
├── AzureMap.svg
├── CarbonIntensityMap.test.tsx
├── CarbonIntensityMap.tsx
├── GCPMap.svg
├── index.ts
└── carbonIntensityStyles.ts

Tasks

For each primary dashboard component, do the following:

• Create a subfolder in /dashboard with the component names in uppercase format (i.e. dashboard/CarbonIntensityMap) to hold each of the component’s files and supporting assets
• Move the primary component into that subfolder, and update import paths as necessary (IntelliJ or VSCode should do this for you)
• Create an index.ts file to export the component as the directory’s default export (for easy imports)
• Move test file of component into new subfolder
• Identify any rendered subcomponents (i.e. ApexBarChart.ts) and move them as well as their test files into the subfolder (make sure imports and paths are updated)
• Check for any remaining assets (images, specific helper files, etc) and move them into the new folder as well

Afterwards:

• Run Changesets, bump any packages that have been updated/changed
• Did you make changes to the client, api or cli package? If so, considering updating the create-app templates.

Tech/Implementation Details

This could also be a good opportunity to identify and organize any reused subcomponents into a common folder.

Good resource, especially for index exporting: https://medium.com/bootstart/you-should-be-using-folder-components-b30b7d165c39

• The CarbonIntensityMap was created with this directory pattern in mind, so it can be a good reference for how each component directory should look.

[dtoakley]

I’m not 100% sure I follow the reasoning behind 1, but maybe could we rename the directory to EmissionsOverTimeChart or EmissionsOverTimeCard as that is what the Line Chart is all about. CloudUsage is just to vague/broad – the whole front-end is about “Cloud Usage”. Hope that makes sense.

[4upz-tw]

That makes sense! I think we could definitely rename it to something better than Cloud Usage so we’ll make that change