feat: Adding serialization types relevant to the new Dataconnection classes#1135
feat: Adding serialization types relevant to the new Dataconnection classes#1135ProPablo wants to merge 8 commits intopeers:masterfrom
Conversation
| * Should map 1:1 with the serialization type property in the class. | ||
| */ | ||
| export type SerializerMapping = { | ||
| [key in SerializationType]: SerializationTypeConstructor; |
There was a problem hiding this comment.
One concern id raise over doing this is that it locks the user into ONLY the SerializerTypes that we provide, Changing this back to
[key: string]: new (
peerId: string,
provider: Peer,
options: any,
) => DataConnection;reverts this
There was a problem hiding this comment.
I think this is a problem. Ideally, future encoding formats can be provided as a plugin to PeerJS.
| token?: string; | ||
| config?: RTCConfiguration; | ||
| debug?: number; | ||
| debug?: LogLevel; |
There was a problem hiding this comment.
Let’s wrap this as a string, so a Typescript user is not forced to use the enum.
debug?: `${LogLevel}`| export class MsgPackPeer extends Peer { | ||
| override _serializers: SerializerMapping = { | ||
| MsgPack, | ||
| ...defaultSerializers, |
There was a problem hiding this comment.
My mental model was that during a life time of a Peer, only one encoding will be used in practice.
I left out the default serializers intentionally, so that a tree-shaked MsgPackPeer does not have to include all of BinaryPack
There was a problem hiding this comment.
Ah I see, thats very fair, in that case, I think it would be more appropriate just to force the user to dependency inject the serialization mapping than to make permuations of Peer that contain the serializers.
This would mean a 'blank' Peer that contains no serializers to begin with, but im not sure how the tree shaking would work on that.
| "check": "tsc --noEmit && tsc -p e2e/tsconfig.json --noEmit", | ||
| "watch": "parcel watch", | ||
| "build": "rm -rf dist && parcel build", | ||
| "build": "npx rimraf dist && parcel build", |
There was a problem hiding this comment.
Should be added to dev-dependencies.
| // options, | ||
| {}, |
There was a problem hiding this comment.
Why not pass options to the dataconnection?
| // options, | ||
| {}, | ||
| ); | ||
| console.log({ options, dataConnection}); |
There was a problem hiding this comment.
To be removed before merging.
| cbor: Cbor, | ||
| msgpack: MsgPack, |
There was a problem hiding this comment.
Including all encodings will increase the bundle size enormously.
The default should just be raw, json and binary, as these are mandated by backwards compatibility.
There was a problem hiding this comment.
Let’s put this into .gitignore.
| export class CborPeer extends Peer { | ||
| override _serializers: SerializerMapping = { | ||
| Cbor, | ||
| ...defaultSerializers, |
| * Should map 1:1 with the serialization type property in the class. | ||
| */ | ||
| export type SerializerMapping = { | ||
| [key in SerializationType]: SerializationTypeConstructor; |
There was a problem hiding this comment.
I think this is a problem. Ideally, future encoding formats can be provided as a plugin to PeerJS.
|
Very welcome PR! BrowserStack fails because this comes from an external fork, if you would like to contribute to PeerJS in the future, I could add you to the organization. Please don’t be afraid to open 10 new small PRs instead of one with multiple edits. That also keeps review times short. |
Thank you!
Yes please, I would be more than glad to contribute more, I have another contribution in the works as well!
Yep yep, thank you for the advice, will follow going forward. |


An example of creating the options with a custom set of serializers would look like this: