What are the other options?
handle the errors, ideally manually
Re:Offline UX Patterns
by wodenokoto on Thursday October 03, 2024 @02:36AM
(#41727876)
What error?
Re:Offline UX Patterns
by mystified5016 on Wednesday October 02, 2024 @06:25PM
(#41725516)
The same options we've had literally since computers were invented. Unexpected and unrecoverable errors are as old as computing. This is not some new field of rocket surgery.
You use whatever mechanism is available in your language/framework to catch exceptions or errors, and you handle it. The program should do its best to recover, fail gracefully, and emit a useful message or log.
This is one of the core tenets of programming. Again, since the dawn of time.
> The user could have gotten logged out somehow, or maybe there's a rate limit or something
All your examples are retryable errors in which the prescription is the same: "keep the message queued until it's successful." And when all your failure modes are like this optimistic-no-feedback works. If you have non-retryable errors in your failure modes "Bad Request", "Gone" this pattern can't be used.
Re:Offline UX Patterns
by ben-schaaf on Wednesday October 02, 2024 @08:37PM
(#41726239)
Not being logged in is not a retryable error.
Sure it is, why wouldn't it be? Keep it stored and queued until they log in again. It's the same as being offline.
What if someone else logs in?
Your local storage, and hence the queue, isn't segmented by user?
Sure they're retryable. But those retries might never succeed (user wipes their phone or uninstalls the app or logs out or clears local app data or a buffer fills up to come up with a few scenarios. Either the request didn't matter to the user at all, in which case sure whatever, or at some point they're going to discover that the thing they thought happened didn't actually happen.
My error buckets and //TODOS with dreams of more refined implementations weren't all that lazy after all.
Re:Offline UX Patterns
by wodenokoto on Thursday October 03, 2024 @02:42AM
(#41727900)
So what you are saying is that you don't think apps should work when offline?
Not at all. I'm saying that they should reflect the unereliability inherent in distributed computing rather than pretend it can't exist with such false notions as "retries will fix it" or "this call can't fail"
Assuming the happy path just leads to the app breaking in weird ways down the road.