Not sure I'm following your exact setup... But you could of course just make a model for your form and _not_ your customer. Without seeing your full setup, it's hard for me to say for sure!
In my apps customer will be a global via VueX. If I go to the Edit Customer view, change customer.name, but don’t save, the change will be visible throughout the rest of the app: the customer list, all the other views where the customer’s name is displayed. It would be a bug to show unsaved data anywhere but in the edit view. And if I go to the edit view, make changes, then exit without saving, then go back, the view should be reset. Making two copies of a global model instance seems like the wrong solution.
Edit: what this is missing is essentially an implementation of forms. That doesn’t necessarily need to be a part of this project, but it should be used together with this. Otherwise you end up at least temporarily persisting changes that were never saved. See the relationship between Django models and forms.
Also, one feature I have implemented in at least one of my apps has been using WebSockets to deliver new, updated, and deleted models from the server. That could be a super powerful addition here.
> And if I go to the edit view, make changes, then exit without saving, then go back, the view should be reset.
This is business logic and it's dependent of the UI. If you have a Save button but the user doens't save and leaves the page, on change route you reset the model. If it doesn't have an explicit button, on change route you save the model. It has nothing to do with the framework.
If you mean the library doesn't have a way to reset the model to its original state, it doesn't take too long to implement, just call fetch as the author says or when you load the original model store a copy somewhere, even inside the model itself.
I disagree. First, I don’t want to write a “destructor” for every view a model it touches, because I already have to write a “constructor”. I will reset the view’s local state when it’s activated and not worry about resetting it when it is deactivated. Also, my apps are built such that state is shared across tabs of the app if they are open in the same browser. The user doesn’t have to navigate away to see model changes. So your solution would be broken in that case.
Calling fetch all the time because the user navigated away doesn’t make sense performance wise.
Think about it. If Django/RoR had their ORM make all modal instances global singletons and any view there could modify the properties of the model, but for persistence still had to save them to the DB, would you want all of your views to have to roll their own reset code? Would you trust such code? No. That would be nuts. So why is that ok on the client side? Local state is ok for emphemeral data. Use it instead of modifying global state with data that is not ready to be committed.
