-
Notifications
You must be signed in to change notification settings - Fork 10.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore(types): make RemoteSocket.data
type safe
#4234
chore(types): make RemoteSocket.data
type safe
#4234
Conversation
Ah formatting. Will fix soon |
6575691
to
b0e7d46
Compare
@@ -769,7 +769,7 @@ export class Server< | |||
* | |||
* @public | |||
*/ | |||
public fetchSockets(): Promise<RemoteSocket<EmitEvents>[]> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So we would have:
const sockets = await io.fetchSockets();
// with the BroadcastOperator
const sockets = await io.in("room-1").fetchSockets<SocketData>();
Is that right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Exactly. We loss the SocketData
type when BroadcastOperator
is created, so it has to be specified. Otherwise it will default to any
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In that case, I think it would make more sense to go with your first solution here, so we have the same API with and without operator (like to()
or except()
).
const sockets = await io.fetchSockets();
const sockets = await io.in("room-1").fetchSockets(); // no additional types
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good to me. Will update the PR
@OrkhanAlikhanov awesome, thanks a lot 👍 |
Adds #4229 (comment)