承诺 Socket.IO/EventEmitter [英] Promisify Socket.IO / EventEmitter

查看:17
本文介绍了承诺 Socket.IO/EventEmitter的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我在谷歌上搜索 Promisify Socket.IO 时没有找到太多东西,这让我有点惊讶.有那么不常见吗?

I am a bit surprised by the fact that I don't find much when googling for Promisify Socket.IO. Is it that uncommon?

我自己也很难承诺:

Promise.promisifyAll(io)
io.onceAsync('connect')
.then((socket) => ...)
.catch((err) => console.log(error))

这总是会触发错误情况,我假设是因为 .once 是一个只有一个参数的回调,其中 Promises 期望第一个是错误.知道如何处理这些事情吗?

This always triggers the error case, I assume because .once is a callback with only one argument, where Promises expect the first one to be the error. Any idea how to deal with these kind of things?

推荐答案

我能想到几个为什么 Promise 不适合与 socket.io 和 EventEmitter 接口的原因:>

I can think of several reasons why promises aren't a good fit with socket.io and EventEmitter interfaces in general:

  1. 在大多数情况下,socket.io 是一个事件驱动的接口,并且 promise 在架构上与可以发生多次的事件不一致(因为 promise 是一次性设备).是的,您可以对 .connect() 使用 promise,但不能对传入消息使用 promise.因此,大多数人(包括我自己)可能认为让一半接口使用 Promise 而另一半使用事件处理程序是没有意义的.对整个 API 使用一种模型可能更好.

  1. For the most part, socket.io is an event driven interface and promises do not align architecturally with events that can occur more than once (since a promise is a one-shot device). Yes, you can use a promise for .connect(), but not for incoming messages. So, most people (myself included) probably don't think it makes sense to have half an interface using promises and the other half using event handlers. Likely better to use one model for the whole API.

Promise.promisifyAll() 需要 node.js 样式的异步回调(错误值作为第一个参数,数据作为第二个参数),这不是任何套接字.io 事件处理程序回调使用.要使 Promise 与 connect 事件一起工作,您必须编写自己的自定义 promsification,这可能比仅使用为其编写的事件处理程序要多得多.

Promise.promisifyAll() requires node.js style async callbacks (with error value as the first argument and data as the second argument) and that isn't what any of the socket.io event handler callbacks use. To make promises work with something like the connect event you'd have to write your own custom promsification which is likely more work than just using the event handler it is written for.

上述情况的一个例外可能是,如果您尝试将下一次发生的事件与其他异步事件(通常不会完成的事情)进行协调,在这种情况下,promise 可能对协调有用.例如,假设您想知道三个单独的异步操作何时全部完成,其中一个是 socket.io 事件的下一次发生.然后,手动承诺该事件可能是有意义的,以便您可以使用承诺来协调您的多个异步操作.

An exception to the above might be if you are trying to coordinate the next occurrence of an event with other async events (something that isn't usually done) in which case promises might be useful for the coordination. As an example, supposed you wanted to know when three separate asynchronous operations were all complete, one of which was the next occurrence of a socket.io event. Then, it might make sense to manually promisify that event so you could use promises to coordinate your multiple async operations.

但是对于普通的 socket.io 使用,promise 并不是一个很好的架构适合.同样,您通常不会对网页中的点击处理程序使用承诺.

But for normal socket.io usage, promises just aren't a good architectural fit. Similarly, you wouldn't typically use promises for a click handler in a web page.

仅供参考,如果您只想承诺 connect 操作,您可以像这样手动执行:

FYI, if you want to promisify just the connect operation, you could do that manually like this:

io.connectAsync = function(url, options) {
    return new Promise(function(resolve, reject) {
        io.connect(url, options);
        io.once('connect', function(socket) {
            resolve(socket);
        });
        io.once('connect_error', function() {
            reject(new Error('connect_error'));
        });
        io.once('connect_timeout', function() {
            reject(new Error('connect_timeout'));
        });
    });
}


io.connectAsync().then(function(socket) {
    // connected here
    socket.on('someMsg', function() {
       // process message here
    });
}, function(err) {
    // error connecting here
});

这篇关于承诺 Socket.IO/EventEmitter的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆