Break stuff. Now.

Optimistic UI State

Make assumptions in the UI way before it's actually legit

March 12, 2015

While I'm rolling in bed, fixing code some teammates's code in the dead of midnight, the thought of "avoiding local component state" keeps crossing my mind. It's due to the fact that I develop components which tend to keep local state rather than share its state directly with the cache layer of the app (model/stores/whatever). This I tend to avoid, but generic components do need to have some internal state somehow, especially when it's not concerned with the data at all. However...

I noticed something while chatting with that teammate on Facebook. Before anything else, I have adblock on with a custom filter that prevents Facebook from sending a "Seen" (coz I want to be perfectly invisible on FB). Essentially it just filters out the AJAX ping that does that. But one thing I notice everytime is that even if I blocked this, the red badge that indicates new messages, notifications and friend requests disappear when I view messages, notifications or friend requests, respectively. What's happening?

It appears that the Facebook UI is optimistic in handling "Seen". The UI immediately removes badges after content is seen, regardless if it has actually saved the state on the server. As proof, when I refresh the page, all the badges reappear. Even phone notifs don't dismiss.

Twitter does the same thing with tweets, pushing the tweet to the feed regardless if it has been saved. If it does save, it refreshes the feed, and still have your tweet end up on top.

So yeah, UI can be optimistic and it's good for UX. The code "assumes" the operation is successful, and makes the app look fast. Like what an officemate said:

If you can't make it, fake it.