You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently middlewares are limited to hook before the server aknowledges a clients message, but it can't hook on the client acknowledging from the client.
Currently data validation logic needs to be rewritten in the logic of every emited with acknowledgements, that may result in a lot of boiler plate code.
New behavior
Introduced the useOutgoing((event: [string, ...any[]], next: (err?: Error) => void) => void) method.
It is behaving much like regular use() does, but before the messages are being sent from the server to the client.
(They do run before the catch all listeners and before the acknowledgement callback gets popped to the ack manager in order to be able to edit the event, or abort it).
Example:
io.on("connection",(socket)=>{socket.useOutgoing((event,next)=>{if(event.length&&typeofevent[event.length-1]==='function'){constcallback=event[event.length-1];event[event.length-1]=(...args)=>{// able to hook right before the acknowledgement callback is executed.callback(...args);}}// do not forget to call nextnext();});});
Other information (e.g. related issues)
I disscussed other option briefly in this issue #4882.
For short, the tricky part about this, is that one might want access to the context of the event that originated the ack repsonse whilst consuming what the client acknowledged. Else it would be of no use hooking there, except for logging purposes I guess.
This would be a solution that doesn't disrupt current usage of Socket.IO, and we have access to the context of the event.
Is this PR basically allowing to add event emit interceptors? It could be a great way to allow acknowledgement caching, in the same way that axios-cache-interceptor does it for Axios requests :-)
Is this PR basically allowing to add event emit interceptors? It could be a great way to allow acknowledgement caching, in the same way that axios-cache-interceptor does it for Axios requests :-)
I haven't played with axios around yet. But from what I read from the axios-cache-interceptor docs the idea of this PR is similar to the interceptors, even tho the implementation varies a little bit. I based my implementation on the socket.io socket middlewares implementation so it works the same (unlike axios cache interceptors where inbound interceptors are FILO and outblound are FIFO).
The main point stands of being able to hook into and filter properly in and outbound requests is the same.
NyaStone
changed the title
Adding support to add middlewares on emitted events
Adding support for middlewares intercepting outgoing events
Dec 22, 2023
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The kind of change this PR does introduce
Current behavior
Currently middlewares are limited to hook before the server aknowledges a clients message, but it can't hook on the client acknowledging from the client.
Currently data validation logic needs to be rewritten in the logic of every emited with acknowledgements, that may result in a lot of boiler plate code.
New behavior
Introduced the useOutgoing((event: [string, ...any[]], next: (err?: Error) => void) => void) method.
It is behaving much like regular use() does, but before the messages are being sent from the server to the client.
(They do run before the catch all listeners and before the acknowledgement callback gets popped to the ack manager in order to be able to edit the event, or abort it).
Example:
Other information (e.g. related issues)
I disscussed other option briefly in this issue #4882.
For short, the tricky part about this, is that one might want access to the context of the event that originated the ack repsonse whilst consuming what the client acknowledged. Else it would be of no use hooking there, except for logging purposes I guess.
This would be a solution that doesn't disrupt current usage of Socket.IO, and we have access to the context of the event.