
Building an Optimistic User Interface in React - jonisar
https://blog.bitsrc.io/building-an-optimistic-user-interface-in-react-b943656e75e3
======
egeozcan
> make our UI update immediately in order to reflect user actions, instead of
> traditionally waiting for the backend's success response

So, a user on a slow network thinks that the request went through and closes
the tab. Boom! You've got yourself the first version of MongoDB on the client
side!

~~~
vbezhenar
You can prevent closing a tab.

~~~
majewsky
Can you prevent Alt-F4? Can you prevent Windows Update? Can you prevent a
power outage?

~~~
vbezhenar
Edge allows to prevent Alt-F4. I guess other sane browsers have the same
behavior. Power outage is an extremely rare condition (especially in a world
of laptops) so I don't think that it's a problem worth solving. I didn't
understand that part about Windows update, it never closed my browser.

~~~
dcd0101
Wow. What’s the justification for this?

~~~
lowtolerance
I’d like to know as well. Preventing users from closing a tab is the kind of
user-hostile UX I’d expect from some of the scummier ad networks.

------
jordache
Is this topic even worthy of an article? Whether the UI reflects user action
optimistically is purely dependent on the use case and requirements. The UI
should behave in a rational way, for the given use case.

Somethings we use are already optimistic - When you use Jira to drag and drop
tasks, the drop event occurs immediately, without waiting for network
response.

There is nothing break thru about this pattern.

------
krisdol
Today my cto and some other old timers were discussing bugs from the early
days of the company, and one of the observations was that optimistic updates
create pessimistic users. Network hiccups, power outages, closed browsers,
server lockups, vpn disconnects, airline-quality wifi, and closed laptops
aside, are you going to have your entire validation stack completely mirrored
on the server and UI (and db schema)? If any of these places do a little more
or a little less error checking than the other, and you optimistically update
the UI, well you’ve just lost your users trust after they lose their data
entry work that appeared to succeed before they moved on, but in fact failed
at some unexpected layer.

There are a lot of ways that google docs indicate to you that you might lose
your data, but unless you have the engineering resources and time to invest
into accomodatingg and recovering from every potential failure scenario in a
distributed system, it’s better to focus on building a transparent product
that fails quickly and clearly when something isn’t right. Optimistic UI, when
done badly, makes users mistrust the data they’re presented. Trust is more
fundamental to a product’s value than how zippy it feels.

------
matte_black
Optimistic UI is best for inconsequential things that don’t matter in consumer
apps such as likes, comments, etc.

But dear God please don’t use it in Enterprise apps.

~~~
spinlock
I feel like any app should implement a pattern like this:

    
    
       action -> UI recognition of action -> display API response
    

For actions that succeed 99% of the time, I think the "UI recognition of
action" can be the success state. For actions with higher failure rates, the
"UI recognition" should be a spinner or something to show the user that work
is being done.

If you've got a project where it's not acceptable to show "success" -> "oops I
mean failure", just go with the spinner all the time. But, it makes a huge
difference if you respond to a click in < 100ms vs. > 100ms.

------
fenwick67
> This interaction and updating phase is often asynchronous by nature, as the
> app waits for a response from the backend whether to update the data or not.
> The update is usually based on the success of the action triggered by the
> user.

> An Optimistic User Interface is when a user triggers an action and the UI
> updates immediately, even though there may be a request pending.

This is also called "lying to your users"

~~~
pault
Generally speaking, optimistic updating should have some type of UI to subtly
display the network status so the user is aware of what is going on under the
hood, but the network activity doesn't block them from performing additional
actions. This model brings a whole boatload of complexity to your
implementation however, so be prudent with where and how often you apply it.

~~~
bpicolo
It's often not worth the overhead to develop for small bits like `likes`. For
small, 30-50ms requests they're not going to notice anything either way. A
brief flash of an icon isn't useful.

~~~
dcd0101
If we’re only talking about operations that are fast, nearly bulletproof, and
trivial, then I’m even less sold on the idea.

In the article it describes reverting the state of the component if the action
fails, asynchronously. IMO that’s much worse than briefly representing a
progress state for a few ms.

------
Blackstone4
With optimistic user interface updates, how are you meant to handle the cases
where requests fail?

Doesn't this introduce unnecessary complexity?

~~~
devmunchies
personally, for things like React, it can actually reduce complexity. There is
only 2 states for a components. For example, an upvote button is "checked" or
"unchecked". But without this there is "checked", "unchecked", and
"inProgress".

