WisarWisar
Dasturlash kitobi/13-QISM — NextJS45 daqiqa

13.4-bob: Rendering — SSR, SSG, ISR, CSR

13-QISM — Next.js · 4-mavzu

1. Kirish va motivatsiya

13.3-bobda Server va Client Components'ni — kod qaerda ishlashini — o'rgandik. Endi unga bog'liq, lekin alohida savolni ko'ramiz: sahifa qachon render bo'ladi? Ya'ni — HTML qaysi paytda yaratiladi? Bu — Next.js'ning eng kuchli, lekin eng ko'p chalkashtiriladigan qismlaridan biri: rendering strategiyalari. SPA'da 11.3-bob faqat bitta javob bor edi — har doim brauzer'da (foydalanuvchi sahifani ochganda). Next.js esa to'rt xil yo'l beradi, va to'g'ri tanlash sahifa tezligi va yangilanishi o'rtasidagi balansni belgilaydi.

To'rt strategiyani qisqa: CSR (Client-Side Rendering — brauzer'da, SPA kabi — interaktiv, lekin SEO/tezlik muammosi); SSR (Server-Side Rendering — har so'rovda server'da render — har doim eng yangi ma'lumot, lekin har so'rov server ishlaydi); SSG (Static Site Generation — build paytida HTML yaratiladi — eng tez, statik fayl, lekin o'zgarmaydigan kontent); ISR (Incremental Static Regeneration — SSG + davriy yangilash — statik tezlik + vaqti-vaqti yangilanish — ikkalasining eng yaxshisi). Eng muhim g'oya — har sahifaga mos strategiya: blog post statik (SSG — kam o'zgaradi, eng tez), e-commerce mahsulot ISR (statik tezlik + narx yangilanishi), foydalanuvchi feed'i SSR (har so'rovda yangi), dashboard CSR (interaktiv, login ortida). Va Next.js App Router'da bu strategiyalar aslida avtomatik (qaysini tanlash — siz fetch va sozlamalar orqali "ishora" qilasiz, Next.js qolganini qiladi).

Bu bob: to'rt strategiya (CSR/SSR/SSG/ISR — chuqur), Next.js qanday qaror qiladi (default statik vs dinamik), routeni dinamik qilish (cookies/headers/searchParams — dinamik funksiyalar), force-dynamic/force-static, revalidate (vaqt-asosli va on-demand yangilash), fetch kesh opsiyalari (no-store/force-cache/next.revalidate), generateStaticParams (dinamik SSG — 13.2 davomi), streaming va Suspense (qisman render), strategiyani tanlash (qaror), va PPR (Partial Prerendering — yangi). Har mavzu, har kod misolida maqsad + izoh + "nima qiladi" tartibida to'liq ochib beriladi.

O'xshatish: Rendering strategiyalari — bu non yopish usullari. SSG (statik) — bu oldindan yopilgan non (build paytida): mehmon kelganda non tayyor turibdi (eng tez), lekin u kecha yopilgan (o'zgarmaydigan — blog post). SSR (har so'rovda render) — bu buyurtmaga yopiladigan non: mehmon kelganda yangidan yopiladi (har doim issiq/yangi — feed), lekin u kutadi (yopish vaqti — server ishlaydi). ISR (SSG + revalidate) — bu kuniga bir marta yangilanadigan non: oldindan yopilgan (tez), lekin har bir necha soatda yangisining yopiladi (statik tezlik + yangilanish — e-commerce mahsulot). CSR (brauzer) — bu mehmon o'zi uyda yopadigan non: tarkibi (ingredient — JavaScript) beriladi, mehmon o'zi pishiradi (interaktiv, lekin kutadi va tashqi nazoratchi — Google — bo'sh oshxonani ko'radi). To'g'ri tanlov — non turiga bog'liq.

Nega muhim?

  • Tezlik vs yangilanish balansi — to'g'ri strategiya sahifani eng tez va to'g'ri ma'lumotli qiladi.
  • SEO va Core Web Vitals — statik/SSR sahifalar Google'da yaxshi (CSR zaif — 13.1: 2.1).
  • Har sahifaga mos — bir ilovada aralash (statik blog, dinamik feed) — Next.js'ning kuchi.
  • Avtomatik, lekin nazoratli — Next.js o'zi qaror qiladi, lekin siz fetch/sozlama bilan boshqarasiz.

2. Nazariya — chuqur tushuntirish

2.1. To'rt rendering strategiyasi (umumiy)

text
  4 STRATEGIYA — HTML QACHON va QAYERDA yaratiladi:

  ┌─────┬──────────────────────┬─────────────────────┬───────────────────────┐
  │     │ HTML qachon          │ Tezlik              │ Qachon ishlatish      │
  ├─────┼──────────────────────┼─────────────────────┼───────────────────────┤
  │ SSG │ BUILD paytida (1 marta)│ ENG TEZ (statik fayl)│ o'zgarmas (blog, docs)│
  │ ISR │ build + davriy yangilanish│ tez (statik) + yangi│ kam o'zgaradi (mahsulot)│
  │ SSR │ HAR so'rovda (server) │ tez (server render) │ dinamik (feed, profil)│
  │ CSR │ brauzer'da (mijoz)    │ sekinroq boshlanish  │ interaktiv (dashboard)│
  └─────┴──────────────────────┴─────────────────────┴───────────────────────┘

  TEZLIK TARTIBI (boshlang'ich yuk):
  SSG (eng tez — tayyor fayl) > ISR (statik) > SSR (server render) > CSR (brauzer)

  YANGILIK TARTIBI (ma'lumot yangiligi):
  SSR (har doim yangi) > ISR (davriy) > SSG (build paytidagi) ; CSR (brauzer'da yangi)

   SSG — tez, lekin o'zgarmas; SSR — yangi, lekin server yuki; ISR — ikkala balans
   Har sahifaga MOS strategiya (kontentga qarab — bir ilovada aralash)

To'rt rendering strategiyasi — Next.js'ning tezlik/yangilanish balansining asosi. To'rt strategiya HTML'ning qachon va qaerda yaratilishi bilan farq qiladi: (1) SSG (Static Site Generation) — HTML build paytida (bir marta — sayt deploy qilinganda) yaratiladi (statik fayl) — eng tez (server faqat tayyor faylni beradi), lekin o'zgarmaydigan kontent uchun (blog post, docs, marketing); (2) ISR (Incremental Static Regeneration) — SSG + davriy yangilash (statik fayl, lekin har N soniyada qayta generatsiya) — tez (statik) + yangi (vaqti-vaqti), kam o'zgaradigan kontent uchun (e-commerce mahsulot — narx kuniga bir marta yangilansa yetadi); (3) SSR (Server-Side Rendering) — HTML har so'rovda server'da render bo'ladi — har doim eng yangi ma'lumot (dinamik — feed, foydalanuvchi profili), lekin har so'rov server ishlaydi; (4) CSR (Client-Side Rendering) — HTML brauzer'da (mijoz) — SPA kabi (interaktiv, dashboard, login ortida — SEO kerak emas). Tezlik tartibi: SSG (eng tez) > ISR > SSR > CSR. Yangilik tartibi: SSR (har doim yangi) > ISR (davriy) > SSG (build paytidagi). Ikki nuqta: (1) SSG tez lekin o'zgarmas, SSR yangi lekin server yuki, ISR ikkala balans; (2) har sahifaga mos strategiya (kontentga qarab — bir ilovada blog SSG, feed SSR, dashboard CSR — aralash). Bu — Next.js'ning moslashuvchanligi.

2.2. CSR — Client-Side Rendering

text
  CSR — brauzer'da render (SPA kabi — 11.3; Client Component'da):

  "use client";
  import { useState, useEffect } from "react";
  export default function Dashboard() {
    const [data, setData] = useState(null);
    useEffect(() => { fetch("/api/data").then(r => r.json()).then(setData); }, []);  // brauzer'da
    return data ? <div>{data.value}</div> : <Spinner />;
  }

  YOKI Next.js'da — TanStack Query 12.4-bob Client Component'da (eng keng CSR):
  "use client";
  const { data } = useQuery({ queryKey: ["data"], queryFn: fetchData });

  QACHON CSR (server render foydasiz):
   Dashboard, admin (login ortida — SEO kerak emas — 11.15)
   Juda interaktiv (real-time, foydalanuvchiga xos — har mijoz har xil)
   Tez-tez o'zgaradigan client ma'lumot (jonli grafik, chat)

   CSR — brauzer'da (Client Component + useEffect/Query); interaktiv, SEO zaif
   Next.js'da CSR — Client Component (statik HTML "qobiq" + brauzer'da ma'lumot)

CSR — Client-Side Rendering — brauzer'da render (SPA kabi — 11.3). Next.js'da CSR — Client Component ("use client")da ma'lumotni brauzer'da olish: useEffect+fetch 11.5-bob yoki ko'pincha TanStack Query 12.4-bob bilan. Bu yerda server bo'sh "qobiq" (HTML strukturasi) beradi, ma'lumot esa brauzer'da olinadi (useQuery yoki useEffect). Qachon CSR (server render foyda bermaydi): (1) dashboard, admin (login ortida — qidiruvda topilishi kerak emas — SEO kerak emas — 11.15); (2) juda interaktiv (real-time, foydalanuvchiga xos — har mijoz har xil ma'lumot ko'radi — server'da oldindan render qilishning ma'nosi yo'q); (3) tez-tez o'zgaradigan client ma'lumot (jonli grafik, chat — har soniya yangilanadi). Ikki nuqta: (1) CSR — brauzer'da (Client Component + useEffect/Query); interaktiv, lekin SEO zaif (Google bo'sh qobiq ko'radi — 13.1: 2.1); (2) Next.js'da CSR — Client Component'ning tabiiy holati (statik HTML qobiq + brauzer'da ma'lumot). CSR — Next.js'da ham mavjud (Client Component orqali), lekin u SPA'ning modeli — server render foydasi bo'lmagan holatlar uchun (dashboard, real-time). Ko'p Next.js ilova CSR + SSR/SSG aralashmasini ishlatadi (interaktiv qism CSR, kontent SSR/SSG).

2.3. SSR — Server-Side Rendering (har so'rovda)

text
  SSR — HAR so'rovda server'da render (har doim eng yangi ma'lumot — dinamik):

  // app/feed/page.tsx — Server Component, HAR so'rovda render (dinamik)
  export default async function FeedPage() {
    //  no-store  kesh YO'Q  HAR so'rovda yangi (SSR):
    const res = await fetch("https://api.example.com/feed", { cache: "no-store" });
    const posts = await res.json();
    return <ul>{posts.map((p) => <li key={p.id}>{p.title}</li>)}</ul>;
  }

  SSR QACHON ISHLAYDI (Next.js avtomatik dinamik qiladi):
  - fetch cache: "no-store" (har so'rovda yangi)
  - cookies(), headers() (so'rovga xos — 2.5)
  - searchParams (URL query — so'rovga bog'liq)
   bulardan biri  sahifa DINAMIK (SSR — har so'rovda render)

  QACHON SSR:
   Har so'rovda yangi ma'lumot (feed, jonli narx, foydalanuvchi profili)
   So'rovga xos (cookie/header — autentifikatsiya, til)

   SSR — har so'rovda server render (eng yangi ma'lumot + SEO); lekin server yuki/sekinroq SSG'dan
   no-store yoki cookies/headers  sahifa dinamik (SSR avtomatik)

SSR — Server-Side Rendering — har so'rovda server'da render (dinamik). Next.js App Router'da SSR — sahifa har so'rovda server'da yangidan render bo'lishi (har doim eng yangi ma'lumot). Misol: app/feed/page.tsx — Server Component, fetch(..., { cache: "no-store" }) (no-store — keshlamaclik, har so'rovda yangi ma'lumot — bu sahifani SSR qiladi). SSR qachon ishlaydi (Next.js avtomatik sahifani dinamik qiladi): (1) fetchda cache: "no-store" (har so'rovda yangi); (2) cookies(), headers() ishlatish (so'rovga xos ma'lumot — 2.5); (3) searchParams ishlatish (URL query — so'rovga bog'liq). Bulardan biri ishlatilsa — sahifa dinamik bo'ladi (SSR — har so'rovda render). Qachon SSR: (1) har so'rovda yangi ma'lumot (feed, jonli narx, foydalanuvchi profili — real-time'ga yaqin); (2) so'rovga xos (cookie/header — autentifikatsiya, til, geolokatsiya). Ikki nuqta: (1) SSR — har so'rovda server render (eng yangi ma'lumot va SEO — Google ko'radi); lekin server yuki bor (har so'rov render — SSG'dan sekinroq, lekin CSR'dan tez va SEO'li); (2) no-store yoki cookies/headers/searchParams sahifa avtomatik dinamik bo'ladi (SSR). SSR — dinamik, foydalanuvchiga xos kontent uchun (statik bo'la olmaydigan).

2.4. SSG — Static Site Generation (build paytida)

text
  SSG — BUILD paytida HTML yaratiladi (eng tez — statik fayl — DEFAULT):

  // app/blog/page.tsx — Server Component, BUILD paytida render (statik — default)
  export default async function BlogPage() {
    //  default fetch — keshlanadi  build paytida bir marta (SSG):
    const res = await fetch("https://api.example.com/posts");   // default: keshlanadi
    const posts = await res.json();
    return <ul>{posts.map((p) => <li key={p.id}>{p.title}</li>)}</ul>;
  }

  SSG QANDAY (Next.js avtomatik statik qiladi):
  - fetch default (keshlanadi) + dinamik funksiya YO'Q (cookies/headers/no-store yo'q)
   sahifa STATIK (build paytida HTML — SSG)

  DINAMIK YO'L (generateStaticParams — 13.2: 2.8):
  // app/blog/[slug]/page.tsx — har slug uchun statik (build'da):
  export async function generateStaticParams() {
    const posts = await fetch(...).then(r => r.json());
    return posts.map((p) => ({ slug: p.slug }));   // /blog/post-1, /blog/post-2... statik
  }

   SSG — build paytida HTML (eng tez — CDN'dan statik fayl); o'zgarmas kontent
   Default (dinamik funksiya yo'q)  statik; dinamik yo'l  generateStaticParams

SSG — Static Site Generation — build paytida HTML yaratiladi (eng tez — App Router'da default). SSG — sahifa build paytida (sayt deploy qilinganda — bir marta) render bo'lishi va statik HTML fayl sifatida saqlanishi. Misol: app/blog/page.tsx — Server Component, fetch(...) (default — keshlanadi); agar dinamik funksiya (cookies/headers/no-store) bo'lmasa, sahifa statik bo'ladi (build paytida bir marta render, keyin har so'rovda tayyor fayl beriladi — eng tez, CDN'dan ham). SSG qanday (Next.js avtomatik statik qiladi): fetch default (keshlanadi) + dinamik funksiya yo'q sahifa statik (build paytida HTML — SSG). Dinamik yo'l uchun ([slug]) — generateStaticParams (13.2: 2.8 — build paytida qaysi slug'lar uchun statik sahifa generatsiya — /blog/post-1, /blog/post-2... — har biri tayyor fayl). Ikki nuqta: (1) SSG — build paytida HTML (eng tez — CDN'dan statik fayl, server render yo'q, ma'lumot olish yo'q — fayl tayyor); o'zgarmaydigan kontent uchun (blog, docs, marketing, terms); (2) default (dinamik funksiya yo'q) Next.js sahifani statik qiladi; dinamik yo'l ([slug]) generateStaticParams bilan statik. SSG — eng yaxshi performance (tezlik), lekin faqat kam o'zgaradigan kontent uchun (yangilansa qayta build kerak — yoki ISR — 2.5).

2.5. ISR — Incremental Static Regeneration

text
  ISR — SSG + DAVRIY YANGILASH (statik tezlik + vaqti-vaqti yangilanish):

  // app/products/[id]/page.tsx
  export default async function ProductPage({ params }) {
    const { id } = await params;
    //  next.revalidate: 3600  har 1 soatda statik HTML qayta generatsiya (ISR):
    const res = await fetch(`https://api.example.com/products/${id}`, {
      next: { revalidate: 3600 },   // 3600 soniya (1 soat) — keyin yangilanadi
    });
    const product = await res.json();
    return <h1>{product.name} — {product.price} so'm</h1>;
  }

  ISR QANDAY ISHLAYDI:
  1. Build paytida statik HTML (SSG kabi — tez)
  2. 1-foydalanuvchi (1 soatdan keyin)  eski statik ko'radi (darrov — tez)
  3. Next.js FONDA yangi HTML generatsiya (revalidate)
  4. Keyingi foydalanuvchi  yangi statik (1 soat davomida — tez, yangi)

  ON-DEMAND ISR (revalidatePath — masalan admin mahsulotni o'zgartirsa):
  import { revalidatePath } from "next/cache";
  revalidatePath("/products");   // darrov yangila (vaqt kutmacdan)

   ISR — statik tezlik (SSG) + davriy yangilanish (revalidate) — e-commerce uchun ideal
   revalidate: N (vaqt) yoki revalidatePath (on-demand — admin o'zgartirsa darrov)

ISR — Incremental Static Regeneration — SSG va SSR'ning eng yaxshi birikmasi (statik tezlik + davriy yangilanish). ISR — sahifa statik (SSG — tez), lekin vaqti-vaqti (yoki on-demand) qayta generatsiya qilinadi (eng yangi ma'lumot bilan). Misol: fetch(..., { next: { revalidate: 3600 } }) — revalidate: 3600 (3600 soniya = 1 soat) — sahifa statik, lekin har 1 soatda qayta generatsiya qilinadi. ISR qanday ishlaydi: (1) build paytida statik HTML (SSG — tez); (2) 1 soatdan keyin birinchi foydalanuvchi eski statikni ko'radi (darrov — tez, kutmaydi); (3) Next.js fonda yangi HTML generatsiya qiladi (revalidate); (4) keyingi foydalanuvchi yangi statikni ko'radi (va keyingi 1 soat davomida — tez va yangi). Bu — "stale-while-revalidate" (eski'ni tez ber, fonda yangila — 12.4: 2.4 g'oyasi, lekin sahifa darajasida). On-demand ISR — revalidatePath("/products") (next/cache'dan) — vaqt kutmacdan darrov yangilash (masalan admin mahsulotni o'zgartirsa — o'sha zahoti sahifa yangilanadi). Ikki nuqta: (1) ISR — statik tezlik (SSG) + davriy yangilanish (revalidate) — e-commerce mahsulot, yangiliklar kabi kam-o'zgaradigan lekin yangilanishi kerak kontent uchun ideal; (2) revalidate: N (vaqt-asosli) yoki revalidatePath/revalidateTag (on-demand — admin o'zgartirsa darrov). ISR — Next.js'ning eng kuchli xususiyatlaridan biri (statik tezlik + dinamik yangilik — ikkolasi).

2.6. Next.js qanday qaror qiladi (statik vs dinamik)

text
  NEXT.JS AVTOMATIK — sahifa STATIK yoki DINAMIK ekanini o'zi aniqlaydi:

  STATIK (SSG/ISR) — DEFAULT, agar:
   Dinamik funksiya YO'Q (cookies/headers/searchParams)
   fetch keshlanadi (default yoki force-cache)
   build paytida HTML (yoki ISR revalidate bilan)

  DINAMIK (SSR) — agar BIRORTAsi bo'lsa:
   cookies() / headers() ishlatilsa (so'rovga xos)
   searchParams ishlatilsa (URL query)
   fetch cache: "no-store"
   export const dynamic = "force-dynamic"
   har so'rovda server render

  ┌────────────────────────────────────────────────────────────┐
  │ Default: STATIK (tez) | Dinamik funksiya  DINAMIK (SSR)    │
  │ Next.js O'ZI aniqlaydi (siz fetch/funksiya bilan "ishora")  │
  └────────────────────────────────────────────────────────────┘

   Next.js avtomatik — default statik; dinamik funksiya (cookies/no-store)  dinamik
   Strategiyani TANLAMAYSIZ — fetch/funksiya orqali "ishora" qilasiz, Next.js qaror qiladi

Next.js qanday qaror qiladi — App Router'ning eng nozik, lekin muhim mexanizmi. Next.js sahifa statik (SSG/ISR) yoki dinamik (SSR) ekanini avtomatik aniqlaydi (siz aniq "SSR" yoki "SSG" deb yozmaysiz — Next.js sizning kodingga qarab qaror qiladi). Statik (default — agar): dinamik funksiya yo'q (cookies/headers/searchParams ishlatilmagan) va fetch keshlanadi (default yoki force-cache) build paytida HTML (yoki ISR revalidate bilan). Dinamik (SSR — agar birortasi bo'lsa): cookies()/headers() ishlatilsa (so'rovga xos ma'lumot), searchParams ishlatilsa (URL query), fetch cache: "no-store", yoki export const dynamic = "force-dynamic" har so'rovda server render. Ikki nuqta: (1) Next.js avtomatik — default statik (eng tez), agar dinamik funksiya (cookies/no-store) ishlatsangiz — dinamik (SSR); (2) siz strategiyani tanlamaysiz to'g'ridan — fetch opsiyalari va dinamik funksiyalar orqali "ishora" qilasiz, Next.js o'zi qaror qiladi (bu chalkash bo'lishi mumkin — shuning uchun build paytida Next.js har sahifa statik/dinamik ekanini ko'rsatadi — buni terminalda tekshirish mumkin). Bu — Next.js'ning "konvensiya orqali" falsafasi (siz kodni yozasiz, Next.js optimal strategiyani tanlaydi). Bu mexanizmni tushunish — sahifa nega statik/dinamik ekanini anglashning kaliti.

2.7. fetch kesh opsiyalari va revalidate

text
  fetch KESH OPSIYALARI (Next.js fetch'ni kengaytirgan — kesh boshqaruvi):

  // 1. DEFAULT (Next.js 15: keshlanMAYDI — har so'rovda; 14: keshlardi):
  fetch(url)                                  // Next 15: dinamik (SSR-kabi)

  // 2. STATIK (build paytida keshla — SSG):
  fetch(url, { cache: "force-cache" })        // doimiy kesh (statik)

  // 3. DINAMIK (har so'rovda yangi — SSR):
  fetch(url, { cache: "no-store" })           // kesh yo'q (har so'rovda)

  // 4. ISR (davriy yangilanish):
  fetch(url, { next: { revalidate: 60 } })    // har 60s qayta generatsiya (ISR)

  // 5. TAG (on-demand invalidation — 12.3 RTK tags kabi):
  fetch(url, { next: { tags: ["products"] } }) // keyin revalidateTag("products")

  SAHIFA DARAJACIDA (butun sahifa):
  export const revalidate = 3600;             // butun sahifa ISR (1 soat)
  export const dynamic = "force-dynamic";     // butun sahifa SSR
  export const dynamic = "force-static";      // butun sahifa SSG

   fetch opsiyasi — kesh/render strategiyasini belgilaydi (cache/revalidate/tags)
   Next.js 15: fetch default keshlamaydi (14'dan farq — aniqroq — 13.1: 2.10)

fetch kesh opsiyalari va revalidate — Next.js sahifa strategiyasini fetch orqali boshqarish. Next.js fetchni kengaytipgan (standart fetchga kesh opsiyalari qo'shgan). Opsiyalar: (1) default — Next.js 15'da keshlamaydi (har so'rovda — dinamik; Next.js 14'da keshlardi — bu chalkash edi, 15'da aniqroq — 13.1: 2.10); (2) cache: "force-cache" — doimiy kesh (statik — SSG); (3) cache: "no-store" — kesh yo'q (har so'rovda yangi — SSR); (4) next: { revalidate: 60 } — har 60 soniyada qayta generatsiya (ISR); (5) next: { tags: ["products"] } — kesh tegi (keyin revalidateTag("products") bilan on-demand yangilash — 12.3 RTK Query tags'iga o'xshaydi). Sahifa darajasida (butun sahifa uchun): export const revalidate = 3600 (butun sahifa ISR), export const dynamic = "force-dynamic" (butun sahifa SSR), export const dynamic = "force-static" (butun sahifa SSG). Ikki nuqta: (1) fetch opsiyasi sahifa strategiyasini belgilaydi (cache/revalidate/tags — har so'rov uchun moslashuvchan); (2) Next.js 15'da fetch default keshlamaydi (14'dan farq — aniqroq, kam "sehrli" kesh — 13.1: 2.10) — shuning uchun statik kerak bo'lganda force-cache yoki revalidate aniq yoziladi. Bu — Next.js'da kesh va render strategiyasini nazorat qilishning asosiy vositasi (har fetch o'z strategiyasiga ega bo'lishi mumkin — moslashuvchan).

2.8. Streaming va Suspense (qisman render)

text
  STREAMING — sahifani QISMAN, BO'LAKLAB yuborish (tez qism darrov, sekin qism keyinroq):

  MUAMMO: sahifada bir qism tez (statik), bir qism sekin (sekin API) — butunni kutacanmi?
  YECHIM: tez qismni darrov yubor, sekin qismni STREAM (Suspense bilan — 11.8):

  // app/dashboard/page.tsx
  import { Suspense } from "react";
  export default function Dashboard() {
    return (
      <div>
        <h1>Dashboard</h1>           {/* darrov (statik) */}
        <Suspense fallback={<Spinner />}>   {/*  sekin qism — alohida stream */}
          <SlowStats />              {/* sekin API — tayyor bo'lgach keladi */}
        </Suspense>
      </div>
    );
  }
  // async function SlowStats() { const data = await slowFetch(); return <Stats data={data}/> }

   Streaming — tez qism darrov ko'rinadi, sekin qism Suspense bilan keyinroq (UX)
   loading.tsx (13.2: 2.5) — butun sahifa streaming'i (Next.js avtomatik Suspense)

Streaming va Suspense — sahifani qisman, bo'laklab yuborish (UX optimizatsiyasi). Muammo: ko'p sahifada bir qism tez (statik sarlavha, navbar), bir qism sekin (sekin API'dan ma'lumot — masalan tahlil). Agar butun sahifani kutsak — foydalanuvchi sekin qism tayyor bo'lguncha butun sahifani (tez qismni ham) ko'rmaydi. Yechim — streaming: tez qismni darrov yuborish (foydalanuvchi ko'radi), sekin qismni stream qilish (Suspense bilan — 11.8 — tayyor bo'lgach keladi). Misol: <h1>Dashboard</h1> (darrov — statik), va <Suspense fallback={<Spinner />}><SlowStats /></Suspense> — SlowStats (sekin API) tayyor bo'lguncha Spinner ko'rinadi, keyin SlowStats "stream" bo'lib keladi (sahifani qayta yuklamacdan). Ya'ni foydalanuvchi sarlavha va navbarni darrov ko'radi (tez qism), tahlil esa keyinroq paydo bo'ladi (sekin qism — alohida). Ikki nuqta: (1) streaming — tez qism darrov ko'rinadi, sekin qism Suspense bilan keyinroq (foydalanuvchi kutmaydi — yaxshi UX); (2) loading.tsx (13.2: 2.5) — butun sahifa streaming'i (Next.js avtomatik Suspense bilan o'raydi — sahifa yuklanayotganda loading.tsx, tayyor bo'lgach kontent). Streaming — Next.js'ning React Server Components + Suspense birikmasining kuchli natijasi (sahifa bo'laklab keladi — eng tez idrok etilgan tezlik).

2.9. Strategiyani tanlash (qaror)

text
  RENDERING STRATEGIYASINI TANLASH (har sahifaga):

  ┌──────────────────────────┬──────────────┬──────────────────┐
  │ Kontent                  │ Strategiya   │ Qanday           │
  ├──────────────────────────┼──────────────┼──────────────────┤
  │ Blog post, docs, terms   │ SSG          │ default (statik) │
  │   (o'zgarmas)            │ (eng tez)    │                  │
  │ Mahsulot, yangilik       │ ISR          │ revalidate: N    │
  │   (kam o'zgaradi)        │ (statik+yangi)│                 │
  │ Feed, profil, jonli narx │ SSR          │ no-store/cookies │
  │   (har so'rovda yangi)   │ (dinamik)    │                  │
  │ Dashboard, admin         │ CSR          │ Client Component │
  │   (interaktiv, login-ortida)│ (brauzer) │ + Query 12.4-bob   │
  └──────────────────────────┴──────────────┴──────────────────┘

  TANLASH SAVOLLARI:
  1. Kontent o'zgaradimi? YO'Q  SSG; KAM  ISR; KO'P  SSR
  2. So'rovga xos? (cookie/user)  SSR (dinamik)
  3. Interaktiv, SEO kerak emas?  CSR (Client)

   O'zgarmas  SSG; kam  ISR; tez-tez  SSR; interaktiv/SEO'siz  CSR
   Bir ilovada ARALASH (blog SSG + feed SSR + dashboard CSR) — Next.js'ning kuchi

Strategiyani tanlash — har sahifaga to'g'ri rendering tanlash (qaror). Kontent turiga qarab: (1) blog post, docs, terms (o'zgarmas) SSG (eng tez — default statik); (2) mahsulot, yangilik (kam o'zgaradi) ISR (statik tezlik + davriy yangilanish — revalidate: N); (3) feed, profil, jonli narx (har so'rovda yangi) SSR (dinamik — no-store/cookies); (4) dashboard, admin (interaktiv, login-ortida — SEO kerak emas) CSR (Client Component + TanStack Query — 12.4). Tanlash savollari: (1) kontent o'zgaradimi? — yo'q SSG, kam ISR, ko'p SSR; (2) so'rovga xos? (cookie/user — masalan har foydalanuvchi har xil) SSR (dinamik); (3) interaktiv, SEO kerak emasmi? CSR (Client). Ikki nuqta: (1) o'zgarmas SSG, kam ISR, tez-tez SSR, interaktiv/SEO'siz CSR; (2) bir ilovada aralash strategiyalar (bosh sahifa — blog SSG, feed — SSR, dashboard — CSR — har sahifa o'z strategiyasi) — bu Next.js'ning kuchi (SPA — faqat CSR; an'anaviy server — faqat SSR; Next.js — har sahifaga mos). To'g'ri tanlov — eng yaxshi tezlik (statik tez) + to'g'ri ma'lumot (dinamik yangi) + SEO (server render). Bu — Next.js'ning tezlik/yangilanish balansining cho'qqisi.

2.10. PPR (Partial Prerendering — yangi) va best practices

text
  PPR (Partial Prerendering — Next.js 14+ yangi, eksperimental  barqarorlashyapti):
   BIR sahifada statik + dinamik ARALASH (eng yaxshi ikkala dunyo):
  - Statik "qobiq" (header, layout) — build paytida (tez, darrov)
  - Dinamik "teshik"lar (foydalanuvchi savati, narx) — so'rovda (Suspense bilan stream)

  // statik sahifa + dinamik bo'lak (Suspense):
  export default function Page() {
    return (
      <div>
        <Header />                          {/* STATIK (build — darrov) */}
        <Suspense fallback={<Skeleton />}>
          <UserCart />                      {/* DINAMIK (so'rovda — stream) */}
        </Suspense>
      </div>
    );
  }

  RENDERING BEST PRACTICES:
   Default statik (eng tez); dinamik faqat kerakli (cookies/no-store — 2.6)
   Kam-o'zgaradigan  ISR (revalidate — SSG'dan tez yangilanish — 2.5)
   Sekin qism  Suspense (streaming — tez qism darrov — 2.8)
   Build'da statik/dinamik tekshir (terminal — qaysi sahifa qanday)
   Interaktiv/SEO'siz  CSR (Client); kontent  SSG/ISR/SSR

   PPR — bir sahifada statik qobiq + dinamik teshik (kelajak — eng yaxshi balans)
   Default statik; dinamik kerakli joyda; sekin qism Suspense (best practices)

PPR va best practices — Next.js rendering'ning kelajagi va yakuniy maslahatlar. PPR (Partial Prerendering) — Next.js 14+ ning yangi (eksperimental, barqarorlashyapti) imkoniyati: bir sahifada statik + dinamik aralash (ikkala dunyoning eng yaxshisi). G'oya: sahifaning statik "qobiq" (header, layout, footer — o'zgarmas) build paytida render bo'ladi (darrov ko'rinadi), va faqat dinamik "teshik"lar (foydalanuvchi savati, jonli narx — Suspense bilan o'ralgan) so'rovda render bo'ladi (stream). Misol: <Header /> (statik — darrov) + <Suspense><UserCart /></Suspense> (dinamik — so'rovda). Natija: foydalanuvchi statik qismni darrov ko'radi (eng tez), dinamik qism keyinroq (stream) — SSG tezligi + SSR yangiligi bir sahifada. Rendering best practices: (1) default statik (eng tez), dinamik faqat kerakli (cookies/no-store — 2.6); (2) kam-o'zgaradigan ISR (revalidate — SSG'dan tez yangilanish — 2.5); (3) sekin qism Suspense (streaming — tez qism darrov — 2.8); (4) build'da statik/dinamik tekshir (terminal — Next.js har sahifa strategiyasini ko'rsatadi); (5) interaktiv/SEO'siz CSR (Client), kontent SSG/ISR/SSR. Ikki nuqta: (1) PPR — bir sahifada statik qobiq + dinamik teshik (kelajak — eng yaxshi balans, hozir eksperimental); (2) default statik, dinamik kerakli joyda, sekin qism Suspense. Bu — Next.js'ning rendering falsafasining yakuni: har qismga mos strategiya (statik tez, dinamik yangi, streaming silliq).

2.11. Hydration — server HTML'ni brauzerda "jonlantirish"

text
  HYDRATION — server yuborgan STATIK HTML'ni brauzerda INTERAKTIV qilish:

  1. Server  tayyor HTML yuboradi (foydalanuvchi darrov ko'radi — SSR/SSG/ISR)
  2. Brauzer  HTML'ni chizadi (ko'rinadi, lekin hali "o'lik" — tugma bosilmaydi)
  3. JS yuklanadi  React HTML'ga "ulanadi" (event listener'lar biriktiriladi)
  4. Endi sahifa INTERAKTIV (onClick, useState ishlaydi) — "hydrated"

   Hydration = server HTML + brauzer JS'ni bir-biriga MOSLASH (qayta chizmasdan)
   shuning uchun server va brauzer BIR XIL HTML chiqarishi SHART

  HYDRATION MISMATCH (xato — server va brauzer HTML har xil):
   Date/Math.random/typeof window — server va brauzerda har xil natija
   localStorage/window'ni to'g'ridan render paytida o'qish (server'da yo'q)
   "Hydration failed... server HTML didn't match client" ogohlantirishi

  YECHIM:
   Server-brauzer farqli qiymatni useEffect ichida (faqat brauzerda) o'qing
   suppressHydrationWarning (faqat muqarrar farq — masalan vaqt — uchun)
   dynamic(() => import(...), { ssr: false }) — komponentni faqat brauzerda render

   Mismatch sababi — render paytida brauzerga xos qiymat (window/Date/random)
   RSC'da Server Component hydrate BO'LMAYDI (JS yuborilmaydi) — faqat Client

Hydration — server yuborgan statik HTML'ni brauzerda interaktiv holatga keltirish jarayoni. SSR/SSG/ISR barchasida server tayyor HTML yuboradi — foydalanuvchi uni darrov ko'radi, lekin bu HTML dastlab "o'lik" (tugmalar bosilmaydi, useState hali ishlamaydi). Keyin brauzerda JavaScript yuklanadi va React shu tayyor HTML'ga ulanadi — DOM'ni qaytadan chizmasdan, mavjud elementlarga hodisa tinglovchilarini (event listener) biriktiradi va komponent holatini tiklaydi. Ana shu jarayon hydration deb ataladi, va shundan keyingina sahifa to'liq interaktiv bo'ladi ("hydrated"). Muhim shart: hydration ishlashi uchun server va brauzer aynan bir xil HTML chiqarishi kerak — React ikkalasini solishtiradi va mos kelishini kutadi. Hydration mismatch — server render qilgan HTML brauzerdagi birinchi render bilan mos kelmaganda yuz beradigan xato: bunda konsolda "Hydration failed... server rendered HTML didn't match the client" ogohlantirishi chiqadi va React o'sha qismni brauzerda qaytadan chizishga majbur bo'ladi (sekinlik). Odatiy sabablari: render paytida Date.now()/new Date() (server va brauzerda vaqt farqi), Math.random(), typeof window, yoki localStorage/windowni to'g'ridan render davomida o'qish (bular server'da mavjud emas). Yechimlar: (1) brauzerga xos qiymatni faqat useEffect ichida (u faqat brauzerda ishlaydi) o'qish; (2) muqarrar farq (masalan real vaqt) uchun tegishli elementga suppressHydrationWarning; (3) komponentni umuman server'da render qilmaslik — dynamic(() => import("./Chart"), { ssr: false }) 13.3-bob. Ikki nuqta: (1) mismatch sababi — render paytida brauzerga xos yoki har safar o'zgaradigan qiymat (window/Date/random); (2) RSC'da Server Component umuman hydrate bo'lmaydi (uning JS'i brauzerga yuborilmaydi — 13.3) — faqat Client Component'lar hydrate qilinadi, shuning uchun mismatch xatolari deyarli har doim Client Component'da bo'ladi.

2.12. Edge vs Node runtime (render qayerda ishlaydi)

text
  RENDER QAYSI MUHITDA ISHLAYDI — Node.js yoki Edge runtime:

  export const runtime = "nodejs";   // DEFAULT — to'liq Node.js
  export const runtime = "edge";     // Edge — yengil, foydalanuvchiga yaqin

  ┌──────────────┬─────────────────────────┬──────────────────────────┐
  │              │ Node.js (default)       │ Edge                     │
  ├──────────────┼─────────────────────────┼──────────────────────────┤
  │ Qayerda      │ markaziy server         │ CDN chekkasi (user'ga yaqin)│
  │ Sovuq start  │ sekinroq                │ juda tez (yengil)        │
  │ Kirish       │ to'liq Node API (fs,    │ cheklangan (Web API only,│
  │              │ Prisma, native paket)   │ fs yo'q, ba'zi paket yo'q)│
  │ TTFB         │ o'rtacha                │ past (geografik yaqin)   │
  │ Mos          │ og'ir ish, DB, to'liq   │ yengil SSR, geolokatsiya,│
  │              │ backend                 │ A/B, personalizatsiya    │
  └──────────────┴─────────────────────────┴──────────────────────────┘

   Node = to'liq imkoniyat (DB/Prisma/fs); Edge = tez + yaqin, lekin cheklangan
   Ko'p ilova default (Node) yetadi; Edge — global past-TTFB kerak bo'lganda

Edge vs Node runtime — render qaysi muhitda ishlashini belgilaydi (nafaqat qachon, balki qayerda). Har route yoki layout export const runtime bilan ikki muhitdan birini tanlashi mumkin: (1) "nodejs" (default) — render markaziy serverdagi to'liq Node.js muhitida ishlaydi, barcha Node API'lariga (fayl tizimi fs, Buffer, Prisma va boshqa native paketlar) kirish bor, lekin sovuq start (cold start) sekinroq va foydalanuvchi geografik jihatdan uzoq bo'lishi mumkin; (2) "edge" — render CDN chekkasida (foydalanuvchiga eng yaqin nuqtada) ishlaydigan yengil muhit (Edge runtime) — sovuq start juda tez va TTFB (birinchi baytgacha vaqt) past, chunki server foydalanuvchiga yaqin, ammo imkoniyatlar cheklangan (faqat Web standart API'lari — fs yo'q, ba'zi Node paketlari, jumladan ba'zi DB drayverlar ishlamaydi). Amaliy tanlov: og'ir ish, to'g'ridan DB so'rovlari (Prisma), murakkab backend mantiq uchun Node (default); yengil SSR, geolokatsiya asosidagi personalizatsiya, A/B test, oddiy so'rovlar uchun Edge (global auditoriya uchun past TTFB). Ikki nuqta: (1) Node — to'liq imkoniyat (DB/Prisma/fs), lekin markazlashgan; Edge — tez va foydalanuvchiga yaqin, lekin cheklangan API; (2) ko'p ilovaga default Node yetadi — Edge'ni faqat butun dunyo bo'ylab past kechikish (latency) muhim bo'lganda va route Edge cheklovlariga sig'sa tanlash mantiqli. Bu — rendering strategiyasi (qachon) bilan bir qatorda runtime (qayerda) — sahifa tezligining yana bir o'lchovi.

2.13. Pages Router bilan qisqa taqqoslash (eski usul)

text
  PAGES ROUTER (eski, pages/ — App Router'gacha) — funksiya orqali strategiya:

  getStaticProps         SSG  (build paytida) — App Router: default fetch keshi
  getStaticProps +
    revalidate: 60       ISR                  — App Router: next.revalidate / export revalidate
  getStaticPaths         dinamik SSG yo'llari — App Router: generateStaticParams
  getServerSideProps     SSR  (har so'rovda)  — App Router: no-store / cookies / force-dynamic
  (funksiya yo'q)        CSR  (klassik React) — App Router: "use client"

   Pages Router: strategiyani ALOHIDA funksiya EKSPORT qilib tanlagansiz (aniq)
   App Router: fetch opsiyasi / dinamik funksiya orqali AVTOMATIK 2.6-bob — moslashuvchan

Pages Router bilan qisqa taqqoslash — App Router'gacha (Next.js 12 va oldingi) pages/ papkasida rendering strategiyasi maxsus funksiya eksport qilish orqali tanlangan (App Router'dagi avtomatik mexanizmdan farqli — 2.6). Moslik jadvali: (1) getStaticProps — sahifani build paytida statik render (SSG) — App Router'da bu default fetch keshi bilan almashtirilgan; (2) getStaticProps + revalidate: 60 — ISR — App Router'da next: { revalidate } yoki export const revalidate; (3) getStaticPaths — dinamik yo'llar ([id]) uchun build paytida qaysi sahifalar statik generatsiya qilinishini belgilash — App Router'da generateStaticParams (13.2: 2.8) bu vazifani bajaradi; (4) getServerSideProps — har so'rovda server render (SSR) — App Router'da cache: "no-store", cookies()/headers() yoki export const dynamic = "force-dynamic"; (5) funksiya umuman bo'lmasa — klassik CSR (React brauzerda), App Router'da "use client". Ikki nuqta: (1) Pages Router'da strategiya aniq (qaysi funksiyani eksport qilishingizga qarab), App Router'da esa avtomatik — fetch opsiyasi va dinamik funksiyalar orqali ishora qilinadi 2.6-bob; (2) yangi loyihalar uchun App Router tavsiya etiladi, ammo eski kod bilan ishlaganda bu funksiyalarni tanish foydali (bir xil tushunchalar — SSG/ISR/SSR — ikki xil sintaksis bilan ifodalanadi). Rendering va kesh o'rtasidagi chuqur bog'liqlik (kesh qatlamlari, revalidateTag, kesh invalidatsiyasi) 13.7-bobda batafsil ochib beriladi.

3. Sintaksis — tez ma'lumotnoma

text
SSG 2.4-bob:         default (dinamik funksiya yo'q) | fetch force-cache | dynamic="force-static"
SSR 2.3-bob:         fetch no-store | cookies()/headers()/searchParams | dynamic="force-dynamic"
ISR 2.5-bob:         fetch { next: { revalidate: 60 } } | export const revalidate = 60
CSR 2.2-bob:         "use client" + useEffect/useQuery (brauzer'da)
FETCH KESH 2.7-bob:  cache:"no-store"(SSR) | "force-cache"(SSG) | next:{revalidate:N}(ISR)
ON-DEMAND 2.5-bob:   revalidatePath("/products") | revalidateTag("products")
DINAMIK YO'L 2.4-bob:generateStaticParams() — [slug] statik (SSG)
STREAMING 2.8-bob:   <Suspense fallback={...}><SlowComponent/></Suspense>
SAHIFA 2.7-bob:      export const revalidate=N | dynamic="force-dynamic"|"force-static"
HYDRATION 2.11-bob:  server HTML + brauzer JS moslashuvi | mismatch  useEffect/ssr:false
RUNTIME 2.12-bob:    export const runtime="nodejs"(default) | "edge"(tez, cheklangan)
PPR 2.10-bob:        statik qobiq + <Suspense>dinamik teshik</Suspense>
PAGES 2.13-bob:      getStaticPropsSSG | getServerSidePropsSSR | getStaticPathsparams

4. Batafsil kod namunalari

Har misol: Maqsad + izohli kod + "Bu kod nima qiladi".

Misol 1 — SSG blog (statik — eng tez — 2.4)

Maqsad: Blog sahifani statik (SSG) qilish — build paytida HTML generatsiya, eng tez yuklanish. Bu o'zgarmaydigan kontent uchun ideal.

tsx
// app/blog/page.tsx — Server Component (default statik — SSG)
export default async function BlogPage() {
  //  force-cache  build paytida bir marta keshlanadi (statik — SSG):
  const res = await fetch("https://api.example.com/posts", {
    cache: "force-cache",   // statik kesh (build paytida)
  });
  const posts = await res.json();

  return (
    <div>
      <h1>Blog</h1>
      <ul>{posts.map((p: { id: string; title: string }) => <li key={p.id}>{p.title}</li>)}</ul>
    </div>
  );
}

Bu kod nima qiladi: Bu — SSG (Static Site Generation) sahifa. fetch(..., { cache: "force-cache" }) — force-cache opsiyasi Next.js'ga "bu ma'lumotni build paytida kesh va statik HTML yarat" deydi (Next.js 15'da default fetch keshlamaydi, shuning uchun statik uchun force-cache aniq yoziladi — 2.7). Natijada: sayt deploy qilinganda (build), bu sahifa bir marta render bo'ladi va statik HTML fayl sifatida saqlanadi. Keyin har bir foydalanuvchi /blogni ochca, server tayyor faylni darrov beradi (ma'lumot olish yo'q, render yo'q — fayl tayyor — eng tez, hatto CDN'dan ham). Bu — blog, docs, terms kabi o'zgarmaydigan kontent uchun ideal (har so'rovda qayta render qilishning ma'nosi yo'q — bir marta build'da yetadi). Kamchilik: agar kontent o'zgarsa (yangi post), sahifa faqat keyingi build'da yangilanadi (yoki ISR — Misol 3 — bilan). Demak SSG — eng tez, lekin statik (o'zgarmas). Next.js bu sahifani build vaqtida statik deb belgilaydi (terminal'da ○ /blog — statik belgisi bilan ko'rsatiladi).

Misol 2 — SSR feed (har so'rovda yangi — 2.3)

Maqsad: Foydalanuvchi feed'ini SSR qilish — har so'rovda server'da yangi ma'lumot bilan render. Bu tez-tez o'zgaradigan, har doim eng yangi bo'lishi kerak kontent uchun.

tsx
// app/feed/page.tsx — Server Component (SSR — har so'rovda)
export default async function FeedPage() {
  //  no-store  kesh YO'Q  HAR so'rovda yangi ma'lumot (SSR):
  const res = await fetch("https://api.example.com/feed", {
    cache: "no-store",   // har so'rovda yangi (dinamik)
  });
  const posts = await res.json();

  return (
    <div>
      <h1>Yangiliklar lentasi</h1>
      {posts.map((p: { id: string; title: string; time: string }) => (
        <article key={p.id}>
          <h2>{p.title}</h2>
          <small>{p.time}</small>   {/* har so'rovda eng yangi */}
        </article>
      ))}
    </div>
  );
}

Bu kod nima qiladi: Bu — SSR (Server-Side Rendering) sahifa. fetch(..., { cache: "no-store" }) — no-store opsiyasi Next.js'ga "bu ma'lumotni keshlama, har so'rovda yangidan ol" deydi — bu sahifani dinamik (SSR) qiladi. Natijada: har bir foydalanuvchi /feedni ochganda, server o'sha zahoti API'dan eng yangi ma'lumotni oladi va HTML render qiladi (har so'rov — yangi render, yangi ma'lumot). Bu — yangiliklar lentasi, ijtimoiy tarmoq feed'i, jonli narx kabi tez-tez o'zgaradigan kontent uchun ideal (foydalanuvchi har doim eng yangi ma'lumotni ko'rishi kerak — statik bo'lsa eskirgan bo'lardi). SSG'dan (Misol 1) farqi: SSG bir marta build'da render (eski qoladi), SSR har so'rovda render (har doim yangi). Kamchiligi: har so'rov server ishlaydi (SSG'dan sekinroq — lekin CSR'dan tezroq va SEO'li — HTML server'da render bo'ladi, Google ko'radi). Next.js bu sahifani dinamik deb belgilaydi (terminal'da ƒ /feed — dinamik belgisi). Eslatma: cookies() yoki headers() ishlatsangiz ham sahifa avtomatik SSR bo'ladi 2.6-bob — masalan autentifikatsiyalgan feed.

Misol 3 — ISR mahsulot (statik + yangilanish — 2.5)

Maqsad: E-commerce mahsulot sahifani ISR qilish — statik tezlik, lekin har soatda narx yangilanishi. Bu kam-o'zgaradigan lekin yangilanishi kerak kontent uchun ideal balans.

tsx
// app/products/[id]/page.tsx — ISR (statik + davriy yangilanish)
export default async function ProductPage({ params }: { params: Promise<{ id: string }> }) {
  const { id } = await params;
  //  revalidate: 3600  statik, lekin har 1 soatda qayta generatsiya (ISR):
  const res = await fetch(`https://api.example.com/products/${id}`, {
    next: { revalidate: 3600 },   // 1 soat (3600 soniya)
  });
  const product = await res.json();

  return (
    <main>
      <h1>{product.name}</h1>
      <p className="price">{product.price} so'm</p>   {/* har 1 soatda yangilanadi */}
      <p>{product.description}</p>
    </main>
  );
}

// Statik yo'llar (build'da qaysi mahsulotlar — 13.2: 2.8):
export async function generateStaticParams() {
  const products = await fetch("https://api.example.com/products").then((r) => r.json());
  return products.map((p: { id: string }) => ({ id: p.id }));
}

Bu kod nima qiladi: Bu — ISR (Incremental Static Regeneration) sahifa — SSG va SSR'ning eng yaxshi birikmasi. fetch(..., { next: { revalidate: 3600 } }) — revalidate: 3600 (1 soat) Next.js'ga "bu sahifani statik qil (tez), lekin har 1 soatda qayta generatsiya qil (yangila)" deydi. Qanday ishlaydi: (1) build paytida statik HTML generatsiya (SSG kabi — tez); (2) 1 soat ichida har so'rov tayyor statik faylni darrov beradi (tez — server render yo'q); (3) 1 soatdan keyin birinchi so'rov — Next.js eski statikni darrov beradi (foydalanuvchi kutmaydi), va fonda yangi HTML generatsiya qiladi (eng yangi narx bilan); (4) keyingi foydalanuvchilar yangi statikni ko'radi (va yana 1 soat). generateStaticParams (13.2: 2.8) — build paytida qaysi mahsulotlar uchun statik sahifa generatsiya qilishni aytadi. Natija: statik tezlik (har so'rov tayyor fayl — SSG kabi) + davriy yangilik (narx har soatda yangilanadi — SSR kabi). Bu e-commerce uchun ideal: mahsulot ma'lumoti kam o'zgaradi (har so'rovda render — SSR — keraksiz, sekin), lekin narx/zaxira vaqti-vaqti yangilanishi kerak (SSG — to'liq statik — eskirgan bo'lardi). ISR — ikkala muammoni hal qiladi (tez + yangi). On-demand yangilash kerak bo'lsa (admin narx o'zgartirsa darrov) — revalidatePath("/products/" + id) 2.5-bob.

Misol 4 — On-demand revalidation (admin o'zgartirsa — 2.5)

Maqsad: Admin mahsulotni o'zgartirganda statik sahifani darrov yangilash (1 soat kutmacdan) — revalidatePath/revalidateTag bilan on-demand ISR. Bu admin o'zgarishlari darrov ko'rinishi kerak bo'lganda.

tsx
// app/api/products/route.ts — API endpoint (admin mahsulot o'zgartiradi — 13.6)
import { revalidatePath, revalidateTag } from "next/cache";

export async function POST(request: Request) {
  const data = await request.json();
  await db.product.update({ where: { id: data.id }, data });   // DB'da yangila

  //  Statik sahifani DARROV yangila (1 soat kutmacdan — on-demand ISR):
  revalidatePath(`/products/${data.id}`);   // shu mahsulot sahifasi qayta generatsiya
  revalidatePath("/products");              // ro'yxat ham
  // yoki teg bo'yicha: revalidateTag("products");

  return Response.json({ success: true });
}

Bu kod nima qiladi: Bu — on-demand ISR (vaqt kutmacdan darrov yangilash). Muammo: ISR (Misol 3) revalidate: 3600 bilan har 1 soatda yangilanadi — lekin agar admin mahsulotni o'zgartirsa (narx, zaxira), foydalanuvchilar 1 soatgacha eski ma'lumotni ko'radi (statik sahifa hali yangilanmagan). Yechim — revalidatePath (next/cache'dan): admin mahsulotni o'zgartirgan API endpoint 13.6-bob DB'ni yangilab, keyin revalidatePath(\/products/${id}`)ni chaqiradi — bu Next.js'ga "shu sahifani **darrov** qayta generatsiya qil" deydi (1 soat kutmacdan — o'sha zahoti). Natija: admin narxni o'zgartirsa, statik sahifa **darrov** yangilanadi (keyingi foydalanuvchi yangi narxni ko'radi — vaqt kutmacdan). revalidatePath — aniq yo'lni yangilaydi (/products/42), revalidateTag("products") — teg bo'yicha (barcha "products" tegli sahifalar — 2.7 — bir vaqtda). Demak ISR ikki usulda yangilanadi: **vaqt-asosli** (revalidate: N — avtomatik, har N soniyada — Misol 3) **va** **on-demand** (revalidatePath/revalidateTag` — qo'lda, o'zgarish bo'lganda darrov — bu misol). Bu birikma — statik tezlik + har doim to'g'ri ma'lumot (admin o'zgartirsa darrov, aks holda davriy). Bu — professional e-commerce/CMS naqshi (statik tezlik, lekin tahrir darrov ko'rinadi).

Misol 5 — CSR dashboard (Client + Query — 2.2)

Maqsad: Dashboard'ni CSR qilish — Client Component + TanStack Query bilan brauzer'da ma'lumot. Bu login ortida, interaktiv, SEO kerak emas sahifalar uchun.

tsx
// app/dashboard/page.tsx — bu CLIENT (CSR — brauzer'da ma'lumot)
"use client";
import { useQuery } from "@tanstack/react-query";   // 12.4

export default function DashboardPage() {
  //  Ma'lumot BRAUZER'da olinadi (CSR — server render emas):
  const { data, isPending } = useQuery({
    queryKey: ["dashboard"],
    queryFn: () => fetch("/api/dashboard").then((r) => r.json()),
  });

  if (isPending) return <Skeleton />;   // brauzer'da loading
  return (
    <div>
      <h1>Dashboard</h1>
      <p>Foydalanuvchilar: {data.users}</p>
      <RealtimeChart data={data.chart} />   {/* interaktiv, jonli */}
    </div>
  );
}

Bu kod nima qiladi: Bu — CSR (Client-Side Rendering) sahifa. "use client" — komponent Client (brauzer'da — 13.3), va ma'lumot brauzer'da olinadi (TanStack Query — useQuery — 12.4). Server faqat bo'sh "qobiq" (HTML strukturasi) beradi, keyin brauzer'da JavaScript ishlab, ma'lumot olib (useQuery), UI qo’shiladi (SPA modeli — 11.3). Nega CSR bu yerda mos: (1) dashboard login ortida (foydalanuvchi tizimga kirgan) — Google bu sahifani indekslamaydi (SEO kerak emas — 11.15); (2) interaktiv va jonli (RealtimeChart — real-time grafik, har soniya yangilanadi — server'da oldindan render qilishning ma'nosi yo'q); (3) foydalanuvchiga xos (har foydalanuvchi o'z ma'lumotini ko'radi — statik/SSG mumkin emas). SSR ham mumkin edi (server'da render), lekin dashboard interaktiv va SEO kerak emasligi uchun CSR yetadi (va TanStack Query'ning kesh/sync afzalliklarini beradi — 12.4). Demak Next.js'da CSR — Client Component'ning tabiiy holati (statik qobiq + brauzer'da ma'lumot), va u SEO kerak emas, interaktiv, foydalanuvchiga xos sahifalar uchun. Bu — Next.js'ning moslashuvchanligi: har sahifa o'z strategiyasini tanlaydi (blog SSG, feed SSR, dashboard CSR — bir ilovada).

Misol 6 — Dinamik funksiya SSR qiladi (cookies — 2.6)

Maqsad: cookies() ishlatish sahifani avtomatik SSR (dinamik) qilishini ko'rsatish — Next.js qanday qaror qilishini (statik vs dinamik) amaliy ko'rsatish.

tsx
// app/profile/page.tsx — cookies() ishlatilgani uchun AVTOMATIK SSR (dinamik)
import { cookies } from "next/headers";   // so'rov cookie'lari (so'rovga xos)

export default async function ProfilePage() {
  //  cookies() — so'rovga xos  sahifa AVTOMATIK dinamik (SSR — 2.6):
  const cookieStore = await cookies();     // Next.js 15: async
  const token = cookieStore.get("token")?.value;

  // Token bilan foydalanuvchi ma'lumotini ol (har so'rov — o'sha foydalanuvchi):
  const res = await fetch("https://api.example.com/me", {
    headers: { Authorization: `Bearer ${token}` },
  });
  const user = await res.json();

  return <h1>Salom, {user.name}!</h1>;
}

Bu kod nima qiladi: Bu — Next.js'ning statik/dinamik qarorini amaliy ko'rsatadi 2.6-bob. cookies() (next/headers'dan) — so'rov cookie'larini o'qiydi (Next.js 15'da async — await cookies()). Cookie — har so'rovga xos (har foydalanuvchining o'z cookie'si — token), shuning uchun Next.js bu sahifani avtomatik dinamik (SSR) qiladi — sahifa statik bo'la olmaydi (chunki har foydalanuvchi uchun har xil — cookie'ga bog'liq). Demak: cookies() ishlatilgan zahoti, Next.js "bu sahifa statik bo'la olmaydi — har so'rovda render kerak" deb biladi (hech qayerda aniq "SSR" deb yozilmadi — cookies() ishlatilishi avtomatik dinamik qildi — 2.6). Token bilan foydalanuvchi ma'lumotini olamiz (har so'rov — o'sha cookie'dagi foydalanuvchi). Bu — autentifikatsiyalgan sahifalarning standart naqshi: cookie (token) o'qib, foydalanuvchiga xos ma'lumot ko'rsatish — bu tabiiy ravishda dinamik (SSR). Xuddi shunday headers() (so'rov header'lari) va searchParams (URL query) ham sahifani avtomatik dinamik qiladi 2.6-bob. Eslatma: bu sahifani statik qilib bo'lmaydi (cookie'siz autentifikatsiya yo'q) — bu to'g'ri (foydalanuvchiga xos kontent dinamik bo'lishi kerak). Bu misol Next.js'ning "kod orqali ishora" falsafasini ko'rsatadi (siz cookies() yozasiz, Next.js dinamik deb qaror qiladi).

Misol 7 — Streaming (Suspense — sekin qism — 2.8)

Maqsad: Sahifani qisman, bo'laklab yuborish — tez qism (sarlavha) darrov, sekin qism (tahlil) Suspense bilan keyinroq. Bu UX'ni (idrok etilgan tezlik)ni keskin oshiradi.

tsx
// app/dashboard/page.tsx
import { Suspense } from "react";

// Sekin komponent (alohida — sekin API'dan):
async function SlowAnalytics() {
  const res = await fetch("https://api.example.com/analytics", { cache: "no-store" });
  const data = await res.json();   // bu SEKIN (2-3 soniya)
  return <div>Tahlil: {data.summary}</div>;
}

export default function DashboardPage() {
  return (
    <div>
      <h1>Dashboard</h1>           {/*  DARROV ko'rinadi (tez qism) */}
      <nav>Navbar</nav>            {/* darrov */}

      {/*  Sekin qism — Suspense bilan STREAM (butun sahifani bloklamaydi): */}
      <Suspense fallback={<div className="skeleton">Tahlil yuklanmoqda...</div>}>
        <SlowAnalytics />          {/* tayyor bo'lgach keladi (stream) */}
      </Suspense>
    </div>
  );
}

Bu kod nima qiladi: Bu — streaming (sahifani bo'laklab yuborish — 2.8). Muammo: SlowAnalytics komponenti sekin API'dan ma'lumot oladi (2-3 soniya). Agar butun sahifani shu sekin komponent uchun kutsak, foydalanuvchi 3 soniya davomida butun sahifani (sarlavha va navbarni ham — garchi ular tez bo'lsa ham) ko'rmaydi (oq ekran). Yechim — Suspense bilan streaming: <h1>Dashboard</h1> va <nav> (tez qism) darrov yuboriladi (foydalanuvchi o'sha zahoti ko'radi), va SlowAnalytics (sekin qism) <Suspense fallback={<Skeleton />}> bilan o'ralgan — uning o'rniga avval skeleton ko'rinadi, keyin (3 soniyadan keyin) SlowAnalytics stream bo'lib keladi (sahifani qayta yuklamacdan — faqat o'sha bo'lak yangilanadi). Ya'ni server sahifani bo'laklab yuboradi: avval tez qism (HTML — sarlavha, navbar, skeleton), keyin sekin qism (tahlil — tayyor bo'lgach). Natija: foydalanuvchi darrov sarlavhani ko'radi (idrok etilgan tezlik — sahifa "tez" tuyuladi), tahlil esa keyinroq paydo bo'ladi (kutish faqat o'sha bo'lak uchun — butun sahifa emas). Bu — React Server Components + Suspense'ning kuchli natijasi (11.8 Suspense'ning Next.js server kontekstidagi qo'llanishi). loading.tsx (13.2: 2.5) — butun sahifa streaming'i, bu misol — sahifa ichidagi aniq qism streaming'i. Streaming — Next.js'ning eng yaxshi UX optimizatsiyalaridan biri.

Misol 8 — Sahifa darajasida strategiya (export const — 2.7)

Maqsad: Butun sahifa strategiyasini bitta qator bilan belgilash — export const orqali (revalidate, dynamic). Bu sahifa darajasida aniq nazorat beradi.

tsx
// app/news/page.tsx

//  Butun sahifani ISR qiladi (har 60 soniyada yangilanadi):
export const revalidate = 60;   // sahifa darajacida ISR

// (yoki: export const dynamic = "force-dynamic";  — butun sahifa SSR)
// (yoki: export const dynamic = "force-static";   — butun sahifa SSG)

export default async function NewsPage() {
  // Bu sahifadagi barcha fetch shu revalidate'ga bo'ysunadi (60s):
  const res = await fetch("https://api.example.com/news");
  const news = await res.json();
  return <ul>{news.map((n: { id: string; title: string }) => <li key={n.id}>{n.title}</li>)}</ul>;
}

Bu kod nima qiladi: Bu — sahifa strategiyasini sahifa darajasida belgilash (har fetchda emas — butun sahifa uchun bir marta — 2.7). export const revalidate = 60 — bu Next.js'ga "butun bu sahifani ISR qil, har 60 soniyada yangila" deydi (sahifadagi barcha fetch shu qoidaga bo'ysunadi — har birida revalidate yozish kerak emas). Bu fetchda next: { revalidate: 60 } yozishning sahifa darajacidagi muqobili (qulayroq — bir joydan butun sahifani boshqarish). Boshqa variantlar: export const dynamic = "force-dynamic" (butun sahifani SSR qiladi — har so'rovda render, barcha kesh'ni o'chirib), export const dynamic = "force-static" (butun sahifani SSG qiladi — to'liq statik, dinamik funksiyalar taqiqlanadi). Bu export constlar — sahifa strategiyasini aniq belgilashnning usuli (Next.js'ning avtomatik qarorini — 2.6 — bekor qilib, aniq strategiya majburlash). Qachon kerak: agar Next.js avtomatik qarori noto'g'ri bo'lsa (masalan sahifa statik bo'lib qoldi, lekin siz dinamik xohlaysiz), yoki aniqlik kerak bo'lsa (kod o'qigan odam sahifa strategiyasini darrov ko'rsin). Demak strategiyani ikki joyda belgilash mumkin: fetch opsiyasida (har so'rov uchun — moslashuvchan) yoki export const (butun sahifa — aniq, qulay). Bu misol sahifa darajacidagi nazoratni ko'rsatadi.

Misol 9 — Aralash strategiya (bir ilovada — 2.9)

Maqsad: Bir ilovada turli sahifalar turli strategiya ishlatishini ko'rsatish — bu Next.js'ning eng katta kuchi (SPA — faqat CSR; Next.js — har sahifaga mos).

tsx
// app/page.tsx — bosh sahifa: SSG (statik — o'zgapmac marketing)
export default async function HomePage() {
  const content = await fetch("https://api.example.com/home", { cache: "force-cache" });
  return <div>{/* statik marketing kontent */}</div>;
}

// app/blog/[slug]/page.tsx — blog: SSG + generateStaticParams (statik)
export const revalidate = 86400;   // kuniga bir marta (ISR — blog yangilanca)

// app/feed/page.tsx — feed: SSR (har so'rovda yangi)
export const dynamic = "force-dynamic";

// app/dashboard/page.tsx — dashboard: CSR (Client — interaktiv)
"use client";
// useQuery bilan brauzer'da

Bu kod nima qiladi: Bu — Next.js'ning eng katta kuchini ko'rsatadi: bir ilovada aralash rendering strategiyalari (har sahifa o'z strategiyasini ishlatadi — 2.9). To'rt sahifa, to'rt strategiya: (1) bosh sahifa (app/page.tsx) — SSG (force-cache — statik marketing kontent, o'zgarmas, eng tez); (2) blog post (app/blog/[slug]/page.tsx) — ISR (revalidate: 86400 — kuniga bir marta yangilanadi — blog o'zgarsa kunlik ham yetadi); (3) feed (app/feed/page.tsx) — SSR (force-dynamic — har so'rovda yangi — yangiliklar har doim eng yangi); (4) dashboard (app/dashboard/page.tsx) — CSR ("use client" — interaktiv, login ortida — SEO kerak emas). Bu — SPA va an'anaviy server'ning cheklovlarini hal qiladi: SPA faqat CSR qila olardi (hammasi brauzer'da — SEO/tezlik muammosi); an'anaviy server faqat SSR (hammasi har so'rovda render — sekin statik kontent uchun); Next.js esa har sahifaga mos strategiya (statik tezlik kerak joyda SSG, yangilik kerak joyda SSR, interaktivlik kerak joyda CSR). Bu — bitta ilova, lekin har sahifa optimal (eng tez + to'g'ri ma'lumot + SEO). Bu moslashuvchanlik — Next.js'ning eng katta afzalligi va nega u ko'p loyihada tanlanishining sababi. Har sahifa yozishda "bu sahifa qaysi strategiyaga mos?" deb o'ylaysiz (2.9 qaror).

Misol 10 — Build natijasini o'qish (statik/dinamik tekshirish — 2.6)

Maqsad: npm run build natijasini o'qib, qaysi sahifa statik/dinamik ekanini tekshirish — Next.js qaror qilgan strategiyani tasdiqlash. Bu debugging va optimizatsiya uchun muhim.

text
# npm run build natijasi (terminal'da Next.js ko'rsatadi):

Route (app)                    Size     First Load JS
┌ ○ /                          1.2 kB   90 kB         ○ = STATIK (SSG)
├ ○ /blog                      0.8 kB   89 kB         statik
├ ● /blog/[slug]               1.1 kB   90 kB         ● = SSG + generateStaticParams
├ ƒ /feed                      0.9 kB   89 kB         ƒ = DINAMIK (SSR)
├ ƒ /profile                   1.0 kB   90 kB         dinamik (cookies — 2.6)
└ ○ /about                     0.5 kB   88 kB         statik

# Belgilar:
# ○ (Static)  — statik (SSG — build'da HTML)
# ● (SSG)     — statik + generateStaticParams (dinamik yo'l, statik)
# ƒ (Dynamic) — dinamik (SSR — har so'rovda render)

Bu kod nima qiladi: Bu — npm run build natijasini o'qish (Next.js qaror qilgan strategiyani tasdiqlash — debugging va optimizatsiya uchun muhim). Next.js'da rendering strategiya avtomatik (2.6 — Next.js o'zi statik/dinamik deb qaror qiladi), shuning uchun build natijasini o'qib, har sahifa qaysi strategiyada ekanini tekshirish muhim. Build'da Next.js har route oldida belgi ko'rsatadi: ○ (Static) — statik (SSG — build'da HTML, eng tez); ● (SSG) — statik + generateStaticParams (dinamik yo'l, lekin statik generatsiya — 13.2: 2.8); ƒ (Dynamic) — dinamik (SSR — har so'rovda render). Nega bu muhim: ba'zan siz sahifani statik bo'lishini kutasiz, lekin u dinamik bo'lib qoladi (masalan tasodifan cookies() yoki keshlanmagan fetch ishlatilgan bo'lsa — 2.6) — bu performance'ga ta'sir qiladi (statik tezroq). Build natijasini ko'rib, "bu sahifa nega dinamik?" deb tekshirasiz (ƒ belgisi — dinamik funksiya bormi?). Masalan agar /blog ƒ (dinamik) bo'lsa, lekin siz statik xohlasangiz — qaysi fetch keshlanmaganini yoki qaysi dinamik funksiya ishlatilganini topib tuzatasiz. Demak build natijasi — Next.js'ning qarorini ko'rish va tasdiqlash vositasi (statik/dinamik audit). Har deploy'dan oldin build natijasini tekshirib chiqish tavsiya etiladi — kutilmagan dinamik sahifalar (sekin) yo'qligiga ishonch hosil qilish uchun. Bu — Next.js rendering'ni nazorat qilishning amaliy usuli.

5. To'g'ri va noto'g'ri holatlar

1) O'zgarmas kontent

text
 blog/docs'ni SSR (har so'rovda render — keraksiz, sekin)
 SSG (statik — eng tez — 2.4)

2) Kam-o'zgaradigan

text
 mahsulotni to'liq SSG (narx eskirgan) yoki SSR (har so'rov — sekin)
 ISR (revalidate — statik tezlik + yangilanish — 2.5)

3) Foydalanuvchiga xos

text
 feed/profil SSG (har foydalanuvchi uchun bir xil — noto'g'ri)
 SSR (cookies/no-store — har so'rovda yangi — 2.3)

4) Kutilmagan dinamik

text
 statik xohlaysan, lekin cookies/no-store dinamik qildi (build tekshirmading)
 build natijani o'qi (○ vs ƒ — Misol 10)

5) Sekin qism

text
 butun sahifani sekin qism uchun kutish (oq ekran)
 Suspense (streaming — tez qism darrov — 2.8)

6) Admin o'zgarishi

text
 ISR revalidate kutish (admin o'zgartirsa 1 soat eski)
 revalidatePath (on-demand — darrov — 2.5, Misol 4)

6. Keng tarqalgan xatolar va yechimlari

Xato 1 — Sahifa statik bo'lishini kutdim, lekin dinamik

Sababi: dinamik funksiya (cookies/headers/searchParams) yoki keshlanmagan fetch 2.6-bob. Yechimi: build natijasini o'qing (Misol 10); dinamik funksiyani olib tashlang yoki fetch'ni keshlang.

Xato 2 — Ma'lumot eskirgan (statik sahifa)

Sababi: SSG (build'dagi ma'lumot) — yangilanmaydi 2.4-bob. Yechimi: ISR (revalidate — 2.5) yoki SSR (no-store — 2.3).

Xato 3 — Dynamic server usage xatosi (build paytida)

Sababi: statik sahifada dinamik funksiya (cookies) ishlatildi 2.6-bob. Yechimi: sahifani dinamik qil (force-dynamic), yoki dinamik funksiyani Client Component'ga.

Xato 4 — Next.js 15'da fetch keshlanmaydi (14'dan farq)

Sababi: Next.js 15 default keshlamaydi 2.7-bob. Yechimi: statik kerak bo'lsa cache: "force-cache" yoki revalidate.

Xato 5 — revalidatePath ishlamaydi

Sababi: noto'g'ri yo'l yoki Server Action/Route'da emas 2.5-bob. Yechimi: revalidatePath("/aniq-yo'l") Server Action/API'da (Misol 4).

Xato 6 — Streaming ishlamaydi (butun sahifa kutadi)

Sababi: Suspense yo'q, yoki sekin qism Suspense'siz 2.8-bob. Yechimi: sekin komponentni <Suspense> bilan o'ra (Misol 7).

Xato 7 — Build sekin (ko'p statik sahifa)

Sababi: generateStaticParams juda ko'p sahifa generatsiya qiladi 2.4-bob. Yechimi: eng muhimlarini statik, qolganini ISR/SSR (on-demand generatsiya).

7. Integratsiya — bu mavzu stack'ning qayerida uchraydi

  • Server Components 13.3-bob: rendering — Server Component'ning server'da qachon render bo'lishi.
  • Routing 13.2-bob: generateStaticParams — dinamik yo'l SSG.
  • Data fetching 13.5-bob: fetch kesh opsiyalari — strategiya belgilaydi.
  • Caching 13.7-bob: revalidate/tags — kesh boshqaruvi (chuqur).
  • Suspense 11.8-bob: streaming — Suspense'ning server versiyasi.
  • SEO 13.8-bob: SSR/SSG — Google indekslash (CSR zaif).
  • TanStack Query 12.4-bob: CSR — Client Component'da.
  • Deploy 13.11-bob: ISR/SSG — Vercel'da optimal.

8. Eng yaxshi amaliyotlar (best practices)

  • Default statik (eng tez; dinamik faqat kerakli — 2.6).
  • O'zgarmas SSG; kam ISR; tez-tez SSR; interaktiv CSR 2.9-bob.
  • ISR kam-o'zgaradiganga (revalidate — statik tezlik + yangilik — 2.5).
  • On-demand revalidatePath (admin o'zgarishi darrov — 2.5).
  • Sekin qism Suspense (streaming — 2.8).
  • Build natijani tekshir (statik/dinamik audit — Misol 10).
  • Next.js 15: force-cache statikga (default keshlamaydi — 2.7).
  • cookies/headers SSR qiladi (avtomatik dinamik — 2.6).
  • Aralash strategiya (har sahifaga mos — 2.9, Misol 9).
  • PPR ko'rib chiq (statik qobiq + dinamik teshik — kelajak — 2.10).

9. Amaliy loyiha: "Aralash Rendering Sayti"

To'rt strategiyani — SSG/ISR/SSR/CSR — bir saytda mustahkamlash.

Maqsad

Sayt qur, har sahifa mos strategiya bilan: marketing (SSG), blog (ISR), feed (SSR), dashboard (CSR).

Talablar (requirements)

  1. SSG: bosh/about (statik — force-cache — Misol 1).
  2. ISR: mahsulot/blog (revalidate + generateStaticParams — Misol 3).
  3. On-demand: admin o'zgartirsa revalidatePath (Misol 4).
  4. SSR: feed/profil (no-store yoki cookies — Misol 2, 6).
  5. CSR: dashboard (Client + Query — Misol 5).
  6. Streaming: sekin qism Suspense bilan (Misol 7).
  7. Sahifa daraja: export const revalidate/dynamic (Misol 8).
  8. Build audit: har sahifa statik/dinamik tekshir (Misol 10).
  9. fetch kesh: force-cache/no-store/revalidate to'g'ri 2.7-bob.
  10. Qaror: har sahifa NEGA shu strategiya (izohla — 2.9).

Maslahatlar (hint)

  • Default statik; dinamik funksiya dinamik qiladi (Xato 1).
  • ISR — revalidate (statik + yangilik — Misol 3).
  • Admin o'zgarish revalidatePath (Misol 4).
  • Sekin Suspense (Misol 7).
  • Build natijani o'qi (○ vs ƒ — Misol 10).
  • Next.js 15: force-cache statikga (Xato 4).

"Tayyor" mezonlari (acceptance criteria)

  • SSG (bosh/about — statik).
  • ISR (mahsulot — revalidate + generateStaticParams).
  • On-demand revalidatePath.
  • SSR (feed — no-store/cookies).
  • CSR (dashboard — Client).
  • Streaming (Suspense).
  • Build audit (statik/dinamik to'g'ri).
  • Har sahifa strategiya oqlangan.

Yechim kodi ataylab berilmagan — bu loyihani o'zingiz yozib ko'ring.

10. Xulosa va keyingi bobga ko'prik

Bu bobda Next.js rendering strategiyalarini chuqur o'rgandik:

  • To'rt strategiya (CSR/SSR/SSG/ISR — 2.1); CSR 2.2-bob; SSR 2.3-bob; SSG 2.4-bob; ISR 2.5-bob.
  • Next.js qaror (statik vs dinamik — 2.6); fetch kesh/revalidate 2.7-bob; streaming (Suspense — 2.8).
  • Strategiya tanlash 2.9-bob; PPR va best practices 2.10-bob.
  • Hydration (server HTML'ni jonlantirish, mismatch xatosi — 2.11); Edge vs Node runtime (render qayerda — 2.12); Pages Router taqqoslash (getStaticProps/getServerSideProps — 2.13).

Endi siz Next.js sahifani qachon va qanday render qilishni — SSG (tez statik), ISR (statik + yangilik), SSR (dinamik), CSR (interaktiv) — bilasiz, va har sahifaga mos strategiyani tanlay olasiz. Bu — tezlik va yangilanish balansining kalitidir.

Keyingi bob — 13.5-bob: Data fetching va Server Actions. Rendering strategiyalarini bildik; endi ma'lumotni qanday olish va o'zgartirishni chuqur ko'ramiz. Server Component'da ma'lumot olish (fetch/DB — to'g'ridan), Server Actions (forma va mutation server'da — "use server" — API route'siz!), forma bilan Server Actions (progressive enhancement), revalidation (mutation'dan keyin), va xato/loading boshqaruvi. Server Actions — Next.js'ning eng yangi, eng kuchli imkoniyatlaridan biri (backend'siz mutation).

Foydalanilgan rasmiy/ishonchli manbalar

  • Next.js rasmiy hujjati (nextjs.org/docs) — "Rendering", "Static and Dynamic Rendering", "Caching", "Incremental Static Regeneration"
  • nextjs.org — fetch options (cache, revalidate, tags), generateStaticParams, revalidatePath/revalidateTag, Streaming
  • Next.js 15 — caching defaults, Partial Prerendering (PPR); React docs — Suspense for streaming, hydration va hydrateRoot
  • Next.js — Route Segment Config (dynamic, revalidate, fetchCache, runtime), Edge va Node.js runtime
  • Next.js — Pages Router: getStaticProps, getStaticPaths, getServerSideProps (App Router bilan taqqoslash uchun)
  • web.dev — Rendering on the Web (CSR/SSR/SSG/ISR), Core Web Vitals (TTFB/LCP — rendering ta'siri)

Izohlar (0)

Izoh yozish uchun kiring.

  • Hozircha izoh yo'q. Birinchi bo'ling!
13.4-bob: Rendering — SSR, SSG, ISR, CSR — Wisar