Show HN: I made helpers for Web Components
github.com
github.com
I'm convinced that web components (and the tech that makes up web components) will eventually find its place in everyday web development. That said, I do think people are making a mistake when they try to use it as a one-to-one replacement for react.
Also, I hope that people don't try to implement 'reactivity' in the React way for Web Components... The correct way to handle state changes in Web Components is by changing their attributes and setting up an attributeChangedCallback inside the component (with an observedAttributes getter which lists out the observed attributes).
Some people won't like that you can only pass string values to components via attributes (unlike React where you can pass anything) but I swear, if you adapt and force yourself to only pass string values (or stringifiable values), your application architecture will massively benefit. You can still select components and call custom functions/methods on them which lets you pass any value, but I would recommend against for most situations.
Attributes are good for handling data going inbound into the component. For outbound data (in the other direction), you should use DOM events. Look into the `bubbles` option when dispatching events. This can be very useful sometimes as it gives you a lot of flexibility; it means that any parent element at any level in the hierarchy can access the data which bubbles up from the child component.
You don't want to update the component on every attribute change as the component might have multiple attributes so you need to batch the changes. Then when changing you also don't want to discard the whole rendered component and render it again. With those 2 things you have React, or much better, without a vdom: LitElement + Lit-html.
It’s not like it’s “compatible” but a different thing, Lit is actually a standard web component the same way as a vanilla one might be.
The only difference is that you extend a different base class instead of HTMLElement, but Lit also extends HTMLElement, they just give you a massive quality of life upgrade when it comes to boilerplate and other developer experience factors and it only costs you like 5kb.
To the point that I think it’s generally a bad idea to extend HTMLElement directly. It’s very very rarely a good trade off though exceptions obviously exist.
If anyone is curious to see what I mean https://lit.dev/docs/
The render lifecycle works best when everything is already in memory. Fetching data based on state updates is tricky. Tasks are supposed to fill this gap, but are still a bit clunky:
https://lit.dev/docs/data/task/
The most reliable approach for me has been to batch api calls and state updates manually in a separate method on the element, and let lit focus only on rendering.
Would love one that does two-way binding.