Optimistic UI updates

Trim down the number of loaders, and be optimistic 🤞
    • Sunday, March 15th 2020
    • 2 minutes read

Updating the UI optimistically is a pattern of persisting a new UI state, before getting the go-ahead approval of the server.

This pattern makes more sense for non-destructive parts of our interfaces. Things like liking a post, marking a tweet as favorite, or as seen below, starring a repository.

github-star

In the above scenario, the Github UI will mark the repository as 'starred', even if the backend hasn't approved of the operation.

But it's fine really! Operations like that are meant to be fast. To properly capture the sequence, I had to drop down to GPRS speed.

The other options would be:

  • Display a loader and then persist the new state
  • Don't display a loader, but cling on the previous state and update when the server responds.

Both of these are suboptimal for such cases.

The first one can be very UX-unfriendly. Seeing small spinners for every single micro-interaction can be very tiring for the user.

The second one, makes the user second-guess if they clicked or not. But most importantly it gives the idea that the application is sluggish, buggy or both.

Sometimes the user expects a delay.

Think of toggling an article from private to public. By slowing things down, we're letting the user know that the operation has been processed and the article is now live.

Even if the interaction is a simple switch, it's an important action that the user knows to expect a delay.

They are not moving to other actions, but instead, they are waiting for a confirmation, and any immediate feedback will put them in disbelief.

Choose wisely

Optimistic updates are meant for complementary actions.

Here are some rules of thumb:

  • The actions should be binary-like. ("Liked", "Starred" or "In saved searches")
  • The actions shouldn't be tied to other parts of the interface.
  • The API response times should be extremely fast.
  • The API success ratio should be near 100%.

We're optimistic, but not stupid for a reason.

Feedback

Eventually, something will go wrong.

Reverting the original state should suffice. Remember we're doing this because we know that the API will respond in less than a second, and it will almost always succeed. The user will notice the change.

Of course, we can also silently-retry or provide feedback. It depends on the context.

Be optimistic 🤞

Thanks for reading!  ❤️
Next up: "Data fetching with React-Query"
Back to Blog