--- 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!