Socket.io: 为事件添加通配符支持

同意。

事件发射器 2

+1
这将允许我们为所有事件创建过滤器。

• 另一个依赖
• 必须反映在客户端（代码？）
• 应该在特定事件之前调用 catchall 吗？ 还是按照定义的顺序？ 需要澄清
• 只有同步行为——为事件引入自定义 _async_ 过滤器不是更好吗？

+1

只有同步行为——为事件引入自定义异步过滤器不是更好吗？
@dvv

我对这个想法很感兴趣。

一些 EE2 选择不是我认为的理想选择，但我 +1 对此的总体想法，即使只支持“*”

真正包罗万象： manager.on("event", function(client, event, data) {} -- 也将允许减少关闭次数

我不记得仅仅添加一个包罗万象的监听器有任何阻力，我记得的唯一争论是我们是否使用“*”或者我们是否使用另一个方法名称，如 .addGlobalListener()

+1
我也需要一种方法来拦截所有事件，并让特定的处理程序查看它们，只有在我完成处理之后。 主要用于记录目的，这将是必需的。 Socket.io 记录器目前仅以一种非常自以为是的方式记录到控制台。
dvv -s 方法真的很合我的口味。
事实上，让我们将事件中继到任何特定的处理程序可能是个好主意，我们只获取所有事件，如 dvv 所述。

请让这个问题动起来:)
很想看到这个功能实现。

好吧，我刚刚将 EE2 添加到我的分支中的一个分支： https :

该分支位于： https :

想法是最受欢迎的。

如果 EE2 去掉奇怪的方法名称并添加.on('*')我会+1

我在 EE2 上是 -1

它给代码增加了更多的膨胀，我们还需要在客户端支持它。 这意味着我们必须提供一个额外的 11.8 KB 库（缩小约 3.5kb）。 但随着即将到来的移动市场，我想尽可能多地节省字节。

如果这真的只是关于有一个通配符/捕获所有侦听器..那么这应该通过覆盖现有的发射函数来完成，该函数只对all侦听器进行一次额外调用。 这就像 3 - 5 个 LOC 更改（不包括注释；)）。 并且应该隐藏在偏好锁后面，因为它会影响性能。 EventEmitting 是一个热门代码路径，应始终尽可能优化和快速。 添加通配符会降低性能。

包罗万象绝对是更重要的部分，如有必要，在此之后打开事件很容易

不要真正关心通配符或 EE2，但必须有一种拦截所有事件的方法。

如果 EE2 ... 添加 .on('*') 我会 +1

TJ你疯了兄弟...

server.on('foo.*', function(value1, value2) {
  console.log(this.event, value1, value2);
});

这是来自 EE2 的 README。 自然是“foo”。 是可选的。

如果 EE2 去掉奇怪的方法名称

我同意。

@pyrotechnick EE2 .on('*')不是一个包罗万象的 iirc

*并不是万能的，因为它盲目地捕获所有事件，但它确实有效地捕获了所有事件，因为模式*匹配所有通道。

效率低下； 但它确实按预期工作。

我错了。 你是对的...

{EventEmitter2} = require 'eventemitter2'

emitter = new EventEmitter2 wildcard: on

emitter.on '*', ->
  console.log <strong i="6">@event</strong>, arguments...

emitter.emit 'foo'
emitter.emit 'foo.bar'

isabel:hydrogen pyrotechnick$ coffee test.coffee 
foo

不过，当涉及到通配符时，我几乎更喜欢这种行为。

当我想到所有这些通配符/“命名空间”事件时，我有点难过； JavaScript 已经有一种匹配模式的绝妙方法——它们存在于 // 中或使用RegExp构建。 这只是太慢了吗？

我可以再次+1 这一点的重要性吗？ 我很想在即将发布的版本中看到这一点。

有人在这里发布了一个解决方案： http :

这不起作用，因为我仍然无法连接到该事件。 在我的应用程序中，服务器不知道客户端的房间名称。 因此，我希望能够回复任何房间的所有消息，并在理想情况下找出发送消息的房间的名称。

为事件添加正则表达式支持.. 这样，可以捕获动词和名词的范围。

+1

+1

+1

+1

+1

我会喜欢处理一切的超级全局方法

io.set('global_listener', function(namespace, event, args, emit){
// 根据命名空间事件和参数做一些事情
// 我可以或不调用emit() 来调用与该命名空间和该事件链接的事件侦听器
});

io.set('global_authorization', function(namespace, handshakeData, callback){
// 基于命名空间和握手数据接受或不接受连接
});

我需要一个支持包罗万象的发射器。 洛杉矶 socket.on("*") ，在客户端上工作，仍然很轻。 所以我从 UI Kit 中取出了@visionmedia的发射器并对其进行了扩展。 也许它很适合这个。 所以，它的价值。 我把这个留在这里： https :

@HenrikJoreteg
我们可能会在https://github.com/component/emitter 中添加“*”
此外，该发射器将为下一个 socket.io 供电。 它包括一个off到removeListener快捷方式，这很好：D

哦，太棒了！

+1

++

+1

+1

+1

+1

+=1

+1

+1

+1

+1

有没有人为此努力过？ 有什么线索吗？

我有一个 _sort of_ 解决方案，可以很好地满足我们需要它的目的，但它不是一个完整的通配符解决方案......更像是'*'的实现

https://github.com/Attorney-Fee/socket.io

+1

+1

+1

+1

+1

+1

我讨厌发表没有任何意义的评论，但是这已经被要求 2 年了，而且所有建设性的东西都已经说了。 所以...

+1

这将很容易添加到用户空间中，我认为不需要在核心代码库中使用它。 如果我可以帮助使用任何钩子来更轻松地扩展事件发射器功能，而无需进行过多的猴子修补，我将很乐意这样做。

这将如何在用户空间中实现？ 我见过的所有解决方案都涉及分叉代码库，有些人已经完全链接到不同的库。

在我的情况下，我只需要一个简单明了的“在一个函数中绝对捕获所有内容”，但 RegEx 支持似乎（对于没有仔细查看源代码的人）太困难，而且肯定会非常有用. 我一直在 Express.JS 路由中使用正则表达式； 能够在 socket.io 中做同样的事情会很好。

传输层/协议将保持不变。 您只需在两端覆盖 'emit' 不仅可以简单地进行地图查找，还可以进行更全面的（基于正则表达式的）搜索。

快速实施建议：

• 当在事件名称中找到“*”时，覆盖on以维护正则表达式的特殊数据结构
• 覆盖emit以首先执行快速案例（常规地图查找），然后通过 '*' 侦听器并查看它们是否匹配。

显然，这不需要叉子。 我所说的钩子的意思是我们可能会找到一个不需要猴子补丁的解决方案，但考虑到这 2 种方法非常简单，我不认为这是一个大问题。

出于好奇，我们不能从用户空间覆盖 socket.Manager.prototype.onClientMessage 吗？

我这样做了并且工作得很好，在节点中，socket.io 模块没有任何变化。 不是很漂亮，可能会坏，但至少你避免分叉。

https://gist.github.com/lmjabreu/5714985

难道不能简单地在需要 socket.io 之前在某处添加process.EventEmitter = require('eventemitter2').EventEmitter2吗？ 这似乎对我有用...

打开原型绝对不是用户态修复。 我知道除了简单的 socket.on('*') 之外，不想实现完整的正则表达式支持或任何东西都会有很长的路要走。

这张票现在已经2岁了。

是否有任何计划来解决它，因为它显然是一个有用的功能？

如果答案是否定的，我想自己分叉并添加它。
但我宁愿只在它可能被合并回上游时才这样做。

请问各位开发者能解答一下吗？

同意几乎所有评论，花哨的东西可以更多或更少争论，但包罗万象会很好。 用户可以自己做，但预定义的程序会更清晰。

很遗憾这不存在。

它确实存在，请参阅之前某人发布的链接
http://stackoverflow.com/questions/8832414/overriding-socket-ios-emit-and-on/8838225

我正在使用它，并且效果很好:)

+1

在我看来，对这样简单的东西进行猴子修补似乎是一种不好的做法，但是，我认为不应该使用大的实现，像Backbone.Events这样简单的东西对于这个问题中的大多数开发人员来说就足够了，我认为。 （虽然Backbone不使用“*”，而是使用“all”来表示全局事件，传入最初调用的事件名称，这才是最好的做法）。 （不过，这只是一个建议）=）

个人对 RegExp 方式 +1，与"*"通配符相比，感觉更多的 Javascript 和更少的控制台。

但就像最新的声音一样，包罗万象的功能似乎更合适。

不确定这是否真的是 socket.io 问题。

归咎于 IMO 的冻结 API。

：+1：

如果有人阅读了这个线程并且仍在寻找一种在 0.9.x 和 1.0.0 上使用通配符事件的方法： https ://www.npmjs.org/package/socketio-wildcard

精彩@geoah ！

@guille hehe，这不是我的，我只是偶然发现的。 谢谢你的辛勤工作 btw ^_^

昨晚为 socket.io 开发了一个中间件。

https://www.npmjs.org/package/socket.io-events

+1
当数据总是以相同的方式处理时，减少创建新侦听器的开销会很好。
@geoah感谢您的中间件，正是我所需要的！

如果中间件工作正常，那么 socket.io 应该保持原样。

这是我个人认为作为 socket.io 本身的一部分非常有意义的事情之一。 除了“这不是这里做事的方式”之外，我认为没有任何理由将其排除在外，这从来都不是一个很好的论点。

争论是我们试图像节点EventEmitter ，而节点没有这个，所以它会变成一个“socket.io-ism”。 在 Node 中有关于添加它的广泛讨论，但没有通过。

@chevex虽然这最初也是我的感觉，但新的中间件支持使您可以轻松添加。 以 socketio-wildcard 为例，导入和使用非常简单； 它可能最终会像 express.js 一样，其中有一些我几乎总是包含的中间件。

这些都是更好的论据。 我猜您不希望 EventEmitter 在默认情况下与节点的行为不同。 @DanH42我也认为你是对的，用中间件来增强它对那些需要它的人来说更有意义。 我收回我的陈述:)

如果只有节点的 EventEmitter 支持开箱即用的通配符。

：+1：

我看到我错过了这个问题，我开始了一个关于转发事件的新问题：
https://github.com/Automattic/socket.io/issues/1715
它包括两种方法来处理来自 socket.io 1.0 的所有事件而不改变它的源。

我只是想要这个用于调试。 我没有权限在我们的项目中添加或修改库。 ：哭泣：

+1
有时，您需要了解所有正在传播的事件！

+1

• 1

我最终使用了 hden 的socketio-wildcard模块； 这似乎是最透明的方法（通过使用中间件）并且对我来说效果很好。 但是 :+1: 把它变成核心！

谢谢马特！ 我被淹没了，但我希望有一个周末来做一些
改进

从我的iPhone发送

2015 年 1 月 6 日上午 8:30，Matt Fletcher [email protected]写道：

我最终使用了@NathanGRomano https://github.com/NathanGRomano的
socketio-events https://www.npmjs.com/package/socket.io-events模块； 它
似乎是最透明的方法（通过使用中间件）并且效果很好
对我来说很好。 但是 [image: :+1:] 将其纳入核心！

—
直接回复此邮件或在 GitHub 上查看
https://github.com/Automattic/socket.io/issues/434#issuecomment -68864750。

+1

+1

++++++

+1 对调试很有用。

如果只是有人在做这件事，我想试一试。 我需要一些来学习 socket.io 代码库，我可能会花一些时间研究其他此类实现。 您对正则表达式模式有何看法？ 太慢了？ 当然，如果不考虑合并，我不会浪费我的时间（我不在乎我的实现是否被拒绝，但如果没有兴趣，那又何必呢，对吧？）。 请维护者指点一下？

我写了一个库 socket.io-events。 我被工作和需要淹没了
再次触摸它。 我想用它来支持致谢

2015 年 7 月 25 日星期六，John Manko通知@ github.com 写道：

如果只是有人在做这件事，我想给它一个
射击。 我需要一些来学习 socket.io 代码库，我可能会
花一些时间看看其他这样的实现。 你的是什么
关于正则表达式模式的想法？ 太慢了？ 当然，我不会浪费我的
时间，如果它不是考虑合并的东西（我不
关心我的实施是否被拒绝，但如果没有兴趣，那为什么
打扰了，对吧？）。 请维护者指点一下？

—
直接回复此邮件或在 GitHub 上查看
https://github.com/socketio/socket.io/issues/434#issuecomment -124901706。

+1

+1 这个问题已经存在 5 年了。 为什么没有再次添加通配符支持？

+1

+1

+1

+1

+666

+1

伙计们，认真的。 每个人都想要这个功能——我想他们明白了。 让我们都停止加号，好吗？ 我宁愿在问题有一些实际进展时收到更新电子邮件。

也就是说，知道很多人感兴趣是很有用的。
我认为理想情况下 GitHub 应该有一个投票系统？

投票系统会很棒，但似乎不太可能很快发生。

我想问题是一个解决方案现在已经发布了很多次，但由于所有的 +1 评论而滚动出视图。

socketio-wildcard 模块对我来说运行良好（不可否认，我还没有更新到最新的节点）。
如果有人能解释为什么这个库不合适，那会很有用吗？

是的， socketio-wildcard工作得很好，但它仍然是一个额外的依赖项，它是如此简单，以至于将其引入核心并一劳永逸地结束整个问题线程会很好。 此外，它消除了任何混淆的余地，即哪个是最好的外部模块使用（通常名称相似）。 也同意如果 GitHub 有一个投票系统会很好，如果只有一种我们可以投票的方式......！

我可能很笨，但我不知道如何使用 IO 客户端对象设置 socketio-wildcard。 这应该认真地，_认真地_ 包含在核心中。 如果 socket.io 的维护者不想这样做，那么应该有人 fork 这个项目，我们都可以搬到那里去，因为这太荒谬了，老实说，我现在对 socket.io 的信任为零。

我知道维护者不必接受每一个提议，但是这个？ 这完全让我感到困惑。 一路走好。

@n2liquid不清楚这应该是核心，但欢迎讨论。 例如，没有其他 Node 事件发射器以这种方式运行，即使在那里也进行了讨论。

@rauchg

不清楚这应该是核心，但欢迎讨论

那我们可以讨论一下吗？

我可以理解您的观点，即这种发射器在节点世界中不一定很常见，但这取决于您要实现的目标......
是严格遵守约定还是提供一个真正有用的库？

很明显，socket.io 的许多用户在没有此功能作为核心功能的情况下确实陷入困境，并且用户期望它应该是合理的。

或者换句话说，在 socket.io 中不提供此功能的论据是什么？
即使实现不是“教科书正确的”，它也会导致在 socket.io 中实现这些“catchall”处理程序的标准方法，而不是人们不得不求助于许多不同的库和方法。
将人们引导到第三方库或解决方法只会使事情变得碎片化，并且尝试维护使用 socket.io 的代码库变得更加脆弱

我宁愿有一个正式的方法来处理catchall包，然后如果以后需要更改，至少可以有一个推荐的迁移程序，而不是让用户自行寻找穿越荒野的路线

@rauchg我认为实现这一点的一种很酷的方法是有一个socket.use(function(data,next){..})函数来捕获套接字上的所有事件，并传递一个 next() 函数，该函数将控制权从 catchall 传递给后续的 catchall 或默认事件处理程序.

这就是我现在使用 socket.io 的方式，因为我需要一种方法来限制每分钟发生的事件数量，我认为这是一个常见用例。 感谢您阅读我的 2 美分。

我最喜欢@Michael77的解决方案。 它不涉及事件发射器接口或实现，甚至允许比我们在这里要求的更多的东西（例如@Michael77的消息限制实现，谁知道还有什么）。

我知道 socket.io 中有一个中间件/使用函数，但它不能在客户端库上使用，而且我不确定它是否用于相同的目的。

@carpii总是有很多理由_不_支持某些东西：增加复杂性，减少熟悉度。 此功能检查两者。

我非常喜欢socket.use想法，在此之上可以轻松地在客户端上实现通配符扩展。

感谢@carpii @Michael77 @n2liquid对此 btw 的反馈。

@rauchg ，对不起，我说了那些关于 socket.io 的坏话。 我度过了糟糕的一天。 谢谢你的这个项目； 它可能并不完美（还），但它确实非常有用。

另外： https :

欢迎@n2liquid _all_ 反馈——谢谢（感谢@hden对socket.io-wildcard 的快速修复）。

scoketio-wildcard 似乎是一个完全有效的解决方案。 我发现自己也想在回调中获取事件名称，以便我可以包装套接字侦听器并通过包装器传播事件，而不是直接将套接字暴露给我的应用程序的其余部分。 我的理解是，如果我想使用通配符执行此操作，则需要 Event Emitter 2。 这只是愚蠢的事情，最好直接暴露套接字吗？ 基于在包装器中侦听“newListener”的东西（但不知道如何触发套接字事件，只知道如何根据在包装器中注册新事件的调用函数来注册套接字事件）？ 还有其他人对能够在回调中访问事件名称感兴趣吗？

@akotlar如果您使用 scoketio-wildcard，则事件名称在回调中可用。

啊，谢谢！ 在 socket.io-wildcard 自述文件中指定它可能很有用。

最近怎么样？
+1 为on("*", function () {客户端和服务器

一路+1

@alexey-sh @emin93如果您愿意从https://github.com/hden/socketio-wildcard阅读文档，是的，客户端和服务器都可以这样做。

@hden谢谢，是的，我看到了，我已经在使用它了。 但它是一个额外的依赖项，没有什么可以反对将它直接集成到 Socket.IO 核心中的，这就是为什么它从我这里得到 +1。

它可以在应用程序逻辑中对所有事件使用一个事件名称来处理：

socket.emit('public-event', {'type': 'login', ...});
socket.emit('public-event', {'type': 'logout', ...});

+1 即使问题已关闭。

+💯 砰！

+1 !!!!

请使用socket.use 。

有没有办法使用 socket.use() 连接到 engine.io 的 PING/PONG 机制？

我遇到了许多用户失去连接的问题，尽管在服务器上进行了大量登录，但它只是说由于 Ping 超时而断开连接。

我想记录 PING/PONG 数据包，但似乎 socket.use() 只能挂钩到高级用户事件消息，而不是 engine.io 的底层协议

+1

+1

+1 自 2011 年以来？ 他们不这样做。 :(

同样，为此添加了socket.use ： https: //socket.io/docs/server-api/#socket -use-fn

@darrachequesne我不知道服务器端的方法如何帮助处理这个请求（这是针对客户端的）。

还有这方面的吗？ 既然socket.use只针对服务器，为什么这张票被关闭了？

我不明白socket.use 。 如何更换

// Server
io.in('room1').emit('backend', data_out);
io.in('room1').emit('frontend', data_out);

像

// Server
io.in('room1').emit('*end', data_out);  // not working code - proper regex would be nice

或者

// Client
socket.on('*end', function(data){  // not working code - proper regex would be nice

找到了一个小的解决方法 - 列出所有可能性：

// Client
var lala = function(data){ 
    // example
}
socket.on('backend', lala);
socket.on('frontend', lala);