3 ms·
Really enjoyed this article. Web components seem promising, I played around with them a bit but I found it difficult dealing with global styling (ie, how do I m
by LAC-Tech 5y ago
Really enjoyed this article. Web components seem promising, I played around with them a bit but I found it difficult dealing with global styling (ie, how do I make my component have the same colour scheme as everything else?).
Probably worth looking into again.
I also concur with the author about lit-html. It does one thing and does it really well, easy to understand, and no transpiling needed. Can't recommend it enough for generating dynamic html client side.
- claviska 5y agoIf you’re using a shadow root, look into CSS Custom Properties which poke through it and the HTML part attribute as well as its corresponding CSS :part() selector.
- xigoi 5y agoReading the MDN documentation for parts, how are they different from classes?
- claviska 5y agoThey are both DOMTokenLists so parts look a lot like classes. The difference is parts are used in a shadow root to expose internal elements for styling. I’ve written a bit about CSS parts here: https://www.abeautifulsite.net/posts/when-to-create-css-parts/ https://www.abeautifulsite.net/posts/when-to-create-css-part...
- wrnr 5y agoI've come to the conclusion that web components (with or without shadow roots) are not the best "elementary particle" to build a webapp out of. Most of the time you want simple divs and sometimes you want custom-tag. The important thing is to have a setup where you can quickly promote a component into a web component proper. I think solid.js has a nice solution this, where you just call a function that wraps the component into a web compoent and registers a tag for it. One issue I have with lit is that it just forces you to turn everything into a web component instead of a carefully deliberated choice.
- LAC-Tech 5y agoWhat's the threshold for you, where something needs to be a web component? Honestly I just like the idea of making my own HTML tags and being able to do more with markup.
- azeirah 5y agoI'm thinking of things that satisfy these three criteria 1. Need to be configurable 2. Are meant to be used many times through an application 3. Are not easily built using regular html For point one, take a loot at input[type="text"] html5 elements for instance. Placeholders, validation, size, stylability, errors. Similarly, the video tag. Volume, play pause, size, quality, playback speed, compatible formats, much more. For point two and three, you could for instance make a Login component, to encapsulate your authentication form into a component, but this is easily achieved using regular html forms. Also, you're most likely only going to use it once or twice. So what are good examples? A sparkline component, this is a type of an inline graph. A markdown or html editor component. Custom interaction or input components. Consider for instance where you're working on an audio mixing application. A rotatableKnob element is an elementary input here.
- wrnr 5y agoOnly web components if you don't control the rest of the page, like someone embedding your component on their page, but I would still give them the control to name the component. That is a lot of work just so you can write my-tag instead of .className in your css file. I think the react way of styling each component inline is the way to go.