feat: join a room from the contact list#350
Conversation
Modifies the call button to say join and allow a user to join a room another participant is in without going to the room view. This doesn't handle if two rooms have the same name.
✅ Deploy Preview for hoppdocs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughParticipantRow now accepts room data and can join an existing room by fetching tokens, ending any active call, applying local mic/camera settings, and starting the room call. Participants now loads rooms and passes them into each row. ChangesRoom join feature
Estimated code review effort: 3 (Moderate) | ~25 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
ESLint install failed. For unrecoverable errors, disable the tool in CodeRabbit configuration. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@tauri/src/components/ui/participant-row-wo-livekit.tsx`:
- Around line 93-94: The room-join flow in joinRoom is currently unreachable
when inACall because the join button is hidden, even though joinRoom already
handles callTokens by ending the active call. Update the gating so the
participant-row UI and joinRoom follow the same switch-call rules: allow the
join path when it needs to replace an active call, but block it when
hasIncomingCall is true to prevent overlapping call state. Check the joinRoom
callback and the related button visibility/disabled logic in
participant-row-wo-livekit.tsx so they stay consistent with the other call-entry
paths.
- Around line 86-88: The room lookup in participant-row-wo-livekit.tsx uses
userPresence?.roomName with props.rooms.find in targetRoom, which can pick the
wrong room when names are duplicated. Update the presence-driven lookup to use a
unique room identifier such as roomId wherever possible, and in the current
ParticipantRow / targetRoom selection path detect ambiguous name matches instead
of silently choosing the first room. If roomId is not yet available in presence,
add a safe fallback that refuses to auto-join when multiple rooms share the same
name.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 782eb864-93d3-4448-b914-c96e933611b4
📒 Files selected for processing (2)
tauri/src/components/ui/participant-row-wo-livekit.tsxtauri/src/components/ui/participants.tsx
| const targetRoom = useMemo( | ||
| () => props.rooms.find((r) => r.name === userPresence?.roomName), | ||
| [props.rooms, userPresence?.roomName], |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift
Avoid joining rooms by non-unique display name.
find((r) => r.name === userPresence?.roomName) can select the wrong room when two rooms share a name, while the token endpoint joins by room id. Prefer carrying roomId in presence; at minimum, block ambiguous matches instead of picking the first one.
Possible local mitigation until presence includes room IDs
- const targetRoom = useMemo(
- () => props.rooms.find((r) => r.name === userPresence?.roomName),
- [props.rooms, userPresence?.roomName],
- );
+ const matchingRooms = useMemo(
+ () => props.rooms.filter((r) => r.name === userPresence?.roomName),
+ [props.rooms, userPresence?.roomName],
+ );
+ const targetRoom = matchingRooms.length === 1 ? matchingRooms[0] : undefined;📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| const targetRoom = useMemo( | |
| () => props.rooms.find((r) => r.name === userPresence?.roomName), | |
| [props.rooms, userPresence?.roomName], | |
| const matchingRooms = useMemo( | |
| () => props.rooms.filter((r) => r.name === userPresence?.roomName), | |
| [props.rooms, userPresence?.roomName], | |
| ); | |
| const targetRoom = matchingRooms.length === 1 ? matchingRooms[0] : undefined; |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@tauri/src/components/ui/participant-row-wo-livekit.tsx` around lines 86 - 88,
The room lookup in participant-row-wo-livekit.tsx uses userPresence?.roomName
with props.rooms.find in targetRoom, which can pick the wrong room when names
are duplicated. Update the presence-driven lookup to use a unique room
identifier such as roomId wherever possible, and in the current ParticipantRow /
targetRoom selection path detect ambiguous name matches instead of silently
choosing the first room. If roomId is not yet available in presence, add a safe
fallback that refuses to auto-join when multiple rooms share the same name.
| const joinRoom = useCallback(async () => { | ||
| if (!targetRoom || isJoiningRoom.current) return; |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Align room Join gating with the switch-call flow.
joinRoom handles callTokens by ending the active call, but the button is hidden while inACall, making that path unreachable. Also block hasIncomingCall like the other call-entry paths to avoid overlapping call state.
Proposed gating adjustment
const joinRoom = useCallback(async () => {
- if (!targetRoom || isJoiningRoom.current) return;
+ if (!targetRoom || hasIncomingCall || isJoiningRoom.current) return;
@@
- }, [targetRoom, callTokens, props.user, setCallTokens, endCall, getRoomTokens, posthog]);
+ }, [targetRoom, callTokens, hasIncomingCall, props.user, setCallTokens, endCall, getRoomTokens, posthog]);
@@
- {userPresence?.roomName && !inACall ?
+ {userPresence?.roomName ?
<Button
variant="gradient-white"
onClick={joinRoom}
- disabled={!targetRoom || isJoiningRoom.current}
+ disabled={!targetRoom || hasIncomingCall || isJoiningRoom.current}Also applies to: 105-108, 160-160, 407-411
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@tauri/src/components/ui/participant-row-wo-livekit.tsx` around lines 93 - 94,
The room-join flow in joinRoom is currently unreachable when inACall because the
join button is hidden, even though joinRoom already handles callTokens by ending
the active call. Update the gating so the participant-row UI and joinRoom follow
the same switch-call rules: allow the join path when it needs to replace an
active call, but block it when hasIncomingCall is true to prevent overlapping
call state. Check the joinRoom callback and the related button
visibility/disabled logic in participant-row-wo-livekit.tsx so they stay
consistent with the other call-entry paths.
Modifies the call button to say join and allow a user to join a room another participant is in without going to the room view.
This doesn't handle if two rooms have the same name.
Screen.Recording.2026-07-01.at.09.22.23.mov
Summary by CodeRabbit
Summary by CodeRabbit
New Features
Bug Fixes
Closes #338