3 ms·

The problem with encapsulated components is you surrender flexibility. For example, “components” for things like buttons and checkboxes are straightforward enou

The problem with encapsulated components is you surrender flexibility. For example, “components” for things like buttons and checkboxes are straightforward enough. But what about a checkbox-list? And how does that component accept data for data-binding purposes? Another place where “components” generally fall-over is when a component needs to act as a parent or container for arbitrary markup: yes, there’s the “slot” system but those are still defined and controlled by the component, not the consumer - even though ultimately it’s the consumer’s application. I compare the situation to the component ecosystem for VB6 and WinForms - which to be fair was a lot worse as consumers often had little to no control over how those components rendered, appeared or behaved - but (no pun intended) elements of the same problem exist today. Another example is WPF - which has major unaddressed issues still - which to be fair is worlds apart from WinForms in terms of what it’s templating system is capable of. A nice thing about WPF was that a component (Control’s) XAML was transparent and editable at design-time in VS, so the consuming application’s developer could get what they want out of it, the catch was that WPF templates are horrendously complex: getting VS to expose the XAML for even a <Button> would dump 50KB+ of markup into your application XAML because it was an all-or-nothing system and you needed XAML for every button state and behaviour - right down to the pulsating button glow effect that was only ever used in Windows Vista...

nateroling 6y ago
Isn’t the answer... more components? If the more complex components are themselves composed of a small number of simple components, you can replicate them with your own tweaks.
claviska 6y ago
It's not always easy to provide a good dev exp with complex components, but it's not impossible. Using composition wisely can offer endless flexibility while maximizing code reuse. For example, Shoelace's <sl-select> component mimics the browser's <select> component. It has single select, multi-select, size variations, shape variations, type-ahead selection, validation states, etc. This component is a composition of <sl-dropdown>, <sl-input>, <sl-menu>, etc. and its entire source is less than 500 LOC (including doc comments and prettier formatting). This is significantly less than many independent <select> alternatives I've seen, and the component itself doesn't have to worry about positioning, styling, etc. because that's handled by lower-level components. > Another place where “components” generally fall-over is when a component needs to act as a parent or container for arbitrary markup: yes, there’s the “slot” system but those are still defined and controlled by the component, not the consumer - even though ultimately it’s the consumer’s application. With web components, slotted content stays in the light DOM and is therefore controlled by the user. It's actually kind of a pain point when building them because, internally, you don't have that much control over arbitrary markup. (You can access markup through slot.assignedNodes() and style things with ::slotted() but it's not what I'd call a first-class experience for component developers.)

nateroling 6y ago

Isn’t the answer... more components? If the more complex components are themselves composed of a small number of simple components, you can replicate them with your own tweaks.

claviska 6y ago

It's not always easy to provide a good dev exp with complex components, but it's not impossible. Using composition wisely can offer endless flexibility while maximizing code reuse. For example, Shoelace's <sl-select> component mimics the browser's <select> component. It has single select, multi-select, size variations, shape variations, type-ahead selection, validation states, etc. This component is a composition of <sl-dropdown>, <sl-input>, <sl-menu>, etc. and its entire source is less than 500 LOC (including doc comments and prettier formatting). This is significantly less than many independent <select> alternatives I've seen, and the component itself doesn't have to worry about positioning, styling, etc. because that's handled by lower-level components. > Another place where “components” generally fall-over is when a component needs to act as a parent or container for arbitrary markup: yes, there’s the “slot” system but those are still defined and controlled by the component, not the consumer - even though ultimately it’s the consumer’s application. With web components, slotted content stays in the light DOM and is therefore controlled by the user. It's actually kind of a pain point when building them because, internally, you don't have that much control over arbitrary markup. (You can access markup through slot.assignedNodes() and style things with ::slotted() but it's not what I'd call a first-class experience for component developers.)