Checking `prop in elem` fails with deferred custom element definitions

Reproduction: https://www.webpackbin.com/bins/-KikMSw9W7D7EHbuTdTX

Context: Skate is using Preact under the hood to render, so h is just a straight export of Preact’s h in that bin. val is a function that ensures props are explicitly set all of the time. Another way to work around the check here would be to use a ref and imperatively set the prop.

I spoke with @developit and the proposed solution is to always set props for anything that isn’t a string or number, while continuing the prop in elem check. However, I’m not sure the in check is still necessary after implementing something like this.

[robdodson]

Oh I agree that long term it might be beneficial for there to be syntax which supports setting attr or prop. I wasn’t actually trying to get into that discussion here, but rather was curious how Preact should handle an undefined object or array given what JSX currently supports. At the moment if the property is undefined, Preact will set an object to <x-foo obj="[object Object"]> and an array to <x-foo arr="1,2,3"> (note the Array is missing square brackets). Initially I thought that it should JSON serialize stuff but am in agreement now that it would be better for it to just set complex objects as properties on the element. Custom Element authors can use a lazy properties approach to handle this.

The last thing I was wondering about was how to deal with SSR. Should an object or array get serialized in that scenario since there’s no ability to set a property. After discussing this with @justinfagnani and @developit I think it’s best if Preact just does nothing here. Like, don’t even try to set the attribute to anything. My reasoning is that I couldn’t think of a use case where this would actually be beneficial to the Custom Element. The element can’t boot up server side, and even if it could, it can’t render shadow DOM so what good is it going to do to pass it a complex object serialized to an attribute? Also, if you were able to somehow upgrade the element server side then you could just set the property on it.

To make this more explicit I tried to write up a list of expected behaviors. Curious what you all think?

Summary of expected behavior

• If an element has a defined property, Preact will use it.
• If an element has an undefined property, and Preact is trying to pass it a string/number/boolean, it will use an attribute.
• If an element has an undefined property, and Preact is trying to pass it an object/array it will set it as a property. (related to #511 )
• If the element is being rendered on the server, and Preact is trying to pass it a string/number/boolean, it will use an attribute.
• If the element is being rendered on the server, and Preact is trying to pass it a object/array, it will not do anything.

[robdodson]

I see. So I guess it really depends on whether or not Preact is being paired with a functioning DOM abstraction on the server side that can properly trigger all of the lifecycle callbacks for custom elements. In that case it should (I guess?) be able to use the same behavior as on the client.

If the element is being rendered on the server, and Preact is trying to pass it a object/array, it will not do anything.

I wrote this comment specifically imagining a situation where there isn’t a DOM abstraction but instead the whole app is trying to be rendered to a big string or something entirely in Node. I have to admit my knowledge of SSR is pretty limited so if this doesn’t seem like the right behavior I’m more than happy to say we should change it 😃