Hacker News Reader

Comment by klabb3 | Hacker News Reader

Those cases should both be solved with optimistic UI, so there’s no difference.

You can have a little checkmark to indicate that it’s synced, like many chat apps do.

> In my experience optimistic UI is way more complex to build. Many times the complexity is worth it though.

Yeah, can attest to this. I’m working on an app[1] that strikes the trifecta: p2p, real-time and offline first. All of those things combined makes the amount of tooling, design patterns and resources available shrink to a tiny sliver compared to a typical web-based tech stack. I have researched probably 100 projects that sound promising but almost all have been a poor fit for one reason or another. I opted to build almost everything from scratch.

Kudos to the JS ecosystem. They are way ahead in this space, with rxdb, watermelon, yjs, automerge etc. Unfortunately I couldn’t use any of them because I use a split-language stack.

[1]: https://payload.app/

View on HN

to add to this -

rotate CRUD mindset to CQRS, now you have a start event and an end event, this is the extent of the pending sync state which can be afforded to the user at any granularity - document level, message level, form or field level, etc.

The cost is that other view queries don't reflect the pending event, only the view that issued the command has an association to the event. Which is usually the UX you want. Consider a master/detail form app where you insert a new record into a collection, but the view is sorted/filtered/paginated and your new record does not match the criteria and therefore vanishes. That is never the right UX. A less surprising alternative UX is to limit record creation to a specific form for the business rules of creation, and that form exists in the context of a specific collection view with business rules around newly created entities of that kind, with an invariant that newly created entities will always appear at the top or bottom of that collection (e.g. new messages are always added to the bottom of the chat history view). Now the optimistic update bypasses the database and simply writes through to the view optimistically and then when the ack is eventually received it seamlessly changes state without any UI jank.

Now you can send many new messages rapidly and if the nth message fails and the rest of the messages went through you get a properly located error. With a CRUD mindset, probably the form is simply disabled until each individual insert succeeds - which means your chat app cannot keep up with you typing!

When you need a single source of truth you cannot use optimistic UI.

E.g. if the user is a realtor, then she can't tell the customer "you have now bought the house" if there is no online connection and you're waiting for a sync. You can fill out and upload the form async, but commitment must be online.

You cannot tell the customer "you might have (or might not have) bought the house, we will only know later".

> You cannot tell the customer "you might have (or might not have) bought the house, we will only know later".

Sure you can - in fact, that's what realtors call offers. You place an offer, and you only find out later if you bought the house, often days later.

Technically correct, but you're missing the point.

Eventually you do need to be able to commit some sort of transaction and get confirmation from the counterparty.

This is correct but you can do tricks to change who the counterparty is, which is often useful. If, instead of putting up a yard sign and saying "this house is for sale" and waiting for someone to come by and complete the transaction, the homeowners entered a contract with a brokerage to sell the house to anyone who is willing to abide by a list of terms (minimum price, occupancy date, etc.), then the brokerage can respond immediately and say "great, the house is yours". This is essentially the equivalent of sending a sell order to a stock broker.

In this case the optimistic UI might be good to have a step like “this request is pending”. So when the form is submitted the data is ready to send and will send when it can. Ideally with an indicator that the user is offline and needs to be online to sync.

You can if you acquire a distributed lock in advance, as per https://electric-sql.com/blog/2022/05/03/introducing-rich-cr...

That's true even if you're example isn't perfect. Some types of transactions have business requirements that demand immediate consistency or responses. Contraindications certainly don't invalidate ideas, though. Use the right to for the job.

> Those cases should both be solved with optimistic UI, so there’s no difference.

Ah, yes, "in theory, the theory and the practice are the same". Unfortunately, in practice, the theory and the practice are not the same, and those cases are regularly not solved with optimistic UI (even though they should), so there is difference.

Git has one interface for disconnected commits and another one for connected ones. Most of the command set is bifurcated around this. Sure there are places where you do the same act for local and remote but those are more the exception than the rule. It's very exposed. They've done very little no create any sort of abstraction across them, and that's probably the right answer.

Ugh. This makes me very sad. Git is a ux disaster, and my gut instinct when realizing I was doing the same thing as git would be to seriously question my thought process.

I'm sorry I made you compare yourself to git.

First I heard of "optimistic UI" was with GraphQL and Apollo, but I had seen the behavior that they someone, perhaps them, gave this name for a lot before.

I don't find the concept "optimistic UI" to be more useful for talking about it or the implementation by Apollo to be more elegant. It's fine but it doesn't solve any problem except one that was created by Apollo's binding of server data to the client, React-style.

Reply on news.ycombinator.com