Skip to main content

React Recording Control Boundary

Expose recording only after your product has made authority, supported formats, consent, storage, and stop behavior clear.

This guide uses mediasfu-reactjs@4.2.9. The control example type-checks against that package. A live recording and a stored artifact require separate end-to-end testing.

What the React control provides​

launchRecording evaluates the supplied recording state and opens the recording flow when the current inputs allow it. Its inputs include modal visibility, launch permission, audio and video support, current recording state, and state callbacks.

Opening the recording flow is not the same as starting capture, receiving consent, or confirming that an artifact was stored.

Typed boundary​

import {
  launchRecording,
  type LaunchRecordingOptions,
} from 'mediasfu-reactjs';

type RecordingControlInput = Pick<
  LaunchRecordingOptions,
  | 'updateIsRecordingModalVisible'
  | 'isRecordingModalVisible'
  | 'stopLaunchRecord'
  | 'canLaunchRecord'
  | 'recordingAudioSupport'
  | 'recordingVideoSupport'
  | 'updateCanRecord'
  | 'updateClearedToRecord'
  | 'recordStarted'
  | 'recordPaused'
  | 'localUIMode'
>;

export function openRecordingControl(input: RecordingControlInput) {
  launchRecording(input);
}

Pass current room values into this boundary. Do not hard-code a host role, supported format, or recording state simply to enable the button.

What your application and backend provide​

  • Clear consent and recording indicators for every affected participant.
  • Role and subscription policy for who can start, pause, resume, or stop.
  • Retention, access, deletion, and export rules.
  • Audit records that do not expose credentials or private media.
  • A user-facing response when recording is unavailable or storage fails.

Observable success​

Treat recording as successful only when the room reports the intended state and your storage workflow confirms the artifact or metadata your product promises. Keep requesting, recording, paused, stopping, saved, and failed states distinct.

Recovery and cleanup​

  • Prevent duplicate start requests while a transition is pending.
  • Keep the user informed if the room disconnects during recording.
  • Provide a deliberate retry or support path for a failed stop or save operation.
  • On room end, stop the recording flow according to policy and clear app-owned recording state.

Release checklist​

  • Test supported and unsupported audio/video combinations.
  • Test unauthorized, declined, cancelled, paused, resumed, failed, and room-ended states.
  • Verify participant consent and visible recording indicators.
  • Verify storage ownership, retention, access, and deletion outside the UI control.
  • Confirm no credentials, media contents, or reusable room authority enter client logs.