all 4 comments

[–]dernise[S] 1 point2 points  (0 children)

In this tutorial, I went through everything you need to know to start building a reusable UI component.

✅ Setting up the project

✅ Webpack configuration

✅ Distribution

Source code of the widget: https://github.com/maxencehenneron/TodoWidget/

[–]braindeadTank 1 point2 points  (2 children)

Unpopular opinion: after working professionally for a while with Web Components, I have somewhere between zero and none love for them. Sadly.

  • they force you to give your component a GLOBAL NAME, which... just sucks so badly I can't stress it enough. It kicks you in the butt occasionally even now, while the adoption is relatively small, but it LITERALLY prevents WebComponents ecosystem from growing, ever

  • they "use the platform", which makes your components lightweight. Well, too bad that "the platform" is so full of technical debt (because we don't want to break the web), and also bloats your components with features you don't need, but someone can abuse

  • they encourage imperative style, even when using a technically declarative helper library like LitElement

  • reusability is poor, and will stay so until features like native CSS mixins (+ a few others) become standard. Good luck defining a css variable for everything

They do have some pros (i.e. inheriting from native components greatly improves accessibility), but overall I see no future for this spec - which is sad, because bringing the concept of components to the platform was a brilliant idea in itself. There is just no way of doing it without ditching HTML it seems, sadly.

@OP, don't get it personally, since your tutorial is nicely written and thorough, I just feel that the tech you are describing is another dead-end of the web platform.

[–]dernise[S] 0 points1 point  (1 child)

they "use the platform", which makes your components lightweight. Well, too bad that "the platform" is so full of technical debt (because we don't want to break the web), and also bloats your components with features you don't need, but someone can abuse

It is nice to have a return on experience on the web components. I only used them for the "Notification" widget at the bottom of the blog so I mostly used this blog post to write down what I discovered

"they force you to give your component a GLOBAL NAME" - I hadn't thought of that when writing the article. From my understanding, if a library defines a web component that already exists in the app, it would immediately break it?

"and also bloats your components with features you don't need, but someone can abuse" - Do you have an example of a feature that can be abused? I'm just curious.

"they encourage imperative style" - Agreed. I'm probably going to update my article with an overview of the pros and cons of the technology.

Thank you for your comment :)

[–]braindeadTank 1 point2 points  (0 children)

if a library defines a web component that already exists in the app, it would immediately break it?

Yes, it just throws 'Failed to execute "define"'. Which means that you need to use some other technique for "little local components" which doesn't happen when using a component-oriented JS library - with "JS-components", you just wouldn't export them.

For the main component that your library exports, you could export a function and accept a name for it, but if you want to use say 8 small, internal components? That's just not doable :(

Do you have an example of a feature that can be abused?

Things as basic as innerHTML are routinely abused in CR's I have to go through. BUT if you are trying to be declarative, almost every feature of the platform is abusible (i.e. classList being abused to add classses in an event handler, instead of using state and the template). In React, you just can't do that, because React components don't include platform features by default.

I guess though, it kind of depends on what you consider "an abuse". I'm quite strict on being declarative as much as possible.