Status Codes
Memetakan status HTTP yang umum ke UI state, recovery action, dan informasi debugging tanpa menampilkan detail server mentah ke user.
Tujuan belajar
- Membedakan success 2xx, client-side request issue 4xx, dan server issue 5xx
- Memetakan 200, 401, 403, 404, 422, 429, dan 500 ke respons frontend yang tepat
- Membedakan HTTP response error dari network failure tanpa status
- Menulis UI error yang memberi recovery action tanpa membocorkan detail internal
Isi lesson
6 blok- 1.Status code membantu UI memilih langkah berikutnyaBelum selesaiWajib
- 2.Memilih UI state dari status responseBelum selesaiWajib
- 3.Coding practiceBelum selesaiWajib
- 4.Cek pemahamanBelum selesaiWajib
- 5.fetch tidak otomatis melempar error untuk 404 atau 500Belum selesaiWajib
- 6.RingkasanBelum selesaiWajib
Status code membantu UI memilih langkah berikutnya
WajibStatus code adalah sinyal dari server tentang hasil request HTTP. 2xx biasanya menandakan request berhasil, 4xx menandakan request tidak dapat dipenuhi karena request, identity, permission, atau input, dan 5xx menandakan server gagal memproses request. Angka bukan copy yang langsung ditampilkan ke user. Frontend perlu mengubahnya menjadi state dan action yang sesuai context.
Contohnya, 401 dapat membawa user kembali ke sign-in flow, 403 berarti user sudah dikenali tetapi tidak memiliki izin, 404 dapat menjadi not-found page, 422 dapat menandai validation error field, 429 meminta retry yang lebih hati-hati, dan 500 membutuhkan error state serta observability. Network failure berbeda: browser mungkin tidak menerima HTTP response sama sekali, sehingga tidak ada status code untuk dipetakan.
Bagian ini memengaruhi progres lesson.
Memilih UI state dari status response
Wajibtype CourseListUiState = "ready" | "sign-in" | "not-found" | "retry-later" | "request-error";
function getCourseListUiState(status: number): CourseListUiState {
if (status >= 200 && status < 300) return "ready";
if (status === 401) return "sign-in";
if (status === 404) return "not-found";
if (status === 429) return "retry-later";
return "request-error";
}Contoh ini mengubah status transport menjadi state yang dapat dipakai UI. 422 sering dipetakan ke error field pada form, bukan list error umum. 403 membutuhkan copy access denied, bukan tombol sign-in. API nyata dapat memakai error code application-level tambahan; type dan mapper project perlu menyimpan detail yang berguna untuk recovery tanpa menyebarkan status check ke seluruh component.
Bagian ini memengaruhi progres lesson.
Coding practice
WajibDibuka di workspace khususMap course status to UI
Buat mapper kecil yang membedakan success, sign-in, not-found, retry-later, dan request error.
Tujuan awal: Fokus di tab TS.
Practice ini dibuka di workspace khusus. Buka practice untuk memakai editor, preview, dan cek otomatis.
Tombol selesai aktif setelah semua validasi wajib lolos.
Cek pemahaman
WajibJawab duluCek pemahaman singkat
Apa respons frontend paling tepat ketika request course detail mendapat 404?
Progres lesson naik setelah jawaban benar.
Peringatan
Wajibfetch tidak otomatis melempar error untuk 404 atau 500
Promise fetch dapat selesai ketika server mengirim 404 atau 500. Periksa response.ok atau status sebelum memperlakukan body sebagai success data. Sebaliknya, kegagalan jaringan, DNS, request dibatalkan, atau CORS browser dapat menghasilkan exception tanpa HTTP status. Beri user copy dan recovery yang dapat dilakukan, bukan raw server error.
Bagian ini memengaruhi progres lesson.
Ringkasan
Wajib- Status code memberi sinyal transport yang perlu diterjemahkan menjadi UI behavior.
- 401, 403, 404, 422, 429, dan 5xx tidak memiliki recovery yang sama.
- Network failure dapat terjadi tanpa status code.
- Jangan tampilkan raw server error atau menyamakan error dengan empty state.
- Berikutnya, kita membaca request dan response sebagai data contract yang dapat diberi type serta mapper.
Bagian ini memengaruhi progres lesson.
Langkah berikutnya
Selesaikan bagian penting lesson ini
Lanjutkan blok wajib berikutnya: Status code membantu UI memilih langkah berikutnya.