Checking `prop in elem` fails with deferred custom element definitions
See original GitHub issueReproduction: 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.
Issue Analytics
- State:
- Created 6 years ago
- Reactions:5
- Comments:9 (1 by maintainers)
Top Results From Across the Web
Checking prop in elem fails with deferred custom element ...
If the element is being rendered on the server, and Preact is trying to pass it a object/array, it will not do anything....
Read more >Handling properties in custom element upgrades
The problem is that the first <script> is type="module" , meaning it's deferred by default, whereas the second is an inline script, which...
Read more >Cannot access attributes of a custom element from its ...
It's because at the time constructor() is called the custom element has no content yet. You should defer that in the connectedCallback() method...
Read more >Custom Elements Everywhere
Making sure frameworks and custom elements can be BFFs. ... Checking `prop in elem` fails with deferred custom element definitions
Read more >Custom Elements v1 - Reusable Web Components
Custom elements allow web developers to define new HTML tags, extend existing ones, and create reusable web components.
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
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
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.
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 😃