Senarai Semak Produksi Praktikal untuk Next.js 16 App Router

Peralihan daripada Pages Router kepada App Router dalam Next.js moden bukan sekadar perubahan sintaks; ia adalah perubahan asas dalam cara kita membina aplikasi web. Di JRV Systems, kami telah melalui transisi ini untuk beberapa projek klien, daripada laman e-dagang sehinggalah ke papan pemuka dalaman. Ini adalah senarai semak produksi Next.js 16 praktikal kami, yang memberi tumpuan kepada keputusan penting dan perangkap biasa apabila melancarkan projek App Router di Vercel.

Keputusan Teras: Komponen Server lwn. Komponen Klien

Dengan App Router, setiap komponen secara lalai adalah React Server Component (RSC). Ini merupakan satu kelebihan prestasi yang besar: komponen dipaparkan (render) di server, dan hanya HTML yang terhasil dihantar ke pelayar. Ini bermakna kurang JavaScript yang perlu dimuat turun dan diproses oleh pengguna.

Kuncinya adalah untuk tahu bila perlu memilih untuk menggunakan Komponen Klien dengan menambah arahan 'use client' di bahagian atas fail.

Gunakan Komponen Klien apabila anda memerlukan:

• Interaktiviti dan State: Apa-apa sahaja yang menggunakan 'hooks' seperti useState(), useEffect(), atau useReducer().
• API Khusus Pelayar: Mengakses window, localStorage, atau objek khusus pelayar yang lain.
• Event Listeners: Fungsi seperti onClick, onChange, dan sebagainya.

Kesilapan biasa adalah menjadikan komponen susun atur (layout) yang besar sebagai komponen klien. Amalan terbaik adalah untuk memastikan Komponen Klien sekecil yang mungkin, meletakkannya di hujung rantaian komponen anda. Contohnya, pada halaman produk, struktur utama halaman, butiran produk, dan penerangan adalah Komponen Server. Hanya bahagian interaktif, seperti butang 'Tambah ke Troli' atau galeri imej dengan 'state', akan diasingkan sebagai Komponen Klien.

Memahami Lapisan Caching Baharu

Ini boleh dikatakan bahagian paling kritikal dalam mana-mana senarai semak produksi Next.js 16. App Router memperkenalkan lapisan caching yang berkuasa tetapi agresif. Tidak seperti Pages Router di mana anda memilih secara eksplisit antara getServerSideProps atau getStaticProps, App Router menyimpan cache permintaan fetch secara lalai.

Apabila anda menggunakan fetch dalam Komponen Server, Next.js secara automatik menyimpan hasil permintaan tersebut. Tingkah laku ini serupa dengan getStaticProps.

const data = await fetch('https://api.example.com/data');

Untuk mengawalnya, anda menggunakan opsyen dalam panggilan fetch:

• fetch(..., { cache: 'force-cache' }): Tetapan lalai. Menyimpan data dalam cache selama-lamanya. Sesuai untuk data yang tidak pernah berubah.
• fetch(..., { cache: 'no-store' }): Ini mematikan caching sepenuhnya, membuat permintaan pada setiap render. Ini bersamaan dengan getServerSideProps.
• fetch(..., { next: { revalidate: 3600 } }): Ini mengaktifkan Incremental Static Revalidation (ISR). Data disimpan dalam cache tetapi akan diambil semula paling banyak sekali setiap 3600 saat (1 jam) jika ada permintaan masuk.

Bagi sistem pengebilan dan papan pemuka yang kami bina, penetapan yang betul adalah amat penting. Kami sering menggunakan no-store untuk data kewangan masa nyata dan masa revalidate yang singkat untuk perkara seperti profil pengguna yang jarang berubah.

Melaksanakan Revalidation Atas Permintaan

Revalidation berasaskan masa (ISR) memang bagus, tetapi kadang-kadang anda perlu mengemas kini kandungan serta-merta. Di sinilah 'on-demand revalidation' memainkan peranan. Ia membolehkan anda membersihkan cache Next.js untuk data tertentu tanpa perlu 'deploy' semula sepenuhnya.

Ini biasanya dilakukan menggunakan 'tag'. Pertama, anda 'tag' permintaan fetch anda:

const res = await fetch('https://.../posts', { next: { tags: ['posts'] } });

Kemudian, anda boleh mencipta satu 'API route' ringkas (dikenali sebagai Route Handler dalam App Router) yang akan membatalkan 'tag' tersebut apabila dipanggil. Laluan ini biasanya dilindungi dan dicetuskan oleh 'webhook' daripada CMS Headless atau perkhidmatan backend yang lain.

// app/api/revalidate/route.js
import { NextRequest, NextResponse } from 'next/server'
import { revalidateTag } from 'next/cache'
 
export async function POST(request: NextRequest) {
  const tag = request.nextUrl.searchParams.get('tag')
  if (!tag) {
    return NextResponse.json({ error: 'Tag diperlukan' }, { status: 400 })
  }
  revalidateTag(tag)
  return NextResponse.json({ revalidated: true, now: Date.now() })
}

Apabila kandungan CMS anda dikemas kini, ia akan memanggil https://laman-anda.com/api/revalidate?tag=posts, dan siaran blog anda akan dikemas kini serta-merta untuk semua pengguna.

Empat Perangkap Produksi yang Lazim Dielakkan

Kami telah menyahpepijat beberapa aplikasi App Router, dan terdapat beberapa isu yang muncul secara konsisten. Berikut adalah empat perkara utama yang perlu diberi perhatian:

• Penggunaan Komponen Klien Berlebihan: Godaan untuk meletakkan 'use client' pada semua komponen untuk menyelesaikan isu interaktiviti adalah kuat. Ini menafikan tujuan RSC, membawa kepada saiz 'bundle' JavaScript yang lebih besar dan masa muat halaman yang lebih perlahan. Sentiasa tanya jika anda boleh mengasingkan bahagian interaktif ke dalam komponen yang lebih kecil dan khusus.
• Laluan Dinamik Secara Tidak Sengaja: Jika anda menggunakan fungsi seperti cookies(), headers(), atau searchParams dalam komponen halaman, halaman tersebut akan dipaparkan secara dinamik pada masa permintaan. Ini selalunya dikehendaki, tetapi boleh menjejaskan prestasi secara tidak dijangka jika anda menyangka halaman itu dijana secara statik. Log binaan Vercel akan memberitahu anda halaman mana yang statik (λ) berbanding dinamik (○).
• Salah Konfigurasi 'Environment Variables': Perbezaan antara 'environment variables' di sisi server dan sisi klien adalah lebih penting sekarang. Mana-mana pembolehubah yang anda perlukan dalam Komponen Klien mesti didahului dengan NEXT_PUBLIC_. Jika terlupa, pembolehubah tersebut akan menjadi undefined di pelayar, punca pepijat yang biasa untuk kunci API atau 'feature flags'.
• Caching API Pihak Ketiga yang Salah: Caching fetch lalai berfungsi dengan baik untuk API anda sendiri. Tetapi untuk API pihak ketiga (contohnya, mendapatkan kadar pertukaran mata wang semasa), caching yang agresif boleh menyajikan data yang sangat lapuk. Untuk panggilan ini, nyatakan secara eksplisit dengan { cache: 'no-store' } atau masa revalidation yang sangat singkat seperti { next: { revalidate: 60 } } untuk memastikan data sentiasa segar.