Troubleshooting dan Debugging untuk Web Developer: Dari HTML, CSS, JavaScript, sampai React

Ada fase yang pasti dialami semua developer: fitur sudah dibuat, tampilannya kelihatan benar, tapi tiba-tiba ada yang aneh. Tombol tidak jalan, layout melebar sendiri, data API tidak muncul, atau komponen React terus render ulang tanpa henti.

Di titik itu, skill yang menyelamatkan kita bukan cuma kemampuan menulis kode, tapi kemampuan membaca masalah.

Itulah kenapa troubleshooting dan debugging penting. Bukan sekadar mencari baris yang error, tapi memahami gejala, mempersempit penyebab, menguji hipotesis, lalu memperbaikinya dengan bukti.

Troubleshooting vs Debugging

Dua istilah ini sering dipakai bergantian, tapi fokusnya sedikit berbeda.

Sederhananya: troubleshooting itu proses investigasi besarnya, debugging itu proses bedah kode di dalamnya.

Developer yang baik biasanya tidak langsung menebak. Ia mengumpulkan bukti dulu: error message, langkah reproduksi, kondisi browser, request network, log server, perubahan terakhir, dan asumsi yang mungkin salah.

Cara Berpikir Saat Menemukan Bug

Sebelum buka Stack Overflow atau tanya AI, coba pakai alur ini dulu.

1. Reproduce

Bug yang tidak bisa diulang biasanya sulit diperbaiki.

Catat langkahnya:

1. Buka halaman login
2. Masukkan email valid
3. Masukkan password salah
4. Klik submit
5. Error muncul tanpa pesan yang jelas

Kalau bug hanya muncul di device tertentu, browser tertentu, atau akun tertentu, catat juga. Detail kecil seperti ini sering menjadi kunci.

2. Observe

Jangan langsung ubah kode. Lihat dulu:

• Apakah ada error di console?
• Apakah request network gagal?
• Apakah response API sesuai?
• Apakah DOM yang muncul sesuai ekspektasi?
• Apakah CSS yang aktif memang CSS yang kita pikir aktif?

Debugging yang buruk biasanya dimulai dari terlalu cepat memperbaiki tanpa memahami.

3. Make a Hypothesis

Buat dugaan yang bisa diuji.

Contoh:

Masalah: data user tidak tampil.
Hipotesis 1: API gagal.
Hipotesis 2: API berhasil, tapi mapping data salah.
Hipotesis 3: state React belum terisi saat render pertama.

Lalu uji satu per satu. Jangan ubah lima hal sekaligus, karena nanti kita tidak tahu perbaikan mana yang benar-benar menyelesaikan masalah.

4. Isolate

Pecah masalah menjadi bagian kecil.

Kalau halaman penuh komponen dan layout, coba isolasi:

• buat file kecil untuk reproduksi
• comment out bagian yang tidak relevan
• ganti data API dengan data dummy
• matikan animasi atau style sementara
• cek komponen satu per satu

Tujuannya bukan membuat kode final, tapi mempersempit area masalah.

5. Fix and Validate

Setelah penyebabnya ketemu, baru perbaiki. Setelah itu validasi:

• bug lama sudah hilang
• tidak ada regression
• case sejenis ikut aman
• kalau perlu, tambah test atau catatan

Debugging tidak selesai saat error hilang. Debugging selesai saat kita tahu kenapa error itu hilang.

Jenis Bug yang Sering Muncul

Bug tidak selalu bentuknya error merah di console. Kadang aplikasi tetap jalan, tapi perilakunya salah.

Syntax Error

Ini tipe paling mudah dideteksi. Biasanya ada typo, kurung kurang, import salah, atau struktur kode tidak valid.

const user = {
  name: "Romi",
  role: "Developer"
// lupa tutup object

Biasanya editor, TypeScript, formatter, atau build tool cepat menangkap bug seperti ini.

Runtime Error

Kode valid secara syntax, tapi gagal saat dijalankan.

const username = user.profile.name;

Kalau user.profile ternyata undefined, aplikasi bisa error. Di sinilah optional chaining, validasi data, dan pemahaman bentuk response API jadi penting.

Logical Error

Ini yang sering paling licin. Tidak ada error, tapi hasilnya salah.

const isAdult = age > 18;

Kalau aturan bisnisnya usia 18 sudah termasuk dewasa, harusnya age >= 18. Kode jalan, tapi logikanya meleset.

UI Bug

Misalnya layout overflow, tombol tertutup elemen lain, text tidak kebaca di dark mode, atau spacing rusak di mobile.

Bug seperti ini sering tidak ketahuan dari console. Kita harus inspeksi DOM, computed style, viewport, dan state responsive-nya.

Integration Bug

Frontend sudah benar, backend sudah benar, tapi kontrak antar keduanya tidak cocok.

Contoh:

{
  "full_name": "Romi Muharom"
}

Tapi frontend membaca:

user.fullName

Tidak ada error besar, tapi data tidak tampil.

Debugging HTML

HTML terlihat sederhana, tapi bug kecil di struktur markup bisa membuat layout dan aksesibilitas berantakan.

Bug umum:

• tag tidak tertutup
• nesting tidak valid
• atribut salah
• alt kosong untuk gambar penting
• heading tidak berurutan
• form tidak punya label

Tools yang bisa dipakai:

• browser Elements panel
• HTML validator
• Lighthouse accessibility audit
• inspect DOM langsung di browser

Debugging CSS

CSS jarang memberi error eksplisit. Ia lebih sering “diam-diam salah”.

Masalah umum:

• selector kalah specificity
• style tertimpa class lain
• overflow horizontal
• position: absolute keluar konteks
• flex/grid tidak sesuai ekspektasi
• responsive breakpoint bentrok
• warna tidak kontras di dark mode

Cara membedahnya:

1. Buka DevTools.
2. Inspect elemen yang bermasalah.
3. Lihat computed style.
4. Matikan/nyalakan property satu per satu.
5. Cek parent element, bukan hanya elemen target.

Contoh klasik: elemen child sudah width: 100%, tapi parent punya min-width besar sehingga tetap overflow. Kalau hanya melihat child, masalahnya tidak ketemu.

Debugging JavaScript

JavaScript memberi banyak alat bantu, tapi kita harus tahu kapan memakai yang mana.

console.log() Masih Berguna

Tidak ada yang salah dengan console.log(), asal dipakai untuk menjawab pertanyaan yang jelas.

console.log("payload before submit", payload);
console.log("api response", response);

Yang kurang berguna adalah log acak tanpa konteks:

console.log("test");
console.log(data);
console.log("masuk");

Log yang baik membantu membaca alur.

Breakpoint Lebih Kuat dari Log

Kalau masalahnya rumit, pakai breakpoint di DevTools.

Dengan breakpoint kita bisa:

• pause di baris tertentu
• lihat nilai variable saat itu juga
• step over / step into / step out
• membaca call stack
• memahami urutan eksekusi

Ini lebih bersih daripada menaruh puluhan console.log().

try-catch Bukan Solusi Semua Error

try-catch berguna untuk menangani error yang memang mungkin terjadi, misalnya request API gagal.

try {
  const response = await fetch("/api/profile");
  const data = await response.json();
  return data;
} catch (error) {
  console.error("Failed to fetch profile", error);
  return null;
}

Tapi jangan pakai try-catch untuk menyembunyikan bug. Kalau error terjadi karena logic salah, perbaiki logic-nya.

Debugging Network Request

Banyak bug frontend sebenarnya bukan bug UI, tapi bug komunikasi data.

Cek tab Network untuk melihat:

• request terkirim atau tidak
• method benar atau tidak
• status code
• request payload
• response body
• CORS error
• auth token
• redirect
• cache

Status code juga memberi petunjuk:

Untuk request, jangan hanya lihat “gagal”. Baca request dan response-nya. Kadang backend sudah menjelaskan error dengan jelas, tapi kita tidak membukanya.

Debugging React

React punya pola masalah sendiri karena UI sangat bergantung pada state, props, render cycle, dan side effect.

Cek Props dan State

Kalau UI tidak berubah, tanyakan:

• state benar-benar berubah?
• props yang diterima component sesuai?
• component yang dirender memang component yang kita edit?
• data sudah ada saat render pertama?
• ada conditional rendering yang menahan UI?

React DevTools sangat membantu untuk melihat struktur komponen, props, dan state tanpa menebak-nebak.

useEffect Sering Jadi Sumber Bug

useEffect berguna untuk side effect seperti fetch data, event listener, subscription, dan sinkronisasi dengan sistem luar. Tapi dependency array sering menjadi sumber masalah.

useEffect(() => {
  fetchUser(userId);
}, [userId]);

Kalau dependency kurang, data bisa stale. Kalau dependency terlalu banyak atau berubah setiap render, effect bisa jalan terus.

Masalah umum di useEffect:

• lupa dependency
• dependency berupa object/function yang selalu berubah
• tidak cleanup event listener
• fetch jalan berulang tanpa sadar
• state update setelah component unmount

Cleanup Itu Penting

Kalau effect memasang listener, timer, atau subscription, bersihkan saat component unmount.

useEffect(() => {
  const onResize = () => {
    console.log(window.innerWidth);
  };

  window.addEventListener("resize", onResize);

  return () => {
    window.removeEventListener("resize", onResize);
  };
}, []);

Tanpa cleanup, bug bisa muncul pelan-pelan: event dobel, memory leak, atau behavior yang terasa random.

Pakai Profiler Kalau Masalahnya Performance

Kalau masalahnya aplikasi terasa lambat, jangan langsung optimasi buta. Pakai React Profiler untuk melihat komponen mana yang render terlalu sering atau terlalu mahal.

Optimasi yang tidak diukur sering hanya membuat kode lebih rumit tanpa hasil yang jelas.

Checklist Debugging Praktis

Saat menemukan bug, pakai checklist ini:

1. Bisa direproduksi?
2. Error muncul di console?
3. Network request berhasil?
4. Data response sesuai bentuk yang dibutuhkan?
5. DOM hasil render sesuai?
6. CSS yang aktif sesuai?
7. State dan props benar?
8. Ada perubahan terakhir yang berhubungan?
9. Bisa diisolasi ke contoh kecil?
10. Setelah fix, sudah dites ulang?

Checklist ini sederhana, tapi membantu kita tidak panik dan tidak menebak terlalu jauh.

Kesimpulan

Debugging bukan kegiatan sampingan. Ia adalah bagian inti dari pekerjaan developer.

Semakin sering kita debugging dengan cara yang rapi, semakin cepat kita membaca pola masalah. Kita jadi tahu kapan harus melihat console, kapan harus membuka Network, kapan harus inspect CSS, kapan harus pakai breakpoint, dan kapan harus berhenti sebentar karena masalahnya bukan di kode, tapi di asumsi kita.

Kode yang bagus memang penting. Tapi developer yang kuat bukan hanya yang bisa menulis fitur, melainkan yang bisa tetap tenang saat fitur itu tidak berjalan sesuai rencana.