Hacker News Reader

Comment by brazukadev | Hacker News Reader

> How would you solve that? To this day I've never seen a workable proposal.

Stencil.js[0] has a working "proposal" or workaround. Not sure if it is good or bad but at least it seems to work. When you ask users of an API how it could be better they should not be responsible for the implementation. If it can't be done so it is better to not do it in place of having a half working solution that most people decide to not use because it does not work for their use cases.

> they have no sympathy for standards developers or the difficulty of the problem

The problem with the browsers API is a lack of an understanding on how to design good ergonomic APIs for the end user. All the standards developers I talked think shadowDOM is great and people that don't like it are holding it wrong.

0. https://stenciljs.com/docs/templating-jsx#slots

View on HN

Stencil's is _not_ a workable platform solution. Stencil is emulating something close to slots _above_ the DOM. Stencil knows the host tree form Stencil's own component definitions, then it flattens before it gets to the DOM. This is basically just what React and every other framework does, just copying the browsers terminology. It's not compatible with anything but Stencil.

In the real DOM you need to know which element from project _from_. The <slot> itself is only half the connection. In a light-DOM only document full of <slot>s you won't know which elements to project where.

> The problem with the browsers API is a lack of an understanding on how to design good ergonomic APIs for the end user.

This could be slightly true, but the statement also misunderstands the role and priorities of standards. When adding new capabilities to first priority is to make something possible at all, and coherent with the rest of the platform. Making a sugary high-level API is often left to libraries at first, and is exactly what libraries like Lit are.

> In the real DOM you need to know which element from project _from_. The <slot> itself is only half the connection. In a light-DOM only document full of <slot>s you won't know which elements to project where.

There's still a concept of "importing" a template. A host node has slots under it and requests to "import" a template from elsewhere in the document. That import process can adopt the slots then. It's "adoption" rather than "projection" and you "lose" that relation to the source document that "slots stay in the same place", but the DOM has never been static with respect to source documents.

I'm not GP, but I would love to understand this issue in more detail. Do you happen to have a good link for me to read about what has been tried and why it failed?

Perhaps it's a naive solution, but I would imagine that much of that could be solved through deferring to component hierarchy and enabling a way to assign things more specifically when defining the components in the CustomElementRegistry. I recognize your username and I realize that you have spent a lot of time thinking about these problems, so I would really appreciate whatever insight you have to offer. Thanks!

Reply on news.ycombinator.com