[RFC] Refactoring GFG repo

[kohchihao]

Issue

As GFG repo continues to grow larger, the current folder structure doesn't seem be as clear and direct to a developer.

As a result, differentiating from a dummy component from a page component is difficult.

Suggestion

src/components:

• Reserved only for dummy components
• No api/business logic should be found within such components
• Components here should be generic and not tied to any particular page

src/pages:

• Reserved only for page components
• Business logic/Apis can be found within the components here
• src/pages/{pageName}/index.js
  • entry point for that particular page
• src/pages/{pageName}/components
  • Components that belong to this page components should live within here
  • Have a index.js that exports all the components within, this is done so that importing components can be in a single line
  • This can be a recursive folder structure.
  • Eg: src/pages/components/RegisterDonor/index.js can have src/pages/components/RegisterDonor/components/RegisterCard/index.js
• src/pages/{pageName}/utils
  • utils that belong to this page should live here
• src/pages/{pageName}/constants
  • constants that belong to this page should live here

src/utils

• Reserved only for generic utils

src/constants

• Reserved only for generic constants

Additionally, try to group the import statements based on their groups if possible, i.e.

// components
import Header from '@components/header';
import SessionProvider from '@components/session/modules/SessionProvider';
import ContactUsPage from '@pages/contactUs';

// constants and utils
import { WISHES } from '@constants/search';
import { isAuthenticated } from '@utils/authentication/authentication';

// dynamic imports
const TopNavigationBar = dynamic(() => import('@components/navbar/modules/TopNavigationBar'), { ssr: false });
const BottomNavigation = dynamic(() => import('@components/navbar/modules/BottomNavigation'), { ssr: false });
const Footer = dynamic(() => import('@components/footer/Footer'), { ssr: false });

Template to copy

// components

// hooks

// constants and utils

// dynamic imports

Benefits

• Separation of concern from each page. As such, we can introduce new UI libraries for individual pages without worrying that it might affect other pages.
• Easier to scale in terms of adding new pages

Downsides

• Potentially might have duplicated codes

[kohchihao]

Please share your concerns and suggestions if any

[jamessspanggg]

I agree that the above is a more maintainable structure, but refactoring this might take quite an effort so I suggest that we do this incrementally, perhaps on a page by page basis

[kohchihao]

@jamessspanggg Agreed. This should be done incrementally. After this is approved by everyone, I will make a todo list within this issue to track what needs to changed.

[jinyingtan]

Folder structure looks good with clear purpose for each location. Just a few questions:

1. src/components is for reusuable components only right?
2. src/pages/{pageName}/utils: Any examples of what utils we have?
3. In this case, colors constants should be in generic constant?

[kohchihao]

@jinyingtan

Regarding

1. Yes. In some sense. Stuff that can be within here could be our Cards, Buttons, Footer, etc...
2. Could be our current utils/algolia/filteringRules --> if we can split them into respective pages, it much easier for the developer to find.
3. Yes. Colors will be within generic constants

[kohchihao]

After speaking to everyone. We have decided to go ahead with this major refactoring. I will put a Todo list inside this issue to keep track of the changes that we need to make over the subsequent weeks.

[kohchihao]

Let's refactor pages first and leave the individual components alone.

By doing this refactor, there might be duplicated code. It is fine because it helps with the readability of the codebase overall. But we shouldn't be afraid of having some duplicated code.