I've been viewing several web component crash courses lately, and I find this video to be the most clear and easy to understand. Thank you for doing this!
I've been looking for the definition of Shadow Root DOM and examples to use it. But this video is one of the most clear and easy to understand. Thank you for doing this!
BIG CONGRATS - that was a very informative and interesting video!! I just begin to learn JS and it makes me even more want to learn it from the ground up!
Nice video, very succinct into to the topic. I especially liked using getters and setters for working with attributes. The one one assertion you make that I would challenge is performance. We have found that our custom elements are much faster than our previous vue.js and react implementations. I 100% agree they are more verbose and as a team there are more decisions to be made such as unbundled or bundled.
At 2:45 you are talking about problems caused by using innerHTML, and it should not be used in complex applications. So how would it be implemented in the much more efficient way? What would you recommend?
Hi Raven, that takes us down the path towards something like a Virtual DOM which React and Vue use, or Tagged template literals which LitElement uses if we're looking for the best implementation. We basically start to reinvent these if looking to improve on innerHTML. These allow us to update just the parts that have changed rather than refreshing the whole DOM of our component.
Actually it is pretty easy. You put the count inside a or any other suitable element. Get a reference to it. Then instead of rendering the innerHTML of the component you just change the innerHTML of the . Normally you use the this.shadow.innerHTML only one time. Then attach listeners to the elements you need and references to the elements you want to change. Have a look at codepen.io/webosm/pen/QWNeVyg for something similar and usefull as a little template.
hiya - my go to is Lit (lit.dev/) when it comes to web components. They use Tagged Template Literals to ensure good performance. Worth checking out for sure.
great video! I'm wondering, why would be better to use some framework rather than sticking with the vanillajs and web components? i thought that actually the vanilla way would present better performance as it has less levels of abstraction (and dependencies). kinda more "low level"
Thanks I was lucky to run into this (it's rare to see things like this.-it's always about framework marketing that put people on the shoulders of giants and make them move from ground up again, when the giant falls). For the eventListner, maybe creating another function and calling it inside this.render, just after inserting the html would have been better. What you've just explained seem to be the core concept behind these frameworks.
Hi Ted, by default everything is blacklisted and can't penetrate into DOM. We can whitelist though by using CSS variables, and Shadow Parts are 2 options. I've a couple of videos on these :-)
hiya - this is all enclosed within backticks (you can see on the line above it ends with a backtick). So this allows us to have a multiline string and also use interpolation (the part with ${this.count) )for variables compared to using double quotes where we have to use a plus to add them in and then reopen the quotes again. Cheers Mark
So, I was a bit disappointed with react ssr, I decided to investigate how I could make a PWA 100% Javascript Vanilla with WebComponent and Shadow dom, so you would have any suggestions where I could start to organize and structure a 100% Javascript Vanilla application for a PWA?
Hi Alexon, it's a tricky one for sure, so far I've stuck with the frameworks and only looked at vanilla conceptually, so can't give much help here afraid. Cheers Mark
I'd suggest wrapping document.createElement with a function that allows you to do stuff like: const scrollTop = ce("div.scrollTop", document.body, { style: {position: "fixed", bottom: 0, left: 0, willChange: transform}, click(e) { window.scrollTop = 0; } }) i made it so.. if you don't know how, I'll show you the.. dunno.. 30 lines i think. this would allow you to create html elements without relying on innerHTML and would ensure you stay in control of your elements. if you construct a dom through that, you don't even need to use stuff like querySelector.
this may come in handy. i am converting a legacy Add-on (FiltaQuilla) for Thunderbird 78 and need to remove remaining xbl bindings - it ain't easy. Add-ons usually don't use frameworks so i need to keep it pure JS (unless Mozilla has a framework) moving away from XUL to HTML is hard as we loose a lot of good functionality that needs to be reimplemented.
please pardon me if this sounds very basic however I failed to understand why was an attribute used to hold the variable instead of an html tag ? I was left wondering if this was a limitation of web components or if this is the correct way to do this and why ? Also can these custom components hold value or text as they very much looks like normal html tag. So do they behave like normal html tags.?.. Once again pardon if these are basic questions as I just started learning js. I appreciate the content provided and simplicity through which the concept was explained since I was able grasp most it despite being a beginner.
Could you not have created the button as a single element in `render` and create a property for `button` at the same time - which means there's no need for `querySelector`?
We can add to the style header within the component is one way as the component author. To apply a theme from outside the component, e.g. as a user of the component then we are looking at things like custom properties ( as these can pierce the ShadowDom ) or CSS Shadow Parts can do this for us also - but not standard across browsers yet I think. Cheers Mark
@@Ashotofcode thanks, I'll try it out again. The last time it didn't work. I thought elementRef was not working on typescript as works in vanilla. I have thought to use something like polymer or stencil
not familiar with HTMLelement, so this might be a dumb question, but is this doable functionally? I have snobbish disdain for oop, I know, I'm the worst
with due respect, I don't understand the hustle. This is how you code in a formal language. It's not gonna be slow. It's not gonna be difficult to maintain if you architect it properly in a modular way. It's way easier to understand what is happening, for nothing is hidden, and as you build your app you'll end up writing less and less code for every new component. Yes, It'll look like a "framework" of your own, but it's gonna be simpler because it's gonna be tailored to your needs and nothing will be there "just in case you need it". I've written big apps in vanilla js starting before jqery ever existed, and no problem whatsoever. The thing with the frameworks and libraries (which I use as well, following the industry common uses) is to have people writing code over a pattern not really having to know much. Great video BTW! cheers.
Web components only exists in plain javascript. That's the main advantage. No need for any immature framework, that evolves too quickly, with code breaking changes every 6 months. Browsers won't support typescript.
While i don't disagree libraries can make things more efficient by taking care of the micromanagement for you (that's what libraries/frameworks do after all), I'm not sure if you are intentionally writing this super long just to get your point across. 1. Why do you need shadow root for this example? 2. If you need to access count and intend to use the attribute as your source of truth, why go thru so many hoops with so many life cycle methods and getters and setters? just just use this.getAttribute('count') every time you need it, no need to observe it and then set it to another variable. This is way over complicated. 3. And the click listener.... a. instead of just querySelector('#btn').addEventListener... you had to make it 2 lines by putting it to a variable and then var.addEventlistener. b. The worst thing you did, calling it after this.render() and then repeat it again in attributeChanges. Dude, just call it once INSIDE the render function after you set the innerHTML. c. You don't have to bind it if you just call it inside an anonymous arrow function. React class components have the same issue, this has nothing to do with web components. You can write the same functionality with a lot less code even without any library. This is exaggerated. You made this harder than it needs to be.
I've been viewing several web component crash courses lately, and I find this video to be the most clear and easy to understand. Thank you for doing this!
Thanks Brad! glad it was of use
Great video.
Many people over-complicate very quickly, but this was concise quick and easy to understand!
I've been looking for the definition of Shadow Root DOM and examples to use it. But this video is one of the most clear and easy to understand. Thank you for doing this!
Awesome, thank you! Cheers Mark 🙂
This true teacher is a five star.
Congratullations.
Thanks! Glad was useful Bernardo 😀
good pace, good voice , good accent , and most importantly Great font size,
👍
Thank you! 😃
Great! You have reinvented the ... framework/library.
Indeed! 😁
BIG CONGRATS - that was a very informative and interesting video!!
I just begin to learn JS and it makes me even more want to learn it from the ground up!
Good job! A very precise and concise explanation, you rock!
Thank you kindly!
we need more video like this
Thanks :-)
amazing video and really easy to follow, I am surprised you don't have more subscribers
Glad you liked it! Cheers Mark
Nice video, very succinct into to the topic. I especially liked using getters and setters for working with attributes. The one one assertion you make that I would challenge is performance. We have found that our custom elements are much faster than our previous vue.js and react implementations. I 100% agree they are more verbose and as a team there are more decisions to be made such as unbundled or bundled.
Fair point thanks Eric - as long as your render is performant then very true I think. Cheers Mark
So what is a better way to handle the innerHTML thing?
Lit 🙂
At 2:45 you are talking about problems caused by using innerHTML, and it should not be used in complex applications. So how would it be implemented in the much more efficient way? What would you recommend?
Hi Raven, that takes us down the path towards something like a Virtual DOM which React and Vue use, or Tagged template literals which LitElement uses if we're looking for the best implementation. We basically start to reinvent these if looking to improve on innerHTML. These allow us to update just the parts that have changed rather than refreshing the whole DOM of our component.
@Raven Dark Lit-html is very efficient and can be easily integrated into vanilla JS
Actually it is pretty easy. You put the count inside a or any other suitable element. Get a reference to it. Then instead of rendering the innerHTML of the component you just change the innerHTML of the . Normally you use the this.shadow.innerHTML only one time. Then attach listeners to the elements you need and references to the elements you want to change. Have a look at codepen.io/webosm/pen/QWNeVyg for something similar and usefull as a little template.
What do you recommend reading about and learning instead of innerHTML?
hiya - my go to is Lit (lit.dev/) when it comes to web components. They use Tagged Template Literals to ensure good performance. Worth checking out for sure.
You have been a real life saver!! Thank you so much. Subscribed!
The API is just INSANE!
Indeed!
Oh, man! You're the best! You've just gotten a new subscriber.
Thanks Paulo :-)
Excellent info to get a foundation. I understand how they work inside, now I just need a how to use them outside 😁
Glad it was helpful Sazaraki! Cheers Mark :-)
Thumb up. Although the missing part here is disconnectedCallback and removeEventListener :)
Thanks - yes those are important for sure :-)
Oh man, this has been really useful. Thank you for sharing!
Glad it was helpful Gideon :-)
great video! I'm wondering, why would be better to use some framework rather than sticking with the vanillajs and web components? i thought that actually the vanilla way would present better performance as it has less levels of abstraction (and dependencies). kinda more "low level"
Good question! Mainly speed of development and not reinventing the wheel I would say are why I use LitElement. Cheers Mark
Thanks for the video. I got a question if you don't mind.
13:37 Why is it that when it's inner HTML you can't add event handler directly on the html?
hiya - I don't think innerHTML gets parsed the same as on page load and the events are not noticed as such. Cheers Mark
Thanks I was lucky to run into this (it's rare to see things like this.-it's always about framework marketing that put people on the shoulders of giants and make them move from ground up again, when the giant falls). For the eventListner, maybe creating another function and calling it inside this.render, just after inserting the html would have been better. What you've just explained seem to be the core concept behind these frameworks.
Hi Darlington, thanks, glad it was helpful, the render function yes that might be cool :-) Cheers Mark
gotta look more into shadow dom, are we able to blacklist most css but selectively pass specific rules (like font)?
Hi Ted, by default everything is blacklisted and can't penetrate into DOM. We can whitelist though by using CSS variables, and Shadow Parts are 2 options. I've a couple of videos on these :-)
Love it! Crystal clear
Thanks Mithat🙂
Nice video. at 3:25 you are writing the body of the render method. The Counter is not encapsulated in double quotes. Why is that?
hiya - this is all enclosed within backticks (you can see on the line above it ends with a backtick). So this allows us to have a multiline string and also use interpolation (the part with ${this.count) )for variables compared to using double quotes where we have to use a plus to add them in and then reopen the quotes again. Cheers Mark
So, I was a bit disappointed with react ssr, I decided to investigate how I could make a PWA 100% Javascript Vanilla with WebComponent and Shadow dom, so you would have any suggestions where I could start to organize and structure a 100% Javascript Vanilla application for a PWA?
Hi Alexon, it's a tricky one for sure, so far I've stuck with the frameworks and only looked at vanilla conceptually, so can't give much help here afraid. Cheers Mark
I'd suggest wrapping document.createElement with a function that allows you to do stuff like: const scrollTop = ce("div.scrollTop", document.body, { style: {position: "fixed", bottom: 0, left: 0, willChange: transform}, click(e) { window.scrollTop = 0; } })
i made it so.. if you don't know how, I'll show you the.. dunno.. 30 lines i think.
this would allow you to create html elements without relying on innerHTML and would ensure you stay in control of your elements.
if you construct a dom through that, you don't even need to use stuff like querySelector.
this may come in handy. i am converting a legacy Add-on (FiltaQuilla) for Thunderbird 78 and need to remove remaining xbl bindings - it ain't easy. Add-ons usually don't use frameworks so i need to keep it pure JS (unless Mozilla has a framework) moving away from XUL to HTML is hard as we loose a lot of good functionality that needs to be reimplemented.
I really liked the video, could you make a video explaining a little more about shadow dom?
Hi Fernando, I'm looking to make one on the new declarative shadow dom for sure soon 😎
i liked your explained, congrat
Thanks Lucas! 😃
please pardon me if this sounds very basic however I failed to understand why was an attribute used to hold the variable instead of an html tag ? I was left wondering if this was a limitation of web components or if this is the correct way to do this and why ? Also can these custom components hold value or text as they very much looks like normal html tag. So do they behave like normal html tags.?.. Once again pardon if these are basic questions as I just started learning js. I appreciate the content provided and simplicity through which the concept was explained since I was able grasp most it despite being a beginner.
Could you not have created the button as a single element in `render` and create a property for `button` at the same time - which means there's no need for `querySelector`?
Thanks for the video
No problem! Cheers Mark
This is really awesome thank you so much!
How would you publish this as a package to npmjs?
how do we apply styles to our component?
We can add to the style header within the component is one way as the component author. To apply a theme from outside the component, e.g. as a user of the component then we are looking at things like custom properties ( as these can pierce the ShadowDom ) or CSS Shadow Parts can do this for us also - but not standard across browsers yet I think. Cheers Mark
This was great!!
Thanks :-)
I love web components, wish they would catch on!
Yeah one day maybe.. Cheers Mark
onde eu posso pegar o seu condigo de exemplo.... para ver se funciona, se é algum erro de digitação... faz todo processo e não atualiza na tela,
Can I create web component using TypeScript? (no frameworks), just like with Vanilla as you have done
Hi Carlos, for sure yes, the typescript will simply compile into javascript and then you are good to go with no framework in sight :-)
@@Ashotofcode thanks, I'll try it out again. The last time it didn't work. I thought elementRef was not working on typescript as works in vanilla. I have thought to use something like polymer or stencil
not familiar with HTMLelement, so this might be a dumb question, but is this doable functionally? I have snobbish disdain for oop, I know, I'm the worst
Great video, Thanks.
Where the css? Great vídeo!
Hi Thiago, no css in this one to keep it simple, but if we added it would slot into the innerHtml with a style tag is one option. Cheers Mark
with due respect, I don't understand the hustle. This is how you code in a formal language. It's not gonna be slow. It's not gonna be difficult to maintain if you architect it properly in a modular way. It's way easier to understand what is happening, for nothing is hidden, and as you build your app you'll end up writing less and less code for every new component. Yes, It'll look like a "framework" of your own, but it's gonna be simpler because it's gonna be tailored to your needs and nothing will be there "just in case you need it".
I've written big apps in vanilla js starting before jqery ever existed, and no problem whatsoever. The thing with the frameworks and libraries (which I use as well, following the industry common uses) is to have people writing code over a pattern not really having to know much. Great video BTW! cheers.
Good points well made thanks Adrian 😀👍 Cheers Mark
wow thank you!
No problem Dio 😊Cheers Mark
Hai, very nice video can you link the code for this video
D'oh sorry think that code is gone now
Web components only exists in plain javascript. That's the main advantage. No need for any immature framework, that evolves too quickly, with code breaking changes every 6 months.
Browsers won't support typescript.
Fair point thanks 😀
Até que atuliza, mas não faz o render novamente....
I didn't get anything.!!
Let's always do alot of good
Cheers!
gem
Thanks :-)
While i don't disagree libraries can make things more efficient by taking care of the micromanagement for you (that's what libraries/frameworks do after all), I'm not sure if you are intentionally writing this super long just to get your point across.
1. Why do you need shadow root for this example?
2. If you need to access count and intend to use the attribute as your source of truth, why go thru so many hoops with so many life cycle methods and getters and setters? just just use this.getAttribute('count') every time you need it, no need to observe it and then set it to another variable. This is way over complicated.
3. And the click listener....
a. instead of just querySelector('#btn').addEventListener... you had to make it 2 lines by putting it to a variable and then var.addEventlistener.
b. The worst thing you did, calling it after this.render() and then repeat it again in attributeChanges. Dude, just call it once INSIDE the render function after you set the innerHTML.
c. You don't have to bind it if you just call it inside an anonymous arrow function. React class components have the same issue, this has nothing to do with web components.
You can write the same functionality with a lot less code even without any library. This is exaggerated. You made this harder than it needs to be.
As opposed to strawberry JS? 😂
Much easier with AlpineJS 😜
For sure :-)
another mess
Could be!