5 ms·
Building an Optimistic User Interface in React
- fenwick67 8y ago> 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"
- darzu 8y agoThat's too harsh. It depends on the operation and the probability of success. If the operation is non-critical and succeeds 99.99% of the time, it makes perfect sense to show the user an "optimistic" result. This is the same principle that multiplayer games use. When a game character is moved in a particular direction, the client shows "optimistic" movement before the server confirms the movement. This is the difference between a playable and unplayable game in many cases.
- braythwayt 8y agoMy bank lies to me all the time. I deposit a cheque, and it puts the funds in my bank. Once it decided I was trustworthy, it even let me spend the money right away. It turns out, though, that it might take _weeks_ for the cheque to clear, and they reserve the right to reverse the deposit and ding me for an NSF fee at any time. Users often prefer optimistic processes to ACID trips.
- pault 8y agoGenerally 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 8y agoIt'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 8y agoIf 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.
- fenwick67 8y ago> It's often not worth the overhead to develop for small bits like `likes` Two things. 1. Likes are not a small detail of a social network app 2. If you're handling a failure state when the HTTP request comes back (like the author does), handling the success state is just an `else`
- mamcx 8y agoA good example of a "correct" way to do this is whatsapp. It signal when 1)it send 2)it get accepted 3)it get read Is optimistic, but is not lying. But if it make believe something have happened whitout proper feedback....
- egeozcan 8y ago> 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!
- swyx 8y agoiirc this is known as minimongo however it is only used in the Meteorjs world for some reason. anyone else know of similar non Meteor solutions?
- vbezhenar 8y agoYou can prevent closing a tab.
- majewsky 8y agoCan you prevent Alt-F4? Can you prevent Windows Update? Can you prevent a power outage?
- vbezhenar 8y agoEdge 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 8y agoWow. What’s the justification for this?
- lowtolerance 8y agoI’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.
- Blackstone4 8y agoWith optimistic user interface updates, how are you meant to handle the cases where requests fail? Doesn't this introduce unnecessary complexity?
- devmunchies 8y agopersonally, 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".
- matte_black 8y agoOptimistic 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 8y agoI 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.
- jordache 8y agoJira's agile card interface is optimistic.
- jordache 8y agoIs 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 8y agoToday 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.