This message was deleted.

just to add to this, our

VideoTrack

wrapper component is as follows:

interface Props {
  participant: LocalParticipant | RemoteParticipant;
  source: Track.Source;
}

export default function ParticipantVideoView(props: Props) {
  const showTrack =
    props.source === Track.Source.ScreenShare
      ? props.participant.isScreenShareEnabled
      : props.participant.isCameraEnabled;

  return showTrack ? (
    <VideoTrack
      className="absolute inset-0 w-full h-full object-cover"
      participant={props.participant}
      source={props.source}
    />
  ) : (
    <ParticipantVideoPlaceholer participant={props.participant} />
  );
}

Hi, can you also share the implementation around the useParticipants hook? A general note: It intuitively makes sense to model your data around participants, but we encountered difficulties when a participant has more than one track (e.g. camera and screen sharing or multiple camera tracks). To address this, we created the TrackReference type, which is an object structured primarily around tracks rather than the participant. You can use it in combination with

TrackLoop

. A working example is our

VideoConference

component (here).

@eager-zoo-16408 interesting, appreciate the quick reply. to your question, we mount the

useParticipants

hook once at the top of the page/component tree, and individual components grab them from the store as necessary. a couple of other quirks that probably aren't relevant, but sharing just in case: • the hscroll I mentioned that displays all participants also allows the host to take actions on participants, such as reordering, muting, and removing from the room. these actions make use of

identity

,

sid

, and

metadata

• we also use

metadata

and

isMicrophoneEnabled

to overlay participant info on the video tracks shown in our grid as you mentioned, due to ^ it was convenient to model around participants, but I'm sure we can reorient around tracks as necessary. thanks again!