Repository navigation
Conversation
josephmyers
left a comment
There was a problem hiding this comment.
Looking even better now. The code is clean enough that I was able to dive a little deeper into things, so I apologize for commenting on changes I've reviewed before. Some of these may involve a bit of discussion between us, so feel free to hit me up about those. Thanks
| minWidth: isMobileWidth ? '100%' : 275, | ||
| maxWidth: 400, | ||
| boxSizing: 'border-box', | ||
| minHeight: isMobileWidth ? minPassageCardHeight : cardHeight, |
There was a problem hiding this comment.
In my mind, this would be 1) height and not minHeight, 2) calculating the tallest card height. This would enforce uniform card height. I noticed differing card heights on mobile, and I was wondering if that was intentional.
| {title} | ||
| </Typography> | ||
| )} | ||
| {mediaId && <PassagePlayButton mediaId={mediaId} />} |
There was a problem hiding this comment.
I think this solution is good, but when the title wraps to a second line, the audio button gets put into the top right corner. It looks a little odd when the word that the line actually wraps on is a long word, because it creates a large gap between the title and audio button.
I think a good solution to this would be to 1) make the audio button part of the title line wrapping, i.e. a span, and 2) make the audio button and the last word a single, non-wrapping element to prevent the audio button being on a line by itself. See below:
const tailIndex = [...new Intl.Segmenter().segment(title)].at(-1)?.index ?? 0;
...
<Typography
variant="h6"
sx={{
minWidth: 0,
lineHeight: (theme) => theme.spacing(3.5),
overflowWrap: 'anywhere',
}}
>
{title.slice(0, tailIndex)}
<Box component="span" sx={{ whiteSpace: 'nowrap' }}>
{title.slice(tailIndex)}{' '}
{mediaId && <PassagePlayButton mediaId={mediaId} />}
</Box>
</Typography>
| <> | ||
| <Typography variant="body2" color="grey"> | ||
| {comment || '\u00A0'} | ||
| {!isChapter && ( |
There was a problem hiding this comment.
This doesn't make a lot of sense to me, since chapters can't have descriptions. Why do we need to be explicit about that here? Maybe it would be a little more "closed for modification" if we said {description && (?
| mediaId: string; | ||
| } | ||
|
|
||
| export function PassageSpeakerButton({ mediaId }: IProps) { |
There was a problem hiding this comment.
This looks great. I do notice that it's not being used for book titles, movements, sections, etc. (this looks like a miss from the beginning). Should that be a separate task?
There was a problem hiding this comment.
We'll make this a separate task.
| mediaId: string; | ||
| } | ||
|
|
||
| export function PassagePlayButton({ mediaId }: IProps) { |
There was a problem hiding this comment.
Although this component is certainly a step in the right direction, it would be more useful if it weren't tied/limited to loading the passage audio. It would be more reusable, e.g. by Discussions, if it were given the audio (URL, Blob, etc.).
There was a problem hiding this comment.
We'll make this a separate task.
| mediaId: string; | ||
| } | ||
|
|
||
| export function PassageSpeakerButton({ mediaId }: IProps) { |
There was a problem hiding this comment.
I'm also thinking that the name could be improved, so as to not be confused with the "speaker" concept. Something like TitleAudioButton?
| } | ||
|
|
||
| export function PassageSpeakerButton({ mediaId }: IProps) { | ||
| const { playing, loading, play, audio } = usePassagePlayback(mediaId); |
There was a problem hiding this comment.
If we want to reuse this, we'll have to change this line. It's strange to me that the "passage playback" is what you have to use for the chapters, since that won't return the right thing for the other card types.
There was a problem hiding this comment.
We'll make this a separate task.
| import { sharedSelector } from '../../selector'; | ||
|
|
||
| // Only one passage plays at a time: starting one stops whichever was playing. | ||
| let stopActive: (() => void) | undefined; |
There was a problem hiding this comment.
Limiting the audio playing to one at a time in a central place is a good idea. My refactor will (and the prototype does) introduce the concept of an audio manager as the gateway for playing any audio, not just passages. This will be vital moving forward
There was a problem hiding this comment.
I am a little concerned about the duplication of effort between this new file and PassageDetailContext, which contains some of this already. Was it an intentional decision of yours to not use that, e.g. are you wanting to move away from that file?
There was a problem hiding this comment.
We will revisit this for future refactor (wrt the audio manager); in the meantime I can investigate how PassageDetailContext works.

Major passage overview rework to match the design
Screenshots:
[Before]

[After]
