Mengimplementasikan Pembaruan Optimistis Secara Manual

Pembaruan optimistis manual dimulai dengan status komponen lokal yang diinisialisasi dari data server: const [items, setItems] = useState(serverItems). Status lokal inilah yang Anda tampilkan dan ubah secara optimistis. Anda NOT boleh mengubah langsung data yang diambil dari server — simpan salinan lokal yang Anda kendalikan.

Saat pengguna memicu mutasi (mengeklik "Tambah", "Suka", atau "Hapus"), lakukan pembaruan status segera sebelum memanggil API: setItems(prev => [...prev, newItem]). UI langsung mencerminkan perubahan tersebut. Hanya setelah pembaruan ini Anda menjalankan permintaan jaringan yang sebenarnya.

Sebelum melakukan pembaruan optimistis, simpan status saat ini: const previousItems = items. Cuplikan ini menjadi target pengembalian Anda. Jika panggilan API gagal, pulihkan nilai ini. Simpan dalam variabel, bukan status, karena Anda hanya membutuhkannya selama mutasi masih menunggu.

Setelah pembaruan optimistis, lakukan panggilan API secara asinkron. Bungkus dalam blok try/catch. Jika berhasil, Anda dapat mengambil ulang data secara opsional untuk menyelaraskannya dengan status server, atau mempercayai status optimistis jika server akan mengembalikan data yang sama. Jika gagal, gunakan status sebelumnya yang telah disimpan untuk melakukan pengembalian.

Di blok catch mutasi, jalankan: setItems(previousItems). Ini mengembalikan status ke keadaan sebelum pembaruan optimistis. Setelah pengembalian, tampilkan notifikasi kesalahan. Pengguna memahami bahwa kegagalan yang jarang terjadi bisa saja terjadi — yang tidak dapat mereka terima adalah ketidakkonsistenan yang tidak diberi tahu.

Setelah mengembalikan status, tampilkan pesan kesalahan: "Tidak dapat menyimpan perubahan. Silakan coba lagi." dengan tombol Coba Lagi yang menjalankan kembali mutasi yang sama. Dengan demikian, pengguna tetap memiliki kendali. Kombinasi pengembalian + notifikasi kesalahan + coba lagi menangani kegagalan dengan baik tanpa memblokir seluruh UI.

Saat menambahkan butir baru secara optimistis, server belum menetapkan ID nyata. Buat ID sementara untuk butir optimistis tersebut: const tempId = crypto.randomUUID(). Gunakan ID ini sebagai kunci butir dalam daftar. Setelah API berhasil merespons, ganti ID sementara dengan ID nyata yang ditetapkan server.

Setelah mutasi pembuatan berhasil, server merespons dengan ID nyata. Perbarui status untuk mengganti butir sementara: setItems(prev => prev.map(item => item.id === tempId ? { ...item, id: serverResponse.id } : item)). Penyelarasan ini memastikan operasi berikutnya menggunakan ID server yang benar.

Jika pengguna memicu dua mutasi secara berurutan dengan cepat, respons mungkin tiba tidak berurutan. Respons mutasi kedua mungkin tiba sebelum respons pertama, dan pengembalian mutasi pertama dapat menimpa status yang benar dari mutasi kedua. Ini adalah kondisi balapan yang khusus terjadi pada UI optimistis.

Salah satu solusi untuk kondisi balapan adalah membuat mutasi berurutan menggunakan antrean. Selama mutasi sedang berlangsung, nonaktifkan tombol pemicu dengan mengatur status isSubmitting menjadi aktif. Izinkan mutasi berikutnya hanya setelah mutasi sebelumnya selesai. Cara ini mengorbankan sebagian daya tanggap, tetapi menjamin urutan status yang benar.

Untuk operasi penghapusan: simpan elemen sebelumnya, keluarkan elemen yang dihapus dari status, panggil API penghapusan, lalu pulihkan status jika terjadi kegagalan. Penghapusan lebih sederhana daripada penambahan karena tidak memerlukan penyelarasan ID, tetapi prinsip yang sama tetap berlaku. Pertimbangkan untuk menambahkan jeda singkat sebelum penghapusan dengan menampilkan opsi "batalkan" sebelum melakukan panggilan API.

Mengapa elemen yang ditambahkan secara optimistis memerlukan ID sementara?

Pola manualnya: simpan previousItems, gunakan setItems untuk menetapkan status baru, lakukan panggilan API, lalu pulihkan status saat gagal dengan setItems(previousItems) dan tampilkan kesalahan. Untuk penambahan, gunakan crypto.randomUUID() sebagai ID sementara dan selaraskan dengan ID server setelah berhasil. Cegah kondisi balapan dengan menonaktifkan pemicu selama mutasi berlangsung. Pemulihan + notifikasi + coba lagi adalah pengalaman pengguna standar saat terjadi kegagalan.