Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Issue #11 provides a solution for using a different type of signaling server. However, certain parts of y-webrtc make assumptions about the messages being sent through the signaling server. This is a suggestion for refactoring some of the code to make it possible to swap out
SignalingConn
with a derived class.In our case, we wanted to use Azure Web PubSub as the signaling server, and Microsoft uses slightly different message formats, event names, and terminology (i.e. "join groups" instead of "subscribe to topics", "group-message" instead of a "message" event, etc.).
Here is our example code where we have derived classes from
SignalingConn
andWebrtcProvider
using the refactored y-webrtc in this PR. It uses the Azure Web PubSub client from Microsoft.The following refactoring was done:
WebsocketClient
and creates a property to hold an instance of it.subscribe
,unsubscribe
, andpublish
methods forSignalingConn
so external code doesn't need to know how to format signaling server messages.connected
method, since clients may determine signaling server connectivity differently.setupClient
method which can be overridden to use a different signaling server client (ex: Azure Web PubSub client) including differing message event names (ex:message
vsgroup-message
)rooms
iteration into ahandleConnect
method, so that global set does not have to be exported and used in derived classes.handleMessage
method so the logic can be reused and does not need to be included in the clientmessage
event definitions of derived classes.Questions
Overriding
WebrtcProvider
just to change the class used for signaling connections seems excessive. Is there a way we can pass this into the base WebrtcProvider instead? Maybe create a factory method that we can override in a derived class.This is the only line we need to change in the
connect()
method:const signalingConn = map.setIfUndefined(signalingConns, url, () => new SignalingConn(url))
What about this needs to be cleaned up to prevent introducing TypeScript errors if/when
y-webrtc.js
is converted to TS?