Explain optimistic UI updates and how to implement them with rollback on error.

Explain optimistic UI updates and how to implement them with rollback on error.

• A. Update the UI immediately and rollback on error if the request fails.
• B. Always wait for server response before updating UI.
• C. Never rollback changes after a failed request.
• D. Optimistic UI is only applicable to read operations.

Answer: (A)

Optimistic UI updates mean updating the interface right away to reflect the user’s action, assuming the server will succeed, so the app feels fast. The rollback-on-error part comes in as a safety net: you keep a snapshot of what UI looked like before the change, apply the optimistic update, and then perform the server request. If the server says the action failed, you revert to the previous state and show an error, so the UI stays consistent with reality. To implement this, track the previous state before the change. Apply the UI update immediately using the new value, then send the request to the server. If the server responds with success, you can optionally reconcile with any data the server returns (in case there are small adjustments). If the request fails, restore the previous state and notify the user. A practical pattern is: take a copy of the current data, apply the change in the UI, fire the network request, and on error restore the old data. In React terms, you might store the current list, save a backup, set the new list optimistically, and in the catch path revert to the backup. Libraries like React Query or Apollo support this approach with dedicated hooks or options to perform optimistic updates and automatically rollback on error. This approach is especially valuable for write actions like liking a post, adding an item to a cart, or editing a field, where immediate feedback improves perceived performance. It’s not about reads, and you should plan for rollback, error messaging, and possible retries to handle failures gracefully.

Optimistic UI updates mean updating the interface right away to reflect the user’s action, assuming the server will succeed, so the app feels fast. The rollback-on-error part comes in as a safety net: you keep a snapshot of what UI looked like before the change, apply the optimistic update, and then perform the server request. If the server says the action failed, you revert to the previous state and show an error, so the UI stays consistent with reality.

To implement this, track the previous state before the change. Apply the UI update immediately using the new value, then send the request to the server. If the server responds with success, you can optionally reconcile with any data the server returns (in case there are small adjustments). If the request fails, restore the previous state and notify the user.

A practical pattern is: take a copy of the current data, apply the change in the UI, fire the network request, and on error restore the old data. In React terms, you might store the current list, save a backup, set the new list optimistically, and in the catch path revert to the backup. Libraries like React Query or Apollo support this approach with dedicated hooks or options to perform optimistic updates and automatically rollback on error.

This approach is especially valuable for write actions like liking a post, adding an item to a cart, or editing a field, where immediate feedback improves perceived performance. It’s not about reads, and you should plan for rollback, error messaging, and possible retries to handle failures gracefully.