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