Manage People in a React Room

Use the supplied people controls in mediasfu-reactjs@4.2.9 to view room members, admit people from a waiting room, answer microphone or camera requests, mute or remove a participant, assign co-host responsibility, and open public or direct messages.

Start with ModernMediasfuGeneric. Its room interface keeps these actions tied to the active socket, participant list, role, room policy, and current media state. You do not need to build an administration dashboard before your first room works.

Prerequisites

• A working room from the React room lifecycle guide.
• An authenticated application user and a backend-authorized room role.
• At least two browser sessions for release testing: one host or moderator and one participant.
• Clear product rules for host, co-host, participant, panelist, and audience actions. Hiding a button is not an authorization boundary; the room service must enforce the role too.

Use the supplied controls first

import { ModernMediasfuGeneric } from 'mediasfu-reactjs';
import {
  createRoomViaBackend,
  joinRoomViaBackend,
} from './room-api';

export function ModeratedRoom() {
  return (
    <ModernMediasfuGeneric
      createMediaSFURoom={createRoomViaBackend}
      joinMediaSFURoom={joinRoomViaBackend}
    />
  );
}

After the room connects:

1. Open Participants to see the current member list.
2. As an authorized host or co-host, use the participant row actions to mute, message, or remove a person.
3. Open Waiting room to accept or reject people waiting to enter.
4. Open Requests to answer microphone, camera, or screen requests.
5. Open Co-hosts to apply only the responsibilities your product grants.
6. Open Messages for the room conversation or a direct conversation.

The supplied interface evaluates room role and responsibility before showing moderator actions. Still treat the server response and the next room-state update as the result—not the button press.

Know when each action succeeded

Action	Success users can observe	Recovery and cleanup
List people	The count and rows match the connected room and update after join or leave.	An empty room is valid. Remove copied participant state when the room closes.
Admit or reject	The waiting entry disappears and an admitted person joins, or a rejected person receives the rejection state.	Keep the entry visible while the request is pending. If the role changed, refresh room state before retrying.
Answer a media request	The request leaves the queue and the participant sees the allowed or denied result.	Explain a denial without exposing internal policy. Do not show media as active until the participant actually publishes it.
Mute a participant	The room reports the participant's audio state as muted.	A local icon change is not enough. Restore the latest room state if the request fails.
Remove a participant	The person leaves the participant list and their remote media is detached.	Prevent duplicate removal requests. Clear any open direct-message selection for that person.
Assign co-host work	The selected responsibilities are reflected in the room and the co-host sees only those controls.	If an update is rejected, keep the previous responsibility set and explain that authority did not change.
Send a message	The message appears once in the promised public or direct conversation.	Keep an unsent draft on a transient failure; do not log message bodies or room authority.

Add app-owned launcher buttons only when needed

The public launch functions toggle the supplied workspaces. They do not perform the privileged action by themselves.

import { useState } from 'react';
import {
  launchCoHost,
  launchMessages,
  launchParticipants,
  launchRequests,
  launchWaiting,
} from 'mediasfu-reactjs';

export function PeopleWorkspaceButtons() {
  const [participants, setParticipants] = useState(false);
  const [waiting, setWaiting] = useState(false);
  const [requests, setRequests] = useState(false);
  const [coHosts, setCoHosts] = useState(false);
  const [messages, setMessages] = useState(false);

  return (
    <nav aria-label="People and communication">
      <button onClick={() => launchParticipants({
        isParticipantsModalVisible: participants,
        updateIsParticipantsModalVisible: setParticipants,
      })}>Participants</button>
      <button onClick={() => launchWaiting({
        isWaitingModalVisible: waiting,
        updateIsWaitingModalVisible: setWaiting,
      })}>Waiting room</button>
      <button onClick={() => launchRequests({
        isRequestsModalVisible: requests,
        updateIsRequestsModalVisible: setRequests,
      })}>Requests</button>
      <button onClick={() => launchCoHost({
        isCoHostModalVisible: coHosts,
        updateIsCoHostModalVisible: setCoHosts,
      })}>Co-hosts</button>
      <button onClick={() => launchMessages({
        isMessagesModalVisible: messages,
        updateIsMessagesModalVisible: setMessages,
      })}>Messages</button>
    </nav>
  );
}

Keep the current room parameters as the only room-state source. If you render ParticipantsModal, WaitingRoomModal, RequestsModal, CoHostModal, or MessagesModal yourself, pass the complete live parameter object supplied by the room. Do not construct a partial socket or participant object just to make a modal appear.

Reconnect and end-state behavior

During a transient disconnect, disable privileged actions and show a reconnecting state. After reconnection, render the participant, waiting, request, responsibility, and message state returned by the room rather than replaying an action simply because its earlier result was unknown.

When a participant leaves or the host ends the room:

• close app-owned panels;
• clear selected participants and unsent sensitive state according to product policy;
• remove app-owned socket listeners;
• detach remote media for people no longer in the room; and
• distinguish an ordinary participant departure from a room ended for everyone.

Release checklist

• Test host, co-host, ordinary participant, panelist, and audience roles you actually offer.
• Verify the backend and room service reject unauthorized moderation even if a client calls an action directly.
• Test empty lists, duplicate names, rapid join/leave, and reconnect.
• Test waiting-room accept and reject with a separate waiting browser.
• Test allowed and denied microphone, camera, and screen requests.
• Confirm mute and removal are visible to both moderator and participant.
• Verify direct messages reach only the intended people and are not written to client logs.
• Confirm participant leave and host end close panels and clear app-owned state.

The example type-checks against mediasfu-reactjs@4.2.9 and exercises its app-owned permission, recovery, and cleanup decisions without opening a room. Run the checklist in a real multi-user room before release.

Next, add polls, breakout rooms, and a whiteboard.