Remix.run Logo
pier25 7 hours ago

For native apps this is less of an issue since they have access to persistent storage but with browsers there's no guaranteed persistence.

WhyNotHugo 7 hours ago | parent [-]

There's guaranteed persistence, but there's no guarantee that the host will be up anytime soon. E.g.: I might leave a final reply with all the details on an issue before going on vacation (or maybe I don't work the next day but my colleagues abroad do!). I see that it's properly posted and close the laptop.

The reply with be delayed by days or weeks, but the UI indicated that it had been properly saved.

pier25 7 hours ago | parent [-]

> There's guaranteed persistence

There's not. Browsers can delete "persistent" storage at any time.

https://developer.mozilla.org/en-US/docs/Web/API/Storage_API...

12_throw_away 6 hours ago | parent | next [-]

It depends. From the link:

> If, for any reason, developers need persistent storage [...] they can do so by using the navigator.storage.persist() method of the Storage API.

This makes a request for guaranteed permanent storage ... which can be approved (or denied) by the user or by browser defaults.

ifwinterco 6 hours ago | parent | prev [-]

Edge case but playing devil’s advocate: a user can also uninstall the native app at any time, and might still expect their last change before they closed the app to be reflected in the web version.

You can never truly trust anything about a client because by definition you don’t control it

killingtime74 6 hours ago | parent [-]

But the os can't uninstall the native app at any time unprompted right

aforwardslash 4 hours ago | parent | next [-]

Corner case: actually, it can. Also, thats how auto-updating works ; depending on local state as a source of truth using browser apis is a terrible idea IMO.

The whole concept of "assume it is committed while we sync in the background" is, in the most cases, a terrible architectural decision, unless it is coupled with explicit feedback (eg. A small visual indicator indicating if the background queue is empty or syncing). Also, it breaks temporality: last-update-wins no longer holds, because update time and sync time are decoupled. And you also create a new problem, which is local cache coherence.

It may be a good fit for some systems (though I cannot think of a single one), but in general is just a horrible solution.

ifwinterco 6 hours ago | parent | prev [-]

No, it’s definitely a lot less likely and probably an edge case you can ignore in practice