Replies: 1 comment 4 replies
-
Thanks for bringing this to my attention. I've added a test to The core of this problem is in the watch decorator, and there are other things I'm not happy about in its current state. As of now, Instead of running on @watch('prop', { waitUntilFirstUpdate: true })
handler() {
// this will run on change but only after the component has updated at least once
} Internally, it uses This change to @watch('prop')
async handler() {
await this.updateComplete;
// this code will run after the next update
} So now we'll get the best of both worlds — just need to be a bit more conscious about the lifecycle. I'll push my changes once I finish updating the rest of the components. |
Beta Was this translation helpful? Give feedback.
-
I have been experimenting this library for a week, because I like it and I would like to integrate it into a real project.
I got a weird error using the
sl-include
component. This happened when I included an HTML page that contained components that used thedisconnectedCallback
method for cleanup internal resources (such as remove event listeners, or destroy other components like the popup).What's up? The
sl-include
component loads the HTML page content twice. But why? This strange behavior led me to investigate further.What I found is related to the @watch decorator which requires a component update even when it's not really needed.
So summing up:
sl-include
component append the HTML contentsl-include
component require an update (because the property is observed with @watch decorator)sl-include
component replace the HTML content previously loadeddisconnectedCallback
methodThis is where the error is throw (this.button is
NULL
):I did some testing and I think the decorator should be modified like this:
@claviska what do you think about?
Beta Was this translation helpful? Give feedback.
All reactions