How are you all handling optimistic UI?

# compose-android

[undermark5]

How are you all handling optimistic UI?

[undermark5]

We've got a scenario where we'd like to ensure immediate UI updates after user interaction. These interactions ultimately will result in some network calls for validation. However, it may be possible to allow the user to interact multiple times within a short time frame, meaning that if the user interacts twice before the first network call get's back, a naive approach for optimistic UI would appear to be "rolled back" before then having the second interaction committed. In theory, debouncing the UI state would prevent this in most circumstances, but that feels wrong.

[Stylianos Gakis]

Feels like not a concern for your UI layer to solve per say, but how your business logic handles such interactions and updates your UiState.

Depending on the scenario there’s different things you can do. Loading states being the easiest approach generally, but it really depends.

[undermark5]

I mean, I kinda feel like loading states for interactions (think like likes/upvotes on social media) kinda go against optimistic UI, and aren't necessarily within the vision for the product. Obviously if it's impossible to manage without them, then the product people will just have to deal with a compromise.

[Stylianos Gakis]

Oh yeah, wouldn’t suggest loading state for a like. But in the end the decision of what happens when that request does not actually go through is not for your compose UI to handle. Hence I think this does not really have much to do with compose itself, so it might be a question for another channel. What do you think?
Would you do this any differently in an app using Views?

[undermark5]

I mean, I suppose it would the same regardless of the UI framework. That being said, I'm still curious how others are handling optimistic UI, if it's simply handling outside of the view layer itself then that's fine.

[Stylianos Gakis]

Compose really works best when you have a single source of truth. So "handling outside of the view layer" in my opinion is the only sensible approach in the first place 😊

[Abinet Zelalem]

You can maintain the state within the composable without hitting any network until another interaction happens on another element.

[Stylianos Gakis]

You can, then you got two sources of truth, and one of them is completely ephemeral and will be lost quite easily

[Abinet Zelalem]

That should be ok I think. A simple form that changes it’s state based on interaction can retain 2 different states.
One intentionally ephemeral state to handle information about the UI and another that you can use to hit your backend/services.
This second state can rely on the first.