What should happen when a Store or StoreMap subclass is detached [and then reattached] to the document?
If it's detached and then immediately reattached, the most efficient approach is to not do anything.
But if it's reattached after a delay, then another approach is for detachedCallback() to stop tracking changes in the store (by calling _untrack()), and then for attachedCallback() to repopulate the list from scratch, and to once again start tracking store changes. However, that might be problematic because (for example) PageableList might lose its paging position.
If it's detached and never reattached, the ideal behavior would be for detachedCallback() to stop tracking changes in the store (by calling _untrack()). Otherwise, the application must manually call Store#destroy().
In any case, the current code is inconsistent and doesn't work. Store#detachedCallback() calls _untrack(), but Store has no corresponding code to requery the store and setup tracking on attachedCallback().
StoreMap#attachedCallback() does have code to call queryStoreAndInitItems(), but it doesn't run on reattach because this._pendingQuery is null.
There's also other code in StoreMap#attachedCallback() that's only meant to be run once: the code to read custom mapping attributes on the element. Probably that code should be moved to a different method.
See original ticket ibm-js/deliteful#589.
What should happen when a
StoreorStoreMapsubclass is detached [and then reattached] to the document?If it's detached and then immediately reattached, the most efficient approach is to not do anything.
But if it's reattached after a delay, then another approach is for
detachedCallback()to stop tracking changes in the store (by calling_untrack()), and then forattachedCallback()to repopulate the list from scratch, and to once again start tracking store changes. However, that might be problematic because (for example) PageableList might lose its paging position.If it's detached and never reattached, the ideal behavior would be for
detachedCallback()to stop tracking changes in the store (by calling_untrack()). Otherwise, the application must manually callStore#destroy().In any case, the current code is inconsistent and doesn't work.
Store#detachedCallback()calls_untrack(), butStorehas no corresponding code to requery the store and setup tracking onattachedCallback().StoreMap#attachedCallback()does have code to callqueryStoreAndInitItems(), but it doesn't run on reattach becausethis._pendingQueryis null.There's also other code in
StoreMap#attachedCallback()that's only meant to be run once: the code to read custom mapping attributes on the element. Probably that code should be moved to a different method.