Skip to main content

Optimistic update: nhanh nhưng phải rollback được

Optimistic update làm UI phản hồi trước khi server xác nhận. Inertia v3 hỗ trợ optimistic page-prop update và rollback khi request fail, nhưng không phải mutation nào cũng phù hợp.

Case tốt: Like

Điểm quan trọng là response server cuối cùng vẫn thay thế optimistic state. UI tạm đoán; server mới quyết định state thật.

Case tốt: Todo nhẹ

Không nên optimistic khi nào?

  • Thanh toán hoặc hoàn tiền.
  • Booking có contention cao.
  • Mutation phụ thuộc inventory/limit/quota.
  • Action có nhiều downstream side effect.
  • User cần biết chắc server đã commit trước khi tiếp tục.
Trong các case đó, loading state rõ ràng thường tốt hơn “giả thành công rồi rollback”.

Checklist trước khi bật optimistic

  1. Có thể tính optimistic state chỉ từ current props + input không?
  2. Nếu fail, rollback có đưa UI về trạng thái dễ hiểu không?
  3. Nếu server normalize dữ liệu khác dự đoán, response cuối có overwrite đúng không?
  4. Double-click/concurrent action có làm counter sai tạm thời không?
  5. Mutation có giá trị tài chính hoặc invariant nghiêm ngặt không? Nếu có, ưu tiên confirmed flow.

Pattern production: optimistic + aggregate reconciliation

Ví dụ toggle active Product làm thay đổi cả row và dashboard count:
Nếu chỉ patch row nhưng stats.active không reconcile, UI sẽ tự mâu thuẫn.

Không optimistic domain invariant khó dự đoán

Ví dụ inventory:
Frontend không đủ thông tin để biết mutation thành công. Hãy dùng pending UI thay vì giả success.

Double-click và idempotency

Optimistic UX không thay thế backend idempotency. Với action có thể double-submit:
Với payment/external side effect, backend vẫn cần idempotency key nếu domain yêu cầu.

Test optimistic flow

Test ít nhất ba state:

Tài liệu chính thức

Nội dung thực chiến trong bài được xây dựng dựa trên API và nguyên lý của Inertia.js v3 Documentation. Khi áp dụng vào dự án, hãy đối chiếu API cụ thể với tài liệu chính thức theo phiên bản bạn đang sử dụng.