[feature] Allow changing arbitrary options during room lifetime (disconnectOnPageLeave implemented)

[Philzen]

This is a proposal (or an RFC if you want) implementing a Proxy on the Room.options property. This enables to switch options on or off that otherwise can only be configured once on instantiation. Potential applications could be to have adaptiveStream or dynacast switches in the example applications, but basically any option can be made configurable at runtime with it.

As a proof-of-concept and first application, this PR implements updating disconnectOnPageLeave after the Room has been created, because that was my XY-Problem that led to this: I wanted to hook up a beforeunload handler so a user confirmation is shown should they navigate away during a LiveKit session that is being recorded. The problem i discovered was that the room was being disconnected anyway after the user chose to stay on the page in the confirm dialog. Digging into the library i realized i had to initialize the Room with disconnectOnPageLeave: false – however i felt i don't want to lose this very sensible default behavior. So i implemented this Proxy, which enables to simply room.options.disconnectOnPageLeave = false when recording starts and my custom beforeunload handler is registered, and vice versa do room.options.disconnectOnPageLeave = true when recording stops.

[changeset-bot]

⚠️ No Changeset found

Latest commit: a40187a

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[lukasIO]

thanks for the suggestion!

I think we'd want to expose dedicated (feature based) methods instead of relying on a proxy for these kind of things.
I don't see an immediate use case (simulcast and dynacast would be rather tricky as that needs updates communicated to the server as well and would - today - have to result in a reconnect).

WRT your use case of custom page leave behaviour, I think it makes sense to leave disconnectOnPageLeave: false and implement the logic for page leave within your app (the defaults events are rather straight forward to hook into)

[Philzen]

I can completely follow your point to expose dedicated (feature based) methods instead of relying on a proxy for these kind of things as being a solid design decision. So i'm just leaving this feature branch here which – as said – was just a suggestion.

I think it makes sense to leave disconnectOnPageLeave: false and implement the logic for page leave within your app (the defaults events are rather straight forward to hook into)

This is of course what i ended up doing, at least for the moment as i didn't want to rely on my custom build of client-sdk-ks ;)
The only thing that i don't like about this is that i have now effectively duplicated perfectly fine event handler logic from the sdk with the sole purpose of being able to enable/disable it after instantiation. As i am sure i won't be the last person that needs something like that, maybe it's worth considering this use case. Of course can see two options here:

Option A would be to expose dedicated methods as you said.
Option B would be to implement a "prevent accidental navigation" feature directly within the sdk (which may be out of scope).