Not working spread props in not default HTML tag (ex: a-box, custom tag of AFRAME)

[juunini]

Describe the bug

Hello, I'm maintainer of @belivvr/aframe-react.
I'm doing make aframe-solid, but I meet under issue.

• When I want to props to spread
• If target tag is default HTML tag, it works fine (ex: div)
• If target tag is not default HTML tag, it works not fine (ex: a-box. custom tag of AFRAME)

I was first meet this issue when I use jest to rendering test.

Your Example Website or App

https://playground.solidjs.com/?version=1.3.13#NobwRAdghgtgpmAXGGUCWEwBowBcCeADgsrgM4Ae2YZA9gK4BOAxiWGjIbY7gAQi9GcCABM4jXgF9eAM0a0YvADo1aAGzQiAtACsyAegDucAEYqA3EohWZ9CM1xpaEXgGVYhNXAAUheYTIASn4rXl5mZzI+AWYACzQ1ESEILF4AOgzaXFjxMileAF5eP1oAyxdBOFwmF29QsN4AHgA+eoamqC0TWgp+DLSsnMYySWaQOISk4WlO7opG-Vme1or2xpE0ADc+zOzc0fH4xOTpDc2Fs5W1-SveQPLJKytksUY6iu9gguam904vXgAazg+AKKk2UDU9DgKmaZA8XgWf08cGaWHqIlozHo8AguDSAHMqgBRLy43AAIXwAEkRHUwFBCIQVIF0RB7lYwJIALpAA

Steps to Reproduce the Bug or Issue

1. Write component
2. The component using spread props
3. The component renders not default HTML tag (ex: a-box)
4. Open browser developer tools
5. See the tag. It is without any props

Expected behavior

When I write under code

import { render } from "solid-js/web";

function Sample(props) {
  const { children, ...others } = props;
  return (
    <a-box {...others}>{children}</a-box>
  );
}

render(
  () => <Sample key="value" key2="value2">sample</Sample>,
  document.getElementById("app"),
);

I want see under code in browser

<a-box key="value" key2="value2">sample</a-box>

Screenshots or Videos

Platform

• OS: [macOS, Solid Playground(maybe linux?)]
• Browser: Chrome
• Version: ^1.3.13

Additional context

No response

[atk]

Could it be that your custom element requires attributes rather than properties? Maybe try attr:[name]={...}?

[juunini]

@atk Like this? it equal result.

https://playground.solidjs.com/?version=1.3.13#NobwRAdghgtgpmAXGGUCWEwBowBcCeADgsrgM4Ae2YZA9gK4BOAxiWGjIbY7gAQi9GcCABM4jXgF9eAM0a0YvADo1aAGzQiAtACsyAegDucAEYqA3EohWZ9CM1xpaEXgGVYhNXAAUheYTIASn4rXl5mZzI+AWYACzQ1ESEILF4AOgzaXFjxMileAF5eP1oAyxdBOFwmF29QsN4AHgA+eoamqC0TWgp+DLSsnMYySWaQOISk4WlO7opG-Vme1or2xpE0ADc+zOzc0fH4xOTpDc2Fs5W1-SveQPLJKytksUY6iu9gguam904vXhQXC4RiIADWcHwBRUmyganocBUxX84MhACZoWBYfC4GiVM0yB4vAs-p44M0sPURLRmPR4BBcGkAOZVACiXnpuAAQvgAJIiOpgKCEQgqQKUiD3KxgSQAXSAA

[juunini]

@atk users can register custom attribute.
Can't know what attribute is given.
Should use spread. Can not evince one by one attribute.

[ryansolid]

The thing is attributes can't accept rich values(objects, arrays, functions) so we default to handling them as properties on custom elements with the expectation most web component libraries will be able to handle either.

Hmm.. looks like forcing attr: or prop: on native elements (custom or otherwise) is not implemented. Possibly oversight on my part.

But before I'd go there I'd focus on the original example. Just because you don't see an attribute reflected doesn't mean it isn't working. I'm assuming it isn't otherwise we wouldn't be here. First is a-box a Custom Element ie is registered with customElements.define? Does is support receiving data via DOM properties.. ie does el.key = "value" and el.key2= "value2" work? In Solid we assume all elements with a - are W3 Web Components.

[juunini]

@ryansolid

Wow.
I'll go to test now it is work or not working.

[juunini]

Umm... Unfortunately, it is not working as intended.

https://codesandbox.io/s/cocky-monad-vz2hxv?file=/src/App.jsx

this code is working

// working
<a-box position="-1 0.5 -3" rotation="0 45 0" color="#4CC3D9"></a-box>

but, this code is not working

function Box(props) {
  const { children, ...others } = props;

  return <a-box {...others}>{children}</a-box>;
}

// ...
// not working
<Box position="-1 0.5 -3" rotation="0 45 0" color="#4CC3D9" />

[juunini]

I found this.
Maybe I can make aframe-solid

[juunini]

I use ref and success insert custom props.
But, I feel it is not right way.

https://playground.solidjs.com/?version=1.3.13#NobwRAdghgtgpmAXGGUCWEwBowBcCeADgsrgM4Ae2YZA9gK4BOAxiWGjIbY7gAQi9GcCABM4jXgF9eAM0a0YvADo1aAGzQiAtACsyAegDucAEYqA3EohWZ9CM1xpaEXgGVYhNXAAUheYTIASn4rXl5mZzI+AWYACzQ1ESEILF4AOgzaXFjxMileAF5eP1oAyxdlCqFcJhdvULDeAB4APgbG5qgtE1oKdo7BOBkCkG84YIKWkIqBxpluXm8IiCjeAGs4fF4MXiycxiDp2dnlui80tVoAc28N-FS93OA7gF1A8uOBuDSyOFwAQVwuEYaBM9FwPjuD2yT1e736s0kCMakiRM0abXRHRAcQSSWE0i6PT6WOa+iJvUxsyaIjQADd+Bk0o8DpIWjj4olktJaXSmvpeVTGvyhfCIGirMkxIx6hVvBMpk13JwvOtNgUVHSoGp6HAVGr8AAmDVgLU6uCGlQtMgeLz85WeOAtLANES0Zj0eAQXBpK5-ACiXi9uAAQvgAJIiepgKCEQgqQIuiBisCSF5AA

[ryansolid]

Yeah. This is getting into that territory where there is some question about how to prioritize this case over standard Web Component case. Most of the time with Web Components you want the ability to set properties as well as attributes so libraries handle both. This seems like just some random HTML element that our heuristics treat like a Web Component but it's just an unknown element. I checked your examples and customElements.get("a-box") returns undefined. While it would be nice to handle cases like this more naturally, I can't see it being a priority especially since it can't be the default given what we want to accomplish with Web Components.

My recommendation is probably just making a wrapper of sorts. Or intercepting property access with a Custom Element. Because even with spreading attr:_____ (which doesn't work currently) it's pretty cumbersome for your use case.

@trusktr I'm looking at this vs custom element and I don't see a great way to keep it consistent without basically pushing the cost onto the library if it doesn't support setting properties. We need to be able to set properties for rich data with Web Components. From your experience with Lume, any thoughts?

[ryansolid]

This issue isn't going anywhere. I don't see this changing. I don't want to just close it though because there is some potential relevant discussion here about handling of arbitrary elements. So moving to discussions.