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.
I'm convinced that plain web components are now the best solution for the front end.
That said, I don't think any libraries are needed to use them well.
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.
> 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
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.
I began developing some web components without delving deeply into the mechanics of Lit and Polymer, aiming to identify gaps in the standard web components API. Early on, I created several decorators and, in hindsight, they closely resemble what Lit provides. Therefore, I might concede that Lit could become a standard. However, since I haven't used it personally, I can't fully endorse it yet.
I think there’s a bit of a misconception for people coming from other frameworks when it comes to Lit and it’s relation to vanilla web components.
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.
I agree, but I feel like there is something still missing.
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:
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.
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.