React UI Ownership Ladder
Choose how much React UI your application should own. Start with the supplied room and move down only when the product experience requires more control.
This guide applies to mediasfu-reactjs@4.2.9.
| Level | Keep from MediaSFU | Your application owns | Choose it when |
|---|---|---|---|
| Prebuilt | The visible room and runtime | Navigation and product context around the room | You need a reliable room quickly |
| Overrides | The room workflow and most UI | Selected cards, controls, menus, or modals | The product is still room-shaped |
| Custom component | Room runtime and parameters | The primary workspace | Your layout differs substantially |
| Headless | Runtime and available state/action handoff | Every visible surface and user-facing state | The product is a console or another app-owned shell |
Recommended path
- Prove secure create, join, media, leave, and host end with the React room lifecycle guide.
- Use UI overrides for the first visual changes.
- Use custom component replacement when the main workspace must change.
- Use headless mode when your application must own the entire visible shell.
What changes as ownership grows
When your application replaces a supplied surface, it also becomes responsible for that surface's accessibility, loading state, denied state, confirmation, recovery, and cleanup. A button that calls a helper is only the beginning of the user experience.
For participant and collaboration controls, keep current room state as the source of truth and apply your app permission policy before exposing actions.
Release checklist
- Verify the baseline room before replacing UI.
- Test the exact roles, browsers, and devices your product supports.
- Preserve confirmation and cleanup for participant leave and host end.
- Do not place long-lived MediaSFU credentials in React code or browser storage.
- Confirm every custom control has an observable success state and a useful failure path.
See Choose your UI mode for the React component patterns behind each level.