Видео

Ah crap, sorry I missed that! I'll do better in the next one!

EXCELLENT suggestion!

The reason I don't do that is because, frankly, I think the "react way" of building most UI is bad. It adds a LOT of extra complexity under the guise of scalability and simplicity.

@@gomakethings Good point.

For me, that threshold is usually when I have multiple pieces of UI all modified by the same piece of data or state. Below that threshold, state-based UI often feels like more work.

@@gomakethings That's helpful criteria, and is what I'm experiencing with keeping an 's DOM and the representation of that DOM with a UI in sync.

Thank you!

That's correct! In most state-based UI libraries, a signal detects changes to its value and automatically causes a render to happen.

Happy to keep creating them. Really appreciate the kind words!

I absolutely love HTML-only stuff like that. And I totally see it. Links, with a few dozen HTML files for the various combinations that could exist.

I won't hold it against you that you pronounce GIF wrong ❤

I plan to keep making them. Thanks so much!

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

Oh shit, I totally misspoke. I meant to say "I like to use let for everything." That hilarious, actually! 😂😂😂

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

@@terrencemoore8739 Thanks for the kind words, and that's AWESOME to hear!

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

I do it all the time. Never run into an issue before.

@@gomakethings My bad, u cant append elements to a CE inside the constructor but you can to the shadowRoot...

@@cloudpuncher4615 You can do that, too. Here's a demo: gist.github.com/cferdinandi/39774222f289c2d6eee22282350e0eea

@@gomakethings Thanks for the reply.... it appear that you can (in chrome) only if you put the <script> after the Custom Element lest you get this error .."Uncaught DOMException: Failed to construct 'CustomElement': The result must not have children"... .For whatever reason it will append to a shadowRoot or append during the during the Custom Element upgrade. You can just do it with connectedCallback() no issues but it would be nice to just create elements and pass in data in the constructor..

Thanks for the kind words, David!

My main issue with development is components are supposed to be reusable, but in frameworks, all of my code eventually gets deprecated by the framework. Meanwhile, that one lazy load function I wrote in vanilla JS has lasted 10 years hahha. I'm really glad I found this channel!

Cheers KB!

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.

@@bourge I wonder if you're seeing flashes of unstyled content, or if the Web Components are being replaced and re-rendered because of hydration.

@@gomakethings it is the rerendering during hydration. I heard that a new spec called declarative shadow dom could help. I wish though that NextJs would better support web components.

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.