-
-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Preact + media-chrome: Props are not passed correctly #4486
Comments
This is running afoul of our props vs attribute detection, as they've unfortunately defined a #4478 would address this, though I'm not particularly fond of it (others may disagree). |
I see. Is there any workaround for this? I tried capitalizing it but it still doesn't work. |
Refs, for example: <MediaPlaybackRateButton ref={(d) => d.setAttribute('rates', '1 2 3')} /> |
Just a tiny note:
having a property is what you'd expect from a web component, is it not? IDL attributes are supposed to be reflections of their content counterpart; preacts current behaviour forces CEs to either:
|
Potentially, but it's the combination of defining a getter/setter yet expecting attributes to be set. Preact assumes that if you've set a getter/setter, you'd expect to Preact/your framework use those rather than switch to attributes.
Potentially, yes. Being a JS framework, I don't think this is problematic; properties are the native interface for interacting with DOM elements. Most properties don't need to be reflected back to attributes, and a few shouldn't. That's not to say the use case is invalid, but that, IMO, properties should be the interface of choice and "the intended order" so to speak. |
But I don't expect any framework, that's why I'm writing a CE ;) anyway, this discussion should probably be done in the mentioned PR, if at all. And about the order: 🤷♀️ possibly. I just find it odd that since the content attribute is there first and the CE is actively upgraded to read the content attribute into its IDL attribute that from there on out the IDL attribute should take charge. In my case I've done just that and it works as expected. Looking through webcomponents.org (specifically githubs own CEs) many also do just that. |
Depends on your usage. If you're registering a Preact component as a custom element, and are already using it in your HTML doc with defined attributes, sure, I agree. This issue shows a different usage though, with a Preact wrapper around a custom element -- it doesn't exist until Preact renders it. I don't think there is a right or wrong here, it's always going to be a guess. I'm not sure if there's any consensus/strong opinions one way or the other but we'll update the PR when/if there is. |
Describe the bug
When using Preact with react components in
media-chrome
package, the props are not passed to the component correctly.For example, the rates for
MediaPlaybackButton
couldn't be set correctly. (it works correctly when using React)To Reproduce
StackBlitz: https://stackblitz.com/edit/create-preact-starter-l7wbnq?file=src%2Findex.jsx
Steps to reproduce the behavior:
Expected behavior
What should have happened when following the steps above?
rates = "1 2 3"
(docs: https://www.media-chrome.org/docs/en/components/media-playback-rate-button)The text was updated successfully, but these errors were encountered: