Add wildcard support for events

[edmellum]

It would be great if you could use a wildcard to capture all events. For example:

client.on("*", function(data) {

}

[joshrtay]

agreed.

EventEmitter2

[DennisRas]

+1
This would allow us to create filters and what not for all events.

[dvv]

• another dependency
• must be reflected at client side (code?)
• should catchall be called before particular event? or in the order of definition? clarification needed
• only sync behavior -- wouldn't it be better to introduce custom async filters for events?

[525c1e21-bd67-4735-ac99-b4b0e5262290]

+1

only sync behavior -- wouldn't it be better to introduce custom async filters for events?
@dvv

I'm quite interested in this idea.

[tj]

some of the EE2 choices are not what I would consider ideal but I +1 the general idea of this, even if only "*" is supported

[dvv]

truly catchall: manager.on("event", function(client, event, data) {} -- will also allow to reduce number of closures

[mikeal]

i don't remember any resistance to just adding a catchall listener, the only debate I remember was whether or not we use "*" or if we go with another method name like .addGlobalListener()

[hdf]

+1
I too would need a way to intercept all events, and have the specific handler get a look at them, only once I'm done processing it. Mostly for logging purposes would this be needed. Socket.io logger currently only logs to the console, and in a very self righteous way.
dvv -s approach is really to my liking.
In fact maybe it would be a good idea to have us relay the event to any specific handler, and we just get all events, as described by dvv.

[DennisRas]

Please get this issue in motion :)
Would love to see this feature implemented.

[einaros]

Well, ok, I just added EE2 to a branch in my fork: einaros@2107ff0

The branch is at: https://github.com/einaros/socket.io/commits/ee2

Thoughts are most welcome.

[tj]

if EE2 gets rid of the weird method names and adds .on('*') I'd +1 that

[3rd-Eden]

I'm a -1 on EE2

It adds more bloat to the code, we also need to support it on the client side. Which means we would have to ship a extra 11.8 KB library (minified ~3.5kb). But with the up coming mobile market I would like to save as much bytes as possible.

If this is really only about having a wildcard / catch all listeners.. Then this should be done by overriding the existing emit function that just does one extra call to a all listener. This would be like a 3 - 5 LOC change (excluding comments ;)). And should be hidden behind a preference lock as it influence performance. EventEmitting is a hot code path and should always be as optimal and fast as possible. Adding wildcards will degrade performance.

[tj]

catch-all is definitely the more important part, it's easy enough to switch on the event after that if necessary

[hdf]

Don't really care about wildcard's, or EE2, but a way, to intercept all events is a must.

[525c1e21-bd67-4735-ac99-b4b0e5262290]

if EE2 ... adds .on('*') I'd +1 that

TJ you crazy bro...

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

That's from the README of EE2. Naturally, the "foo." is optional.

if EE2 gets rid of the weird method names

I agree.

[tj]

@pyrotechnick the EE2 .on('*') isnt a catch-all iirc

[525c1e21-bd67-4735-ac99-b4b0e5262290]

* is not catch-all in the sense that it blindly catches all events but it does effectively catch all events since the pattern * matches all channels.

It's inefficient; but it does work as expected.

[525c1e21-bd67-4735-ac99-b4b0e5262290]

I was mistaken. You're right...

{EventEmitter2} = require 'eventemitter2'

emitter = new EventEmitter2 wildcard: on

emitter.on '*', ->
  console.log @event, arguments...

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

isabel:hydrogen pyrotechnick$ coffee test.coffee 
foo

I almost prefer this behaviour when it comes to wildcards though.

When I think about all of this wildcard/"namespaced" events stuff it kind of makes me sad; JavaScript already has a fantastic way to match patterns -- they live in // or are constructed with RegExp. Is this just too slow?

[jrperina]

Can I +1 the importance of this again. I'd love to see this in an upcoming release.

[ghost]

Someone posted a solution here: http://stackoverflow.com/questions/8832414/overriding-socket-ios-emit-and-on/8838225

[jrperina]

That doesn't work because I still can't connect to the event. In my application the server doesn't know the name of the room from the client. So I want to be able to respond to all messages for any room and ideally find out the name of the room that the message was sent on.

[mycall]

Add regular expression support for events.. this way, ranges of verbs and nouns can be caught.

[ivzhao]

+1

[mikermcneil]

+1

[tapanpandita]

+1

[alberteddu]

+1

[jcrugzz]

+1

[dmail]

I would be fond of a super global method wich handle everything

io.set('global_listener', function(namespace, event, args, emit){
// do something based on namespace event and arguments
// I can or not call emit() to call event listeners linked with that namespace and that event
});

io.set('global_authorization', function(namespace, handshakeData, callback){
// based on namespace and handshakeData accept or not the connection
});

[HenrikJoreteg]

I needed an emitter that supported catch-alls a. la. socket.on("*"), worked on the client, and was still light weight. So I took @visionmedia's emitter from UI Kit and extended it a bit. Perhaps it would be a decent fit for this. So, for what it's worth. I'll just leave this here: https://github.com/HenrikJoreteg/wildemitter

[rauchg]

@HenrikJoreteg
We might add '*' out of the box to https://github.com/component/emitter.
Also, that emitter is going to power next socket.io. It includes an off shortcut to removeListener which is nice :D

[guiprav]

@rauchg, I'm sorry I said those bad things about socket.io. I was having a bad day. Thank you for this project; it may not be perfect (yet), but it sure is very useful.

Also: hden/socketio-wildcard#13

[rauchg]

@n2liquid all feedback is welcome – thank you (and to @hden for that quick fix on socket.io-wildcard).

[akotlar]

scoketio-wildcard seems like a perfectly valid solution. I found myself also wanting to get the event name in callback, so that I could wrap the socket listener and propagate events through the wrapper, rather than directly exposing the socket to the rest of my application. My understanding is that this would require Event Emitter 2 if I wanted to do this with a wildcard. Is this just something silly to do, better to directly expose the socket? Something based on listening for 'newListener' in the wrapper (but don't know how to trigger on socket event, only how to register the socket event based on the calling functions registering a new event in the wrapper)? Anyone else interested in being able to access the event name within the callback?

[hden]

@akotlar The event name is available in the callback if you are using scoketio-wildcard.

[akotlar]

Ah, thanks! It may be useful to specify this in the socket.io-wildcard readme.

[alexey-sh]

how it's going?
+1 for on("*", function () { for both client and server

[emin93]

+1 all the way

[hden]

@alexey-sh @emin93 If you would kindly read the document from https://github.com/hden/socketio-wildcard, yes it's possible to do so for both client and server.

[emin93]

@hden Thanks and yes i saw that and i'm already using it. But it's an extra dependency and nothing speaks against integrating it directly into Socket.IO core, that's why it gets a +1 from me.

[mkhahani]

It can be handled in the app logic using one event name for all events:

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

[juanpaulo]

+1 even though issue is closed.

[crobinson42]

+💯 bang!

[materazu]

+1 !!!!

[darrachequesne]

Please use socket.use.

[carpii]

Is there a way to hook into engine.io's PING/PONG mechanism using socket.use() ?

I am having an issue where many users are losing connection, and despite extensive logging on server, it just says they disconnected due to Ping Timeout.

I'd like to log the PING/PONG packets, but it seems socket.use() can only hook into the high level user-event messages, and not engine.io's underlying protocol

[freeman3s]

+1

[gtk2k]

+1

[bolajipemipo]

+1 since 2011? They ain't doing it. :(

[darrachequesne]

Again, socket.use was added for that matter: https://socket.io/docs/server-api/#socket-use-fn

[ghost]

@darrachequesne I don't see how a method on the server-side helps with this request (which is for the client).

[pecknigel]

Any more on this? Since socket.use is only for the server, why is this ticket closed?

[bor8]

I don't understand socket.use. How to replace

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

with something like

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

or

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

---

Found a small workaround - listing all possibilities:

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

[numandev1]

can i use subscribe like this socket.on('posting/*'
where I wanna get all posting like this
posting/1
posting/2
posting/3

[darrachequesne]

@nomi9995 no, but implementing this should be quite straightforward:

socket.onAny((eventName, ...args) => {
  if (/posting\/.*/.test(eventName)) {
    // ...
  }
});

Reference: https://socket.io/docs/v4/listening-to-events/#socketonanylistener