-
Notifications
You must be signed in to change notification settings - Fork 14
Description
Currently you allow Aurelia to continue binding to detached entities.
Why? In theory, one shouldn't be displaying a detached entity and there is no good reason to care about subsequent changes to a detached entity. You might as well unsubscribe.
I realize that Breeze still raises propertyChanged
when you set the property of a detached entity. Do we care?
If we don't care, we should discard the BreezeObservableObject
(boo
) when the entity becomes detached.
When are entities detached?
An entity can become detached for a number of reasons.
- you detach it programmatically
- you deleted an unsaved new entity
- you called
rejectChanges
on an unsaved new entity - after a successful save of an entity marked for delete
- after clearing the
EntityManager
What if we re-attach a detached entity?
Hmmm. If a view is bound to entity "x" . You detach it by one of the mechanisms just described. Then somehow you re-attached it behind the scenes without ever changing its view binding?
I'm not sure what happens. Aurelia probably thinks that the object's bound properties are observable and will be waiting for those callbacks to fire.
I personally don't think this scenario makes practical sense. You shouldn't put the user in this situation anyway. When an entity is detached it should be removed from view.
But I'm open to a counter argument.