Next.js

## Benefits over CRA

[My summary of below on Twitter](https://twitter.com/housecor/status/1508428589242458113)

1. Faster startup (compiles pages on-the-fly)
2. Faster builds (uses swc and Turbopack).
3. Supports React Server components with automatic server-side caching
4. Static generation support
5. Server-side rendering with dynamic data via `getServerSideProps`. This often leads to faster loading performance since HTTP calls start earlier, and the server typically has a much faster and more reliable connection than the user's machine/phone. It also improves SEO.
6. Strong opinions about where things go (makes it easy to switch between projects)
7. More active development (check release notes!)
8. Built in, file-based client-side routing. Dynamic routes via [placeholder].js syntax. Export async `getStaticPaths` func inside that returns an array possible id values. Also export `getStaticProps` to fetch necessary data.
9. Auto code splitting by route (splits CSS modules too). So, lazy loads by default (set priority to true to eager load)
10. Auto prefetches links
11. Automatically rendered to avoid layout shift (Next/Image helps enforce this by requiring width and height)
12. next/image optimizes images, even for external sources. Optimizes them on-demand instead of at build time.
13. Prettier error page (though errors are occasionally cryptic)
14. Built in Head component for title, favicon, meta tags (no need for Helmet)
15. Built-in styled-jsx (but like CRA can use any CSS-in-JS lib)
16. Integrated hosting, CI, and deployment via Vercel. Ephemeral branches: Push to any Git branch to preview, hosted. Then push to main to deploy. Slick. Like Netlify.
17. Eliminates unused CSS
18. Already supports React 18 server components
19. Add files to pages/api to get a serverless API. Useful for saving form input, calling a 3rd party API, or previewing draft content.
20. Uses Express and supports Express middleware
21. Font optimization
22. Built in scroll restoration

## Cons
1. Have to restart the app sometimes
2. Occasionally cryptic error messages
3. "Leaky" Link abstraction requires declaring href in odd ways depending on what's being wrapped. To add attributes like className, target, rel, etc to the actual anchor, must actually slap an anchor underneath: https://github.com/vercel/next-learn/blob/master/basics/snippets/link-classname-example.js
4. File based routing leads to multiple files named index.
5. Starting dev doesn't catch TS errors. Gotta run the page.
6. Missing: eject, ESLint, Testing

## 3 rendering strategies

1. [Static generation](https://nextjs.org/docs/basic-features/pages#static-generation-recommended) (generates HTML at build time). Win: Renders without JS! Pre-renders each page’s HTML, instead of via client-side JS. (So better perf and SEO). Minimal JS is included as needed (called hydration after load). To decide if this is merited, ask yourself: "Can I pre-render this page ahead of a user's request? Can even do static generation with data using `getStaticProps`, so data is fetched during build (from file system or HTTP). (in dev this runs on page load). See oddities below for more on getStaticProps. Pages that use Static Generation and assets (JS, CSS, images, fonts, etc) will automatically be served from the Vercel Edge Network, which is blazingly fast.
2. Server-side rendering - Dynamically generates HTML on each request. Use when page shows frequently updated data / content changes on every request. Use `getServerSideProps` instead. Time to first byte (TTFB) will be slower than [getStaticProps](https://nextjs.org/docs/basic-features/data-fetching#getstaticprops-static-generation) because the server must compute the result on every request, and the result cannot be cached by a CDN without extra configuration. Pages that use [Server-Side Rendering](https://nextjs.org/docs/basic-features/pages#server-side-rendering) and [API routes](https://nextjs.org/docs/api-routes/introduction) automatically become isolated Serverless Functions. This allows page rendering and API requests to scale infinitely.
3. Static get without data + fetch data client side (use for private, user-specific pages where SEO isn’t relevant - that’s a LOT of pages)

Can choose between the 3 above on each page.

NOTE: Do Not Fetch an API Route from getStaticProps or getStaticPaths (would be nonsensical because the code only runs on the server).

Easily add Tailwind (Likely true for CRA too?)
Polyfills fetch

Oddities
1. No src dir. Instead: all folders at root: pages, components, public
2. No index.html. To customize the tag, (for example to add the lang attribute), create a pages/_document.js file
For global CSS, must create pages/_app.js - This component is common across all pages. Think “base page”. You cannot import global CSS anywhere else.
getStaticProps or getServerSideProps to import external blog data into the index page.
Can query DB directly since it only runs server-side. Code in getStaticProps isn’t even sent to client.
Note: getStaticProps can only be exported from a page

## Dev tools used behind the scenes
- Turbopack
- Swc
- Babel
- TypeScript

## Conditional Rendering
```js
if (typeof window !== 'undefined') {
// client-side-only code
}
```
or, via a component: https://github.com/vercel/next.js/issues/2473#issuecomment-587551234

## Addons

[Next-runtime](https://github.com/smeijer/next-runtime) provides Remix-like ability to handle posts in the same file via `getServerSideProps`.
https://github.com/blitz-js/superjson