Dev Server & Hot Reload

Analogi: gladi resik vs pentas sungguhan

Bayangkan kamu ikut pentas drama. Sebelum hari-H, ada gladi resik: boleh salah dialog, sutradara langsung teriak memberi tahu di adegan berapa, dan kamu bisa mengulang adegan itu tanpa mengulang seluruh lakon dari awal. Itulah npm run dev.

Hari pentasnya adalah npm run build + npm start: penonton sudah duduk, tidak boleh salah, semuanya harus rapi dan cepat. Kamu tidak akan gladi di depan penonton, dan kamu tidak akan pentas saat latihan. Dua mode, dua tujuan, jangan tertukar.

Apa yang dilakukan npm run dev?

Development server melakukan tiga hal untukmu. Pertama, kompilasi on-demand: hanya halaman yang kamu buka yang dikompilasi, jadi start-nya cepat walau project-mu punya ratusan halaman. Kedua, Fast Refresh: setiap kali kamu menyimpan file, browser diperbarui otomatis. Ketiga, error overlay: error kompilasi atau runtime muncul sebagai lapisan merah di browser lengkap dengan nama file dan nomor baris.

Kombinasi ketiganya menciptakan feedback loop yang sangat pendek: ubah, simpan, lihat hasil dalam sekejap. Inilah alasan ngoding Next.js terasa "hidup".

Contoh 1: edit teks, browser ikut berubah

Buat halaman sederhana seperti ini:

// app/page.tsx (versi 1)
export default function Home() {
  return <h1>Warung buka jam 8</h1>;
}

Buka http://localhost:3000, lalu ubah teksnya dan simpan:

// app/page.tsx (versi 2, setelah edit dan save)
export default function Home() {
  return <h1>Warung buka jam 7 pagi!</h1>;
}

Tanpa menekan refresh, tanpa mengklik apa pun, browser menampilkan teks baru. Itulah Fast Refresh bekerja: Next.js mendeteksi file berubah, mengkompilasi ulang hanya modul itu, lalu menukar UI di browser. Kamu tidak pernah "menunggu build" untuk perubahan kecil.

Contoh 2: state tidak hilang saat edit (keajaiban Fast Refresh)

Fast Refresh bukan sekadar auto-reload. Bedakan dengan contoh komponen interaktif ini:

// app/kasir/page.tsx
"use client";

import { useState } from "react";

export default function Kasir() {
  const [jumlah, setJumlah] = useState(0);

  return (
    <main>
      <h1>Kopi terjual: {jumlah}</h1>
      <button onClick={() => setJumlah(jumlah + 1)}>+1 kopi</button>
      <p>Edit teks paragraf ini lalu save: angka di atas tidak kembali ke 0.</p>
    </main>
  );
}

Coba: klik tombol "+1 kopi" beberapa kali sampai angka menjadi 5, lalu edit teks paragrafnya dan simpan. Angka tetap 5. Kalau ini auto-reload biasa (F5), state akan reset ke 0 dan kamu kehilangan posisi kerjamu, misalnya isi form yang sudah diketik setengah. Fast Refresh mempertahankan state React selama perubahanmu tidak mengubah struktur hooks. Untuk iterasi UI, ini penghemat waktu yang luar biasa.

Catatan kecil: baris "use client" di atas diperlukan karena useState hanya jalan di browser. Artinya akan dikupas tuntas di modul Server Component vs Client Component, untuk sekarang cukup ikuti polanya.

Error overlay: sutradara yang cerewet tapi membantu

Buat kesalahan sengaja, misalnya typo nama variabel, dan simpan. Browser menampilkan overlay merah berisi pesan error, nama file, dan nomor baris yang bermasalah. Di banyak setup, mengklik lokasi error langsung membuka file itu di editor-mu pada baris yang tepat.

Sikap yang benar: jangan panik. Overlay merah bukan vonis project rusak, melainkan laporan kerja. Baca pesannya (biasanya sangat literal: "X is not defined" berarti memang X tidak didefinisikan), perbaiki, simpan, overlay hilang sendiri. Developer berpengalaman pun melihat overlay ini puluhan kali sehari, bedanya mereka tidak takut padanya.

Port: default 3000

Dev server default berjalan di port 3000 (http://localhost:3000). Kalau port itu sudah dipakai project lain, Next.js tidak error: ia bertanya apakah boleh memakai 3001. Kamu juga bisa memaksa port tertentu:

npx next dev -p 4000

Berguna saat kamu menjalankan dua project bersamaan, misalnya frontend dan contoh tutorial, agar tidak rebutan port.

Dev bukan untuk production

Ini aturan keras: dev server tidak dioptimasi (tidak ada minifikasi serius, ada tooling debug yang berat) dan tidak aman untuk dihadapkan ke internet publik. Alur yang benar selalu:

npm run build
npm start

build mengkompilasi dan mengoptimasi seluruh aplikasi (prosesnya lebih lama, wajar), start menjalankan hasil optimasi itu dalam mode production. Kalau kamu deploy ke Vercel, langkah ini ditangani otomatis. Kalau ke VPS sendiri, jangan pernah menjalankan npm run dev di sana.

Catatan teknis: Setiap mengubah next.config.js atau .env, restart dev server (Ctrl+C lalu npm run dev lagi). Variabel dan konfigurasi itu dibaca sekali saat server dinyalakan, tidak ikut Fast Refresh.

Kesalahan umum pemula

1. Menjalankan npm run dev di server production

SALAH: Karena "lebih gampang dan langsung jalan", menjalankan npm run dev di VPS production. Akibatnya website lambat (tidak teroptimasi), boros memori, dan mengekspos tooling debug ke publik.

BENAR: Selalu npm run build lalu npm start untuk production. Dev hanya untuk laptop-mu sendiri.

2. Panik melihat overlay merah

SALAH: Melihat overlay error pertama kali, mengira project rusak total, lalu menghapus node_modules dan install ulang (membuang 10 menit untuk masalah sebaris).

BENAR: Baca pesan error-nya: nama file + nomor baris sudah ditunjukkan. Perbaiki baris itu, simpan, lanjut. Overlay adalah teman, bukan musuh.

3. Refresh manual (F5) setiap habis edit

SALAH: Kebiasaan dari zaman PHP: setiap menyimpan file, refleks menekan F5. Akibatnya state hilang terus (form ke-reset, posisi scroll kembali ke atas) dan kamu menyalahkan framework.

BENAR: Cukup simpan file. Biarkan Fast Refresh bekerja dan state-mu tetap utuh. F5 hanya diperlukan kalau kamu memang ingin menguji dari kondisi segar.

4. Mengubah config lalu heran kenapa tidak berpengaruh

SALAH: Mengedit next.config.js, menyimpan, lalu bingung kenapa redirect baru tidak jalan. Mengulang edit berkali-kali dengan frustrasi.

BENAR: Config dibaca sekali saat server start. Restart dev server setiap habis mengubah config atau file .env. Ini salah satu dari sedikit hal yang tidak di-cover Fast Refresh.