You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
the module replaces custom elements using render functions that accept props and children as arguments and produce a HTML tree as output, which is consistent with the definition of a component in React and similar frameworks.
Rationale for moving away from the name rehype-components
The rendering is static and doesn't have anything to do with React components which re-render dynamically.
The module has nothing to do with Web Components either.
The module just replaces a HTML element with a new HTML tree, so it's closer to the idea of a search-replace than to the idea of an encapsulated component.
Rationale for rename to rehype-custom-elements
The nature of these elements in the HTML is that of custom elements, not of components as they exist in e.g. React JSX expressions.
Also unlike React components, these custom elements are not distinguished by a capitalized name, but can instead be distinguished from other elements with a hyphen inside the tag name
Rationale against renaming to rehype-custom-elements
The module doesn't have anything to do with DOM-implemented custom elements, nor with the CustomElementRegistry
The text was updated successfully, but these errors were encountered:
I say keep the name rehype-components as this module let's you create encapsulated and reusable HTML definitions which sounds a lot like components to me.
Moving to rehype-custom-elements might end up causing confusion because as you mention it doesn't have anything to do with DOM custom elements that live client side. If anything this reminds me of server side rendering or static site generation.
I am working a similar package as rehype-components was somewhat limited to me. I wanted basically an implementation of web components (with slots and custom properties). The package is not documented but it does work similarly to what web components would be and this is how I imagine a rehype-components plugin to work.
I started a separate repository because I have not been familiar with the unified syntax tree and the ecosystem, so this was a practice to me. Currently, I am rewriting my big universal component to a set of separated components. If you find it appropriate, I can pull it into your repository and we could publish together with extended functionality or I can publish mine independently. If you prefer, reply here reach me out by any other channel. Thank you in advance!
Rationale for keeping the name
rehype-components
:Rationale for moving away from the name
rehype-components
Rationale for rename to
rehype-custom-elements
Rationale against renaming to
rehype-custom-elements
The text was updated successfully, but these errors were encountered: