Closed
Description
When editing a resource via the default edit view changes will stay on the resource even when navigating away. The changes are not persisted and are gone when the user refreshes but not when navigating to a different page. This might give the impression the resource is saved to the server and can lead to unintentional data loss.
We should make it so that when the user leaves the edit page the resource gets refreshed so it shows its state from before it was edited.
Activity
joepio commentedon Jul 9, 2024
Some thoughts:
Form fields (in the edit page) should not update the
Resource
in theStore
. The fact that the store is updated, instead of some local value, is at the heart of this issue.A refresh after navigating away should fix OPs issue, but it does not fix the underlying issue.
Perhaps the
useValue
hook deserves some additional thoughts. Live updates (before the commit is signed / accepted) are useful for having a responsive, fast app, but a value should not be set in a Form before the "save" button is pressed, I think.Polleps commentedon Jul 10, 2024
I don't really see a problem with the store being updated. It makes it relatively simple to work with complex shared data throughout the app. Using some kind of clone of the resource or a separate object with values kind of goes against the read/write nature of resources and AtomicData.
Refreshing the resource when the edit form unmounts is also a lot simpler and completely bypasses other issues like dealing with serverside updates of the resource that can introduce merge conflicts with the cloned data.
#906 Reset resource after cancel edit
#906 Reset resource after cancel edit
#906 Reset resource after cancel edit
Merge upstream (#23)