Proč mě zaujal NextJs

1/13/2025

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 Next.js mi nedal na vybranou. Má vlastní <Image /> komponentu která 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í 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 si vytvoříme skript generate-blur.mjs, který vygeneruje Base64 kód pro placeholder. Ten jsem pak použil v <Image /> komponentě takto:   
  
    placeholder="blur" blurDataURL={imageBlur || image}
  Výsledek se mi osobně zamlouvá více než spinner nebo skeleton, 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í změnou je, že App Router používá "use server" v komponentách 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.

Nejvíc mě zaujalo jak jednoduché je použití [slug] routování. Jako příklad uvedu tento projekt. Začal jsem ho bez velkého přemýšlení – prostě jsem jel podle intuice a neuvědomil si, že už je stránka větší a že bude potřeba použít něco pro routování, proto jsem předělal tento web, aby fungoval 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 pří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.