Video

He might have misspoke, I remember in one newsletter he said he used let for everything, so he might have got them switched up

Just tried making a web component without using the shadow dom, it worked great!

The source code is in the description. Maybe you're doing something that is a little off?

I'd need more specifics about the errors you're seeing to answer that.

@@gomakethings There are flash effects on every page loads. This is only for Nextjs apparently due to the way it handles hydration of the DOM.

No, that's just how DOM manipulation works in general. It's not specific to the shadow DOM (or lack thereof). If you target elements that don't exist yet, you'll get errors.

Thanks!

Historically, the Fisher-Yates shuffle produced more random results than a simple Math.random(), which tends to skew towards the middle over time. MDN used to have details about this on their site, but they're not longer there.

Thank you!

Couldn't agree more!

That's a great suggestion, thanks!

Same way you'd test any DOM manipulation component. Jest is well suited to it, I think.

I think this is a symptom of thinking about Web Components as React components rather than their own, unique thing. React has poisoned the web well. gomakethings.com/html-web-components/

Oh I totally agree that react has ruined the web.... I am massive on core web vitals and have built a web app using only native web components with html CSS and vanilla js.... That scores 100 across the board... The problem I found and if you have any suggestions is that if you mix the light Dom and the shadow dom it causes CLS... So the only way was to use web components that are self contained.

@@BenHewart Forgive me, but what does CLS stand for?

CLS (Cumulative Layout Shift) measures visual stability in Core Web Vitals. It quantifies how much elements on a page move unexpectedly as it loads. High CLS means a poor user experience, as content shifting can disrupt interactions. As the light Dom loads first and then native web components it can make elements jump about as the page loads hence I went for a full shadow dom component to fix this

Happy to show you if your interested no pressure 😉

This comes up a lot! There are two reasons: 1. The Web Component itself isn't a button. One of it's child elements is. If I wanted the custom element itself to behave like a button, I'd also need to add stuff like a `role` attribute and additional event listeners. 2. That's also unfortunately not how Web Components work. You extend the HTMLElement, then layer in your custom behavior. You can't reliably extend other element types with customElements.define(). There was a spec in the works that would let you extend native elements with custom functionality using `is` attribute. Firefox and Chromium moved forward with it, and then the WebKit team straight up refused to implement it, effectively killing the spec. developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/is My understanding is that there's a replacement spec in the works that WebKit is allegedly onboard with, but I don't know much about it at this time as it's nowhere near production ready.

Could be! Could get expensive for a public extension, of course. The whole benefit of "serverless" is that you don't have to worry about maintaining the server, just the function (or functions) that run on it.

Thanks!

I wrote a little bit about this a few weeks ago: gomakethings.com/the-different-ways-to-instantiate-a-web-component/ If you have a specific example in a code pen or GitHub repo you'd like me to look at, though, that works too!

Cheers!

You're welcome!

You're welcome! If you have any questions along the way, feel free to ask!

They're invalid, and I should probably stop doing it. In my mind, if I'm creating a custom element, I like to use custom attributes with it. An HTML validator will complain about them, but CSS and JavaScript will work with them just fine. For safety, I could also add a dash to the names to ensure no conflicts with future attribute names. I lean heavily on attributes in my web components, and having to write data-* constantly is fatiguing, IMO.

Thanks! Can you clarify what you mean by this: "ow to encapsulate the web component code within the component itself and how that then gets consumed by the HTML?" I'd be delighted to make a vide about if, once I better understand what you're asking.

Sure. What I see in these two videos is you’ve got the ‘pick-at-random.html’ file that contains ‘pick-at-random’ element and below that the JavaScript to make it work. How is this then reusable? For example, I’d like to use it on a different page, how would I go about doing that. Let me know if you’d like me to elaborate further.

@@NeilMerton Yep, that helps a lot. Thanks Neil!

That's a good suggestion, thanks!

GREAT suggestion! Let me add that to the list!

"Better" isn't the word you're looking for. "Can prevent issues in certain contexts." The problem you're describing can still happen even when using connectedCallback. There are a bunch of strategies to fix it. But in your case, DOM scripts should be loaded in the footer or use async/defer or be wrapped in a DOMContentLoaded event. What you're describing would happen if you were using plain old DOM manipulation methods, too. More on all of that here: gomakethings.com/the-different-ways-to-instantiate-a-web-component/

Thnx for the reply and extra info!

I don't like it, personally: gomakethings.com/what-about-lit-for-web-components/

Regarding the spec: it doesn't actually say that, though most people (including me, previously) interpreted it that way. "The specification recommends that, as far as possible, developers should implement custom element setup in this callback rather than the constructor." Does setup mean add/remove elements? Attach events? Something else? It's not clear. Hawk Ticehurst has a great article on this: hawkticehurst.com/writing/you-are-probably-using-connectedcallback-wrong/ What I do know is that setting up elements in connectedCallback is a bad idea, because it can lead to the same elements being rendered multiple times if an element is, for example, moved with the append() method. You can prevent it by using special .loaded properties or whatever, but just doing it once in the constructor() is, IMO, a lot more bulletproof and simple.

Regarding localStorage, there are many ways to handle it. Outside the component (with some event to trigger the behavior) is one possible solution. Calling it a mistake is disingenous, though. What you really mean is "I would have approached this differently." That's fine, of course. The best and worst thing about JS is that there's always more than one way to do a thing. But the approach I used in this unscripted first pass isn't a mistake. It's just not what you would have done.

@@gomakethings re constructor: Spec seems very clear to me. MDN: "In the class constructor... you should not add new attributes or children". HTML Standard 4.13.2: "When authoring custom element constructors... The element must not gain attributes or children." And you can prevent double loading by using methods like replaceChidren(). Hawk's post is about event listeners and not rendering child elements.

@@gomakethings re localstorage: I'm not going to sugarcoat my take for a grown man. In my opinion, it is a mistake to couple this UI component to a persistence mechanism (you know why, I know why, everyone knows why). Granted your solution is passable as a first draft for educational purposes but it can be easily improved, and should be. In my opinion.

@@netssrmrz I'm not asking you to "sugarcoat" anything. But let's be clear: your opinion is not the same thing as fact. You disliking something doesn't make it wrong. Senior developers constantly and arrogantly insisting something non-obvious is obvious is, frankly, why I have students. I'm asking you to engage in polite discussion. If you want to do the techbro reply guy thing, this isn't the right channel for you. This is the only time I'm going to say it. Next time, you get blocked.

I obviously had to keep going into the DOM a fair bit for this one, but case studies like this reinforce that it's the better approach for me: gomakethings.com/removing-react-dramatically-improves-performance-a-case-study/

Thank you for the kind words!

In theory, yes, that should be enough. In reality, it's not. 😞 Many screen reader/browser combinations will NOT announce the <title> unless you add an aria-labeledby attribute to the SVG, with a value that points to the ID of the <title>. In the end, since you're messing with ARIA anyways, aria-label is the least complicated way to do that.

@@gomakethings Only downside of `aria-label` is it isn't translatable. For buttons and links, I stick with visually hidden text, which I'm fine appearing if CSS doesn't load. For landmark elements, I use `aria-labelledby` and point it to the corresponding section heading.

@@davidluhr Agreed! I've had accessibility experts argue both approaches to me over the years. For this particular project, I went with the easiest one to implement, but probably could have discussed the tradeoffs a bit more.

Couldn't agree more! It's sad that this isn't the norm in dev education.

I'm both delighted and saddened to hear that! Glad you appreciate, but a huge bummer that most tech educators never cover it.

I could do that, yea. Historically, `Math.random()` has provided a less uniformly random shuffle than the Fisher-Yates algorithm. I'm not worried about the 473 extra bytes, personally.

@@gomakethings I wasn't worried about the extra bytes, at least not primarily. Sometimes 20%+ extra code might well be worthwhile if the code becomes more readable. But my impression was that the added complexity makes the code harder to read for people who will have to maintain it or, in this particular case, for your audience. And regarding Fisher-Yates: It may well be true that Fisher-Yates is better than other shuffling methods. But here no shuffling is needed. (And BTW, the shuffle method uses Math.random() as well.) Finally, please don't get me wrong if I appear to be nit-picking. I like your videos and I just wanted to help improving. (Unfortunately youtube has no versioning support...)

@@HeribertSchuetz I took this as a kindly discussion among peers, so no worries at all! I agree about making the code harder to read.

Thank you so much for the kind words!

1. I addressed state directly in this video already. 2. As I mentioned IN THE VIDEO, there's a part two coming that will cover loading the data. 3. There's no race conditions to worry about in this simple app. 4. This isn't a video about organizing code. 5. How about I just leave the title as is.

The Shadow DOM... 1. Adds additional complexity to the Web Component authoring experience. 2. Can introduce accessibility issues. 3. Makes components much harder to style. 4. Prevents the component from taking advantage of global styles. 5. Is often a solution in search of a problem. 6. Tries to let WC's do things "the React way," but React does those things better.

I agree with GoMakeThings. I've worked on several WC projects at various companies including building component libraries and 90% of the time we've needed to deliver highly customisable components. From my experience Shadow DOM feels like an edge case. Anyway, once you have "open" components its trivial to wrap them in a closed Shadow DOM version.

The very first paragraph on the web components documentation page immediately highlights encapsulation as its primary feature. I think you’re just trying to sound controversial by calling it an anti-pattern. It’s fine if you don’t prefer to use it that way but please don’t tell your audience they are doing it wrong. Do they make things more complex? Maybe but compared to what? Not all complexity is bad. It depends on the context.

@@cb73 Nope. I've built a LOT of Web Components. The benefits of the Shadow DOM, in my experience, are grossly outweighed by its many disadvantages. Isn't it strange how Web Components have been around for years, but only really started taking off once a bunch of folks started saying, "Hey, you don't actually need the Shadow DOM"?

Shadow dom is not all black or white. It very much depends on the functionality of your web components. Web components scope is not limited to only wrapping forms and inputs, even if in majority of cases it is.

@@pragmasoft I've been using Web Components for several years (to build full apps ;) and I agree with "Go Make Things" that shadow DOM functionality is only required in edge cases, for the same reasons he stated. Unfortunately, most tutorials overcomplicate things by appearing to make shadow DOM mandatory.

Sorry about that! I use a white background for my videos because it has better contrast and is thus a better choice for folks with certain vision issues. I do recognize the white can be intense, though.

😂 100%!

Thank you!