feat(fuselage): extract controlled AudioPlayerControls from AudioPlayer

Merged
GG
4mo ago
+138-59

Why

AudioPlayer owns its own <audio> element and playback state internally, so it can't be driven by an external/shared media element. That makes cases like a persistent player (audio that keeps playing while the UI that hosts it unmounts, e.g. navigating between rooms) impossible to build on top of it — consumers currently have to re-implement the whole control layout.

What

Extracts the presentational part of AudioPlayer into a new, fully controlled AudioPlayerControls component and exports it:

  • AudioPlayerControls renders play/pause, seek, elapsed time, playback speed and the optional download button. It owns no <audio> element and no playback state — everything is driven by props (isPlaying, currentTime, durationTime, playbackSpeed, onTogglePlay, onSeek, onChangePlaybackSpeed, download props and labels).
  • AudioPlayer keeps its previous self-contained behavior (creates the <audio>, manages state) and now composes AudioPlayerControls internally.

Consumers that need to drive a shared/external element use AudioPlayerControls directly; everyone already using AudioPlayer is unaffected.

Backward compatibility

Non-breaking. AudioPlayer's public props and rendered output are unchanged — it just delegates its inner layout to AudioPlayerControls.

Notes

Added a Controls story demonstrating the controlled usage. Changeset included (@rocket.chat/fuselage: minor).