Currently working on a thing that creates React wrappers around my custom elements, based on a Custom Elements Manifest, and I just cant help but think how absolutely ass backwards and ridiculous this all is.
The next time I see someone say web components require so much code and boilerplate, I'm gonna point them to some of the hacks/hoops I had to jump through just to get HTML support in React.
Its nice that Stencil supports this, and that with Custom Elements Manifest we can create this for other libraries, too, but its ridiculous we need to resort to this kind of thing in the first place. If React would just support HTML, we wouldnt need to use these workarounds.
Coding is as much a matter of personal growth as it is of logic and control-flow. I keep patience, curiosity, & exuberance in the same toolbox as vim and git.
*Opinions posted are my own*
Coding is as much a matter of personal growth as it is of logic and control-flow. I keep patience, curiosity, & exuberance in the same toolbox as vim and git.
*Opinions posted are my own*
I've always found extra lines of boilerplate to be such a weird argument. We live in a time where we have emmet abbreviations and code snippets in our editors, why is a few extra lines of boilerplate such a big deal when it reduces the amount of black box magic to basically 0? Seems like such a no-brainer to me :|
It definitely is really backwards, but this seems to be the only way when the other party is bigger. Even if it doesn't make sense, we have to cater to them in order to provide better interoperability and get better adoption.
Not sure what you mean with "black box magic". I always think of React as being exactly that (coming from someone who generally prefers vanilla instead of using frameworks)?
I meant that while React functional components may be very little code compared to the class-based HTMLElement or LitElement or what have you, it is worth having a bit more code if it means roughly no black box magic and it is interoperable and aligns with browser standards (DOM vs Virtual DOM to name an example)
Coding is as much a matter of personal growth as it is of logic and control-flow. I keep patience, curiosity, & exuberance in the same toolbox as vim and git.
*Opinions posted are my own*
Coding is as much a matter of personal growth as it is of logic and control-flow. I keep patience, curiosity, & exuberance in the same toolbox as vim and git.
*Opinions posted are my own*
Currently working on a thing that creates React wrappers around my custom elements, based on a Custom Elements Manifest, and I just cant help but think how absolutely ass backwards and ridiculous this all is.
The next time I see someone say web components require so much code and boilerplate, I'm gonna point them to some of the hacks/hoops I had to jump through just to get HTML support in React.
Stencil already supports the WC <> React wrapper out of the box. Check it out here:
github.com/ionic-team/stencil-ds-o...
It‘s quite simple to set it up & thanks to the engrained usage of TS it can be fully autogenerated
Its nice that Stencil supports this, and that with Custom Elements Manifest we can create this for other libraries, too, but its ridiculous we need to resort to this kind of thing in the first place. If React would just support HTML, we wouldnt need to use these workarounds.
It's definitely pathetic, especially considering the mountains of money moving through Menlo Park
Did you end up publishing this?
Yeah, bit experimental still, but here it is: npmjs.com/package/cem-plugin-reactify
I've always found extra lines of boilerplate to be such a weird argument. We live in a time where we have emmet abbreviations and code snippets in our editors, why is a few extra lines of boilerplate such a big deal when it reduces the amount of black box magic to basically 0? Seems like such a no-brainer to me :|
It definitely is really backwards, but this seems to be the only way when the other party is bigger. Even if it doesn't make sense, we have to cater to them in order to provide better interoperability and get better adoption.
Not sure what you mean with "black box magic". I always think of React as being exactly that (coming from someone who generally prefers vanilla instead of using frameworks)?
I meant that while React functional components may be very little code compared to the class-based HTMLElement or LitElement or what have you, it is worth having a bit more code if it means roughly no black box magic and it is interoperable and aligns with browser standards (DOM vs Virtual DOM to name an example)
It's not either-or. There are many web component libraries with an FP flavour:
Just off the top of my head.
Web Components !== OOP
You don't have to give up your functional programming style to use web components!
More importantly:
React isn't the only functional UI framework
Preact works just fine with the DOM and has for years.
OP is about web compat, not flaming FP or OOP styles.
I dunno, are they really bigger or do they just have a louder bark? 🤔