MATERI 15 / 20
Async dan state: hasil terlambat juga perlu aturan
Permintaan jaringan tidak selalu selesai dalam urutan yang dikirim. Antarmuka perlu menjelaskan apa yang sedang terjadi dan menjaga hasil lama agar tidak menimpa keputusan terbaru.
Modelkan keadaan yang terlihat
Gunakan keadaan seperti idle, loading, success dan error. Data kosong yang berhasil dimuat berbeda dari belum ada respons. Tulis apa yang boleh dilakukan pengguna di setiap keadaan. Menonaktifkan tombol selama operasi bisa membantu pengalaman, tetapi backend tetap harus menangani request ulang secara benar.
Urutan respons bisa berubah
Pengguna mencari A lalu AB. Respons AB tiba lebih dulu, kemudian A datang terlambat. Jika semua respons langsung mengganti layar, hasil pencarian mundur. Tandai permintaan yang masih relevan dengan nomor urut atau identitas query, dan abaikan hasil yang sudah usang. Pembatalan request berguna tetapi bukan satu-satunya penjaga kebenaran.
Efek perlu memiliki umur
Jika komponen ditutup, request atau subscription yang dibuatnya mungkin masih aktif. Bersihkan sumber daya sesuai mekanisme framework. Saat error, simpan input yang masih berguna dan berikan cara mencoba kembali. Jangan memakai spinner tanpa batas; tentukan timeout atau cara menjelaskan bahwa hasil belum diketahui.
Pencarian #1: A → dikirim lebih dulu Pencarian #2: AB → menjadi permintaan aktif Respons #2 tiba → tampilkan AB Respons #1 tiba → abaikan karena sudah usang State kosong berhasil: success dengan items = []
Giliran kamu.
Gambar transisi state pencarian. Simulasikan dua respons dengan urutan terbalik dan satu request gagal. Tentukan hasil mana yang boleh mengubah layar.
- Loading dan kosong dibedakan
- Respons usang tidak menimpa hasil baru
- Ada cara pulih setelah gagal