You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For traditional apps data loss is considered a severe sin, although we've lost some of that in the move to web apps. If someone makes changes to an app without autosave and neglects to save or the browser crashes, those changes are lost. It would be straightforward to every mavo app to periodically back up any changed data to localstorage (since we already have that functionality) but delete the backup when data is successfully saved. On init, a mavo could check for a localstorage backup and, if it finds one, ask the user if they want to load from the backup.
One could imagine using timestamps to get more clarity on whether a backup should be used, but user confirmation is probably still essential since it is possible for a user to save differently changed data using a different machine, which they might not want to overwrite from backup.
Even if autosave is in use, backup might still make sense if the autosave interval is large enough to risk data loss.
Data could conceivably get large enough to make the backup to localstorage slow and disruptive, so perhaps there should be an mv-no-backup attribute to prevent it.
Someday we might want to generalize this functionality to allow mavo to store and explore an unlimited set of data versions, as google docs does, but that's not as important.
The text was updated successfully, but these errors were encountered:
First, I agree this is very useful for a number of use cases. Not just for backup functionality, but also for the far more prominent use case of being able to work offline, and merge data when you get connectivity again.
However, implementation cost is also quite high.
First, we can't simply store a snapshot of the whole dataset, we'd want to adopt a data diff to (see https://jsonpatch.com/) to store edits. That is more broadly useful, as it will also make it easier to work with backends that support incremental changes, and will open the way to granular AC in the future or even proper undoing.
Second, even associating the data with the Mavo app is not trivial in the general case (the app id could change, which can happen with no author intervention if the app is unnamed and another app is added before it).
User confirmation would definitely be needed, which means this also involves end-user facing changes, localization, customization, etc.
That said, none of this is insurmountable, and all of it is useful more broadly, so I'm not opposed to working on this. It would likely need to start from a plugin, though the underlying changes (e.g. moving towards a diff format) would be done in Mavo.
For traditional apps data loss is considered a severe sin, although we've lost some of that in the move to web apps. If someone makes changes to an app without autosave and neglects to save or the browser crashes, those changes are lost. It would be straightforward to every mavo app to periodically back up any changed data to localstorage (since we already have that functionality) but delete the backup when data is successfully saved. On init, a mavo could check for a localstorage backup and, if it finds one, ask the user if they want to load from the backup.
One could imagine using timestamps to get more clarity on whether a backup should be used, but user confirmation is probably still essential since it is possible for a user to save differently changed data using a different machine, which they might not want to overwrite from backup.
Even if autosave is in use, backup might still make sense if the autosave interval is large enough to risk data loss.
Data could conceivably get large enough to make the backup to localstorage slow and disruptive, so perhaps there should be an mv-no-backup attribute to prevent it.
Someday we might want to generalize this functionality to allow mavo to store and explore an unlimited set of data versions, as google docs does, but that's not as important.
The text was updated successfully, but these errors were encountered: