Star Wars Mini Wiki is powered by SWAPI GQL to serve mini wiki of star wars.
- emotion: to provide css in js styling in css performance
- graphql: for better than REST API (no debate XD)
- any UI library: It was planned to use ThemeUI (actually it was installed on first commit), but the website UI is too minimalist to use UI library.
- lodash or any util libraries: even though there is some utilities that might be useful but lodash is too fat for this simple projects.
The reason to not including this wonderful libraries is to only boost preformance (even though the score on this is quite
lowcheck performance section below). The developer saw the opportunity to implement Next JS' SSG as a comparison to another Next JS projects which not using SSG.
consists of 12 pages (the global & detail page), namely:
- films + detail
- characters + detail
- planets + detail
- species + detail
- starships + detail
- vehicles + detail
This 12 pages only use the same 2 base components, which is <GetAllLayout /> & <DetailLayout />.
The only reason to separate it into 12 files in pages folder is to avoid heavy slug & enable the NextJS built-in SSG + page optimization feature. If this were created with create-react-app, it considerable to use only 1-2 page files & spill the if else conditioning simultaneously with the routing.
This the best part! Next JS' SSG actually works very nice on production! the CLS is scored low caused by the absence of shimmer/skeleton implmentation.
*and its PWA enable ;)
Don't be confused by @/ import because it just webpack mapping to <rootDir>/src to shorten import
This is the second best part and the laziest part XD. Next JS' SSG gives the built in .fallback: 'blocking' feature to block the HTML before the static fetching complete. It is kinda "turn off" the hydration best practices, but in small project with multiple pages like this we can implement error handling frugally XD
It will show the loading spinner given empty data (may caused by failed query, abnormal data, etc.)
