Open sruenwg opened 6 months ago
Just so we have something to work off of:
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.)
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.
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.
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.
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.
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β¦
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:
/components
? Which components might make sense to be refactored into a more generic component which can then live in/components
?/features
directory which would make sense to adopt from thebulletproof-react
structure?