[DanitaBaires]

> 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.

[IgorPartola]

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.