Next.js Server Components Itu Gampang Error Kalau Kamu Lupa Cek 3 Hal Teknis Ini

Next.js Server Components Itu Gampang Error Kalau Kamu Lupa Cek 3 Hal Teknis Ini
Photo by Jason Leung/Unsplash

Halo, bro and sis developer! Gimana kabarnya? Pasti lagi seru-serunya eksplorasi Next.js App Router, kan? Nah, begitu Next.js rilis Server Components (SC), dunia web development terasa kayak naik roller coaster. Di satu sisi, performanya gila-gilaan, loading jadi super cepat, dan kita bisa akses database langsung tanpa API endpoint yang ribet. Tapi di sisi lain, kalau kita salah sedikit, error yang muncul itu kadang bikin frustrasi dan bikin kita pengen balik aja ke Pages Router yang lama.

Server Components memang keren banget, tapi konsepnya benar-benar memisahkan dunia server (Node.js) dan dunia client (Browser). Jarak antara dua dunia ini yang sering jadi sumber masalah, terutama buat yang baru pindah dari React murni atau Next.js versi lama.

Sebagai tim dari Javapixa Creative Studio, yang setiap hari ngulik dan ngoprek arsitektur Next.js terbaru untuk klien-klien yang butuh solusi enterprise maupun startup yang scalable, kami sudah sering banget ketemu dengan tiga jenis error teknis paling umum yang bikin Server Components mendadak crash atau nggak berfungsi sebagaimana mestinya.

Kalau kamu sering dapat pesan error misterius atau komponen kamu tiba-tiba nggak mau di-render setelah migrasi ke App Router, kemungkinan besar kamu lupa cek salah satu dari tiga hal fundamental ini. Yuk, kita bedah satu per satu, biar kamu nggak lagi buang-buang waktu cuma buat debugging hal sepele.

*

1. Pelanggaran Batas Lingkungan: ‘Use State’ di Tempat yang Salah (The Environment Boundary Error)

Ini adalah error paling klasik dan sering kali yang pertama developer baru temui. Next.js Server Components berjalan 100% di server, lho. Mereka di-render menjadi HTML dan dikirim ke browser tanpa payload JavaScript yang berlebihan. Konsekuensinya jelas: Server Components tidak bisa mengakses API atau hooks yang hanya ada di browser.

Rule of Thumb yang harus kamu tanamkan:

A. Jangan Pernah Menggunakan Browser-Specific API di Server Components

Server Components (yang secara default Next.js adalah Server Component, kecuali ada ‘use client’ di baris pertama) tidak mengenal lingkungan browser. Kalau kamu iseng mencoba mengakses hal-hal ini, crash sudah pasti terjadi:

window atau document: Ini adalah objek global di browser. Kamu akan langsung mendapatkan error ReferenceError: window is not defined karena saat komponen itu dieksekusi, ia sedang di lingkungan Node.js, bukan di browser* pengguna. localStorage atau sessionStorage: Sama seperti window, ini adalah fitur browser*. Reaksi Hooks yang Interaktif: useState, useEffect, useReducer, useContext, atau bahkan custom hooks yang di dalamnya memanggil hooks di atas. Semua itu adalah API yang butuh runtime JavaScript di sisi client*.

Gimana Solusinya? Komposisi (Composition) adalah Kunci!

Solusi Next.js bukanlah memaksakan Server Component untuk melakukan hal yang interaktif. Solusinya adalah membagi tugas.

Jika kamu punya komponen besar () yang merupakan Server Component, tapi di dalamnya ada tombol () yang butuh useState untuk menghitung jumlah item, kamu harus melakukan ini:

  1. Buat sebagai Client Component dengan menambahkan ‘use client’ di baris paling atas.
  2. Di dalam , silakan gunakan useState, event listeners, dan akses window jika perlu.
  3. Impor dan gunakan di dalam Server Component parent ().

Intinya, biarkan Server Component melakukan fetching data dan rendering statis, sementara Client Component fokus pada interaksi dan manajemen state. Mencampuradukkan kedua tugas ini tanpa membatasi dengan ‘use client’ adalah resep cepat menuju error yang bikin kepala pusing.

*

2. Bahaya Meneruskan Properti Non-Serializable (The Serialization Pitfall)

Server Components dan Client Components berkomunikasi melalui props. Namun, karena SC di-render di server dan hasil rendering-nya dikirim ke client (bersama dengan tree komponen), ada aturan sangat ketat tentang jenis data apa yang boleh kamu lemparkan dari Server Component ke Client Component.

Next.js Next.js menggunakan proses Serialization. Ini berarti data harus bisa diubah menjadi format yang bisa dikirim melalui jaringan (seperti JSON), dan kemudian dibaca ulang di sisi client.

Hal-hal yang Pasti Gagal (Non-Serializable):

Fungsi (Functions): Ini adalah error yang paling sering ditemui. Kamu punya Server Component, kamu fetch data, dan kamu coba kirim function handler (misalnya onClickHandler) sebagai prop ke Client Component anak. Next.js akan crash karena function* tidak bisa di-serialize.

javascript
    // Di Server Component
    const handleClick = () => console.log('Clicked!'); // GAGAL!
    return ;

Simbol (Symbol), Map, Set, atau Date Objects (Kadang Bermasalah): Objek yang kompleks atau tidak standar JSON sering kali gagal atau terdegradasi kualitasnya saat di-serialize. Khusus Date, ia mungkin ter-serialize menjadi string ISO-8601, tapi hati-hati jika kamu mengandalkan bahwa ia tetap berupa objek Date di sisi client*.

Mengapa Ini Penting?

Kesalahan ini sering terjadi karena developer terbiasa di Pages Router di mana semua komponen adalah Client Components secara default, sehingga meneruskan fungsi sebagai prop adalah hal yang sangat wajar.

Gimana Solusinya? Jaga Batasan Data Murni dan Komposisi Anak!

Ada dua cara utama untuk mengatasi masalah Serialization ini:

Solusi A: Pastikan Props Murni Data JSON

Jika kamu mengirim data dari SC ke CC, pastikan itu hanyalah primitive types (string, number, boolean) atau array dan object biasa yang berisi primitive types. Jika kamu perlu mengirim objek Date, ubah dulu menjadi string di sisi server sebelum dikirim, dan ubah kembali menjadi objek Date menggunakan new Date(string) di sisi client.

Solusi B: Fungsi Harus Dikelola oleh Client Component Itu Sendiri

Jika Client Component butuh fungsi interaktif (misalnya untuk menangani klik), fungsi itu harus didefinisikan di dalam Client Component itu sendiri, atau di Server Component yang merupakan parent dari Client Component (yang mana parent tersebut juga harus diubah menjadi Client Component).

Solusi C: Slotting dengan children atau Prop Komponen (Pahlawan Sesungguhnya)

Ini adalah teknik tingkat lanjut yang sangat efisien dan merupakan best practice di Next.js App Router.

Ingat, Server Component tidak bisa mengirim fungsi sebagai prop, tapi Server Component bisa mengirim Server Component lain sebagai children atau prop.

Contoh: Kamu punya Client Component yang butuh tombol yang diisi data dari server.

javascript
// Server Component Parent
import ClientLayout from './ClientLayout';
import ServerProfileWidget from './ServerProfileWidget';export default async function DashboardPage() {
  // ServerProfileWidget di-render di server
  // ClientLayout hanya mendapat data props yang sederhana
  return (
    }>
      Konten Utama (Juga Server Component)
    
  );
}

Dengan menggunakan children atau prop yang berisi elemen React (yang bisa berupa Server Component), kita menghindari masalah Serialization. Client Component hanya menerima elemen React yang sudah di-render (atau promise untuk di-render) dan tidak perlu tahu data atau logika internal dari elemen tersebut.

Di Javapixa Creative Studio, kami selalu mendorong klien kami untuk mengadopsi pola komposisi ini. Selain menghindari error Serialization, ini juga menjaga kode lebih bersih dan memastikan bahwa hanya JavaScript yang benar-benar dibutuhkan untuk interaksi saja yang masuk ke bundle client.

*

3. Kebocoran Dependensi Server ke Client Bundle (The Dependency Leakage)

Ini adalah error yang lebih halus, sering kali tidak langsung menyebabkan crash besar, tetapi mengakibatkan bundle JavaScript client kamu jadi bengkak dan waktu loading jadi lambat.

Next.js sangat cerdas dalam memisahkan kode Server dan Client. Jika kamu menandai sebuah komponen sebagai ‘use client’, Next.js seharusnya hanya memasukkan kode client ke dalam bundle browser.

Namun, masalah muncul ketika kamu secara tidak sengaja mengimpor dependensi yang hanya boleh berjalan di server ke dalam Client Component.

Skenario Khas Gagal: Import Berat di Client Component

Misalnya, kamu punya fungsi utilitas di Server Component yang mengakses sistem file atau menggunakan library database yang berat:

javascript
// libs/server-utils.js (Ini cuma boleh jalan di Server)
import fs from 'fs'; // Node.js API
import 'heavy-database-driver'; // Library yang sangat besar
// ... fungsi server-side lainnya

Kemudian, kamu membuat Client Component yang relatif kecil:

javascript
// components/ClientButton.jsx
'use client';
import { someHelperFunction } from '@/libs/server-utils'; // MASALAH BESAR!
import React, { useState } from 'react';

Ketika Next.js melihat import { someHelperFunction } from '@/libs/server-utils'; di dalam komponen yang ditandai sebagai 'use client', bundler akan berasumsi bahwa semua yang ada di server-utils.js (termasuk fs dan heavy-database-driver) perlu di-bundle dan dikirim ke browser.

Dampaknya?

  1. Error Runtime: Kamu mungkin mendapatkan error seperti fs is not defined di browser karena Node.js API di-bundle dan coba dijalankan di lingkungan browser.
  2. Bundle Bloat: Meskipun tidak crash, bundle client kamu akan berisi ribuan baris kode yang seharusnya hanya ada di server.

Gimana Solusinya? Jangan Pernah Import Server Logic ke Client Component!

Solusi utama di sini adalah memisahkan kode secara radikal dan menggunakan komposisi (lagi-lagi komposisi!).

A. Pisahkan Utilitas Secara Jelas

Buat dua folder utilitas yang sangat jelas: server-utils dan client-utils. Jangan pernah impor dari server-utils ke dalam file yang memiliki ‘use client’.

B. Gunakan Server Component sebagai Pembawa Data

Jika Client Component butuh data yang diproses oleh server logic (misalnya, data yang diolah dari fs atau database), jangan impor fungsi pengolahannya ke Client Component. Biarkan Server Component parent yang menangani pemanggilan fungsi server, memproses data menjadi pure JSON data, dan meneruskan data tersebut sebagai props yang serializable ke Client Component.

javascript
// Benar: Server Component memanggil Server Logic, lalu kirim data murni
export default async function ServerDataFetcher() {
  const data = await getHeavyDataFromDB(); // Fungsi ini ada di file server-only
  return ;
}

C. Lakukan Impor Parsial (Jika Benar-benar Perlu)

Jika di dalam file server-side ada beberapa fungsi yang sebenarnya client-friendly, pastikan kamu menggunakan export dan import bernama yang spesifik, atau lebih baik lagi, pindahkan fungsi yang client-friendly itu ke file terpisah yang tidak mengandung dependensi server-only.

*

Penutup: Fokus pada Arsitektur, Bukan Sekadar Kode

Memahami Next.js Server Components bukan cuma tentang tahu kapan pakai useState, tapi tentang memahami batas arsitektur. Next.js mendorong kita untuk berpikir tentang jaringan, lingkungan, dan payload secara default. Ini adalah lompatan besar dalam web development modern.

Jika tim kamu atau perusahaan kamu sedang berjuang dengan migrasi besar-besaran ke App Router, atau butuh arsitektur Next.js yang optimal, scalable, dan bebas dari error fundamental seperti yang kita bahas di atas, di situlah keahlian Javapixa Creative Studio berperan. Kami tidak hanya menulis kode; kami merancang sistem yang efisien, memastikan Server Components dan Client Components bekerja harmonis demi performa terbaik.

Ingat, Server Components itu kuat. Kalau kamu dapat error yang aneh, jangan panik. Cek lagi tiga poin ini:

  1. Apakah kamu pakai API browser di komponen tanpa ‘use client’? (Cek window, useState).
  2. Apakah kamu mengirim fungsi atau objek kompleks sebagai prop dari SC ke CC? (Cek Serialization).
  3. Apakah Client Component kamu tidak sengaja mengimpor library yang seharusnya hanya ada di server? (Cek Dependency Leakage).

Kuasai tiga hal ini, dan pengalaman kamu dengan Next.js App Router dijamin akan jauh lebih mulus dan performanya akan ngacir! Selamat ngoding!