Socket.io: Platzhalterunterstützung für Ereignisse hinzufügen

Erstellt am 29. Juli 2011  ·  130Kommentare  ·  Quelle: socketio/socket.io

Es wäre toll, wenn Sie einen Platzhalter verwenden könnten, um alle Ereignisse zu erfassen. Zum Beispiel:

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

}
enhancement

Hilfreichster Kommentar

wie geht's?
+1 für on("*", function () { für Client und Server

Alle 130 Kommentare

einverstanden.

EreignisEmitter2

+1
Dies würde es uns ermöglichen, Filter zu erstellen und was nicht für alle Ereignisse.

  • eine andere Abhängigkeit
  • muss auf der Clientseite reflektiert werden (Code?)
  • sollte Catchall vor einem bestimmten Ereignis aufgerufen werden? oder in der Reihenfolge der Definition? Klärung nötig
  • nur Synchronisierungsverhalten - wäre es nicht besser, benutzerdefinierte _async_-Filter für Ereignisse einzuführen?

+1

nur Synchronisierungsverhalten - wäre es nicht besser, benutzerdefinierte asynchrone Filter für Ereignisse einzuführen?
@dvv

Diese Idee interessiert mich sehr.

Einige der EE2-Auswahlmöglichkeiten sind nicht das, was ich für ideal halten würde, aber ich +1 für die allgemeine Idee, auch wenn nur "*" unterstützt wird

wirklich ein Sammelsurium: manager.on("event", function(client, event, data) {} -- wird auch die Anzahl der Schließungen reduzieren

Ich kann mich nicht erinnern, dass ich nur einen Catchall-Listener hinzugefügt habe. Die einzige Debatte, an die ich mich erinnere, war, ob wir "*" verwenden oder nicht, oder ob wir einen anderen Methodennamen wie .addGlobalListener() verwenden.

+1
Auch ich bräuchte eine Möglichkeit, alle Ereignisse abzufangen und den spezifischen Handler einen Blick darauf zu werfen, nur wenn ich mit der Verarbeitung fertig bin. Dies wird vor allem für Protokollierungszwecke benötigt. Der Socket.io-Logger meldet sich derzeit nur an der Konsole an, und das auf sehr selbstgerechte Weise.
dvv -s Ansatz ist wirklich nach meinem Geschmack.
Tatsächlich wäre es vielleicht eine gute Idee, das Ereignis an einen bestimmten Handler weiterleiten zu lassen, und wir erhalten nur alle Ereignisse, wie von dvv beschrieben.

Bitte bringen Sie dieses Thema in Gang :)
Würde diese Funktion gerne implementiert sehen.

Nun, ok, ich habe gerade EE2 zu einem Zweig in meinem Fork hinzugefügt: https://github.com/einaros/socket.io/commit/2107ff00f3ddf2d781d3e3c3b7dfb1fc990f7ec5

Die Filiale ist unter: https://github.com/einaros/socket.io/commits/ee2

Gedanken sind herzlich willkommen.

Wenn EE2 die seltsamen Methodennamen loswird und .on('*') hinzufügt, würde ich das +1 geben

Ich bin -1 auf EE2

Es fügt dem Code mehr Blähungen hinzu, wir müssen es auch auf der Clientseite unterstützen. Das bedeutet, dass wir eine zusätzliche 11,8-KB-Bibliothek (verkleinert ~3,5kb) liefern müssten. Aber mit dem kommenden mobilen Markt möchte ich so viel Bytes wie möglich sparen.

Wenn es wirklich nur darum geht, einen Platzhalter zu haben / alle Listener zu fangen.. Dann sollte dies durch Überschreiben der vorhandenen emit-Funktion erfolgen, die nur einen zusätzlichen Aufruf an einen all Listener ausführt. Dies wäre wie eine 3 - 5 LOC-Änderung (ohne Kommentare ;)). Und sollte hinter einer Einstellungssperre versteckt sein, da sie die Leistung beeinflusst. EventEmitting ist ein Hot-Code-Pfad und sollte immer so optimal und schnell wie möglich sein. Durch das Hinzufügen von Platzhaltern wird die Leistung beeinträchtigt.

Catch-All ist definitiv der wichtigere Teil, es ist einfach genug, das Event danach bei Bedarf anzuschalten

Kümmern Sie sich nicht wirklich um Wildcards oder EE2, aber eine Möglichkeit, alle Ereignisse abzufangen, ist ein Muss.

wenn EE2 ... .on('*') hinzufügt, würde ich das +1 geben

TJ, du verrückter Bruder...

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

Das ist aus der README von EE2. Natürlich das "foo". es ist optional.

wenn EE2 die seltsamen Methodennamen loswird

Ich stimme zu.

@pyrotechnick der EE2 .on('*') kein Allrounder iirc

* ist kein Catch-All in dem Sinne, dass es blind alle Events abfängt, aber effektiv alle Events abfängt, da das Muster * auf alle Kanäle passt.

Es ist ineffizient; aber es funktioniert wie erwartet.

Ich lag falsch. Du hast recht...

{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

Ich bevorzuge dieses Verhalten jedoch fast, wenn es um Wildcards geht.

Wenn ich an all diese Wildcard/"Namespaced"-Ereignisse denke, macht mich das irgendwie traurig; JavaScript bietet bereits eine fantastische Möglichkeit, Muster abzugleichen – sie leben in // oder werden mit RegExp konstruiert. Ist das einfach zu langsam?

Darf ich die Bedeutung noch einmal +1 geben. Ich würde das gerne in einer kommenden Veröffentlichung sehen.

Das funktioniert nicht, weil ich mich immer noch nicht mit der Veranstaltung verbinden kann. In meiner Anwendung kennt der Server den Namen des Raums vom Client nicht. Ich möchte also auf alle Nachrichten für jeden Raum antworten können und im Idealfall den Namen des Raums herausfinden, an den die Nachricht gesendet wurde.

Fügen Sie Unterstützung für reguläre Ausdrücke für Ereignisse hinzu. Auf diese Weise können Bereiche von Verben und Substantiven erfasst werden.

+1

+1

+1

+1

+1

Ich hätte gerne eine super globale Methode, die alles handhabt

io.set('global_listener', function(namespace, event, args, emit){
// etwas tun basierend auf Namespace-Ereignis und Argumenten
// Ich kann emit() aufrufen oder nicht, um Ereignis-Listener aufzurufen, die mit diesem Namespace und diesem Ereignis verknüpft sind
});

io.set('global_authorization', function(namespace, handshakeData, callback){
// basierend auf Namespace und HandshakeData akzeptieren oder nicht die Verbindung
});

Ich brauchte einen Emitter, der Catch-Alls unterstützt. la. socket.on("*") , arbeitete am Client und war immer noch leicht. Also habe ich den Emitter von @visionmedia aus dem UI Kit genommen und etwas erweitert. Vielleicht wäre es dafür geeignet. Also, was es wert ist. Ich lasse das einfach hier: https://github.com/HenrikJoreteg/wildemitter

@HenrikJoreteg
Wir könnten '*' out of the box zu https://github.com/component/emitter hinzufügen
Außerdem wird dieser Emitter next socket.io mit Strom versorgen. Es enthält eine off Verknüpfung zu removeListener was nett ist: D

Oh toll!

+1

++

+1

+1

+1

+1

+=1

+1

+1

+1

+1

Hat schon jemand darauf hingearbeitet? Irgendeine Spur?

Ich habe eine _irgendwie_ Lösung, die für die Zwecke, für die wir sie brauchten, gut genug funktioniert hat, aber es ist keine vollständige Wildcard-Lösung ... eher eine Implementierung von '*'

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

+1

+1

+1

+1

+1

+1

Ich hasse es, einen Kommentar zu hinterlassen, der nichts Sinnvolles beiträgt, aber dies wird jetzt seit 2 Jahren angefordert und es wurde bereits alles Konstruktive gesagt. So...

+1

Dies wäre im Userland ziemlich einfach hinzuzufügen, ich sehe nicht die Notwendigkeit, es in der Kerncodebasis zu haben. Wenn ich mit irgendwelchen Hooks helfen kann, um es einfacher zu machen, die Event-Emitter-Funktionalität ohne zu viel Affen-Patching zu erweitern, werde ich dies gerne tun.

Wie würde dies im Userland umgesetzt? Alle Lösungen, die ich gesehen habe, beinhalten das Forking der Codebasis, und einige Leute haben insgesamt mit verschiedenen Bibliotheken verknüpft.

In meinem Fall brauche ich nur ein schlichtes "Absolut alles in einer Funktion abfangen", aber die RegEx-Unterstützung scheint (für einen Mann, der sich die Quelle nicht zu genau angeschaut hat) nicht allzu schwierig zu sein und wäre sicherlich unglaublich nützlich . Ich verwende in meinen Express.JS-Routen ständig reguläre Ausdrücke; Es wäre schön, das gleiche in socket.io tun zu können.

Die Transportschicht/das Protokoll würde unverändert bleiben. Sie würden einfach 'emit' an beiden Enden überschreiben, um nicht einfach eine Kartensuche durchzuführen, sondern eine umfassendere (regexp-basierte) Suche.

Vorschläge zur schnellen Umsetzung:

  • Überschreiben Sie on , um eine spezielle Datenstruktur für die regulären Ausdrücke beizubehalten, wenn '*' im Ereignisnamen gefunden wird
  • Überschreiben Sie emit um zuerst den schnellen Fall (normale Kartensuche) durchzuführen, gehen Sie dann die '*'-Listener durch und sehen Sie, ob sie übereinstimmen.

Dies erfordert natürlich keine Gabel. Was ich mit Hooks meinte, ist, dass wir möglicherweise eine Lösung finden können, um das Affen-Patching nicht zu benötigen, aber wenn man bedenkt, dass diese 2 ziemlich einfache Methoden sind, halte ich das für kein großes Problem.

Könnten wir nicht einfach aus Neugier die socket.Manager.prototype.onClientMessage aus dem Userland überschreiben?

Ich habe dies getan und funktionierte gut, in Node, keine Änderungen am socket.io-Modul. Nicht sehr schön und wahrscheinlich zu brechen, aber zumindest vermeiden Sie das Gabeln.

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

Könnte man nicht einfach process.EventEmitter = require('eventemitter2').EventEmitter2 irgendwo hinzufügen, bevor socket.io benötigt wird? Das scheint bei mir zu funktionieren...

Das Öffnen des Prototyps ist definitiv kein Userland-Fix. Ich verstehe, dass ich keine vollständige Regex-Unterstützung oder etwas anderes implementieren möchte, als ein einfaches socket.on('*') würde einen langen Weg gehen.

Dieses Ticket ist jetzt 2 Jahre alt.

Gibt es Pläne, es anzugehen, da es sich eindeutig um ein nützliches Feature handelt?

Wenn die Antwort nein ist, würde ich es gerne selbst verzweigen und hinzufügen.
Aber ich würde es vorziehen, dies nur zu tun, wenn es wahrscheinlich ist, dass es wieder im Upsteam zusammengeführt wird.

Kann das bitte ein Entwickler beantworten?

Ich stimme fast allen Kommentaren zu, ausgefallene Sachen können mehr oder weniger diskutabel sein, aber ein Sammelbegriff wäre schön. Benutzer können dies selbst tun, aber ein vordefiniertes Verfahren wäre sauberer.

Schade, dass es das nicht gibt.

Es existiert, siehe den Link, den jemand zuvor gepostet hat
http://stackoverflow.com/questions/8832414/overriding-socket-ios-emit-and-on/8838225

Ich benutze das und es funktioniert super :)

+1

Affen-Patching auf so etwas Einfaches zu machen, scheint mir eine schlechte Praxis zu sein, aber ich denke, dass keine große Implementierung verwendet werden sollte, etwas Einfaches wie Backbone.Events wird für die meisten Entwickler in dieser Ausgabe ausreichen. Ich denke. (obwohl Backbone nicht "*", sondern "all" für das globale Ereignis verwendet und den ursprünglich aufgerufenen Ereignisnamen übergibt, was einfach das Beste ist). (ist aber nur ein Vorschlag) =)

Persönlich +1 zum RegExp-Weg, es fühlt sich im Vergleich zum Platzhalter "*" mehr Javascript und weniger Konsole an.

Aber wie bei den neuesten Stimmen scheint eine Catch-All-Funktion geeigneter zu sein.

Ich bin mir nicht sicher, ob dies tatsächlich ein socket.io-Problem ist.

Eine eingefrorene API, die IMO beschuldigt.

:+1:

Falls jemand diesen Thread liest und immer noch nach einer Möglichkeit sucht, Wildcard-Ereignisse auf 0.9.x und 1.0.0 zu verwenden: https://www.npmjs.org/package/socketio-wildcard

Wunderbares @geoah !

@guille hehe, es ist nicht meins, ich bin gerade darüber gestolpert. danke für deine harte arbeit übrigens ^_^

Gestern Abend eine Middleware für socket.io auf den Markt gebracht.

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

+1
Es wäre schön, den Aufwand für das Erstellen neuer Listener zu reduzieren, wenn die Daten immer gleich behandelt werden.
@geoah Danke für die Middleware, hat genau das gemacht, was ich brauchte!

Wenn die Middleware einwandfrei funktioniert, sollte socket.io so bleiben, wie es ist.

Dies ist eines der Dinge, die ich persönlich als Teil von socket.io selbst für absolut sinnvoll halte. Ich sehe kein Argument dafür, es wegzulassen, außer "das wird hier nicht so gemacht", was nie ein sehr gutes Argument ist.

Das Argument ist, dass wir versuchen, genau wie der Knoten EventEmitter , und der Knoten hat dies nicht, also würde es zu einem "socket.io-ism". Es gab umfangreiche Diskussionen in Node über das Hinzufügen und es hat es nicht geschafft.

@chevex Während dies ursprünglich auch mein Gefühl war, macht es die neue Middleware-Unterstützung ziemlich einfach, sich selbst hinzuzufügen. Wenn man sich socketio-wildcard als Beispiel ansieht, ist es kinderleicht zu importieren und zu verwenden; es wird wahrscheinlich nur so aussehen wie express.js, wo es ein paar Middleware gibt, die ich fast immer einbeziehe.

Das sind viel bessere Argumente. Ich denke, Sie möchten nicht, dass sich der EventEmitter standardmäßig anders verhält als der Knoten. Und @ DanH42 Ich nehme an, Sie haben auch Recht, dass eine Erweiterung mit Middleware für diejenigen sinnvoller ist, die sie benötigen. Ich ziehe meine Aussage zurück :)

Wenn nur der EventEmitter des Knotens sofort Platzhalter unterstützt.

:+1:

Wie ich sehe, habe ich diese Ausgabe verpasst, ich habe eine neue Ausgabe zu Weiterleitungsereignissen gestartet:
https://github.com/Automattic/socket.io/issues/1715
Es enthält zwei Möglichkeiten, alle Ereignisse von socket.io 1.0 zu behandeln, ohne die Quelle zu ändern.

Ich möchte das nur zum Debuggen. Ich habe nicht die Autorität, Bibliotheken in unserem Projekt hinzuzufügen oder zu ändern. :Schluchzen:

+1
Manchmal müssen Sie alle Ereignisse kennen, die sich ausbreiten!

+1

  • 1

Am Ende habe ich das socketio-wildcard- Modul von

Danke Matt! Ich wurde überschwemmt, aber ich hoffe, ein Wochenende zu haben, um etwas zu machen
Verbesserungen

von meinem Iphone gesendet

Am 6. Januar 2015 um 8.30 Uhr schrieb Matt Fletcher [email protected] :

Am Ende habe ich https://github.com/NathanGRomano 's
socketio-events-modul https://www.npmjs.com/package/socket.io-events ; es
scheint die transparenteste Methode zu sein (durch Verwendung von Middleware) und funktioniert ziemlich
schön für mich. Aber [image: :+1:] dafür, dass du das in den Kern bekommst!


Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/Automattic/socket.io/issues/434#issuecomment -68864750.

+1

+1

+++++

+1 wäre zum Debuggen nützlich.

Wenn es darum geht, dass jemand nur daran arbeitet, würde ich es gerne versuchen. Ich werde einige brauchen, um die Codebasis von socket.io zu lernen, und ich werde wahrscheinlich einige Zeit damit verbringen, andere solche Implementierungen zu betrachten. Was halten Sie von Regex-Mustern? Zu langsam? Natürlich werde ich keine Zeit verschwenden, wenn es nicht für eine Zusammenführung in Frage kommt (es ist mir egal, ob meine Implementierung abgelehnt wird, aber wenn kein Interesse besteht, warum sich dann die Mühe machen, oder?). Kann ein Betreuer bitte beraten?

Ich habe eine Bibliothek socket.io-events geschrieben. Ich wurde mit Arbeit und Not überschwemmt
es wieder zu berühren. Ich möchte die Danksagungen damit unterstützen

Am Samstag, den 25. Juli 2015, schrieb John Manko [email protected] :

Wenn es darum geht, dass jemand nur daran arbeitet, würde ich es gerne geben
Schuss. Ich werde etwas brauchen, um die socket.io-Codebasis zu lernen, und ich werde wahrscheinlich
verbringen Sie einige Zeit mit der Betrachtung anderer solcher Implementierungen. Was sind deine
Gedanken zu Regex-Mustern? Zu langsam? Natürlich werde ich meine nicht verschwenden
Zeit, wenn es nicht etwas ist, das für eine Zusammenführung in Betracht gezogen würde (ich tue es nicht)
kümmern, wenn meine Implementierung abgelehnt wird, aber wenn kein Interesse besteht, warum dann?
stören, oder?). Kann ein Betreuer bitte beraten?


Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/socketio/socket.io/issues/434#issuecomment -124901706.

+1

+1 Dieses Problem besteht seit 5 Jahren. Warum wurde die Wildcard-Unterstützung nicht wieder hinzugefügt?

+1

+1

+1

+1

+666

+1

Leute, ernsthaft. Jeder will diese Funktion - ich denke, sie bekommen sie. Hören wir bitte alle mit den Plus-Einsen auf? Ich würde lieber eine Update-E-Mail erhalten, wenn es tatsächlich Fortschritte bei dem Problem gibt.

Das heißt, es ist nützlich zu wissen, dass viele Leute interessiert sind.
Ich denke, GitHub sollte idealerweise ein Abstimmungssystem haben?

Ein Abstimmungssystem wäre toll, wird aber in absehbarer Zeit wahrscheinlich nicht passieren.

Ich denke, das Problem ist eine Lösung, die jetzt schon oft gepostet wurde, aber wegen all der +1-Kommentare nicht sichtbar ist.

Das socketio-wildcard-Modul hat bei mir gut funktioniert (zugegeben, ich habe noch nicht auf den neuesten Knoten aktualisiert).
Es wäre nützlich, wenn jemand erklären könnte, warum diese Lib nicht geeignet ist?

Ja, socketio-wildcard funktioniert einwandfrei, aber es ist immer noch eine zusätzliche Abhängigkeit, die so einfach ist, dass es schön wäre, in Core eingeführt zu werden und diesen ganzen Thementhread ein für alle Mal zu beenden. Es beseitigt auch jeglichen Raum für Verwirrung, welches das beste externe Modul ist (oft ähnlich benannt). Stimmen Sie auch zu, dass es gut wäre, wenn GitHub ein Abstimmungssystem hätte, wenn es nur eine Möglichkeit gäbe, darüber abzustimmen ...!

Ich bin vielleicht dumm, aber ich habe keine Ahnung, wie man socketio-wildcard mit IO-Client-Objekten einrichtet. Dies sollte ernsthaft _ernsthaft_ in den Kern aufgenommen werden. Wenn die Betreuer von socket.io das nicht wollen, sollte jemand dieses Projekt einfach abspalten und wir könnten alle dorthin ziehen, denn das ist einfach lächerlich und ich habe jetzt ehrlich gesagt kein Vertrauen in socket.io.

Ich verstehe, dass Betreuer nicht jeden Vorschlag annehmen müssen, aber das? Das verwirrt mich einfach total. Weiter so.

@n2liquid es ist nicht so klar, dass dies im Kern sein sollte, aber die Diskussion ist willkommen. So verhält sich beispielsweise kein anderer Node-Event-Emitter, obwohl auch dort eine Diskussion geführt wurde.

@rauchg

Es ist nicht so klar, dass dies im Kern sein sollte, aber die Diskussion ist willkommen

Könnten wir dann darüber diskutieren?

Ich kann Ihren Hinweis verstehen, dass diese Art von Emitter in der Knotenwelt nicht unbedingt üblich ist, aber es hängt davon ab, was Sie erreichen möchten ....
Ist die Idee, sich strikt an Konventionen zu halten oder eine wirklich nützliche Bibliothek bereitzustellen?

Es scheint klar, dass viele Benutzer von socket.io wirklich stolpern, ohne dass diese Funktion im Kern enthalten ist, und es scheint für einen Benutzer vernünftig zu sein, dies zu erwarten.

Oder anders ausgedrückt: Was sind die Argumente dafür, diese Funktion NICHT in socket.io bereitzustellen?
Selbst wenn die Implementierung nicht „lehrbuchkorrekt“ ist, würde dies dazu führen, dass diese „Catchall“-Handler in socket.io standardmäßig implementiert werden, anstatt auf viele verschiedene Bibliotheken und Methoden zurückgreifen zu müssen.
Das Anweisen von Benutzern an eine Drittanbieter-Lib oder eine Problemumgehung fragmentiert nur die Dinge und macht es noch anfälliger, eine Codebasis zu pflegen, die socket.io verwendet

Mir wäre es viel lieber, es gäbe einen formalen Weg, Catchall-Pakete zu handhaben, und wenn es später geändert werden muss, kann es zumindest eine empfohlene Migrationsprozedur geben, anstatt es dem Benutzer zu überlassen, seinen eigenen Weg durch die Wildnis zu finden

@rauchg Ich denke, eine coole Möglichkeit, dies zu implementieren, wäre eine socket.use(function(data,next){..}) Funktion, die alle Ereignisse auf dem Socket abfängt und der eine next()-Funktion übergeben wird, die die Kontrolle vom Catchall an nachfolgende Catchalls oder Standard-Event-Handler übergibt .

So verwende ich socket.io gerade, weil ich eine Möglichkeit brauchte, um die Anzahl der Ereignisse pro Minute zu begrenzen, was meiner Meinung nach ein häufiger Anwendungsfall ist. Danke für das Lesen meiner 2 Cent.

Die Lösung von @Michael77 gefällt -Implementierung und ermöglicht sogar mehr Dinge, als wir hier fragen (z. B. die Implementierung der Nachrichtendrosselung von

Ich weiß, dass es in socket.io eine Middleware-/Use-Funktion gibt, aber sie kann in der Clientbibliothek nicht verwendet werden, und ich bin mir nicht sicher, ob sie dem gleichen Zweck dient.

@carpii es gibt immer gute Gründe, etwas _nicht_ zu unterstützen: Komplexität erhöhen, Vertrautheit reduzieren. Diese Funktion kreuzt beides an.

Mir gefällt die Idee von socket.use sehr gut, darüber hinaus könnte man die Wildcard-Erweiterung einfach auf dem Client implementieren.

Danke @carpii @Michael77 @n2liquid für dein Feedback zu diesem Thema.

@rauchg , es tut mir leid, dass ich diese schlechten Dinge über socket.io gesagt habe. Ich hatte einen schlechten Tag. Vielen Dank für dieses Projekt; es ist vielleicht (noch) nicht perfekt, aber es ist sicherlich sehr nützlich.

Außerdem: https://github.com/hden/socketio-wildcard/issues/13

@n2liquid _alle_ Feedback ist willkommen – danke (und an @hden für die schnelle Lösung von socket.io-wildcard ).

skoketio-wildcard scheint eine vollkommen gültige Lösung zu sein. Ich wollte auch den Ereignisnamen im Rückruf abrufen, damit ich den Socket-Listener umschließen und Ereignisse durch den Wrapper weitergeben kann, anstatt den Socket direkt für den Rest meiner Anwendung verfügbar zu machen. Mein Verständnis ist, dass dies Event Emitter 2 erfordern würde, wenn ich dies mit einer Wildcard tun wollte. Ist das nur etwas dummes, besser direkt die Steckdose freizulegen? Etwas, das darauf basiert, im Wrapper nach 'newListener' zu lauschen (aber wissen nicht, wie man bei einem Socket-Ereignis triggert, sondern nur, wie man das Socket-Ereignis basierend auf den aufrufenden Funktionen registriert, die ein neues Ereignis im Wrapper registrieren)? Ist noch jemand daran interessiert, auf den Ereignisnamen innerhalb des Rückrufs zugreifen zu können?

@akotlar Der Ereignisname ist im Rückruf verfügbar, wenn Sie skoketio-wildcard verwenden.

Ah danke! Es kann sinnvoll sein, dies in der Readme-Datei von socket.io-wildcard anzugeben.

wie geht's?
+1 für on("*", function () { für Client und Server

+1 auf alle Fälle

@alexey-sh @emin93 Wenn Sie freundlicherweise das Dokument von https://github.com/hden/socketio-wildcard lesen würden, ja, es ist sowohl für Client als auch für Server möglich.

@hden Danke und ja, ich habe das gesehen und benutze es bereits. Aber es ist eine zusätzliche Abhängigkeit und nichts spricht dagegen, es direkt in den Socket.IO-Kern zu integrieren, deshalb bekommt es von mir eine +1.

Es kann in der App-Logik mit einem Ereignisnamen für alle Ereignisse behandelt werden:

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

+1, obwohl das Problem geschlossen ist.

+💯 Knall!

+1 !!!!

Bitte verwenden Sie socket.use .

Gibt es eine Möglichkeit, sich mit socket.use() in den PING/PONG-Mechanismus von engine.io einzuklinken?

Ich habe ein Problem, bei dem viele Benutzer die Verbindung verlieren, und trotz umfangreicher Anmeldung auf dem Server heißt es nur, dass sie die Verbindung aufgrund eines Ping-Timeouts getrennt haben.

Ich möchte die PING/PONG-Pakete protokollieren, aber es scheint, dass socket.use() nur in die High-Level-Benutzerereignisnachrichten einhaken kann und nicht in das zugrunde liegende Protokoll von engine.io

+1

+1

+1 seit 2011? Sie tun es nicht. :(

Auch hier wurde socket.use hinzugefügt: https://socket.io/docs/server-api/#socket -use-fn

@darrachequesne Ich sehe nicht, wie eine Methode auf der Serverseite bei dieser Anfrage hilft (die für den Client bestimmt ist).

Mehr dazu? Da socket.use nur für den Server bestimmt ist, warum wird dieses Ticket geschlossen?

Ich verstehe socket.use . So ersetzen Sie

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

mit sowas wie

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

oder

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

Habe einen kleinen Workaround gefunden - Auflistung aller Möglichkeiten:

// Client
var lala = function(data){ 
    // example
}
socket.on('backend', lala);
socket.on('frontend', lala);
War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

thebinarypenguin picture thebinarypenguin  ·  4Kommentare

kootoopas picture kootoopas  ·  4Kommentare

varHarrie picture varHarrie  ·  3Kommentare

gCurtisCT picture gCurtisCT  ·  4Kommentare

adammw picture adammw  ·  4Kommentare