Senarai Semak Produksi Next.js 16 Praktikal Kami untuk Vercel

App Router dalam Next.js merupakan satu anjakan paradigma dalam cara kita membina aplikasi web. Ia membawa ciri-ciri hebat seperti Server Components dan caching terperinci, tetapi ia juga memperkenalkan kerumitan baharu. Di JRV Systems, kami telah memindahkan projek-projek baharu kami—daripada platform e-dagang sehinggalah ke papan pemuka dalaman untuk perniagaan di Malaysia—kepada App Router. Peralihan ini memerlukan kami membina satu set amalan terbaik yang baharu.

Artikel ini berkongsi senarai semak produksi Next.js 16 dalaman kami, yang telah ditambah baik selepas melancarkan pelbagai aplikasi di Vercel. Ia adalah panduan praktikal, bukan teoretikal, yang direka untuk membantu anda melancarkan projek dengan yakin.

Keputusan Teras: Server vs. Client Components

Keputusan yang paling kerap anda perlu buat ialah sama ada sesuatu komponen itu patut dijalankan di server atau di client. Paradigma baharu ini mengutamakan server, satu perubahan besar.

• Server Components (Lalai): Setiap komponen yang anda cipta dalam direktori app adalah Server Component secara lalai. Ia berjalan sepenuhnya di server, boleh menjadi async, dan sesuai untuk mendapatkan data, mengakses pangkalan data, atau mengendalikan kunci sensitif. Ia tidak boleh menggunakan 'hooks' seperti useState atau useEffect kerana ia tidak berjalan dalam pelayar web.

• Client Components (Pengecualian): Anda perlu memilih secara eksplisit untuk menjadikan sesuatu komponen sebagai Client Component dengan menambah arahan 'use client' di bahagian paling atas fail. Gunakannya hanya apabila perlu.

Panduan kami mudah: sesuatu komponen hanya patut menjadi Client Component jika ia memerlukan interaktiviti. Ini termasuk:

• Menggunakan useState, useEffect, atau useContext.
• Mengendalikan 'event' pelayar web seperti onClick atau onChange.
• Mengakses API khusus pelayar web seperti window atau localStorage.

Untuk memastikan saiz 'bundle' JavaScript di sisi klien kekal kecil, letakkan Client Components serendah mungkin dalam pepohon komponen. Daripada menjadikan keseluruhan halaman sebagai Client Component, asingkan bahagian interaktif (seperti butang atau borang) ke dalam komponennya sendiri dan import ia ke dalam Server Component induk.

Caching: Memahami Tetapan Lalai Baharu

Kelakuan caching dalam App Router adalah agresif dan sering menjadi punca kekeliruan. API fetch kini diintegrasikan secara mendalam dengan lapisan caching Next.js. Secara lalai, sebarang permintaan fetch akan di-cache secara automatik untuk tempoh yang tidak terhad.

Ini bagus untuk prestasi kandungan statik tetapi boleh menyebabkan data lapuk jika anda tidak berhati-hati. Berikut ialah cara untuk menguruskannya:

• Untuk data dinamik: Jika anda memerlukan data terkini pada setiap permintaan, seperti menyemak stok untuk laman e-dagang, gunakan opsyen cache: 'no-store'. fetch('https://api.example.com/data', { cache: 'no-store' })

• Untuk data yang divalidasi semula (ISR): Jika data boleh menjadi lapuk untuk tempoh yang singkat, gunakan opsyen next.revalidate. Ini menetapkan pembatalan cache berdasarkan masa dalam unit saat. Ia sesuai untuk entri blog atau halaman produk yang tidak berubah setiap saat. fetch('https://api.example.com/data', { next: { revalidate: 3600 } }) // Validasi semula setiap jam

Memahami perkara ini adalah bahagian kritikal dalam mana-mana senarai semak produksi Next.js 16. Sentiasa sahkan 'header' Cache-Control dalam aplikasi anda yang telah dilancarkan untuk memastikan strategi caching anda berfungsi seperti yang dirancang.

Revalidation Atas Permintaan untuk Kemas Kini Segera

Revalidation berdasarkan masa (ISR) amat berguna, tetapi kadangkala anda perlu mengemas kini kandungan serta-merta. Contohnya, apabila pentadbir klinik mengemas kini slot janji temu dalam SaaS yang kami bina, atau apabila pengurus e-dagang menukar harga produk. Di sinilah revalidation atas permintaan (on-demand revalidation) memainkan peranan.

Next.js menyediakan dua fungsi utama untuk ini, biasanya dicetuskan oleh 'webhook' atau 'server action':

1. revalidatePath('/path/to/page'): Ini akan membersihkan cache untuk satu laluan URL yang spesifik. Ia mudah dan terus.
2. revalidateTag('tag-name'): Ini lebih berkuasa. Anda boleh 'menanda' permintaan fetch tertentu dengan satu rentetan. Kemudian, dengan memanggil revalidateTag menggunakan rentetan yang sama, ia akan membatalkan cache untuk setiap permintaan fetch yang menggunakan tanda tersebut, di seluruh aplikasi anda. Ini sangat baik untuk mengemas kini semua halaman yang memaparkan data tertentu.

Kami di JRV Systems menggunakan revalidateTag secara meluas. Untuk klien e-dagang, kami menanda data produk dengan products. Apabila harga dikemas kini melalui panel admin mereka, satu 'webhook' akan memanggil 'endpoint' revalidation kami, yang mencetuskan revalidateTag('products'), memastikan semua senarai dan butiran produk memaparkan harga baharu serta-merta.

Masalah Lazim Produksi yang Telah Kami Selesaikan

Berikut adalah empat isu biasa yang kami temui semasa membantu klien beralih ke App Router. Menambah semakan ini ke dalam proses anda akan menjimatkan masa anda daripada proses penyahpepijatan.

• Terlupa 'use client': Pembangun cuba menggunakan useState dalam komponen, dan aplikasi gagal dengan ralat yang sukar difahami. Penyelesaiannya hampir selalu adalah dengan menambah arahan 'use client'. Ia perkara pertama yang kami semak.

• Mencampuradukkan Environment Variables: Ingat bahawa Server Components berjalan di server, tetapi Client Components dipaparkan di klien. Sebarang 'environment variable' yang diperlukan dalam Client Component mesti didahului dengan NEXT_PUBLIC_. Pembolehubah khusus server (seperti rentetan sambungan pangkalan data) tidak sepatutnya mempunyai awalan ini dan hanya boleh diakses dalam Server Components untuk mengelak daripada mendedahkannya kepada pelayar web.

• Penggunaan Client Components yang Berlebihan: Kesilapan biasa adalah menjadikan 'layout' atau halaman peringkat atasan sebagai Client Component. Ini memaksa semua komponen di bawahnya menjadi Client Component juga, yang akan meningkatkan saiz 'bundle' JavaScript sisi klien secara mendadak dan menafikan faedah prestasi Server Components.

• Salah Faham tentang Paparan Dinamik: Fungsi seperti cookies() atau headers() daripada next/headers atau penggunaan searchParams akan menyebabkan halaman dipaparkan secara dinamik pada masa permintaan. Ini selalunya yang dikehendaki, tetapi jika anda menjangkakan halaman itu statik dan ia tidak, biasanya ia disebabkan salah satu fungsi ini digunakan di mana-mana dalam pepohon komponen.

Semakan Terakhir Sebelum Pelancaran

Sebelum anda 'merge' ke main dan 'deploy', lalui senarai terakhir ini:

1. Semak Log Binaan: Cari sebarang amaran atau ralat. Output binaan Vercel sangat informatif.
2. Audit Saiz 'Bundle' Klien: Gunakan @next/bundle-analyzer untuk memeriksa saiz JavaScript sisi klien anda secara visual. Adakah terdapat sebarang 'library' besar yang dihantar ke pelayar web secara tidak dijangka?
3. Sahkan 'Header' Caching: Gunakan 'developer tools' pelayar web anda untuk memeriksa tab 'Network'. Semak 'header' Cache-Control dan X-Vercel-Cache untuk mengesahkan strategi caching anda diguna pakai dengan betul.
4. Uji 'Webhook' Revalidation: Jika anda menggunakan ISR atas permintaan, cetuskan 'webhook' anda dan sahkan bahawa kandungan dikemas kini di laman web seperti yang dijangkakan.

Mengikuti senarai semak produksi Next.js 16 yang berstruktur seperti ini telah membantu pasukan kami di JRV Systems menyampaikan aplikasi yang lebih stabil dan berprestasi tinggi. App Router mempunyai keluk pembelajaran, tetapi keupayaannya amat berbaloi untuk dipelajari.