node-datachannel
node-datachannel copied to clipboard
feat: accept preconfigured PeerConnection as polyfill arg
There are cases where we need to use methods on PeerConnection that are not available on RTCPeerConnection, but then we wish to pass the RTCPeerConnection on to other code for it to use in a polymorphic node/browser way.
Add an option to the polyfilled RTCPeerConnection to pass a preconfigured PeerConnection instance in, instead of always creating one.
Thanks for the PR. But I can not see any reference from docs. https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/RTCPeerConnection
It's a non standard option, true.
It'll only appear as a valid option if you import the polyfill and use it directly.
If you use the bundled types from lib.dom.d.ts it'll not be available.
As I understood this is a special case for your app. Since this part is polyfill I am not sure how to continue.
The problem is that the peerConnection property of the polyfill is a private property so it cannot be accessed or overridden by a subclass.
If you won't accept an init param, what about returning the PeerConnection instance from a _createPeerConnection method that can be overridden?
The only alternative to have the polyfill here behave the same that browsers do is to copy the whole RTCPeerConnection class to the libp2p codebase in order to override this one line which doesn't seem like the right solution.
Hello,
I thought you didn't need this PR anymore. Instead of modifying the init param, adding an overridable function is better.
Could you please create a PR for this?
Will do! Though do you want to land #324 first as it'll likely cause conflicts.
I thought you didn't need this PR anymore
No problem, I had gone a bit quiet. It's mostly because this PR, #256 and the various linked libdatachannel/libjuice PRs are needed for me to ship the webrtc-direct listener in node.js so it's a bit all-or-nothing.
No, please don't wait for #324
I tried adding a createPeerConnection method to the RTCPeerConnection polyfill class that subclasses can override.
It doesn't really work though - since the this.#peerConnection field is set in the RTCPeerConnection constructor the extending class hasn't had the chance to override the createPeerConnection method from the RTCPeerConnection prototype before it is called.
I think the approach in this PR is simpler?
It's not so different from what this module already does in extending the RTCConfiguration interface to add the peerIdentity string.
I see.
Could you please solve the conflicts? Then we can merge it.
Done!