Socket.io: There needs to be a wildcard feature in event handling

[viziionary]

Note: The 'anything' event in docs can be confused as a global event, but of course isnt.

There should exist something to the effect of:

socket.wildcard = 'myWildcardValue';
socket.on('myWildCardValue', function(eventName, data){
    //handle all incoming events
}

See:

http://stackoverflow.com/questions/10405070/socket-io-client-respond-to-all-events-with-one-handler

http://stackoverflow.com/questions/32552155/how-do-i-handle-all-incoming-socket-events-rather-than-a-specific-one

http://stackoverflow.com/questions/32552481/did-the-socket-io-global-event-end-up-in-release?noredirect=1#comment52961409_32552481

Because there's no support for this, developers are having to modify Socket.io client side (note, the node.js patch for this is not applicable client side) with code like this:

var socket = io.connect();
var globalEvent = "*";
socket.$emit = function (name) {
    if(!this.$events) return false;
    for(var i=0;i<2;++i){
        if(i==0 && name==globalEvent) continue;
        var args = Array.prototype.slice.call(arguments, 1-i);
        var handler = this.$events[i==0?name:globalEvent];
        if(!handler) handler = [];
        if ('function' == typeof handler) handler.apply(this, args);
        else if (io.util.isArray(handler)) {
            var listeners = handler.slice();
            for (var i=0, l=listeners.length; i<l; i++)
                listeners[i].apply(this, args);
        } else return false;
    }
    return true;
};
socket.on(globalEvent,function(event){
    var args = Array.prototype.slice.call(arguments, 1);
    console.log("Global Event = "+event+"; Arguments = "+JSON.stringify(args));
});

[viziionary]

Client side modification of socket.io could interfere with new or existing syntax of Socket.io, why not give us an officially supported wildcard option?

It can't hurt. Just define a null wildcard property on the io object and if it's defined when handling events, route all events through that event's handler.

[denghongcai]

you can try my pr, more advanced feature

2247

[fourpixels]

I would so love this! I was already trying to figure out a cleaner implementation, but never got there. This is needed for so many things like spam filter and global commands. Having all commands use the same id and then send object with further description of the package is insane..

[Michael77]

+1000

[viziionary]

yeah, it's been months though and the devs haven't said anything back. I'm actually not quite skilled enough in JS to make a good pull request on a code-base this advanced, does anyone else have the skill / desire to add this via pull request and see what the devs think?

[nkzawa]

https://github.com/hden/socketio-wildcard is not enough for you?

[viziionary]

@nkzawa That's server side, what about client side?

[viziionary]

Also, many people seem to agree that this should be a native feature.

[fourpixels]

@nkzawa are there any negative sides of adding just another emit to onevent function in Socket (server side)? The _socketio-wildcard_ package is overriding the basic functionality, which I think is a bit dangerous in terms of keeping things up-to-date in different packages. In terms of client-side I too agree this could be done better and without monkey-patching.

@denghongcai The idea of middleware might be pretty handy, but I think a simple emit will be more robust solution.

[denghongcai]

@fourpixels if you need simple emit you can try https://github.com/hden/socketio-wildcard
socket middleware can used to validate data and limit message send rate

[fourpixels]

I know I can use some third party packages - I can even create my own. But is this really needed when we talk about something so simple and fundamental? Is it going to hurt so much implementing it? When developers start spending time hacking into the system in order to do something very simple and commonly used, then this is a clear sign something's wrong and action is needed.

Also I don't see how socketio-wildcard is going to work on the client side, when there is module.exports and require functions there.. which means no plain JS.

[viziionary]

Yeah I have no idea why Socket.io devs are still ignoring this / refusing to implement it natively.

[juanpaulo]

I would love to see this feature soon!

[fourpixels]

Seems like this is never going to happen :)

[viziionary]

Yeah guess not.

[whitecolor]

Is there a real need for this? Imo it's just brings ambiguity. If you have something of dynamic nature for event names (that you want to handle in single scope) it should probably go inside event payload (data). It is just the matter of design, usually event handlers for events has either obligatory event type parameter, or in second design case, they don't have such parameter at all, socket.io choosed the first option.

[fourpixels]

It's a pretty common approach to do something on each event that is dispatched - I can't understand how this might be a problem. Instead of repeating code on each handler (and having huge notes so that if someone adds new listener on a different file to remember to execute the common thing) you can easily have a wildcard.
I can't imagine it being soooo hard to implement, come on! If there are people needing it and it won't break anything, then why not do it?

[whitecolor]

If there are people needing it and it won't break anything, then why not do it?

Because it is not needed and may encourage wrong design decisions. Event names are supposed to be kind of static things defined by domain, you should be explicit about it.

[fourpixels]

The fact that you don't need it doesn't mean it's not needed at all :) I would like to know how you will implement a spam filtering system (let's say not getting more than X messages in Y time) without this feature in a somehow not-that-hackish way?

[Michael77]

How about a middleware method, such as socket.use(middlewareFunc)?
This way, it won't pollute the event matching logic, and people will get what they are asking for.

[whitecolor]

Yes I would say that it is more correct to implement traffic filtering on a different level of abstraction.

[darrachequesne]

socket.use is now available in 1.6.0 (thanks to those PR https://github.com/socketio/socket.io/pull/2306 & https://github.com/socketio/socket.io/pull/2356).