Move AudioLayout to grid - #16133
Conversation
d8a8ce0 to
7ab3d37
Compare
bb701eb to
33da9a8
Compare
|
Hello 👋! When you're ready to run Chromatic, please apply the You will need to reapply the label each time you want to run Chromatic. |
44275d5 to
93243d7
Compare
| ArticleDisplay[format.display] | ||
| }Layout`} | ||
| /> | ||
| {audioData ? ( |
There was a problem hiding this comment.
Alternatively this fork could (should?) happen inside <MainMedia /> as the audio player here is just a different type of main media. As far as I can tell it's not used anywhere else.
There was a problem hiding this comment.
I think that will ultimately mean the AudioBlockElement gets handled in renderElement along with most other kinds of element? Perhaps then we won't need the separate audio-data.ts file?
One caveat is that renderElement will also get used for body elements. I don't know if @oliverabrahams is aware of a reason we wanted to avoid this when implementing audio articles?
There was a problem hiding this comment.
Merging into MainMedia makes sense imo, the video play is handled there for video pages, right?
There was a problem hiding this comment.
Yeah I'm with you - have had a stab in 01e8d98.
Edit: I get the impression there's a deeper discussion to be had about where best to house the audio player (something else handled by renderElement perhaps) though I'd argue that discussion and any subsequent changes are beyond the scope of this pull request and warrant their own
There was a problem hiding this comment.
Yeah I'm with you - have had a stab in 01e8d98.
Edit: I get the impression there's a deeper discussion to be had about where best to house the audio player (something else handled by
renderElementperhaps) though I'd argue that discussion and any subsequent changes are beyond the scope of this pull request and warrant their own
Right that's nicer already! But to expand on what Jamie said I think the AudioPlayer could be added here https://github.com/guardian/dotcom-rendering/blob/main/dotcom-rendering/src/lib/renderElement.tsx#L992, to let renderElement handle it and remove the separate handling for it altogether.
0bc3a39 to
76e769a
Compare
961b98a to
546b54a
Compare
| ArticleDisplay[format.display] | ||
| }Layout`} | ||
| /> | ||
| {audioData ? ( |
There was a problem hiding this comment.
I think that will ultimately mean the AudioBlockElement gets handled in renderElement along with most other kinds of element? Perhaps then we won't need the separate audio-data.ts file?
One caveat is that renderElement will also get used for body elements. I don't know if @oliverabrahams is aware of a reason we wanted to avoid this when implementing audio articles?
a1a3536 to
b63fee8
Compare
60f41d3 to
1add331
Compare
|
@copilot please rebase this PR and resolve conflicts |
c067d5e to
78b4938
Compare
d8133d0 to
e49a970
Compare
0af5484 to
ad4d486
Compare
|
Seen on PROD (merged by @frederickobrien 12 minutes and 41 seconds ago) Please check your changes! |
Following on from #15428 and #16119, this absorbs AudioLayout into the grid system. The changes here are built atop some general tidying/refactoring of how audio player components work in #16339.
Open question: I started implementing it but thought it was worth asking the question. Why is the body wider for video articles than for audio ones? This only occurs at the
widebreakpoint and to my mind seems needless. If we align their appearance both can be quite happily accommodated by themediagrid layout.Why?
Less code, fewer headaches, reduced existential dread.
Screenshots