---
# System prepended metadata

title: Status Page One Pager
tags: [' Devx', ui, ' refactor']

---

---
tags: ui, refactor, Devx
---

# Status Page One Pager

## tl;dr

*Using bullet points or at tops 4-5 sentences, explain the take-away readers should have.*

- `protocol-frontend > components` folder is the pool for all UI components used in the project (~44 Components). 
- The folder is getting larger and bloated with all of these files as long as we continue developing and add more feature to the frontend layer. 
- The component is losing context and its relations with the page(s) that are using them. This could affect DevX and navigating could be more harder with a folder heirarchy that add context/relation to these files.

## Situation

*Set the stage for us, how did you end up on this problem.*

- At Project Planning Meetin, there was a discussion for adding a dashboard for DAOs, which will require adding more dozen of components to project's compontents pool. 
- I suggested that the folder is getting larger and could affect our insights and navigation through the project. 
- A discussion for what if this can benefit us or not continued. What is the benefits from changing the folder heirarchy of the components or pages folder can add to us.

## Pain Points

*What are the actual pain points you're experiencing that you want to solve with your idea.*

- This is more enhancment than leaving it to become a pain in the near future. 
- Little or obsecure insights about Modularization: What the most common components the main building blocks of the app.
- You only can navigate to these components through code or search. 
- You have no idea how many components related to page under use.

## Proposed Solution

*What you're proposed solution to the pain points is.*

There is no strong opinion on that. The idea is add context to the comonent from just looking at the file heirarchy: 
- Each component could be accompanied with the page its using.
    - Either next to its page (I favor that). 
    - or in a named folder. 
- For common components that are used in muliple pages could be moved to a `/common` folder. 
- Note that we have a distinct lib for the building, styled blocks that will be used in the whole app. 
## Considerations

*Any considerations we should keep in mind while thinking through your one pager.*
- This might be a premature optimization (keating). 
- We can at least agree on a vision & opinion for the next added pages as expirment, then gradually updated the project as needed. 
- If we wanted to go further & create a feature-wise package, we can even [locate queries](https://tkdodo.eu/blog/effective-react-query-keys#colocate) next to it

---

## Meeting Notes 

- Notes from when we're able to sync up!