Matikan Fetch, Bukan Sekadar Sembunyikan UI

Saya membuka tab Network di browser, me-refresh halaman detail wisata di portal WisataKota, dan melihatnya lagi. Satu baris request merah menyala: GET ke endpoint reviews yang membalas 404 dengan status 404. Ini terjadi di setiap kali halaman dimuat, padahal fitur rating itu udah saya matiin dari dashboard admin.

Awalnya saya pikir ini bukan masalah besar. Logika saya waktu itu sederhana. Kalo fiturnya mati, komponen UI-nya nggak akan dirender. Saya cuma membungkus bagian review dengan kondisi if (!rating_enabled) return null. Secara visual, halaman terlihat bersih. Nggak ada bintang, nggak ada kotak komentar. Saya merasa tugas udah beres.

Ternyata saya salah. Fungsi getReviews di server component tetap dieksekusi sebelum kondisi render itu diperiksa. Akibatnya, aplikasi tetap melakukan satu wasted round-trip ke backend Go API. Lebih parah lagi, request ini sengaja dirancang untuk mengembalikan 404 sesuai kontrak slice sebelumnya, seperti yang udah saya dokumentasikan di artikel <a href="/id/blog/review-mati-tetap-404">review mati tetap 404</a> [2]. Jadi, saya bukan cuma membuang bandwidth, tapi juga membanjiri log server dengan error yang sebenarnya bukan error.

Kontrak Data Lebih Penting dari Tampilan

Masalahnya ada di cara saya memandang flag konfigurasi. Sebuah flag seperti rating_enabled bukan sekadar saklar lampu untuk tampilan. Itu adalah kontrak data. Kalau nilainya false, artinya data ulasan untuk entitas itu secara fundamental nggak ada. Memaksa sistem untuk tetap menjemput data yang secara desain nggak ada adalah pemborosan sumber daya yang konyol.

Prinsipnya sekarang jelas: matikan fetch bukan sembunyikan elemen visual. Kita harus mengamankan jaringan dulu, baru mengurus piksel.

Matikan Fetch di Akar

Langkah pertama yang saya ambil adalah menghentikan eksekusi fungsi fetch itu sendiri. Di dalam server component, saya menambahkan pengecekan awal.

// Rating dimatikan -> endpoint reviews 404 by design; skip fetch.
if (entity.rating_enabled !== false) {
  try {
    reviewsData = await getReviews(entity.id, { limit: 5 });
  } catch {
    // Reviews stay empty
  }
}

Perhatikan penggunaan === false. Ini adalah idiom default-on yang sengaja saya pilih. Data lama di database mungkin masih memiliki nilai undefined untuk kolom ini. Dengan memeriksa ketidaksamaan ketat terhadap false, baris data lama tetap akan merender ulasan secara normal, sementara data baru yang secara eksplisit dimatikan akan benar-benar dilewati.

Unmount, Bukan CSS Hide

Setelah jaringan diamankan, baru saya menangani lapisan presentasi. Saya mengganti logika penyembunyian lama menjadi conditional rendering yang membatalkan mounting komponen sama sekali [1].

{entity.rating_enabled !== false && (
  <section>{/* ulasan: ringkasan + form + daftar */}</section>
)}

Pendekatan ini memastikan React nggak pernah mengalokasikan memori atau menjalankan efek samping untuk bagian ulasan yang nggak relevan. Bonusnya, section yang di-unmount juga absen total dari accessibility tree, jadi screen reader nggak akan nemu sisa-sisa UI mati [3]. Saya juga menerapkan pola yang sama untuk fitur lain, seperti hanya menampilkan lencana sewa ketika rental_enabled === true, dan memperluas penjagaan kartu kontak dengan memvalidasi keberadaan baris contact_person.

Banyak developer cenderung memilih jalan pintas dengan menyembunyikan elemen di sisi klien karena terasa lebih cepat diimplementasikan. Tapi bagi saya, membiarkan request jaringan yang tahu akan gagal tetap berjalan adalah bentuk kelalaian teknis. Filosofi utamanya tetap sama: matikan fetch bukan sembunyikan. Mematikan request di sumbernya adalah satu-satunya cara yang masuk akal untuk menghormati kontrak data yang udah kita buat sendiri.

Sumber 1. React Documentation, "Conditional Rendering", react.dev/learn/conditional-rendering 2. Artikel internal, "review-mati-tetap-404", adityo.web.id/review-mati-tetap-404

Sources

• [1] React Docs: Conditional Rendering
• [2] Review Mati Tetap 404 (internal)
• [3] web.dev: Hiding and updating content