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
lib/optionInterfaces.ts
Outdated
| * 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}`
lib/msgPackPeer.ts
Outdated
| 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.
package.json
Outdated
| "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.
lib/peer.ts
Outdated
| // options, | ||
| {}, |
There was a problem hiding this comment.
Why not pass options to the dataconnection?
lib/peer.ts
Outdated
| // options, | ||
| {}, | ||
| ); | ||
| console.log({ options, dataConnection}); |
There was a problem hiding this comment.
To be removed before merging.
lib/optionInterfaces.ts
Outdated
| 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.
pnpm-lock.yaml
Outdated
There was a problem hiding this comment.
Let’s put this into .gitignore.
lib/cborPeer.ts
Outdated
| export class CborPeer extends Peer { | ||
| override _serializers: SerializerMapping = { | ||
| Cbor, | ||
| ...defaultSerializers, |
lib/optionInterfaces.ts
Outdated
| * 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: