-
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
improve emit types #4817
improve emit types #4817
Conversation
Open question:
|
Broadcast emits only return a single ack value
Improve type definitions of `emit` and `emitWithAck` to prevent uses in an incorrect manner
This avoids having tons of red squiggles showing on the IDE for a succeeding test tsd will still error out if a `ts-expect-error` goes unused, so it functionally is about the same
@darrachequesne, I've improved the types further, and also removed I also added in the type-fest library as a dependency. It only has types in it, so it shouldn't impact anything more than npm installing one more package in production. It should be pretty straight-forward to instead inline the 2 types I'm using from the library. Looking at the package-lock file, it's already included about 10 times with nearly as many different versions resolving. I'll be away from computers from Saturday till October, so feel free to make any needed changes to the PR. |
@darrachequesne, could you review this when you get a chance? |
@ZachHaber sorry for the delay, I'm taking a look at this. |
lib/typed-events.ts
Outdated
@@ -241,3 +301,11 @@ export type DecorateAcknowledgementsWithMultipleResponses<E> = { | |||
? (...args: ExpectMultipleResponses<Params>) => Result | |||
: E[K]; | |||
}; | |||
|
|||
export type RemoveAcknowledgements<E> = { |
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.
I'm not sure to understand here, shouldn't the events with an acknowledgement be flltered out?
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.
It currently just removes the callback function instead of filtering out the events with acknowledgements. It should probably just filter them out in hind sight, shouldn't it?
I was trying to be more permissive than restrictive in what was allowed based on what would technically work.
package.json
Outdated
@@ -52,7 +52,8 @@ | |||
"debug": "~4.3.2", | |||
"engine.io": "~6.5.2", | |||
"socket.io-adapter": "~2.5.2", | |||
"socket.io-parser": "~4.2.4" | |||
"socket.io-parser": "~4.2.4", | |||
"type-fest": "^3.13.1" |
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.
We try to keep our prod dependencies to the bare minimum, so I think we'll indeed need to copy the types from type-fest
.
@@ -252,7 +255,10 @@ export class Namespace< | |||
* @return a new {@link BroadcastOperator} instance for chaining | |||
*/ | |||
public to(room: Room | Room[]) { | |||
return new BroadcastOperator<EmitEvents, SocketData>(this.adapter).to(room); | |||
return new BroadcastOperator< | |||
DecorateAcknowledgementsWithMultipleResponses<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.
Couldn't we move the DecorateAcknowledgementsWithMultipleResponses
type to the BroadcastOperator
class, so we don't have to apply it everytime?
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.
I definitely think that would be nicer; however after looking at the code, I don't think we can.
The BroadcastOperator
has an expectSingleResponse
flag, which changes the behavior between single responses and multiple. With that, the options I see are to either: apply the decorations when switching to a BroadcastOperator
, or to setup the expectSingleResponse as a third generic type parameter on the BroadcastOperator.
This makes DX nicer as typescript will show errors in the file as you work, instead of requiring compilation steps
Awesome work, thanks a lot 👍 |
@ZachHaber Awesome work, thank you for your contribution! However, it seems like your PR caused #4914, is there any chance you can look into this? |
@lts20050703 I'll take a look and see if I can figure that out! |
The kind of change this PR does introduce
Current behavior
The types of the
emit
,emitWithAck
,serverSideEmit
, andserverSideEmitWithAck
have issues with their types.They revert to
any
very often or aren't arrays when they should be (server/namespace emit and server/namespace => broadcastOperator emit).New behavior
This fixes most of this behavior and adds tests for them.
Other information (e.g. related issues)
Fixes #4813