Server-Side Rendering vs Client-Side Rendering

Musím se přiznat, že když jsem poprvé začal používat Next.js, vůbec jsem nechápal rozdíl mezi SSR (Server-Side Rendering) a CSR (Client-Side Rendering). Většinu projektů jsem do té doby dělal ve Vite nebo obyčejném Reactu. Pak jsem ale narazil na potřebu psát "use client" do komponent, které obsahovaly React hooky nebo interaktivní funkce jako onClick. To mě přimělo začít se více zajímat o web jako takový.

Časem jsem zjistil, že není úplně chytré cpát zbytečný JavaScript a React hooky, jako useEffect, do každé komponenty. Jasně, složité weby a aplikace se bez toho neobejdou, ale já jsem měl radost, když jsem svou aplikaci nebo jednoduchou webovou stránku dokázal udělat rychlejší díky tomu, že jsem odstranil zbytečný JavaScript. Místo toho jsem se naučil řešit funkce tak, aby běžely pouze na serveru, což mi přišlo mnohem efektivnější.

Next.js `<Image />` komponenta

Optimalizace obrázků mě dřív nijak zvlášť nezajímala, ale když jsem objevil možnosti Next.js <Image /> komponenty, byl jsem nadšený. Tahle komponenta totiž umí:

Automaticky převádět obrázky do formátu WebP, což zmenšuje jejich velikost a zrychluje načítání.
Podporuje lazy loading – obrázky se načítají, jen když jsou viditelné na obrazovce uživatele.
Snadno nastavit responzivní design pomocí atributů sizes nebo layout.
Používat placeholdery – například rozmazaný náhled obrázku (blur) před úplným načtením.

Rozmazaný placeholder jsem zakomponoval i na této stránce. Pokud máte pomalejší připojení, místo spinneru nebo skeletonu se nejdříve zobrazí rozmazaný obrázek, který je vygenerovaný jako Base64. K tomu jsem použil knihovnu Sharp, kterou Next.js podporuje.

Jak jsem to udělal?

Stačí nainstalovat knihovnu Sharp:

npm install sharp

Potom jsem vytvořil skript generate-blur.mjs, který mi generoval Base64 kód pro placeholder. Ten jsem pak použil v <Image /> komponentě takto:


  placeholder="blur" 
  blurDataURL={imageBlur || image}

Výsledek vypadá profesionálněji než klasické spinnerové načítání, a navíc je to super jednoduché na implementaci.

File-Based Routing

Dříve jsem ve svých projektech používal klasické routes Example

Ze začátku mě překvapilo, že Next.js používá složku app. Ano, od začátku jsem pracoval s verzí Next.js 14/15, která používá App Router. Zásadní rozdíl oproti Pages Routeru je například v tom, že App Router má footer a navbar v layoutu tak, jako je tomu na této stránce.

Další zásadní věcí je, že App Router má Server Components jako výchozí. V App Routeru se také nesetkáte s funkcemi jako getStaticProps nebo getServerSideProps, jak tomu je u Pages Routeru. Místo toho můžete jednoduše používat fetch() přímo v komponentách.

Využití [slug] v routeru:

Tohle mě na App Routeru zaujalo asi nejvíce. Jako příklad uvedu tento projekt. Začal jsem ho bez velkého přemýšlení – prostě jsem jel podle intuice a úplně zapomněl, že existuje něco jako [slug].tsx. Kvůli tomu jsem musel předělávat část projektu, aby fungovala přes slug: Commit

Vytvoření vlastního API Routeru

Vlastní API route jsem použil například ve svém projektu Aware. Na projektu jsem používal React Query a původně jsem fetchoval data napřímo na HomePage. Ale protože React Query běží na clientu a ne na serveru, a abych mohl fetchovat stránky jako například "for-you", musel jsem nastavit vlastní server endpoint route.ts (pro GET, POST requesty). Nejprve jsem vytvořil GET endpoint, přidal try-catch, logoval jsem error, pak jsem si vzal usera z funkce validateRequest(), a když je user autorizován, fetchnul jsem posts. Posts vracím: return Response.json(posts). Potom můžu použít React Query, pomocí kterého můžu dělat requesty na tento endpoint.

TypeScript , TailwindCSS a Deployment na Vercel

Ze začátku jsem se TypeScriptu hodně vyhýbal, protože jsem nechápal, proč bych se ho měl učit, když jsem měl pocit, že ani pořádně neumím JavaScript. Postupem času jsem ale zjistil, že je lepší mít TypeScript v projektu.
Pokud ho nechcete používat, nemusíte – můžete klidně psát klasický JavaScript, i když to není úplně nejlepší praxe. Jak jsem s ním postupně přicházel do styku, začal jsem pomalu objevovat, v čem je užitečný, hlavně u větších projektů. Díky TypeScriptu jsem začal přemýšlet o kódu jinak a snažím se psát komponenty co nejjednodušší na údržbu. Je to sice pořád „work in progress“, ale už vidím, jaké výhody mi to přináší.
S Tailwindem jsem začal prakticky od samého začátku, kdy jsem začal používat JSX, a od té doby jsem na klasické CSS skoro nesáhl. A nasazení na Vercel mi připadá neskutečně jednoduché, obzvlášť s Next.js – možná proto, že Vercel vlastně vytvořil Next.js jako open-source framework. Vercel navíc automaticky nasazuje všechny změny, které commitnu do hlavní branch na GitHubu. Proto u mých projektů často uvidíte Next.js, TypeScript, TailwindCSS a Deploymnet na Vercel.com.