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
This is technically a bug, since the connected/disconnected callbacks effectively are created once per constructor and never change per instance. So you might think that the connected/disconnected callbacks should use the same WeakMap system as the FACE callbacks, in order to fix the bug.
However, it doesn't actually matter in practice, because every callback closure just passes in this/elm, which is unique per instance:
(This bug only applies to native custom element lifecycle mode.)
Currently the UpgradableConstructor uses a WeakMap to keep track of lifecycle callbacks for FACE:
lwc/packages/@lwc/engine-dom/src/custom-elements/create-custom-element.ts
Lines 45 to 48 in 187a24d
However, it doesn't do this for connected/disconnected callbacks:
lwc/packages/@lwc/engine-dom/src/custom-elements/create-custom-element.ts
Lines 97 to 111 in 187a24d
This is technically a bug, since the connected/disconnected callbacks effectively are created once per constructor and never change per instance. So you might think that the connected/disconnected callbacks should use the same
WeakMap
system as the FACE callbacks, in order to fix the bug.However, it doesn't actually matter in practice, because every callback closure just passes in
this
/elm
, which is unique per instance:lwc/packages/@lwc/engine-core/src/framework/rendering.ts
Lines 340 to 357 in 187a24d
(To get the
vm
, the underlying callbacks callgetAssociatedVM(elm)
.)Here is a test that confirms that the current behavior is correct: 687572e
So basically, the
WeakMap
s are useless at best and a perf hit at worst. It should be possible to greatly simplify this code.The text was updated successfully, but these errors were encountered: