Through considering Shopify’s use of Remote DOM, @jakearchibald proposed that we introduce create and destroy operations; create could be called the first time a new element is being attached to the tree, and destroy could be called in a FinalizationRegistry callback, once the element is no longer used by the partner.
I was initially resistant to this because a) this does not fall out naturally from the MutationObserver subclass for environments with a real DOM, and b) because it required the host to do more work, since each individual attribute/ property set on elements will arrive as a separate message in this model. However, I think this may be the better tradeoff, since situations like reordering a table view (Jake’s main example) could require a huge amount of excess information being sent over the bridge, with each table row potentially needing both a remove and insert operation.
Original proposal (includes some code showing an approach to doing this with MutationObserver) (Shopify-only)
Through considering Shopify’s use of Remote DOM, @jakearchibald proposed that we introduce
createanddestroyoperations;createcould be called the first time a new element is being attached to the tree, anddestroycould be called in aFinalizationRegistrycallback, once the element is no longer used by the partner.I was initially resistant to this because a) this does not fall out naturally from the
MutationObserversubclass for environments with a real DOM, and b) because it required the host to do more work, since each individual attribute/ property set on elements will arrive as a separate message in this model. However, I think this may be the better tradeoff, since situations like reordering a table view (Jake’s main example) could require a huge amount of excess information being sent over the bridge, with each table row potentially needing both a remove and insert operation.Original proposal (includes some code showing an approach to doing this with
MutationObserver) (Shopify-only)