Socket.io @SubscribeMessage should return acknowledgment instead of new emit?

[MickL]

I'm submitting a...

[ ] Regression 
[ ] Bug report
[X] Feature request
[ ] Documentation issue or request
[ ] Support request

Current behavior

@SubscribeMessage return statement does a new client.emit() instead of sending a response(acknowledgement):

    @SubscribeMessage('someMessage')
    onSomeMessage(client, data: any) {
        return {event: 'someResponse', data: 'Im a separate message' };
    }

In contrast something like @Get() returns the response:

  findAll(@Param('id') id) {
      return `Returning cat with id ${id}...`;
  }

Expected behavior

Wouldn't it make sense (logically + for consistency) to have the return statement actually return a response (acknowledgement) to the received message?

   @SubscribeMessage('someMessage')
    onSomeMessage(client, data: any) {
        return 'Response to someMessage';
    }

And for sending separate messages explicitly emit a new message?

   @SubscribeMessage('someMessage')
    onSomeMessage(client, data: any) {
       client.emit(event: 'otherMessage', 'Send a different message'); // Or somehow different it this way we cant use interceptors
    }

[AndyGura]

@MickL I wrote separate module to do it:
https://www.npmjs.com/package/nestjs-socket-handlers-with-ack

Looking forward to see this functionality built-in in NestJS

[kamilmysliwiec]

It is something that applies solely to socket.io. Since we need to support different platforms as well, we have to provide a more generic solution. However, this sounds reasonable:

1. When returned value is nil, don't emit anything.
2. When returned value is an object with event property, emit an event.
3. When returned value is an object without event property, send response (acknowledgement)

[MickL]

Sounds perfect to me!

[kamilmysliwiec]

Done in 5.3.0 :)

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.