-
Notifications
You must be signed in to change notification settings - Fork 31
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
Refactor YoutubeAtom
so it does not rely on an external elementId
#10218
Conversation
Size Change: +103 B (0%) Total Size: 744 kB ℹ️ View Unchanged
|
aede77a
to
b8e4bcf
Compare
Hello 👋! When you're ready to run Chromatic, please apply the |
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.
The YoutubeAtom is partially server rendered so the overlay shows on the SSR. The overlay uses the unique id too so it might mean we temporarily have ids in the DOM that are not-unique.
This might not be an issue in practice if the ids get set before the YouTube player initialises but I know we've had issues in the past with the player not being able to correctly identify the right video to play because of duplicate ids.
It's worth trying the storybook tests manually to check they work as expected, particularly the duplicate video tests.
dotcom-rendering/src/components/YoutubeAtom/YoutubeAtom.test.tsx
Outdated
Show resolved
Hide resolved
7c45379
to
c0b8974
Compare
c0b8974
to
cfbd8a9
Compare
03c6d50
to
13f7942
Compare
YoutubeAtom
so it does not rely on an external elementId
13f7942
to
7f2142b
Compare
Hello 👋! When you're ready to run Chromatic, please apply the |
7f2142b
to
152e323
Compare
@@ -297,7 +298,7 @@ test.describe('YouTube Atom', () => { | |||
// Listen for the ophan call made when the video is played | |||
const ophanPlayEventPromise2 = interceptOphanPlayEvent({ | |||
page, | |||
id: 'gu-video-youtube-1e89d5bd-489e-470a-857e-4f30e85b5aec', |
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.
Did we expect this to be the same id as the first video?
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 think so. Aiui Ophan doesn't care about duplicate videos it just wants to log each video play.
Actually if this is the elementId it looks like a bug as I would have expected we give Ophan the videoId
(assetId
prop in YoutubeBlockComponent.importable
) and not the unique / elementId which can change across renders.
dotcom-rendering/dotcom-rendering/src/components/YoutubeBlockComponent.importable.tsx
Line 186 in 8257432
id: `gu-video-youtube-${id}`, |
Worth checking with the Ophan team what their expectations are for these events.
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.
Actually this is the CAPI element.id
and not the unstable element.elementId
so it should persist across renders and of course otherwise the test would fail. The question remains as to what Ophan want to be logged i.e. the element.id or the videoId / assetId
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.
So correctly done in renderElement
but not Card
. Quite confusing—I'll update.
f9b7b48
to
de6d6d3
Compare
de6d6d3
to
82c1dd2
Compare
we can generate a unique elementI from an increasing integer on the client. On the server this defaults to 0 or `undefined` rename the elementId to id for the MainMedia type
82c1dd2
to
e0a4772
Compare
dotcom-rendering/src/components/YoutubeBlockComponent.importable.tsx
Outdated
Show resolved
Hide resolved
dotcom-rendering/src/components/YoutubeBlockComponent.importable.tsx
Outdated
Show resolved
Hide resolved
const [loadPlayer, setLoadPlayer] = useState<boolean>(false); | ||
useEffect(() => { | ||
if (elementId === 'server') { | ||
// We may never load the player on the server | ||
return; | ||
} | ||
|
||
if (!hasOverlay) { | ||
// load the player if there is no overlay | ||
setLoadPlayer(true); | ||
} else if (overlayClicked) { | ||
// load the player if the overlay has been clicked | ||
setLoadPlayer(true); | ||
} | ||
}, [elementId, hasOverlay, overlayClicked]); |
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'm wondering if this could be simplified.
Instead of elementId could we pass through index: number | undefined
and return in the main render path if isUndefined(index)?
I think that would mean the other state could remain derived and it would remove a useEffect and a re-render.
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.
Okay, I’ll keep the changes to a minimal and just add one more check:
if (isUndefined(index)) {
loadPlayer = false;
}
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.
👍
What does this change?
Generate the
elementId
on the client from an increasing integer.See the following article to test: http://localhost:3030/Article/https://www.theguardian.com/world/live/2022/mar/28/russia-ukraine-war-latest-news-zelenskiy-putin-live-updates
Why?
The
elementId
only needs to be truly unique on the client-side which. If there are clashes on the server, it’s fine.We cannot use the
useId
hook here as it produces identical IDs for the same video, due to the tree inside the island being identical…elementId
#10216Screenshots
N/A – Identical