Trong nhiều ứng dụng, cảm giác “nhanh” không chỉ đến từ backend mạnh hay database tối ưu. Đôi khi người dùng thấy ứng dụng mượt hơn vì giao diện phản hồi ngay lập tức, trước cả khi server xử lý xong. Cách làm này thường được gọi là optimistic UI. Ví dụ quen thuộc: người dùng bấm “thích” một bài viết. Thay vì chờ API trả về thành công rồi mới đổi màu nút và tăng số lượt thích, frontend cập nhật giao diện ngay. Nếu request thành công, mọi thứ giữ nguyên. Nếu thất bại, giao diện cần hoàn tác hoặc thông báo rõ ràng. Optimistic UI phù hợp với thao tác nào? Không phải thao tác nào cũng nên cập nhật lạc quan. Cách này phù hợp khi: - Xác suất thành công cao, ví dụ like, bookmark, đánh dấu đã đọc. - Thao tác có thể hoàn tác hoặc sửa lại dễ dàng. - Hậu quả khi hiển thị tạm sai không quá nghiêm trọng. - Người dùng cần cảm giác phản hồi nhanh. Ngược lại, nên cẩn thận với các thao tác như thanh toán, chuyển tiền, đặt vé, thay đổi quyền truy cập hoặc xóa dữ liệu quan trọng. Với những trường hợp này, giao diện có thể hiển thị trạng thái “đang xử lý” thay vì giả định thành công. Một luồng xử lý thực tế Giả sử ứng dụng có tính năng lưu bài viết: 1. Người dùng bấm nút “Lưu”. 2. Frontend đổi trạng thái nút sang “Đã lưu” ngay lập tức. 3. Gửi request lên server. 4. Nếu server trả về thành công, giữ nguyên trạng thái. 5. Nếu server trả về lỗi, đổi lại về “Chưa lưu” và hiển thị thông báo nhẹ nhàng như “Không thể lưu bài viết, vui lòng thử lại”. Điểm quan trọng là frontend phải lưu được trạng thái cũ để rollback. Nếu chỉ cập nhật giao diện mà không có kế hoạch hoàn tác, lỗi mạng hoặc lỗi server sẽ khiến dữ liệu trên màn hình lệch với dữ liệu thật. Những lỗi thường gặp khi dùng optimistic UI Một lỗi phổ biến là cho phép người dùng bấm liên tục trong lúc request chưa hoàn tất. Ví dụ bấm like nhiều lần có thể làm frontend và backend lệch trạng thái. Cách xử lý là khóa tạm nút, gom thao tác, hoặc thiết kế API theo kiểu idempotent để cùng một thao tác gửi lại không tạo kết quả sai. Lỗi khác là chỉ xử lý trường hợp thành công. Trong môi trường thật, request có thể timeout, mất mạng, hết phiên đăng nhập hoặc server từ chối vì dữ liệu không hợp lệ. Vì vậy, mỗi thao tác optimistic nên có ít nhất ba trạng thái: đang cập nhật, thành công, thất bại. Cũng cần chú ý đến dữ liệu danh sách. Nếu người dùng thêm bình luận, frontend có thể chèn bình luận tạm vào đầu danh sách với trạng thái “đang gửi”. Khi server trả về bình luận thật kèm ID chính thức, frontend thay bản tạm bằng bản thật. Nếu thất bại, có thể cho phép “gửi lại” thay vì xóa ngay, đặc biệt khi nội dung người dùng đã gõ khá dài. Lời khuyên khi áp dụng - Chỉ dùng optimistic UI cho thao tác rủi ro thấp. - Luôn có cơ chế rollback hoặc retry. - Hiển thị trạng thái đang xử lý khi cần, đừng để người dùng tưởng mọi thứ đã chắc chắn thành công. - Tránh cập nhật nhiều nơi trên giao diện mà không có nguồn dữ liệu rõ ràng. - Kiểm thử các tình huống mất mạng, request chậm, lỗi 401, lỗi 500 và người dùng bấm liên tục. Optimistic UI không phải mẹo trang trí giao diện, mà là một quyết định thiết kế luồng dữ liệu. Khi làm đúng, ứng dụng có cảm giác nhanh và tự nhiên hơn. Khi làm vội, nó có thể tạo ra trải nghiệm khó hiểu: màn hình báo đã lưu nhưng tải lại thì mất, số liệu nhảy lung tung, hoặc người dùng không biết thao tác của mình có thành công hay không. Vì vậy, hãy bắt đầu từ những tính năng nhỏ, đoán trước tình huống thất bại và luôn chuẩn bị một đường lui rõ ràng.