[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.