Currently, whenever a view model is updated, it always triggers an update for all its children, as well. However, if the data given is no different from the current data, then there should be no need to trigger an update cascade, or even assign any values on the view model that was "updated", to begin with.
This would also allow the newly introduced LazyLoad component to be more efficient, by being able to re-use a cached rendered template even after a sheet is closed and then re-opened.
The challenge however, lies in detecting a "no change" scenario. After all, just because a parent view model's data didn't actually change, doesn't mean a child view model's data might not have changed. As an example: an actor sheet view model only allows updating its isEditable, isSendable and isOwner properties. But the skill list view models also rely on the skill documents embedded on the actor document. So, if a skill was added to, removed from or altered on the actor, then the skill list must update itself and its children.
So perhaps the update-cascade is unavoidable. But perhaps a new mechanism, like child view models "reporting" whether their data set has changed, might be useful.
Currently, whenever a view model is updated, it always triggers an update for all its children, as well. However, if the data given is no different from the current data, then there should be no need to trigger an update cascade, or even assign any values on the view model that was "updated", to begin with.
This would also allow the newly introduced
LazyLoadcomponent to be more efficient, by being able to re-use a cached rendered template even after a sheet is closed and then re-opened.The challenge however, lies in detecting a "no change" scenario. After all, just because a parent view model's data didn't actually change, doesn't mean a child view model's data might not have changed. As an example: an actor sheet view model only allows updating its
isEditable,isSendableandisOwnerproperties. But the skill list view models also rely on the skill documents embedded on the actor document. So, if a skill was added to, removed from or altered on the actor, then the skill list must update itself and its children.So perhaps the update-cascade is unavoidable. But perhaps a new mechanism, like child view models "reporting" whether their data set has changed, might be useful.