You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the absence of native Object.observe, MDV must maintain a static list of binding participants. Because there is no discrete disposition step for elements, if a user simply discards all references to a Polymer node, we have no way of unbinding that node, and it is never GC'd.
We plan to employ a scheme whereby MDV bindings on a subtree can be deactivate/reactivated. Deactivation will remove the binding data from MDV static lists and store that data on the node itself. Reactivation will restore that binding data to MDV.
If a node is discarded while deactivated, it can GC appropriately.
The idea is to activate nodes on document insertion, and deactivate them on removal, with the added notion of a 'spin down' time, measured in some small number of microtasks, in which the user can re-insert a node or utilize it's API before it's deactivated after removal.
We also intend to add a facility to control activation imperatively, for non-standard use cases. Of course, the onus will be on the user at this point to ensure proper deactivation before GC can occur.
The text was updated successfully, but these errors were encountered:
A slightly simpler system was implemented. Binding state is not cached so it's not possible to re-activate bindings after unbinding has occurred. Instead the requirement is that the user must prevent deactivation during the spin down period.
To facilitate this, these public methods have been exposed on polymer elements:
asyncUnbindAll: unbind the element after a short period of time.
cancelUnbindAll: prevent the element from being unbound if it's been scheduled to be unbound by a call to asyncUnbindAll.
Here's what Polymer does:
at ready time, create bindings and call asyncUnbindAll
at inserted time, call cancelUnbindAll
at removed time, call asyncUnbindAll
The resulting system is mostly transparent and mirrors standard dom behavior. There is one exception: if a user wants a polymer element to remain bound when not in the document, the user must call cancelUnbindAll when the element is created or removed from the document. It's then the user's responsibility to call unbindAll to dispose of the element
In the absence of native Object.observe, MDV must maintain a static list of binding participants. Because there is no discrete disposition step for elements, if a user simply discards all references to a Polymer node, we have no way of unbinding that node, and it is never GC'd.
We plan to employ a scheme whereby MDV bindings on a subtree can be deactivate/reactivated. Deactivation will remove the binding data from MDV static lists and store that data on the node itself. Reactivation will restore that binding data to MDV.
If a node is discarded while deactivated, it can GC appropriately.
The idea is to activate nodes on document insertion, and deactivate them on removal, with the added notion of a 'spin down' time, measured in some small number of microtasks, in which the user can re-insert a node or utilize it's API before it's deactivated after removal.
We also intend to add a facility to control activation imperatively, for non-standard use cases. Of course, the onus will be on the user at this point to ensure proper deactivation before GC can occur.
The text was updated successfully, but these errors were encountered: