[HN Gopher] Show HN: Hyphen - an elegant custom element base cla...
___________________________________________________________________
Show HN: Hyphen - an elegant custom element base class with good
ergonomics
Author : keepamovin
Score : 30 points
Date : 2023-11-05 08:49 UTC (14 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| rco8786 wrote:
| I read the entire README and have absolutely zero idea what Hypen
| does (and I am a relatively experienced javascript/react
| programmer).
|
| Perhaps a 1-2 sentence explanation, plus some code examples,
| would help.
| dmix wrote:
| I didn't understand it until I looked at the index.html source
| code example (code > words sometimes) and I think it's a thin
| wrapper around Web components https://developer.mozilla.org/en-
| US/docs/Web/API/Web_compone...
|
| But don't quote me on that, I just use Vue for a living
| deanebarker wrote:
| This is correct. It's a wrapper around web components, kind
| of like Lit (which they credit in the acknowledgements).
|
| Web components are cool, but the spec is bare. This means, a
| lot of rote work gets custom implemented. There are a lot of
| frameworks popping up, trying to "standardize" this.
|
| Hyphen appears to one of these.
| dhimes wrote:
| Thank you. That would be a great leading paragraph on their
| web page if anyone from the project is reading this.
| andybak wrote:
| Me neither. "An elegant custom element base class" could relate
| to any programming language. I skim the page and see angle
| brackets - so it's browser-related.
|
| Great - but for what? Is this client-side, server-side? Does it
| relate to a specific framework or approach?
|
| I don't blame the project. They know their audience. It's the
| HN policy where extra context in the post title is forbidden
| that hurts stuff like this.
| keepamovin wrote:
| Thanks, its good feedback! :)
| keepamovin wrote:
| Point taken, good idea on the summary and code to all who
| provided that feedback. Indeed code > words sometimes!
|
| That was silly of me! I'm sorry, I'll correct that. Thank y'all
| for pointing that out! :)
| croes wrote:
| >Hyphen simplifies the creation of custom Web Components, which
| are a standard for reusable user interface elements for web
| pages.
|
| Was that part added later?
| verisimilidude wrote:
| It's really clear to me. (And I did account for the subsequent
| README commits since your comment). But that's probably because
| I already know Web Components well. I'm in the market.
|
| In the following line...
|
| > Hyphen - A custom element base class for great developer
| ergonomics.
|
| ...I would recommend adding a link on "custom element" that
| points to a definition somewhere. This might make it easier for
| skimmers to parse the meaning of this opening line.
| garrettjoecox wrote:
| I'd suggest not naming the your main interface of your library
| "$", for various obvious reasons.
| regularfry wrote:
| Obvious if you've been around long enough. I wouldn't be
| surprised if the majority of people reading this have never
| actually worked with jquery, only heard the bedtime horror
| stories.
|
| (I mean, leaving aside the fact that it's utterly
| nondescriptive...)
| andybak wrote:
| I still rather miss it. Sniff...
| dr_kiszonka wrote:
| I used jQuery in a few personal projects and it was very
| useful. It was 10 - 15 years ago, so I am sure there are
| better tools now, but for a hobbyist it was great.
| andybak wrote:
| The syntax still seems much more pleasant for DOM
| manipulation than vanillaJS. It had a nice pseudo-
| functional interface and a ton of elegant helpers.
| Whenever I do DOM manipulation in vanilla I wonder to
| myself if the API couldn't be a bit more user-friendly
| and readable.
| troupo wrote:
| For low-level-ish work (like DOM manipulation) there are
| still no better tools than jQuery
| explaininjs wrote:
| Also browser dev tools still implement $ as a
| document.querySelector sort of alias.
| morbicer wrote:
| Fair warning about the use of eval in the readme.
|
| Anyone caring about CSP headers can't use this project and that
| anyone should be everyone even though the CSP header is PITA to
| setup.
| catapart wrote:
| Odd that they chose to use the unsafe "eval", where there's a
| drop-in, safe(r) replacement with
|
| ``` const properties = Object.keys(injections);
|
| const values = Object.values(injections);
|
| htmlString = new Function(...properties, 'return `' +
| templateString + '`')(...values);
|
| ```
|
| Other than that weirdness, this is a pretty sweet little library!
| I've already built my own version of it, so it's nice to see a
| lot of the same techniques I used re-applied here. Definitely
| feels like doing something right if other people are thinking
| along the same lines!
|
| I hope this more project sees more utility than mine! I
| backpedaled on the idea of 'wrapping' custom web components after
| I figured that learning my abstractions wasn't any different than
| learning native web component abstractions (which I couldn't
| justify). I definitely think there are good uses for this type of
| thing, but it was very hard to scale it to app level and not have
| to build data-oriented abstractions which started mildly coupling
| components (on the interface level, rather than as a requirement
| for rendering). So once I started breaking down the components
| abstract enough pieces that they were useful as standalone
| components, I wasn't using any of my custom functionality, so I
| just migrated it all back to native, not-extended-from-my-library
| components.
|
| I'm very eager to see mature projects using these kinds of
| wrappers, though, because I do think there are ways to push the
| native web-component experience further, and I think these are
| the kinds of projects that help with that.
| spankalee wrote:
| The custom element spec definitely only deals with the
| mechanics of when are where to run your component's lifecycle
| code - it says nothing about data. So your choices are
| basically property accessors, which are interoperable, but
| require prop-drilling for global-ish data, or something
| proprietary like a state management library.
|
| The Web Components Community Group (WCCG) is offering something
| of a third way with the community protocols:
| https://github.com/webcomponents-cg/community-protocols
|
| The Context protocol provides tree-scoped ambient data in an
| interoperable way. It's implemented by Lit and FAST (I
| believe). It doesn't replace a data store, but it's often used
| to provide data stores to components, and at least reduce some
| coupling.
| catapart wrote:
| Ah, good to know! Hadn't really looked too far into component
| render batching, but I'm glad there are efforts underway!
|
| I just meant that once I was rendering out each component
| without having to have it's parent know about its sub-
| components, I didn't have much use for global contexts or
| passing state to a component, itself. Auto-re-rendering isn't
| as compelling as just setting whatever data on the attribute
| change, or via a child element insertion/removal. Child
| element maintenance requires a lookup, instead of just re-
| rendering with the new state, but the DOM is really good at
| querying, so you can just look them up.
|
| And so, once you remove auto-re-rendering (first render is
| still arcane, but it's still a pretty simple code snippet to
| accommodate templating), and state-based re-render
| triggering, there's not a lot that is added to the web
| component that isn't just a "different" way to do it, instead
| of demonstrably "better".
|
| Of course, everyone's mileage may vary! Just my two cents
| after working with them for a few years. And my work has
| pushed me toward a "simpler is better" approach, which isn't
| universal. For people trying to make very complex web
| components that can benefit from batching tree renders, no
| amount of breakup will help (and my assumption is that it
| will actually hurt a lot? Web Components don't feel "cheap"
| as far as instantiation goes). So it's nice to have people
| working on these kinds of things so that we can one day get a
| drop in DAW web-component, or a performant "spread-sheet"
| component.
| spankalee wrote:
| How does something like this work:
| template() { return `
| <span>${greeting}, ${host.name}!</span> <button
| onclick="changeGreeting">Change Greeting</button>
| `; }
|
| I don't see `greeting` or `host` defined anywhere in scope, so
| this should be an error. Did you forget to prefix them with
| `this.`?
| evan_ wrote:
| Here's the function that evaluates the template:
| with (this.state) { return eval(`(function
| ${this.template.toString().replace(/^\s*function\s+/,'')}())`);
| }
|
| So it's effectively turning everything in `this.state` into a
| local var and evaluating the code in the template function in
| that context.
| spankalee wrote:
| That's so difficult for humans and tools to reason about. It
| would completely break intellisense and lots of lint rules.
| What's the reason for this?
___________________________________________________________________
(page generated 2023-11-05 23:02 UTC)