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
Another issue I have is that if a user defines a custom element after defining a custom attribute, then if the attribute tries to use any of the element's APIs, it may throw because the element isn't upgraded yet (f.e. 'this.element.someMethod' is not a function).
What can we do?
Can we maybe provide an option when defining an attribute, to tell it to wait for the element that it is on to have been upgraded (only if the name contains a -)?
The assumption is that the element will eventually be defined. After at timeout of 10 seconds or something, an error could be thrown, or an error logged, then the attribute can be instantiated anyways.
With the option being true, then the behavior would be as it is now.
The thought is, that it'd be great for an attributes connectedCallback, disconnectedCallback, and changedCallback to be fired after the element is already upgraded, then someone writing a custom attribute doesn't have to worry about async conditions or have to add extra complexity to their code.
The text was updated successfully, but these errors were encountered:
Yeah, good food for thought. I'm digging into it now. I'll report back if I come up with anything implementation-wise, or if I find some pattern to deal with it on the consumer end (which could provide hints for an implementation).
Another issue I have is that if a user defines a custom element after defining a custom attribute, then if the attribute tries to use any of the element's APIs, it may throw because the element isn't upgraded yet (f.e.
'this.element.someMethod' is not a function
).What can we do?
Can we maybe provide an option when defining an attribute, to tell it to wait for the element that it is on to have been upgraded (only if the name contains a
-
)?The assumption is that the element will eventually be defined. After at timeout of 10 seconds or something, an error could be thrown, or an error logged, then the attribute can be instantiated anyways.
With the option being
true
, then the behavior would be as it is now.The thought is, that it'd be great for an attributes
connectedCallback
,disconnectedCallback
, andchangedCallback
to be fired after the element is already upgraded, then someone writing a custom attribute doesn't have to worry about async conditions or have to add extra complexity to their code.The text was updated successfully, but these errors were encountered: