Senarai Semak Produksi Next.js 16 Praktikal untuk App Router

Peralihan App Router: Kenapa Anda Perlu Senarai Semak Baru

Next.js 13 telah memperkenalkan App Router, satu anjakan paradigma yang signifikan berbanding Pages Router yang biasa kita gunakan. Kini setelah stabil dalam versi yang kita boleh panggil Next.js 16 (versi utama semasa), ia mengubah secara asas cara kita membina dan melancarkan aplikasi. Ia bukan lagi sekadar tentang routing berasaskan fail; ia kini tentang seni bina berpusatkan komponen yang mengutamakan rendering di server secara lalai.

Di JRV Systems, kami telah membantu beberapa perniagaan di Malaysia untuk memindahkan aplikasi mereka atau memulakan projek baharu dengan seni bina ini. Proses pembelajarannya memang ada, dan tabiat lama semasa proses pelancaran tidak selalunya boleh diguna pakai. Inilah senarai semak produksi Next.js 16 dalaman kami, yang telah diperhalusi daripada pengalaman melancarkan projek sebenar di Vercel.

Komponen Server vs. Client: Satu Peraturan Mudah

Konsep paling asas dalam App Router ialah perbezaan antara Komponen Server (RSC) dan Komponen Client. Peraturan utamanya mudah: mulakan dengan Komponen Server, dan hanya pilih Komponen Client apabila benar-benar perlu.

Komponen Server berjalan secara eksklusif di server. Ia boleh mengakses pangkalan data atau sistem fail secara terus, mengambil data, dan ia menghasilkan HTML sebelum dihantar ke pelayar. Paling penting, ia tidak menghantar sebarang JavaScript ke client, yang membawa kepada masa muat halaman awal yang lebih pantas.

Anda hanya perlu beralih kepada Komponen Client dengan menambah arahan 'use client' di bahagian atas fail apabila anda memerlukan fungsi khusus untuk pelayar.

Guna Komponen Client untuk:

• Fungsi event seperti onClick() atau onChange()
• State dan lifecycle hooks, seperti useState(), useEffect(), atau useReducer()
• API khusus pelayar seperti localStorage, window, atau Geolocation API
• Pustaka pihak ketiga yang bergantung kepada mana-mana di atas (contohnya, banyak pustaka carta atau animasi)

Kesilapan biasa adalah menjadikan seluruh halaman sebagai Komponen Client. Sebaliknya, pastikan Komponen Client anda sekecil dan sespesifik yang mungkin. Sebagai contoh, halaman produk boleh menjadi Komponen Server yang mengambil data produk, manakala butang 'Tambah ke Troli' yang interaktif di dalamnya adalah Komponen Client yang kecil dan terasing.

Menguasai Aturan Caching Baharu

Salah satu perubahan paling berkesan yang sering mengejutkan pembangun perisian ialah tingkah laku caching yang baharu. Dalam App Router, API fetch asal diperluaskan oleh Next.js untuk menyimpan cache permintaan secara automatik. Ini adalah ciri prestasi yang hebat tetapi boleh menyebabkan data lapuk jika anda tidak menyedarinya.

Secara lalai, fetch('https://api.example.com/data') akan di-cache selama-lamanya. Ini serupa dengan tingkah laku getStaticProps dalam Pages Router, menjadikan pengambilan data anda statik secara lalai.

Untuk mengawalnya, anda mempunyai beberapa pilihan:

• Dinamik, Tanpa Cache: fetch('...', { cache: 'no-store' }). Ini memastikan data diambil semula pada setiap permintaan, berfungsi seperti getServerSideProps.
• Revalidasi Berasaskan Masa (ISR): fetch('...', { next: { revalidate: 3600 } }). Ini memberitahu Next.js untuk menyimpan cache respons tetapi mengambilnya semula jika ada permintaan masuk selepas masa yang ditetapkan (dalam kes ini, 3600 saat atau 1 jam).

Memahami dan memilih strategi caching dengan sengaja untuk setiap pengambilan data adalah langkah kritikal dalam mana-mana senarai semak produksi Next.js 16. Untuk laman e-dagang yang kami bina, harga produk mungkin disahkan semula setiap jam, manakala kandungan catatan blog mungkin di-cache sehingga diberitahu secara eksplisit untuk dikemas kini.

Revalidasi Atas Permintaan (On-Demand) dengan Tags

Revalidasi berasaskan masa memang berguna, tetapi bagaimana jika anda perlu mengemas kini halaman sebaik sahaja kandungannya berubah dalam CMS headless anda? Di sinilah Incremental Static Regeneration (ISR) atas permintaan menggunakan tag menjadi penting.

Proses ini melibatkan dua langkah:

1. Tag pengambilan data anda: Apabila anda mengambil data yang mungkin perlu disahkan semula, anda menetapkan tag padanya. Contohnya, mengambil senarai artikel boleh kelihatan seperti ini: fetch('https://my-cms/api/articles', { next: { tags: ['articles'] } }).

2. Cetuskan revalidasi melalui API route: Anda mencipta satu API route yang selamat (cth., /api/revalidate) yang boleh dipanggil oleh CMS anda menggunakan webhook setiap kali artikel diterbitkan atau dikemas kini. Di dalam route ini, anda memanggil fungsi revalidateTag(): revalidateTag('articles').

Apabila API route ini dicapai, Vercel akan membersihkan cache untuk sebarang pengambilan data yang berkaitan dengan tag articles. Pengguna seterusnya yang melawat halaman yang menggunakan data tersebut akan mendapat versi yang baru dijana. Ini memberikan prestasi laman statik dengan kedinamikan laman yang dijana oleh server.

Empat Masalah Produksi Lazim yang Telah Kami Selesaikan

Sebagai sebahagian daripada kerja kami, kami sering menyemak atau menyahpepijat aplikasi Next.js untuk klien. Beberapa isu yang sama dengan App Router sering muncul. Menambah perkara ini ke dalam senarai semak anda boleh menjimatkan masa anda daripada kekecewaan.

1. Menggunakan Hooks Bahagian Client dalam Komponen Server: Kesilapan paling biasa ialah cuba menggunakan useState atau useEffect dalam komponen yang tidak mempunyai arahan 'use client'. Ingat, Komponen Server adalah untuk menjana UI, bukan untuk mengurus state interaktif. Mesej ralat dari Next.js agak jelas, tetapi ia mewakili halangan konseptual untuk pasukan yang baru dengan model ini.

2. Pendedahan Environment Variable yang Salah: Peraturan untuk environment variable tetap sama, tetapi ia sering menjadi punca kekeliruan. Sebarang pembolehubah yang diperlukan dalam pelayar (di dalam Komponen Client) mesti didahului dengan NEXT_PUBLIC_. Komponen Server boleh mengakses mana-mana environment variable bahagian server dengan selamat terus melalui process.env tanpa awalan tersebut.

3. Menjadikan Seluruh Halaman sebagai Komponen Client: Menambah 'use client' di bahagian atas fail page.tsx adalah satu anti-corak prestasi. Ia secara efektif menukar seluruh halaman anda dan semua anaknya menjadi aplikasi yang dijana di bahagian client, menafikan faedah utama RSC. Sentiasa letakkan arahan 'use client' ke komponen interaktif yang paling spesifik yang memerlukannya.

4. Ketidakcekapan Pengambilan Data: Dengan RSC, mana-mana komponen boleh mengambil datanya sendiri. Walaupun ini bagus untuk kebebasan komponen, ia boleh membawa kepada panggilan pangkalan data yang berlebihan (cth., beberapa komponen mengambil profil pengguna yang sama). Untuk mengatasinya, Next.js secara automatik menyahgandakan permintaan fetch yang serupa. Untuk sumber data selain fetch seperti klien pangkalan data, anda harus membungkus fungsi data anda dengan utiliti cache() dari React untuk mencapai penyahgandaan yang serupa dalam satu laluan render.