Skip to content

Conversation

@toger5
Copy link
Contributor

@toger5 toger5 commented Dec 2, 2025

From internal discussions about this PR: https://matrix.to/#/!tDLCaLXijNtYcJZEey:element.io/$jPuIV8UAaCVC8IPEe8LaJPDbaZ85o6nnCdxVeQoMcx0?via=element.io&via=matrix.org&via=robin.town

  • We have understood the actual model of the state. (They are NOT simply linear but change how many dimensions they have dependent on the state)
    • 1D: [loading transport + create LK Room]
    • 3D:[connectingToLkRoom, createTracks, matrixState]This one is the thing that makes it complicated. We can create tracks before we are connected to the lk room or after (!! connected to lk room is not the sama as lk room created) so this is the thing that made it feel so wrong with the prev appraoch!
    • 2D:[publishing, matrixState]We can only start the publishing states once both independent prev states connectingToLkRoom, createTracks are ready.
  • We have found some good names for the states (some are still pending)
  • We have noticed that the {state: string, error: Error} structure is not ideal -> a simple "or-Type" is a lot simpler and more elegant State | Error (especially with the dimension changes)

@toger5 toger5 marked this pull request as ready for review December 9, 2025 14:24
@toger5 toger5 requested a review from a team as a code owner December 9, 2025 14:24
@toger5 toger5 requested a review from robintown December 9, 2025 14:24
@toger5 toger5 added the PR-Developer-Experience Release note category. A PR that does not change EC but improves working with the repository. label Dec 9, 2025
);

// Keep matrix rtc session in sync with localTransport$, connectRequested$ and muteStates.video.enabled$
// inform the widget about the connect and disconnect intent from the user.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

where does this come from.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this was pulled to make the join rtc session functions sync.

Copy link
Member

@BillCarsonFr BillCarsonFr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We've done a live review of that together, so it is fine by me.
Just some minor comments, but no blockers

try {
await expect(continueButton).toBeVisible({ timeout: 5000 });
await expect(continueButton).toBeVisible({ timeout: 700 });
// why do we need to put in the passwor if there is a continue button?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this can be removed now? Looks like it was some old onboarding UI from web that is not needed anymore?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cool that makes sense. I was wondering in what cases it would be used.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove all continueButton related code.

page.getByRole("heading", { name: `Welcome ${username}` }),
).toBeVisible();

// Dismiss incompatible browser toast
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we add more test to be sure that we really dismiss the popup we think we dismiss (check the title)?

This is fixed by updating playwright, right? is it really needed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It helps us save time if we are slow with merging renovate and need to debug why our test fail.

const mediaDevices = useMediaDevices();
const trackProcessorState$ = useTrackProcessorObservable$();
useEffect(() => {
logger.info("START CALL VIEW SCOPE");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

add some prefix to the log until we have proper prefixed logger?
Something like [InCallView]

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a proper logger.

@toger5 toger5 merged commit cf453ba into livekit Dec 11, 2025
19 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

PR-Developer-Experience Release note category. A PR that does not change EC but improves working with the repository.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants