Socket.io: Agregue compatibilidad con comodines para eventos

acordado.

EventEmitter2

+1
Esto nos permitiría crear filtros y lo que no para todos los eventos.

• otra dependencia
• debe reflejarse en el lado del cliente (código?)
• ¿Se debe llamar a catchall antes de un evento en particular? o en el orden de definición? aclaración necesaria
• solo comportamiento de sincronización: ¿no sería mejor introducir filtros _async_ personalizados para eventos?

+1

solo comportamiento de sincronización: ¿no sería mejor introducir filtros asíncronos personalizados para eventos?
@dvv

Estoy bastante interesado en esta idea.

algunas de las opciones de EE2 no son lo que yo consideraría ideales, pero hago +1 en la idea general de esto, incluso si solo se admite "*"

verdaderamente atrapante: manager.on("event", function(client, event, data) {} - también permitirá reducir el número de cierres

No recuerdo ninguna resistencia a simplemente agregar un oyente general, el único debate que recuerdo fue si usamos o no "*" o si usamos otro nombre de método como .addGlobalListener ()

+1
Yo también necesitaría una forma de interceptar todos los eventos y hacer que el controlador específico los vea, solo una vez que termine de procesarlos. Principalmente para propósitos de registro, esto sería necesario. El registrador de Socket.io actualmente solo inicia sesión en la consola, y de una manera muy moralista.
El enfoque de dvv -s es realmente de mi agrado.
De hecho, tal vez sería una buena idea que retransmitiéramos el evento a cualquier controlador específico, y obtenemos todos los eventos, como lo describe dvv.

Ponga en marcha este problema :)
Me encantaría ver implementada esta función.

Bueno, está bien, acabo de agregar EE2 a una rama en mi bifurcación: https://github.com/einaros/socket.io/commit/2107ff00f3ddf2d781d3e3c3b7dfb1fc990f7ec5

La sucursal está en: https://github.com/einaros/socket.io/commits/ee2

Los pensamientos son bienvenidos.

si EE2 se deshace de los nombres de métodos extraños y agrega .on('*') , haría +1 en eso

Soy un -1 en EE2

Agrega más hinchazón al código, también necesitamos admitirlo en el lado del cliente. Lo que significa que tendríamos que enviar una biblioteca adicional de 11,8 KB (minificada ~ 3,5kb). Pero con el mercado móvil que se avecina, me gustaría ahorrar la mayor cantidad de bytes posible.

Si realmente se trata solo de tener un comodín / capturar a todos los oyentes ... Entonces esto debería hacerse anulando la función de emisión existente que solo hace una llamada adicional a un all oyente. Esto sería como un cambio de 3 a 5 LOC (sin incluir comentarios;)). Y debe ocultarse detrás de un bloqueo de preferencia, ya que influye en el rendimiento. EventEmitting es una ruta de código activo y siempre debe ser lo más óptima y rápida posible. Agregar comodines degradará el rendimiento.

catch-all es definitivamente la parte más importante, es bastante fácil activar el evento después de eso si es necesario

Realmente no me preocupan los comodines o EE2, pero una forma de interceptar todos los eventos es imprescindible.

si EE2 ... agrega .on ('*') haría +1 en eso

TJ, hermano loco ...

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

Eso es del README de EE2. Naturalmente, el "foo". es opcional.

si EE2 se deshace de los nombres de métodos extraños

Estoy de acuerdo.

@pyrotechnick el EE2 .on('*') no es un iirc general

* no es todo en el sentido de que captura ciegamente todos los eventos, pero efectivamente captura todos los eventos ya que el patrón * coincide con todos los canales.

Es ineficiente; pero funciona como se esperaba.

Estaba equivocado. Tienes razón...

{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

Sin embargo, casi prefiero este comportamiento cuando se trata de comodines.

Cuando pienso en todas estas cosas de eventos con comodines / "espacios de nombres", me entristece un poco; JavaScript ya tiene una forma fantástica de hacer coincidir patrones: viven en // o están construidos con RegExp . ¿Es esto demasiado lento?

¿Puedo +1 en la importancia de esto de nuevo? Me encantaría ver esto en un próximo lanzamiento.

Alguien publicó una solución aquí: http://stackoverflow.com/questions/8832414/overriding-socket-ios-emit-and-on/8838225

Eso no funciona porque todavía no puedo conectarme al evento. En mi aplicación, el servidor no conoce el nombre de la habitación del cliente. Así que quiero poder responder a todos los mensajes de cualquier sala e idealmente averiguar el nombre de la sala a la que se envió el mensaje.

Agregue soporte de expresiones regulares para eventos ... de esta manera, se pueden capturar rangos de verbos y sustantivos.

+1

+1

+1

+1

+1

Me encantaría un método súper global que manejara todo

io.set ('global_listener', function (espacio de nombres, evento, argumentos, emitir) {
// hacer algo basado en el evento y los argumentos del espacio de nombres
// Puedo o no llamar a emit () para llamar a los oyentes de eventos vinculados con ese espacio de nombres y ese evento
});

io.set ('global_authorization', function (espacio de nombres, handshakeData, devolución de llamada) {
// basado en el espacio de nombres y handshakeData acepta o no la conexión
});

Necesitaba un emisor que admitiera catch-alls a. la. socket.on("*") , funcionó en el cliente y todavía era liviano. Así que tomé el emisor de @visionmedia del UI Kit y lo extendí un poco. Quizás sería una buena opción para esto. Entonces, por lo que vale. Dejaré esto aquí: https://github.com/HenrikJoreteg/wildemitter

@HenrikJoreteg
Podríamos agregar '*' fuera de la caja a https://github.com/component/emitter.
Además, ese emisor alimentará el próximo socket.io. Incluye un acceso directo off a removeListener que es bueno: D

¡Oh, asombroso!

+1

++

+1

+1

+1

+1

+ = 1

+1

+1

+1

+1

¿Alguien ha trabajado en esto todavía? ¿Algún tipo de rastro?

Tengo una _sort of_ solution que funcionó lo suficientemente bien para los propósitos para los que la necesitábamos, pero no es una solución comodín completa ... más como una implementación de '*'

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

+1

+1

+1

+1

+1

+1

Odio dejar un comentario que no aporta nada significativo, pero esto se ha solicitado desde hace 2 años, y ya se ha dicho todo lo constructivo. Entonces...

+1

Esto sería bastante fácil de agregar en el área de usuario, no veo la necesidad de tenerlo en la base de código central. Si puedo ayudar con cualquier gancho para que sea más fácil extender la funcionalidad del emisor de eventos sin demasiados parches de mono, con mucho gusto lo haré.

¿Cómo se implementaría esto en la tierra de los usuarios? Todas las soluciones que he visto implican bifurcar el código base, y algunas personas se han vinculado a diferentes bibliotecas por completo.

En mi caso, solo necesito una simple y simple "captura absolutamente todo en una función", pero el soporte de RegEx no parece (para un tipo que no ha mirado la fuente demasiado de cerca) demasiado difícil, y ciertamente sería increíblemente útil . Utilizo expresiones regulares en mis rutas Express.JS todo el tiempo; Sería bueno poder hacer lo mismo en socket.io.

La capa / protocolo de transporte permanecería inalterada. Simplemente anularía 'emitir' en ambos extremos para no simplemente hacer una búsqueda de mapa, sino una búsqueda más completa (basada en expresiones regulares).

Sugerencias de implementación rápida:

• Anule on para mantener una estructura de datos especial para las expresiones regulares cuando '*' se encuentra en el nombre del evento
• Anule emit para hacer primero el caso rápido (búsqueda de mapa normal), luego revise los oyentes '*' y vea si coinciden.

Obviamente, esto no requiere un tenedor. Lo que quise decir con ganchos es que potencialmente podemos encontrar una solución para no requerir el parche de mono, pero considerando que esos 2 son métodos bastante simples, no considero que sea un gran problema.

Solo por curiosidad, ¿no podríamos simplemente anular el socket.Manager.prototype.onClientMessage de userland?

Lo hice y funcioné bien, en el nodo, sin cambios en el módulo socket.io. No es muy bonito y es probable que se rompa, pero al menos evita bifurcar.

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

¿No se podría simplemente agregar process.EventEmitter = require('eventemitter2').EventEmitter2 algún lugar antes de que se requiera socket.io? Esto parece funcionar para mí ...

La apertura del prototipo definitivamente no es una solución para el usuario. Entiendo que no querer implementar el soporte completo de expresiones regulares ni nada más que un simple socket.on ('*') sería de gran ayuda.

Este boleto tiene 2 años ahora.

¿Hay planes para abordarlo, ya que es claramente una característica útil?

Si la respuesta es no, me gustaría bifurcarlo y agregarlo yo mismo.
Pero preferiría hacer esto solo si es probable que se vuelva a fusionar.

¿Algún desarrollador puede responder a esto, por favor?

De acuerdo con casi todos los comentarios, las cosas sofisticadas pueden ser más o menos discutibles, pero un resumen sería bueno. Los usuarios pueden hacerlo ellos mismos, pero un procedimiento predefinido sería más limpio.

Es una pena que esto no exista.

Existe, vea el enlace que alguien publicó anteriormente
http://stackoverflow.com/questions/8832414/overriding-socket-ios-emit-and-on/8838225

Estoy usando esto y funciona muy bien :)

+1

Hacer parches de mono a algo simple como eso me parece, para mí, algo así como una mala práctica, sin embargo, creo que no se debe usar una gran implementación, algo simple como Backbone.Events será suficiente para la mayoría de los desarrolladores en este tema, Creo. (aunque Backbone no usa "*", sino "all" para el evento global, pasando el nombre del evento al que se llamó originalmente, que es lo mejor que se puede hacer). (es solo una sugerencia, sin embargo) =)

Personalmente +1 a la forma de RegExp, se siente más Javascript y menos consola en comparación con el comodín "*" .

Pero al igual que las últimas voces, una función general parece más adecuada.

Aunque no estoy seguro de si esto es realmente un problema de socket.io.

Una API congelada para culpar a la OMI.

: +1:

En caso de que alguien lea este hilo y todavía esté buscando una forma de usar eventos comodín en 0.9.xy 1.0.0: https://www.npmjs.org/package/socketio-wildcard

¡Maravilloso @geoah !

@guille jeje, no es mío, me lo encontré. gracias por todo su arduo trabajo por cierto ^ _ ^

Anoche preparé un middleware para socket.io.

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

+1
Sería bueno reducir la sobrecarga de crear nuevos oyentes cuando los datos siempre se manejarán de la misma manera.
@geoah Gracias por el middleware, ¡hice exactamente lo que necesitaba!

Si el middleware funciona bien, socket.io debería permanecer como está.

Esta es una de esas cosas que personalmente creo que tiene mucho sentido como parte del propio socket.io. No veo ningún argumento para dejarlo fuera, excepto "así no se hacen las cosas aquí", que nunca es un buen argumento.

El argumento es que intentamos trabajar como el nodo EventEmitter , y el nodo no tiene esto, por lo que se convertiría en un "socket.io-ism". Hubo extensas discusiones en Node sobre agregarlo y no lo logró.

@chevex Aunque originalmente esto también era mi sentimiento, el nuevo soporte de middleware hace que sea bastante fácil de agregar usted mismo. Mirando socketio-wildcard como ejemplo, es muy simple de importar y usar; probablemente terminará siendo como express.js donde hay un par de middleware que casi siempre incluyo.

Esos son argumentos mucho mejores. Supongo que no querrá que el EventEmitter se comporte de manera diferente al nodo de forma predeterminada. Y @ DanH42 Supongo que también tienes razón en que aumentarlo con middleware tiene más sentido para quienes lo necesitan. Me retracto de mi declaración :)

Si solo el EventEmitter del nodo admite comodines listos para usar.

: +1:

Veo que me perdí estos problemas, comencé un nuevo problema sobre el reenvío de eventos:
https://github.com/Automattic/socket.io/issues/1715
Incluye dos formas de manejar todos los eventos de socket.io 1.0 sin alterar su fuente.

Solo quiero esto para depurar. No tengo la autoridad para agregar o modificar bibliotecas en nuestro proyecto. :sollozo:

+1
¡A veces, necesitas conocer todos los eventos que se están propagando!

+1

• 1

Terminé usando el módulo socketio-wildcard de

¡Gracias Matt! Me he hundido, pero espero tener un fin de semana para hacer algo.
mejoras

Enviado desde mi iPhone

El 6 de enero de 2015, a las 8:30 a. M., Matt Fletcher [email protected] escribió:

Terminé usando @NathanGRomano https://github.com/NathanGRomano's
módulo socketio-events https://www.npmjs.com/package/socket.io-events ; eso
parece el método más transparente (mediante el uso de middleware) y funciona bastante
muy bien para mi. ¡Pero [imagen:: +1:] por poner esto en el núcleo!

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/Automattic/socket.io/issues/434#issuecomment -68864750.

+1

+1

++++++

+1 sería útil para depurar.

Si se trata de alguien trabajando en esto, me gustaría intentarlo. Necesitaré algunos para aprender el código base de socket.io, y probablemente pasaré algún tiempo mirando otras implementaciones similares. ¿Cuáles son sus pensamientos sobre los patrones de expresiones regulares? ¿Demasiado lento? Por supuesto, no voy a perder el tiempo si no es algo que se consideraría para una fusión (no me importa si mi implementación es rechazada, pero si no hay interés, entonces para qué molestarse, ¿verdad?). ¿Un mantenedor puede asesorarlo?

Escribí una biblioteca socket.io-events. He estado inundado de trabajo y necesidad
tocarlo de nuevo. Me gustaría apoyar los reconocimientos con él.

El sábado 25 de julio de 2015, John Manko [email protected] escribió:

Si se trata de que alguien esté trabajando en esto, me gustaría darle una
Disparo. Necesitaré algunos para aprender el código base de socket.io, y probablemente
dedique algún tiempo a observar otras implementaciones similares. Que es tu
pensamientos sobre los patrones de expresiones regulares? ¿Demasiado lento? Por supuesto, no voy a desperdiciar mi
tiempo si no es algo que se consideraría para una fusión (no
me importa si mi implementación es rechazada, pero si no hay interés, ¿por qué?
molestar, ¿verdad?). ¿Un mantenedor puede asesorarlo?

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/socketio/socket.io/issues/434#issuecomment -124901706.

+1

+1 este problema tiene 5 años. ¿Por qué no se ha añadido de nuevo la compatibilidad con comodines?

+1

+1

+1

+1

+666

+1

Chicos, en serio. Todo el mundo quiere esta función, creo que la entienden. Detengámonos todos con los más uno, ¿por favor? Prefiero recibir un correo electrónico de actualización cuando haya algún progreso real con el problema.

Dicho esto, es útil saber que muchas personas están interesadas.
Creo que idealmente GitHub debería tener un sistema de votación.

Un sistema de votación sería genial, pero no parece probable que suceda pronto.

Supongo que el problema es que se ha publicado una solución muchas veces, pero se pierde de vista debido a todos los comentarios +1.

El módulo socketio-wildcard me ha funcionado bien (es cierto que aún no he actualizado al último nodo).
Sería útil si alguien pudiera explicar por qué esta biblioteca no es adecuada.

Sí, socketio-wildcard funciona perfectamente bien, pero sigue siendo una dependencia adicional que es tan simple que sería bueno ser introducido en el núcleo y terminar todo este hilo de problemas de una vez por todas. También elimina cualquier espacio para la confusión en cuanto a cuál es el mejor módulo externo para usar (a menudo con un nombre similar). También esté de acuerdo en que sería bueno si GitHub tuviera un sistema de votación, ¡si solo hubiera una manera de poder votar sobre él ...!

Puede que sea tonto, pero no tengo ni idea de cómo configurar socketio-wildcard con objetos de cliente IO. Esto debería incluirse en serio, _en serio_ en el núcleo. Si los mantenedores de socket.io no quieren hacerlo, alguien debería simplemente bifurcar este proyecto y todos podríamos mudarnos allí, porque esto es simplemente ridículo y, honestamente, no tengo ninguna confianza en socket.io ahora.

Entiendo que los mantenedores no tienen que aceptar todas las propuestas, pero ¿esta? Esto simplemente me desconcierta por completo. Camino a seguir.

@ n2liquid no está tan claro que esto debería estar en el núcleo, pero la discusión es bienvenida. Por ejemplo, ningún otro emisor de eventos de Nodo se comporta de esta manera, aunque también se tuvo una discusión allí cuando.

@rauchg

no está tan claro que esto deba estar en el núcleo, pero la discusión es bienvenida

¿Podríamos tener una discusión sobre esto entonces?

Puedo entender su punto de que este tipo de emisor no es necesariamente común en el mundo de los nodos, pero depende de lo que esté tratando de lograr ...
¿La idea es adherirse estrictamente a las convenciones o proporcionar una biblioteca realmente útil?

Parece claro que muchos usuarios de socket.io realmente están tropezando sin que esta característica esté en el núcleo, y parece razonable que un usuario espere que así sea.

O para decirlo de otra manera, ¿cuáles son los argumentos para NO proporcionar esta característica en socket.io?
Incluso si la implementación no es 'correcta de libro de texto', resultaría en una forma estándar de implementar estos controladores 'catchall' en socket.io, en lugar de que las personas tengan que recurrir a muchas bibliotecas y métodos diferentes.
Dirigir a las personas a una biblioteca de terceros o una solución alternativa solo fragmenta las cosas y lo hace aún más frágil intentar mantener una base de código que use socket.io

Preferiría que hubiera una forma formal de manejar todos los paquetes, y luego, si es necesario cambiarlo más tarde, al menos puede haber un procedimiento de migración recomendado, en lugar de dejar que el usuario encuentre su propia ruta a través del desierto.

@rauchg Creo que una forma genial de implementar esto sería tener una función socket.use(function(data,next){..}) que capture todos los eventos en el socket, y se le pase una función next () que pase el control del catchall a catchalls subsiguientes o manejadores de eventos predeterminados .

Así es como estoy usando socket.io en este momento porque necesitaba una forma de limitar la cantidad de eventos por minuto, que creo que es un caso de uso común. Gracias por leer mis 2 centavos.

Me gusta más la solución de @ Michael77 . No toca las interfaces o la implementación del emisor de eventos e incluso permite más cosas de las que pedimos aquí (por ejemplo, la implementación de @ Michael77 y quién sabe qué más).

Sé que hay una función de uso / middleware en socket.io, pero no se puede usar en la biblioteca del cliente, y no estoy seguro de si sirve para el mismo propósito.

@carpii siempre hay buenas razones para _no_ apoyar algo: agregar complejidad, reducir la familiaridad. Esta característica marca ambos.

Me gusta mucho la idea socket.use , además de la cual se podría implementar fácilmente la extensión comodín en el cliente.

Gracias @carpii @ Michael77 @ n2liquid por sus comentarios sobre esto por cierto.

@rauchg , lamento haber dicho esas cosas malas sobre socket.io. Estaba teniendo un mal día. Gracias por este proyecto; puede que no sea perfecto (todavía), pero seguro que es muy útil.

También: https://github.com/hden/socketio-wildcard/issues/13

Los comentarios de @hden por esa solución rápida en socket.io-wildcard ).

scoketio-wildcard parece una solución perfectamente válida. También me encontré queriendo obtener el nombre del evento en la devolución de llamada, para poder envolver el detector de socket y propagar eventos a través del contenedor, en lugar de exponer directamente el socket al resto de mi aplicación. Tengo entendido que esto requeriría Event Emitter 2 si quisiera hacer esto con un comodín. ¿Es esto algo tonto, mejor exponer directamente el enchufe? ¿Algo basado en escuchar 'newListener' en el contenedor (pero no sé cómo disparar un evento de socket, solo cómo registrar el evento de socket según las funciones de llamada que registran un nuevo evento en el contenedor)? ¿Alguien más está interesado en poder acceder al nombre del evento dentro de la devolución de llamada?

@akotlar El nombre del evento está disponible en la devolución de llamada si está utilizando scoketio-wildcard.

¡Ah gracias! Puede ser útil especificar esto en el archivo Léame de socket.io-wildcard.

¿cómo va?
+1 por on("*", function () { tanto para el cliente como para el servidor

+1 todo el camino

@ alexey-sh @ emin93 Si tiene la amabilidad de leer el documento de https://github.com/hden/socketio-wildcard , sí, es posible hacerlo tanto para el cliente como para el servidor.

@hden Gracias y sí, lo vi y ya lo estoy usando. Pero es una dependencia adicional y nada habla en contra de integrarlo directamente en el núcleo de Socket.IO, es por eso que obtiene un +1 de mí.

Se puede manejar en la lógica de la aplicación usando un nombre de evento para todos los eventos:

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

+1 aunque el problema esté cerrado.

+ 💯 ¡bang!

+1 !!!!

Utilice socket.use .

¿Hay alguna manera de conectarse al mecanismo PING / PONG de engine.io usando socket.use ()?

Tengo un problema en el que muchos usuarios están perdiendo la conexión y, a pesar de iniciar sesión extensamente en el servidor, solo dice que se desconectaron debido a Ping Timeout.

Me gustaría registrar los paquetes PING / PONG, pero parece que socket.use () solo puede conectarse a los mensajes de eventos de usuario de alto nivel, y no al protocolo subyacente de engine.io

+1

+1

+1 desde 2011? No lo están haciendo. :(

Nuevamente, se agregó socket.use para el caso: https://socket.io/docs/server-api/#socket -use-fn

@darrachequesne No veo cómo un método en el lado del servidor ayude con esta solicitud (que es para el cliente).

¿Algo más sobre esto? Dado que socket.use es solo para el servidor, ¿por qué está cerrado este ticket?

No entiendo socket.use . Cómo reemplazar

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

con algo como

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

o

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

Encontré una pequeña solución, enumerando todas las posibilidades:

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