📎 Organize components/pages into features

[sruenwg]

Description

Discuss and implement the reorganization of the frontend code into features.

We concluded in https://github.com/sugar-cat7/vspo-portal/pull/259 that we should consider organizing the frontend by feature, following the bulletproof-react project structure. The main motivation for this is to organize component/page utilities such that they live close to and are scoped only to the components/pages in which they are meant to be used (as opposed to the current design where utilities must either be globally scoped or file-scoped).

Potential points to discuss:

1. What comprises a feature? What features does the app have?
2. Which components and pages might belong to which feature?
3. Which components are generic enough to remain in /components? Which components might make sense to be refactored into a more generic component which can then live in /components?
4. Is there anything aside from the /features directory which would make sense to adopt from the bulletproof-react structure?

[sruenwg]

Just so we have something to work off of:

1. I am personally unsure as to what we should consider a feature. @sugar-cat7 mentioned pages and features might map 1-to-1, but to me a big appeal of the /features structure is how pages can be grouped based on relatedness. For example, /clips and /twitch-clips are similar in purpose/functionality and have shared components specific only to these pages, so I feel encapsulating this in something like a clips/clip-browser feature might make a lot of sense. (With that being said, I agree that maybe a lot of pages should just be their own feature.)

2. Building on the above pattern, here is a rough preliminary idea:

   features
   ├── events
   │   ├── pages
   │   │   ├── Events (exported to /pages/events/[yearMonth]
   │   │   └── Event  (exported to /pages/events/details/[id]
   │   └── components
   │       └── ...
   ├── livestreams
   │   ├── pages
   │   │   ├── Freechats (exported to /pages/freechat)
   │   │   └── Schedule  (exported to /pages/schedule/[status])
   │   └── components
   │       ├── LivestreamCard
   │       └── ...
   ├── site-news
   │   ├── pages
   │   │   ├── SiteNewsList (exported to /pages/site-news)
   │   │   └── SiteNewsItem (exported to /pages/site-news/[id])
   │   └── components
   │       └── ...
   ├── about
   │   ├── pages
   │   │   ├── About (exported to /pages/about)
   │   └── components
   │       └── ...
   ├── clips
   │   ├── pages
   │   │   ├── YouTubeClips (exported to /pages/clips)
   │   │   └── TwitchClips  (exported to /pages/twitch-clips)
   │   └── components
   │       ├── SearchDialog
   │       ├── ClipTabs
   │       ├── ClipList
   │       ├── ClipCard
   │       └── ...
   └── policies
   ├── pages
   │   ├── Terms   (exported to /pages/terms)
   │   └── Privacy (exported to /pages/privacy-policy)
   └── components
       └── ...

   This is just an idea so we can start discussing benefits/drawbacks of different designs. In the structure above I mainly created features out of groupings of pages which shared similar components and functionality.

3. I feel most components can stay in /components aside from clearly page/component-specific ones such as ClipTabs, ClipList, Livestreams, LivestreamCard, and SearchDialog. Maybe VideoModal should also be its own feature.

[sugar-cat7]

Certainly, it's incorrect to say that features and pages have a one-to-one relationship; it seems more appropriate to group related files based on modules or functional units, such as grouping all clip-related functionality together.

1. Personally, I consider the following to be the unique features of the current web application:

• Posting of streaming information (archives, upcoming, live, freechat (though it's debatable whether it should be included))
• Posting of clips (YouTube, Twitch)
• Posting of events (List, Detail)
• Posting of announcements (Site News)
• Posting about how to use the site (About?)
• Posting of terms (Terms/Privacy Policy)

Therefore, I don't feel any discomfort with the structure @sruenwg has shown in point 2.

Regarding point 3, I also think it would be good to generalize LivestreamDetailsModal, LivestreamCard into components like Modal and Card, and then customize them in features like ClipCard for clips and LivestreamCard for livestreams. It also seems appropriate to encapsulate specific fetcher functions from lib/api.ts and type definitions from types within their respective features.

I don't have anything particular for point 4. If I had to mention something, it would be about splitting the util files. But even that seems to be a matter of transferring specific logic and making adjustments if the readability is poor.

[sruenwg]

It also seems appropriate to encapsulate specific fetcher functions from lib/api.ts and type definitions from types within their respective features.

👍

Posting of announcements (Site News)

Unrelated to this issue but 'announcements' might also have been a good name for #252…