Even though web components have been losing steam in recent days, they have a lot of advantages. One of them is writing framework-agnostic componen...
For further actions, you may consider blocking this person and/or reporting abuse
One thing nearly everyone does is due to incorrect documentation:
can be written as:
Note the use of
append
andappendChild
. In most examplesappendChild
s return value is never used.append
can added multiple text-nodes or elements.And the global template.innerHTML isn't necessary either:
Docs also say you "use super() first in constructor"
That is incorrect also.
You can use any JavaScript before
super()
; you just can not usethis
until it is created by thesuper()
callThanks for letting us know about this. The code looks much cleaner, and yes! not creating a template element would be much better as the global namespace wouldn't be polluted. I'll add this comment to the article ๐
Shouldn't be innerHTMLing in constructor. Better to use the template
If you don't take my word; then maybe you take this guy his comment on
innerHTML
I don't know the guy personally .. but Justin Fagnani sounds familiar ๐
Can you motivate that statement, Benny
innerHTML
andappend(Child)
all do the same: they add content to a DOMThat
.createElement"template")
takes extra CPU cycles; content is parsed once.With
.innerHTML=
content is also parsed once.So there is only benefit if code does
template.cloneNode(true)
multiple timesif you know you're only going to use the element once, yeah there's no difference.
But if you're going to construct the element several times, then you're going to invoke the parser on each instance.
If the element's shadow DOM is extensive, that could add up fast.
Moreover, keeping the template static means it's parsed up front.
Truly said. Altough I wouldn't say just because of this, that the docs are "incorrect". Maybe the first one is more readable for newcomers. Anyway, super useful comment though. Thanks.
See what code newcomers have to dig through (unless they don't RTFM) in the
attachShadow
MDN documentation: developer.mozilla.org/en-US/docs/W...If you understand "// Always call super first in constructor" is incorrect
you can write that 33 lines
constructor
(most likely) without any comments:If you want to score W3C points; feel free to update that MDN article.
I did some MDN updates; then concluded there is way more effect adding comments to Web Component blogposts.
And I recently published my first Dev.to post explaining Web Components are about semantic HTML (IMHO)
And ... there is more wrong in that MDN Count Words example..
this.parentNode
DOM access should be done in theconnectedCallback
, as the DOM might not even exist when theconstructor
runs<p is="word-count"></p>
Will never work in Safari, because Apple only implemented Autonomous Elements and (for the past 5 years) has strong arguments to not implement Customized Built-In ElementsThese APIs are all very low-level and using them directly isn't all that practical. I usually prefer creating some simple wrappers around them, small and simple enough that I can just copy-paste them into any random project without having to worry about updating them.
For the
HTMLElement
class I've created this "improved" version that takes care of as much of the typical preamble without sacrificing too much flexibility or building a whole new framework.Low-Level ??
They are part of the JavaScript engine, no lower than an Array or any other API
You can "improve" your code:
to
MDN append documentation
You should add
webcomponents
tag to your article too.Thanks! will be adding it right away.
web components are losing steam? :O
Yes, they do.
They don't run on coal like Frameworks, they are part of JavaScripts' core technologies, thus run on modern power. No steam required any longer.