Socket.io: イベントのワイルドカードサポートを追加する

同意した。

EventEmitter2

+1
これにより、すべてのイベントに対してではなく、フィルターを作成できるようになります。

• 別の依存関係
• クライアント側で反映する必要が
• 特定のイベントの前にキャッチオールを呼び出す必要がありますか？ または定義の順序で？ 明確化が必要
• 同期動作のみ-イベントにカスタムの_async_フィルターを導入する方が良いのではないでしょうか。

+1

同期動作のみ-イベントにカスタム非同期フィルターを導入する方が良いのではないでしょうか？
@dvv

私はこの考えに非常に興味があります。

EE2の選択肢のいくつかは、私が理想と考えるものではありませんが、「*」のみがサポートされている場合でも、これの一般的な考え方を+1します。

本当にキャッチオール： manager.on("event", function(client, event, data) {} -クロージャーの数を減らすこともできます

キャッチオールリスナーを追加することへの抵抗を覚えていません。覚えている唯一の議論は、「*」を使用するかどうか、または.addGlobalListener（）のような別のメソッド名を使用するかどうかでした。

+1
私も、すべてのイベントをインターセプトし、処理が完了した後でのみ、特定のハンドラーにそれらを確認させる方法が必要になります。 主にロギングの目的でこれが必要になります。 Socket.ioロガーは現在、コンソールにのみ、非常に独善的な方法でログを記録します。
dvv-sアプローチは本当に私の好みです。
実際、dvvで説明されているように、イベントを特定のハンドラーに中継して、すべてのイベントを取得することをお勧めします。

この問題を動かしてください:)
この機能が実装されるのを楽しみにしています。

さて、わかりました。フォークのブランチにEE2を追加しました： https ：

ブランチは次の場所にあります： //github.com/einaros/socket.io/commits/ee2

考えは大歓迎です。

EE2が奇妙なメソッド名を取り除き、 .on('*')を追加した場合、私はそれを+1します

私はEE2で-1です

それはコードにさらに肥大化を追加します、私達はまたそれをクライアント側でサポートする必要があります。 つまり、追加の11.8 KBライブラリ（最小化された約3.5kb）を出荷する必要があります。 しかし、今後のモバイル市場では、できるだけ多くのバイトを節約したいと思います。

これが本当にワイルドカードを使用すること/すべてのリスナーをキャッチすることだけである場合..次に、これは、 allリスナーへの追加の呼び出しを1回だけ実行する既存のemit関数をオーバーライドすることによって実行する必要があります。 これは、3〜5のLOC変更のようになります（コメントを除く;））。 また、パフォーマンスに影響するため、設定ロックの背後に隠す必要があります。 EventEmittingはホットコードパスであり、常に可能な限り最適かつ高速である必要があります。 ワイルドカードを追加すると、パフォーマンスが低下します。

キャッチオールは間違いなくより重要な部分です。必要に応じて、その後イベントをオンにするのは簡単です。

ワイルドカード（EE2）についてはあまり気にしないでください。ただし、すべてのイベントをインターセプトする方法は必須です。

EE2 ...が.on（ '*'）を追加する場合、私はそれを+1します

TJあなたはクレイジーブロ...

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

これはEE2のREA​​DMEからのものです。 当然、「foo」。 オプションです。

EE2が奇妙なメソッド名を取り除く場合

同意します。

@pyrotechnick the 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）{
//名前空間とhandshakeDataに基づいて接続を受け入れるかどうか
}）;

キャッチオールをサポートするエミッターが必要でした。 ラ。 socket.on("*")は、クライアントで動作し、それでも軽量でした。 そこで、UI Kitから@visionmediaのエミッターをhttps ：

@HenrikJoreteg
箱から出してhttps://github.com/component/emitterに「*」を追加する場合があり
また、そのエミッターは次のsocket.ioに電力を供給します。 removeListenerへのoffショートカットが含まれています。これは素晴らしいです：D

ああ、すごい！

+1

++

+1

+1

+1

+1

+ = 1

+1

+1

+1

+1

誰かがこれに取り組んだことがありますか？ どんなトレイル？

必要な目的には十分に機能する_sortof_ソリューションがありますが、本格的なワイルドカードソリューションではありません...「*」の実装のようなものです

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

+1

+1

+1

+1

+1

+1

意味のあることは何も貢献しないコメントを残すのは嫌ですが、これは2年前から要求されており、建設的なことはすべてすでに言われています。 そう...

+1

これはユーザーランドに追加するのはかなり簡単です。コアコードベースに追加する必要はないと思います。 モンキーパッチをあまりかけずにイベントエミッター機能を簡単に拡張できるようにするためのフックを手伝うことができれば、喜んでそうします。

これはユーザーランドでどのように実装されますか？ 私が見たすべてのソリューションはコードベースをフォークすることを含み、何人かの人々は完全に異なるライブラリにリンクしました。

私の場合、必要なのは単純で単純な「1つの関数ですべてを完全にキャッチする」だけですが、正規表現のサポートは（ソースをあまり詳しく調べていない人には）それほど難しくはなく、確かに信じられないほど便利です。 。 Express.JSルートでは常に正規表現を使用しています。 socket.ioで同じことができるといいでしょう。

トランスポート層/プロトコルは変更されません。 両端の「emit」をオーバーライドするだけで、マップルックアップを実行するだけでなく、より包括的な（正規表現ベースの）検索を実行できます。

簡単な実装の提案：

• イベント名に「*」が見つかった場合に正規表現の特別なデータ構造を維持するには、 onをオーバーライドします
• emitをオーバーライドして、最初に高速ケース（通常のマップルックアップ）を実行し、次に「*」リスナーを調べて、それらが一致するかどうかを確認します。

明らかに、これはフォークを必要としません。 私がフックで意味したのは、モンキーパッチを必要としない解決策を見つけることができる可能性があるということですが、これら2つは非常に単純な方法であるため、大きな問題とは見なしません。

好奇心から、userlandから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、それは私が偶然見つけた私のものではありません。 頑張ってくれてありがとう^ _ ^

昨夜、socket.ioのミドルウェアを作成しました。

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

+1
データが常に同じように処理される場合は、新しいリスナーを作成するオーバーヘッドを削減すると便利です。
@geoahミドルウェアをありがとう、私が必要なことを正確に実行しました！

ミドルウェアが正常に機能する場合、socket.ioはそのままである必要があります。

これは、socket.io自体の一部として私が個人的に完全に理にかなっていると感じているものの1つです。 「この辺りで物事が行われる方法ではない」ことを除いて、それを除外することについての議論は見当たりません。これは決して非常に良い議論ではありません。

引数は、ノードEventEmitterと同じように動作しようとしますが、ノードにはこれがないため、「socket.io-ism」になります。 それを追加することについてNodeで広範な議論がありましたが、それは成功しませんでした。

@chevexこれはもともと私の気持ちでもありましたが、新しいミドルウェアのサポートにより、自分で簡単に追加できます。 例としてsocketio-wildcardを見ると、インポートして使用するのは非常に簡単です。 おそらく、ほとんどの場合、ミドルウェアがいくつか含まれているexpress.jsのようになってしまうでしょう。

それらははるかに良い議論です。 EventEmitterがデフォルトでノードとは異なる動作をすることは望ましくないと思います。 また、 @ DanH42は、ミドルウェアで拡張する方が、それを必要とする人にとってより理にかなっていると思います。 私は私の声明を撤回します:)

ノードのEventEmitterのみがそのままワイルドカードをサポートしている場合。

：+1：

この問題を見逃したようです。イベントの転送に関する新しい問題を開始しました。
https://github.com/Automattic/socket.io/issues/1715
ソースを変更せずにsocket.io1.0からのすべてのイベントを処理する2つの方法が含まれています。

デバッグ用にこれが欲しいだけです。 プロジェクトにライブラリを追加または変更する権限がありません。 ：sob：

+1
時々、あなたは伝播しているすべてのイベントを知る必要があります！

+1

• 1

最終的にhdenの

ありがとうマット！ 私は圧倒されましたが、週末を過ごしていくつかを作りたいと思っています
改善

私のiPhoneから送信された

2015年1月6日午前8時30分、MattFletchernotifications @ github.comは次のように書いています。

@NathanGRomanohttps ：//github.com/NathanGRomanoを使用することになりました
socketio-eventshttps ： //www.npmjs.com/package/socket.io-eventsモジュール; それ
（ミドルウェアを使用することによる）最も透過的な方法のようで、かなり機能します
私にとってはうまく。 しかし、これをコアに取り入れるための[画像:: + 1：]！

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/Automattic/socket.io/issues/434#issuecomment-68864750 。

+1

+1

++++++

+1はデバッグに役立ちます。

誰かがこれに取り組んでいるだけの問題なら、私はそれを試してみたいと思います。 socket.ioコードベースを学ぶためにいくつかが必要であり、おそらく他のそのような実装を調べるのに少し時間を費やすでしょう。 正規表現パターンについてどう思いますか？ 遅すぎる？ もちろん、それがマージの対象となるものでなければ、時間を無駄にするつもりはありません（実装が拒否されてもかまいませんが、興味がない場合は、なぜわざわざするのですか？）。 メンテナはアドバイスしてもらえますか？

ライブラリsocket.io-eventsを作成しました。 私は仕事と必要性に溢れています
もう一度触れます。 謝辞をサポートしたいのですが

2015年7月25日（土曜日）には、ジョン・漫湖の[email protected]は書きました：

誰かがこれに取り組んでいるだけの問題なら、私はそれに与えたいと思います
ショット。 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モジュールは私にとってうまく機能しています（確かに私はまだ最新のノードに更新していません）。
このlibが適切でない理由を誰かが説明できれば便利ですか？

ええ、 socketio-wildcardは完全にうまく機能しますが、それでも非常に単純な追加の依存関係なので、コアに導入して、この問題スレッド全体を完全に終了するだけでよいでしょう。 また、どちらが使用するのに最適な外部モジュールであるか（多くの場合、同様の名前が付けられています）について混乱する余地がなくなります。 また、GitHubに投票システムがあれば、それに投票できる方法があればいいのではないかと同意します...！

ばかげているかもしれませんが、IOクライアントオブジェクトを使用してsocketio-wildcardを設定する方法がわかりません。 これは真剣に、コアに_真剣に_含まれるべきです。 socket.ioのメンテナがそれを望まない場合は、誰かがこのプロジェクトをフォークするだけで、全員がそこに移動できます。これはばかげているだけで、正直なところ、socket.ioに対する信頼はまったくありません。

メンテナがすべての提案を受け入れる必要はないことは理解していますが、これは？ これは完全に私を困惑させます。 行く方法。

@ n2liquidこれが核心にあるべきかどうかは明確ではありませんが、議論は大歓迎です。 たとえば、他のノードイベントエミッターは、いつそこでも議論があったとしても、このように動作しません。

@rauchg

これが核心にあるべきかどうかは明確ではありませんが、議論は大歓迎です

それでは、これについて話し合うことができますか？

この種のエミッターはノードの世界では必ずしも一般的ではないというあなたの指摘は理解できますが、それはあなたが何を達成しようとしているのかによります。
規則を厳密に順守するという考えですか、それとも本当に便利なライブラリを提供するという考えですか？

socket.ioの多くのユーザーが、この機能がコアになっていないのに本当につまずいていることは明らかであり、ユーザーがそうあるべきだと期待するのは合理的だと思われます。

言い換えれば、socket.ioでこの機能を提供しないという議論は何ですか？
実装が「教科書に正しくない」場合でも、多くの異なるライブラリやメソッドに頼る必要はなく、socket.ioにこれらの「catchall」ハンドラーを実装する標準的な方法になります。
サードパーティのライブラリまたは回避策にユーザーを誘導すると、断片化するだけで、socket.ioを使用するコードベースを維持しようとするとさらに脆弱になります。

キャッチオールパケットを処理する正式な方法があったほうがいいのですが、後で変更する必要がある場合は、ユーザーが荒野を通る独自のルートを見つけるためだけに残すのではなく、少なくとも推奨される移行手順があります。

@rauchgこれを実装するクールな方法は、ソケット上のすべてのイベントをキャッチするsocket.use(function(data,next){..})関数を持ち、キャッチオールから後続のキャッチオールまたはデフォルトのイベントハンドラーに制御を渡すnext（）関数を渡すことだと思います。 。

これが私が現在socket.ioを使用している方法です。これは、1分あたりに発生するイベントの量を制限する方法が必要だったためです。これは一般的な使用例だと思います。 私の2セントを読んでくれてありがとう。

@ Michael77のソリューションが一番好きです。 これは、イベントエミッターのインターフェースや実装には影響せず、ここで求めている以上のことも可能にします（たとえば、

socket.ioにミドルウェア/ use関数があることは知っていますが、クライアントライブラリでは使用できず、これと同じ目的を果たしているかどうかはわかりません。

@carpii何かをサポートしない理由は常にあります。複雑さを増す、親しみやすさを減らすことです。 この機能は両方をチェックします。

私はsocket.useアイデアがとても好きで、その上にクライアントにワイルドカード拡張機能を簡単に実装できます。

このところでフィードバックをありがとう@ carpii @ Michael77 @ n2liquid 。

@ rauchg 、

また： https ：

@ n2liquid _all_のフィードバックは大歓迎です-あなたに感謝（と上の簡単な解決策として@hdenするsocket.io-ワイルドカード）。

scoketio-wildcardは完全に有効な解決策のようです。 また、コールバックでイベント名を取得したいと思っていました。これにより、ソケットをアプリケーションの残りの部分に直接公開するのではなく、ソケットリスナーをラップし、ラッパーを介してイベントを伝播できます。 私の理解では、ワイルドカードを使用してこれを実行するには、Event Emitter2が必要になります。 これは、ソケットを直接公開する方がよい、ばかげたことですか？ ラッパーで「newListener」をリッスンすることに基づいたもの（ただし、ソケットイベントでトリガーする方法がわからない、ラッパーに新しいイベントを登録する呼び出し関数に基づいてソケットイベントを登録する方法のみ）？ コールバック内でイベント名にアクセスできることに興味がある人は他にいますか？

@akotlar scoketio-wildcardを使用している場合、イベント名はコールバックで使用できます。

ああ、ありがとう！ これをsocket.io-wildcardreadmeで指定すると便利な場合があります。

どのようにそれが起こっている？
クライアントとサーバーの両方でon("*", function () { +1

ずっと+1

@ alexey-sh @ emin93 https://github.com/hden/socketio-wildcardからドキュメントを親切に読んでいただければ、クライアントとサーバーの両方で読むことができます。

@hdenありがとう、はい、私はそれを見ました、そして私はすでにそれを使っています。 しかし、これは追加の依存関係であり、Socket.IOコアに直接統合することに反対するものは何もありません。そのため、私から+1を取得します。

これは、すべてのイベントに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

2011年から+1？ 彼らはそれをしていません。 :(

繰り返しになりますが、 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);