Knowledge base

Git

Set repo-level user:

git config user.name "2blo"
git config user.email 2blo.dev@gmail.com

Change commit author (note that there is both an author tag and the author line in the commit description)

git commit --amend --author="2blo <2blo.dev@gmail.com>"

The PR will persist the old author, delete the PR, or rebase -i drop the commit and push --force

Autocomplete tailwind anywhere - add to vscode settings.json:

  "tailwindCSS.experimental.classRegex": [
    "\"([^\"]*)" // "..."
  ]

fetch data with useEffect() --> client side render: learn Nextjs (but use Tanstack query).
"Every page is prerendered by default"
SSR: generate html for EACH request
hydration: attach event handlers to buttons
"opt to SSR pages with getServerSideProps"
SSR + CDN caching, fast for the second user. Cache control header: Cache-Control: max-age=<seconds>, (wont refresh after unless a user comes?)

CSS + JS assets that is put on CDN has infinite max-age, but you want to update it when you redeploy. Done by hashing the asset "name/url". Does not work for normal pages since we want to use the same url.
max-age in browser, s-maxage in CDN. dont use big max-age since the user's content cannot be force updated (I guess it is not an issue for new users). s-maxage will be guaranteed to run periodically, so you can update for users that had a long max-age.
stale-while-revalidate=59: no / short max-age -> slow SSR, but with stale-while-revalidate=59 you get the stale while it is rendering (dont care about rendered), so it is like ISR in nextjs. However, if the cache is 59 sec or older, we will wait for SSR.
Vercel has static caching by default, no custom headers needed. Cannot bypass caching (I assume it is too expensive otherwise)
Vercel uses max-age=0 and must-revalidate by default (can change in vercel.json), to control cache in 1 single place?
ISR vs cache-control headers: ISR has global cache, so if one region has a cache miss, it can reuse a non-stale cache that was recently rendered on behalf of another region.
In nextjs, you can manually revalidate a page (without waiting for a user), with e.g a webhook to your api:

Vercel puts edge functions and "static files" (cached SSG content?) on the edge (CDN).
static files is in every CDN location, but functions only in some. -Edge functions are the same as serverless functions except closer to the user.

when to use what: good demos

SSR - ~~ecommerce page~~ - only reason to use is SEO, prefer SSG + client side fetching for speed.
SSG - blog - static or does not update often "headless CMS", renders once on build time?
CSR - just text from source code(?) - no, that is still SSG, its e.g useEffect().
SWR - client side fetching - works nice with SSG. Does not use caching though.
ISR - incremental static regeneration - SSG but rebuild periodically, for nextJS: on nav, get pre-rendered, start render for next person.

SWR

Query

can cache
nice for handling succes, load, error state for mutation syncing with client and server.

pages/api/x are used by clients docs.
pages/server/x are used by middleware etc: docs.
tRPC has nothing do do with routing, it just lets your client query the backend API in a type safe way. You still route with nextjs using pages/your_page.tsx and Link components: t3 trpc docs.

getStaticProps on a fixed path will use SSG, generated on build
getStaticProps + getStaticPaths on a dynamic route pages/blogs/[id].ts will do the same. "use when data comes from other place like DB or headless CMS", what if all the data is static HTML/images from your "repo"? It does not matter, we run at build time anyway. If the path is not dynamic, just use getStaticProps. This will be done by default for pages that dont need outside data.
You can use local file api cache to not have to make the same api request in both getStaticPaths and getStaticProps.

runs between request and return of static content. Middleware can be e.g auth, for t3: error if not authed. I guess you could do it in your javascript, but then you need to redo it explicitly in each file.
Based on personal info in cookie, like language, country, group, redirect to personalized page.

CMS - frontend + content coupled, like Wordpress.
headless CMS, just content stored somewhere, behind an API that you can use on multiple clients.