Is Socket derived from EventEmitter?

[thomas-huegel]

Hi,
In Node.js, Socket is derived from EventEmitter, which enables one to use Rx.Observable.fromEvent() on Socket objects.
Afaik, it does not seem to be the case in 0MQ, at least in the TypeScript declaration file.
Am I wrong? Would it be complicated to have Socket derive from EventEmitter (as claimed in the book of Jim Wilson) ?
Otherwise, how can one make an Rx.Observable from a zmq.Socket ?
Thank you.

[rolftimmermans]

Yes, it inherits from EventEmitter here https://github.com/zeromq/zeromq.js/blob/master/lib/index.js#L318

[rgbkrk]

We use this library with RxJS in @nteract by using fromEvent like this:

export function createObservable(socket) {
  return fromEvent(socket, "message").pipe(
    map(msg => {
      // Conform to same message format as notebook websockets
      // See https://github.com/n-riesco/jmp/issues/10
      delete msg.idents;
      return msg;
    }),
    publish(),
    refCount()
  );
}

Since we use it in two directions, we also create a subscriber like this:

export function createSubscriber(socket) {
  return Subscriber.create({
    next: messageObject => {
      socket.send(new jmp.Message(messageObject));
    },
    complete: () => {
      // tear it down, tear it *all* down
      socket.removeAllListeners();
      socket.close();
    }
  });
}

And then form a Subject with both of those so we have a full duplex communication on top of Rx:

export function createSubject(socket) {
  const subj = Subject.create(
    createSubscriber(socket),
    createObservable(socket)
  );
  return subj;
}

By the sound of it, I think this means that the typescript definition is not completely accurate. Where do you get it from?

[thomas-huegel]

Thank you for your answers, I think that my problem lies in the TS definition file from @types/zeromq@4.5.3 where zmq.Socket is not derived from anything.
Line 59 of index.d.ts declares: export class Socket {

[rolftimmermans]

The latest 6.0 beta release is written in TypeScript so there should no longer be a mismatch in the type definitions. It would be great if you could try it out! The new version has a new API that addresses some fundamental issues with the previous API, but it does include a compatibility layer that should make upgrading easier. See #189 for the reasoning behind the new API.

If you run into any problems feel free to report it here or in a new issue.