You might have noticed that the timer declaration has moved from the constructor to the connectedCallback, and this was to simplify passing in the dynamic interval delay value, which would only be queryable once the element is mounted (or connected)
There's two things I want to add here:
Setting up the timer in the constructor and removing it in the connectedCallback would have meant the component would have stopped working if it was ever removed from the document and inserted elsewhere. Setting it in the connectedCallback to re-start it when re-attaching is the correct way about this.
It is not entirely correct that the attribute for the delay value is only queryable when the element is mounted. If the element has already been parsed by the time the custom element is defined, the constructor will have full access to the element and its children, including attributes. Only if the custom element is already defined before the element is parsed, the constructor will run before any of the attributes or child elements have been parsed.
Note: This is equivalent static observedAttributes = ["x-interval"];, and if you had more than one attribute to track, you would comma-separate them in that array.
If you already have an attrs attribuet, then I would hope nobody would actually comma-separate them and instead just write something like this:
staticobservedAttributes=Object.keys(Timer.attrs)
Last but not least, the final version of the component would behave somewhat inconsistently. Detaching the component would initially pause the counting. Updating the interval attribute would then resume the counting. Connecting the element again would then start a second interval that could never be cancelled anymore and would continue to count up until the page is closed.
An easy way to fix this would be to just check if the object is actually connected in the attributeChangedCallback 😁
Setting it in the connectedCallback to re-start it when re-attaching is the correct way about this.
This makes so much sense, and I don't know how I missed this!
It is not entirely correct that the attribute for the delay value is only queryable when the element is mounted. If the element has already been parsed by the time the custom element is defined, the constructor will have full access to the element and its children, including attributes. Only if the custom element is already defined before the element is parsed, the constructor will run before any of the attributes or child elements have been parsed.
This has taken me a quite a while to wrap my head around. I had someone else also flag this for me when I did the first post, and to be honest it hasn't clicked until now. I'll work on the correction and update the post. Thank you!
Good shout! I'll add that in too and signpost that by doing so all of your attributes will be tracked, which is probably what you'd want most of the time.
Detaching the component would initially pause the counting. Updating the interval attribute would then resume the counting. Connecting the element again would then start a second interval that could never be cancelled anymore and would continue to count up until the page is closed.
Great catch! I definitely didn't play that scenario out. I'll make the correction!
Honestly, thank you so much for taking the time to read the post and give me feedback! Greatly appreciate it.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
There's two things I want to add here:
Setting up the timer in the constructor and removing it in the
connectedCallbackwould have meant the component would have stopped working if it was ever removed from the document and inserted elsewhere. Setting it in theconnectedCallbackto re-start it when re-attaching is the correct way about this.It is not entirely correct that the attribute for the delay value is only queryable when the element is mounted. If the element has already been parsed by the time the custom element is defined, the constructor will have full access to the element and its children, including attributes. Only if the custom element is already defined before the element is parsed, the constructor will run before any of the attributes or child elements have been parsed.
If you already have an
attrsattribuet, then I would hope nobody would actually comma-separate them and instead just write something like this:Last but not least, the final version of the component would behave somewhat inconsistently. Detaching the component would initially pause the counting. Updating the interval attribute would then resume the counting. Connecting the element again would then start a second interval that could never be cancelled anymore and would continue to count up until the page is closed.
An easy way to fix this would be to just check if the object is actually connected in the
attributeChangedCallback😁Thank you very much for your feedback.
This makes so much sense, and I don't know how I missed this!
This has taken me a quite a while to wrap my head around. I had someone else also flag this for me when I did the first post, and to be honest it hasn't clicked until now. I'll work on the correction and update the post. Thank you!
Good shout! I'll add that in too and signpost that by doing so all of your attributes will be tracked, which is probably what you'd want most of the time.
Great catch! I definitely didn't play that scenario out. I'll make the correction!
Honestly, thank you so much for taking the time to read the post and give me feedback! Greatly appreciate it.