[steve_adams_86]

Another choice would be optimistic UI updates (assume the checkbox will end up checked. If not, revert to unchecked and display feedback about an error).

I’ve tended to use this in UIs which rely on server state, and it usually makes things feel much snappier. In my experience it’s rare that an optimistic update isn’t fulfilled as expected, so the user experience is improved overall.

I’d hesitate to do it absolutely everywhere, though. In large forms it would be preferable to do batch updates rather than updating on every field interaction, for example.

[solardev]

That causes rubberbanding, doesn't it, where the checkbox looks checked at first and then unchecks itself a few seconds later when the server says "nope"?

[steve_adams_86]

It can, yes, but the snap back should always be accompanied by feedback to allow the user to understand what happened.

There are pitfalls (what if the user thinks a setting saved and closes their browser, but it failed after they closed the tab?) which are addressable but it takes work and complexity. I think optimistic UI can be helpful. Generally speaking it’s a layer of complexity I’d tend to try to avoid, though.

Tools like Relay for graphql come with excellent implementations of this which I’d say are worth using if you’ve adopted the library, for example.