Improve folder structure and file naming

[berteotti]

Description Here each one of us must comment his personal best folder structure to help us come up with the best solution.

Definition of done

• [ ] Description is created (Task creator)
• [ ] Code is complete (Developer)
• [ ] Scope of test and what was done section is defined in task (Developer)
• [ ] Review passed (Code reviewer)
• [ ] Verified manually (QA)
• [ ] Test cases created/updated if necessary (QA)
• [ ] Change successfully merged
• [ ] Release notes added if needed

[Diogomartf]

I think it's important to create an UI (could be a better name) folder with only "styled"/visual components, to have a distinction from components tied with logic.

[Diogomartf]

I think it's important to create an UI (could be a better name) folder with only "styled"/visual components, to have a distinction from components tied with logic.

[berteotti]

Old description:

Folder structure is a bit messy. Is hard to know where is the right place to write new code and the folder structure should reflect that, being self-explanatory.

Sometimes we use index.tsx file to write components, other times we use the component name to name the file. This should follow the same rule everywhere.

Also, we have a lot of code within each index file. We should mind separation of concerns and write "different" code in different files (the file name defines what the code is about).

We have yet to discuss and decide which folder structure we want/need.

[Mi-Lan]

Yeah I agree with @Diogomartf this is usually handled by always having 2 files for each component one for the logic part and the other just for styles called styleds.ts it is very common pattern and will solve issue with overbloated components.

• But in general how this should be handled is that all components inside the components folder are just view components with minimal logic since they are meant to be reusable.
• If you look an uniswap-s codebase and go through components folder you will see that this codebase is designed to be like that. They handle very little of logic inside of there and most of the parts come together inside the pages folder.

[wixzi]

I suggest to go with below structure of component splitting. Instead of a fixed way of logic, styled components. Split based on functionality.

`Collections` is the Page level
|-> `Components`  shared components of collections
|-> `Create Page` (folder)
|-> `MarketingCollectionPage` (folder)
           |->  `MarketingCollectionPage.tsx`
           |->  `MarketingCollectionPage.test.tsx`
           |->  `index.tsx` exports MarketingCollectionPage.tsx
           |->  `MarketingCollectionPageSubComponet.tsx`
           |->  `collectionUtils.ts`
           |->  `collectionTypes.ts` all these files can live in this level or Subfolders as per complexity and exported from index.tsx if need to expose outside.

|->  index.tsx All Collections routes will here as sub routes 

Also move to yarn workspaces and separate features into packages like core -> Routing, Bridging and all core functionality can live here ui -> The design system of swapr with all UI components and Icons swapr -> View logic of swapr storybook -> All storybook configurations and general stories. (component stories can live with each component in swapr) utils -> General utils, like routing, trim, or all shared utils can live here tests -> All cypress and synpress tests (unit tests still live along the components) api -> All api's and schemas can be moved here along with mocks so its easy to unit test with mocks docs -> All documentation can live here

[Mi-Lan]

I suggest to go with below structure of component splitting. Instead of a fixed way of logic, styled components. Split based on functionality.

`Collections` is the Page level
|-> `Components`  shared components of collections
|-> `Create Page` (folder)
|-> `MarketingCollectionPage` (folder)
           |->  `MarketingCollectionPage.tsx`
           |->  `MarketingCollectionPage.test.tsx`
           |->  `index.tsx` exports MarketingCollectionPage.tsx
           |->  `MarketingCollectionPageSubComponet.tsx`
           |->  `collectionUtils.ts`
           |->  `collectionTypes.ts` all these files can live in this level or Subfolders as per complexity and exported from index.tsx if need to expose outside.

|->  index.tsx All Collections routes will here as sub routes 

Also move to yarn workspaces and separate features into packages like core -> Routing, Bridging and all core functionality can live here ui -> The design system of swapr with all UI components and Icons swapr -> View logic of swapr storybook -> All storybook configurations and general stories. (component stories can live with each component in swapr) utils -> General utils, like routing, trim, or all shared utils can live here tests -> All cypress and synpress tests (unit tests still live along the components) api -> All api's and schemas can be moved here along with mocks so its easy to unit test with mocks docs -> All documentation can live here

Hey men not sure if you read my last comment but our codebase is supposed to be already kinda structured like this. So components folders should be just view and pages folder should be view-logic which is similar to what you are suggesting. Yeah I agree with stories part as well and if we go with unit tests they can also be done within storybook I wrote more about that on the storybook issue...

[wixzi]

I suggest to go with below structure of component splitting. Instead of a fixed way of logic, styled components. Split based on functionality.

`Collections` is the Page level
|-> `Components`  shared components of collections
|-> `Create Page` (folder)
|-> `MarketingCollectionPage` (folder)
           |->  `MarketingCollectionPage.tsx`
           |->  `MarketingCollectionPage.test.tsx`
           |->  `index.tsx` exports MarketingCollectionPage.tsx
           |->  `MarketingCollectionPageSubComponet.tsx`
           |->  `collectionUtils.ts`
           |->  `collectionTypes.ts` all these files can live in this level or Subfolders as per complexity and exported from index.tsx if need to expose outside.

|->  index.tsx All Collections routes will here as sub routes 

Also move to yarn workspaces and separate features into packages like core -> Routing, Bridging and all core functionality can live here ui -> The design system of swapr with all UI components and Icons swapr -> View logic of swapr storybook -> All storybook configurations and general stories. (component stories can live with each component in swapr) utils -> General utils, like routing, trim, or all shared utils can live here tests -> All cypress and synpress tests (unit tests still live along the components) api -> All api's and schemas can be moved here along with mocks so its easy to unit test with mocks docs -> All documentation can live here

Hey men not sure if you read my last comment but our codebase is supposed to be already kinda structured like this. So components folders should be just view and pages folder should be view-logic which is similar to what you are suggesting. Yeah I agree with stories part as well and if we go with unit tests they can also be done within storybook I wrote more about that on the storybook issue...

☝🏼 I am also onboard. 👍🏼 My idea was little different. All shared components can be on components folder and specific components can live nearby. But I am ok with the above structure also since our project don't have that many pages.

[berteotti]

Here is a doc summarising what was discuss about folder structure on June 24th meet, made by @Mi-Lan (Good job man!) https://docs.google.com/document/d/1mr9gleqXWNDVrJ27hEKaBC29etMUNVjYRQdyeffEyH8