> Kill Firefox before they could kill HTML Imports
I’m not sure I understand the hostility here. Isn’t the point of the web to be open standards that reach consensus?
If Web Components are so great, why am I not using them?
171–180 of 189 posts
Re: If Web Components are so great, why am I not using them?
#172I used Lit in a client project, which still seems to be the most common way to author web components. Styling and composition was really hard, much harder than in typical React, Vue or Svelte projects.
It is future proof to build the atoms of a design system as web components (e.g. sliders, buttons and so on), but component composition is better done in a proper framework (e.g. Vue). This way companies could more easily start new projects with their existing design system, independent of the framework.
I wouldn’t consider building a complex applications with Lit again, just the design system atoms.
Re: If Web Components are so great, why am I not using them?
#173Web components don't solve any of the problems day-to-day devs ACTUALLY care about.
Encapsulation and ease of reusability / configuration?
Just as an example - a widget to manage a list of number ranges. Build it up like a form element - it provides a value prop with the type ‘[number,number][]’
You need to display the current collection of min/max pairs, and add / remove / edit the collection - it’s essentially a mini CRUD component.
There is no default html element that provides this functionality - you need an ordered list of pairs of number inputs, a confirm changes button, a ‘add new’ and ‘remove this entry’ button - you need a whole collection of stuff to provide the functionality.
But once you’ve got it all worked out, wrap it in a web component and you can use it in 8 different places across your admin tool - ‘’ and boom, you’re ready to go.
Using web components to define a library of common interface elements works just fine.
Re: If Web Components are so great, why am I not using them?
#174Earlier quoted context omitted.
Most of the time you have the tab and the panel to display the content of the tab a super simple demo implementation of something like this https://web.dev/components-howto-tabs/ In regards of slots, they are a nice way to allow a user of you webcomponent to overwrite/replace parts of your component with something else. This is most of the time a more advanced feature and I find it quite nice to build headless compon…
> Most of the time you have the tab and the panel to display the content of the tab a super simple demo implementation of something like this https://web.dev/components-howto-tabs/ That's exactly what I'm saying is bad. Why does the user of the howto-tabs have to type "slot='panel'" when that information is already communicated by the fact that it's a "howto-panel" inside a "howto-tabs"? This is a useless leaking of…
you can just have an unnamed slot. I'm probably missing something here haven't build a tabs thing in a long time. But just trying this out for a couple of minutes the thing you want seems to be possible. I didn't do any styling here and the code is just something I hacked down to test it. Where hn-tabs is your tab-area and hn-tab your tab-
class HnTabs extends HTMLElement {
constructor() {
super();
this._tabs = {}
this.attachShadow({ mode: 'open' })
const ul = document.createElement('ul')
this.shadowRoot.appendChild(ul)
const slot = document.createElement('slot')
this.shadowRoot.appendChild(slot)
slot.addEventListener('slotchange', () => {
ul.innerHTML = ''
const tabs = Array.from(this.querySelectorAll('hn-
if (!tabs.some((tab) => tab.hasAttribute('active')
tabs[0].setAttribute('active', '')
}
tabs.forEach((tab) => {
const li = document.createElement('li')
li.innerText = tab.getAttribute('text')
ul.appendChild(li)
li.addEventListener('click', (e) => {
tabs.forEach((t) => t.removeAttribute('active'
tab.setAttribute('active', '')
})
})
})
}
}
customElements.define('hn-tabs', HnTabs);
class HnTab extends HTMLElement {
static get observedAttributes() {
return ['active'];
}
constructor() {
super()
this.attachShadow({ mode: 'open' });
this._slot = document.createElement('slot')
this.shadowRoot.appendChild(this._slot)
this._slot.style.display = 'none'
console.log(this.slot)
}
attributeChangedCallback() {
this.#activeStatus()
}
connectedCallback() {
this.#activeStatus()
}
#activeStatus(){
const active = this.hasAttribute('active');
this._slot.style.display = active ? 'block' : 'none'
}
}
customElements.define('hn-tab', HnTab);Re: If Web Components are so great, why am I not using them?
#175Earlier quoted context omitted.
meanwhile Im like... 1
Meanwhile I’m like… That’s a Content Security Policy violation.
2 men are having lunch, one complaints that he always has cheese on his sandwiches. The other says, just ask your wife for something else? He responds: I always make it myself.
Content-Security-Policy: script-src 'self'; script-src-attr 'unsafe-hashes' 'sha256-9lIp1merGZMC6sfoM+OcgpSSRJJr18teLzyFangr0FY='
Re: If Web Components are so great, why am I not using them?
#176Earlier quoted context omitted.
> The shadow DOM can inherit styles if you specify the styles that you want to inherit. Ah yes, I've heard about this "mixing CSS into your HTML". The entire point of CSS is that you can write selectors that can affect anything, import it in the header, and you're done. If you're telling me I have to import a new CSS file (or repeat myself and import the same CSS file) inside of every custom element I create, obvious…
> Consider: if I'm distributing a library of web components, which of my users' CSS files that I know nothing about do I include? If you are distributing a library of web components, wouldn't you provide a CSS api for the things that are supposed to be styleable via CSS custom properties and styleable parts? Case in point: consider Shoelace. > a completely useless non-solution Consider the existing libraries of web c…
> If you are distributing a library of web components, wouldn't you provide a CSS api for the things that are supposed to be styleable via CSS custom properties and styleable parts?
If you read my previous comments you'll see that the parts that should be styleable--i.e. the content of the component I've defined--are user-defined, so no, I can't document them.
> Consider the existing libraries of web components — Shoelace for something generic, RedHat's Patternfly or Adobe's Spectrum for something company-specific. How much of a non-solution are they, really?
If you read what I said in context, I'm not saying components are useless, I'm saying the unstyled shadow DOM is a completely useless non-solution to the problem I've described.
Re: If Web Components are so great, why am I not using them?
#177Earlier quoted context omitted.
I don't have a problem with the idea of making each component have a render function which can be called whenever you need to render or re-render the component and I concede that there is some elegance in being able to construct a complex HTML component using a single template string. But you don't need React to do this. This idea of rendering a component whenever its internal state changed existed long before React.…
And yet the adoption shows that plenty of people see reasons not to use plain Web Components.
Just like how plenty of people see reasons to start wars and waste tax payer money on bureaucracy. Or why billions of people choose to join one religion instead of another... All logical right?
How do you explain different religions being very popular and yet contradicting each other on many critical points? They can't both be right if they contradict each other yet they may both be hugely popular...
Re: If Web Components are so great, why am I not using them?
#178 ARE all Web Components, and have been for many moons so Browser vendors could implement their own UI.
So everyone using a Browser *IS* using Web Components.
It just took some years for the technology to be opened up with the Custom Elements API to us mortals here in Userland.
Re: If Web Components are so great, why am I not using them?
#179Earlier quoted context omitted.
Most of the time you have the tab and the panel to display the content of the tab a super simple demo implementation of something like this https://web.dev/components-howto-tabs/ In regards of slots, they are a nice way to allow a user of you webcomponent to overwrite/replace parts of your component with something else. This is most of the time a more advanced feature and I find it quite nice to build headless compon…
> Most of the time you have the tab and the panel to display the content of the tab a super simple demo implementation of something like this https://web.dev/components-howto-tabs/ That's exactly what I'm saying is bad. Why does the user of the howto-tabs have to type "slot='panel'" when that information is already communicated by the fact that it's a "howto-panel" inside a "howto-tabs"? This is a useless leaking of…
use: slotAssignment: 'manual'
Re: If Web Components are so great, why am I not using them?
#180Earlier quoted context omitted.
> Most of the time you have the tab and the panel to display the content of the tab a super simple demo implementation of something like this https://web.dev/components-howto-tabs/ That's exactly what I'm saying is bad. Why does the user of the howto-tabs have to type "slot='panel'" when that information is already communicated by the fact that it's a "howto-panel" inside a "howto-tabs"? This is a useless leaking of…
you can just have an unnamed slot. I'm probably missing something here haven't build a tabs thing in a long time. But just trying this out for a couple of minutes the thing you want seems to be possible. I didn't do any styling here and the code is just something I hacked down to test it. Where hn-tabs is your tab-area and hn-tab your tab- class HnTabs extends HTMLElement { constructor() { super(); this._tabs = {} th…
Unless you are still in the IE world (which is challenging when using WCs), use one `append` instead of multiple `appendChild`