[HN Gopher] Show HN: I made helpers for Web Components
___________________________________________________________________
Show HN: I made helpers for Web Components
Author : mfcc64
Score : 40 points
Date : 2024-07-21 09:09 UTC (13 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| astraloverflow wrote:
| Nice to see more web component stuff.
|
| 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.
| hooverd wrote:
| We use them for footers. The brand team can maintain them and I
| slap the WC link on whatever I'm doing.
| impostervt wrote:
| Looks like the beginnings of something like lit elements.
|
| Would love one that does two-way binding.
| meiraleal wrote:
| Lit-html is such a great piece of code. It should be part of web
| components standard.
| vim-guru wrote:
| 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.
| mdhb wrote:
| 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.
|
| If anyone is curious to see what I mean https://lit.dev/docs/
| mock-possum wrote:
| A thousand percent agree. Web components are so much better
| with a little lit in the mix
| oneshtein wrote:
| IMHO, van-element is much simpler.
| cryptica wrote:
| 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.
___________________________________________________________________
(page generated 2024-07-21 23:08 UTC)