-
Notifications
You must be signed in to change notification settings - Fork 54
Fix VideoPlayer in Next docs #1085
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
Conversation
🦋 Changeset detectedLatest commit: 3d225f6 The changes in this PR will be included in the next version bump. This PR includes changesets to release 8 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
🟢 No design token changes found |
🟢 No visual differences foundOur visual comparison tests did not find any differences in the UI. |
3ede5c0
to
f2e1a6b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR ensures that VideoPlayer
’s internal ref isn’t overridden by a null
ref passed from Next.js, and updates the changeset for this fix.
- Refactor: move the
ref
prop after the spread to guarantee it overrides any incoming ref - Changelog: add a patch-level changeset entry for this internal refactoring
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
File | Description |
---|---|
packages/react/src/VideoPlayer/VideoPlayer.tsx | Moved the ref prop after the spread so it always wins |
.changeset/chilled-bottles-hug.md | Added a patch changeset for the internal refactoring |
Comments suppressed due to low confidence (2)
packages/react/src/VideoPlayer/VideoPlayer.tsx:73
- Consider adding a unit or integration test that passes a null ref prop (simulating Next.js behavior) and verifies that the internal ref is still attached correctly.
<video title={title} controls={false} className={clsx(styles.VideoPlayer, className)} {...rest} ref={ref}>
.changeset/chilled-bottles-hug.md:5
- The changeset description could be more specific by mentioning that this patch fixes a ref override issue when Next.js passes a null ref.
Minor internal refactoring to `VideoPlayer` component
f2e1a6b
to
e0acd4c
Compare
@@ -70,7 +70,7 @@ const Root = ({ | |||
return ( | |||
<div className={styles.VideoPlayer__container} ref={fullscreenRef}> | |||
<div className={styles.VideoPlayer__overlayContainer}> | |||
<video ref={ref} title={title} controls={false} className={clsx(styles.VideoPlayer, className)} {...rest}> | |||
<video title={title} controls={false} className={clsx(styles.VideoPlayer, className)} {...rest} ref={ref}> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@joshfarrant can you add a test for this to ensure the ref doesn't get overridden?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think I can unfortunately.
We'd be testing the internals of React at this point and I'm not sure there's a way to actually assert that.
Might be worth discussing this a bit further as — if I understand the underlying issue correctly — we're working around a react-live bug/functionality here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've just tested in react-live's demo and the ref
prop isn't being set to null
there, so maybe there's a bug in our implementation. I'll put this PR on hold for a while and look into it a bit further
'@primer/react-brand': patch | ||
--- | ||
|
||
Minor internal refactoring to `VideoPlayer` component |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could there be a scenario where someone was passing a ref as a prop, which now won't work because we're no longer spreading it in?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't believe that's possible no. The VideoPlayer
doesn't implement forwardRef
, so ref
is dropped as a prop before it ever reaches the component. That means it's not been possible for someone to pass in a ref before this point.
Given that, I'm not 100% sure why props.ref
is ending up as null
(rather than undefined
) when rendered in the docs.
The only thing that I think could be causing it is that react-live
doesn't implement that same React behaviour of dropping the ref
prop, which results in it getting through to the component.
In that case, the only environment this change should affect is in our docs.
@joshfarrant FYI this change, combined with the recent Doctocat updates seems to have fixed the VideoPlayer previews 🙌 https://primer-e8d998b27d-26139705.drafts.github.io/brand/components/VideoPlayer/ Once you're confident this change won't lead to a downstream regression in the library, let's ship it. |
Summary
Fixes
VideoPlayer
in Next docs by ensuringVideoPlayer
ref
isn't overriden bynull
ref passed by Next docs. I'm not entirely sure why, but the Next docs pass a ref ofnull
to rendered components.The
VideoPlayer
intentionally doesn't accept aref
prop as it instead exposes auseVideo()
context to facilitate interaction with the video player. Aref
is available through that context if required.Because of this, we can explicitly override any refs provided directly to
VideoPlayer
and resolve the issue with the Next docs.What should reviewers focus on?
Contributor checklist
update snapshots
label to the PR)Reviewer checklist