webcomponents: unnecessary wrappers
See original GitHub issueDescribe the bug
The outcome produces a builder-component
which wouldn’t exist in the React counterpart, meaning that each component will result in DOM bloat for no reason, nor benefits.
To Reproduce Steps to reproduce the behavior:
- visit this demo example
- inspect the DOM
- note
builder-component
wraps the DIV, which is the only thing React would render instead
Expected behavior
A div
builtin extend that is="builder-component-xxx"
where xxx
is the unique relation between the MyComponent
function and the outcome in the DOM.
Additional context
The only way to represent React output as Custom Element is to use builtin extends, available in every browser but Safari, which can easily be polyfilled if necessary in case window.safari
or window.webkit
exists, through import maps or ad-hoc builds for these targets.
The output should be a custom elements which represents what the React function would return and update its state/view whenever a state is triggered.
This is because it’s impossible otherwise to represent special nodes such as td
, li
, tr
, option
, or others, if these get wrapped by unrelated nodes.
Changing div
with td
as returned node will indeed fail.
Issue Analytics
- State:
- Created a year ago
- Comments:9 (5 by maintainers)
Top GitHub Comments
@samijaber thanks! About the example, this is just a quick summary of what should be done, but it requires special care for props and it doesn’t include fragments possibility. Bear in mind 1:1 React to WC is extremely difficult to have, simply because the paradigm is different, and so are the primitives used behind the scene.
React
WC
Now, with this kind of outcome, we can represent pretty much every JSX except for fragments, which cannot really be represented as single WC because we can’t extend, or define, a fragment in a declarative way, so that use case might require a special
<partial-content>
Custom Element that takes its previous node and append to it its content.Last, but not least, it should be possible to have inner components through “virtual slots” injected once with the
innerHTML
on connected callback, and updated later on each time it’s needed (propagate updates down those references).So, updates propagates down but there’s no need to propagate up, except for events that bubble already so … it’s all good.
I hope this give you a better idea of what I mean when I say that currently mitosis does not provide React to WC conversion.
this is what I mean: the outcome creates a wrapper of what React would’ve created …
This does not work when components cannot be wrapped, as it is for
<table>
,<td>
,<li>
,<option>
and other standrd HTML element otherwise possible with React.Indeed, this example/demo is not possible with current mitosis webcomponents target, but if it is, please show me that exact demo outcome after mitosis, where the rendered output should be exactly this one, as it is for its React counterpart:
I hope this is now clear.