Socket.io: إضافة دعم أحرف البدل للأحداث

تم إنشاؤها على ٢٩ يوليو ٢٠١١  ·  130تعليقات  ·  مصدر: socketio/socket.io

سيكون من الرائع أن تتمكن من استخدام حرف بدل لالتقاط جميع الأحداث. على سبيل المثال:

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

}
enhancement

التعليق الأكثر فائدة

كيف الحال؟
+1 مقابل on("*", function () { لكل من العميل والخادم

ال 130 كومينتر

متفق عليه.

EventEmitter2

+1
سيسمح لنا هذا بإنشاء عوامل تصفية وما لا يناسب جميع الأحداث.

  • تبعية أخرى
  • يجب أن تنعكس في جانب العميل (كود؟)
  • يجب استدعاء catchall قبل حدث معين؟ أم بترتيب التعريف؟ التوضيح المطلوب
  • سلوك المزامنة فقط - أليس من الأفضل تقديم مرشحات _async_ مخصصة للأحداث؟

+1

سلوك المزامنة فقط - أليس من الأفضل تقديم عوامل تصفية غير متزامنة مخصصة للأحداث؟
dvv

أنا مهتم جدًا بهذه الفكرة.

بعض خيارات EE2 ليست ما أعتبره مثاليًا ولكنني أقوم بإجراء +1 للفكرة العامة لذلك ، حتى لو تم دعم "*" فقط

جماعي حقيقي: manager.on("event", function(client, event, data) {} - سيسمح أيضًا بتقليل عدد عمليات الإغلاق

لا أتذكر أي مقاومة لمجرد إضافة مستمع جامع ، كان النقاش الوحيد الذي أتذكره هو ما إذا كنا نستخدم "*" أم لا أو إذا استخدمنا اسم طريقة أخرى مثل .addGlobalListener ()

+1
أنا أيضًا سأحتاج إلى طريقة لاعتراض جميع الأحداث ، وإلقاء نظرة على المعالج المحدد ، بمجرد الانتهاء من معالجتها. في الغالب لأغراض التسجيل ستكون هناك حاجة إلى هذا. يقوم Socket.io logger حاليًا بتسجيل الدخول إلى وحدة التحكم فقط ، وبطريقة عادلة جدًا.
نهج dvv -s هو حقا تروق لي.
في الواقع ، ربما تكون فكرة جيدة أن ننقل الحدث إلى أي معالج محدد ، ونحصل فقط على جميع الأحداث ، كما هو موضح بواسطة dvv.

يرجى تشغيل هذه المشكلة :)
أحب أن أرى هذه الميزة مطبقة.

حسنًا ، حسنًا ، لقد أضفت للتو EE2 إلى فرع في مفترقتي: https://github.com/einaros/socket.io/commit/2107ff00f3ddf2d781d3e3c3b7dfb1fc990f7ec5

الفرع موجود في: https://github.com/einaros/socket.io/commits/ee2

الأفكار موضع ترحيب كبير.

إذا تخلصت EE2 من أسماء الطرق الغريبة وأضفت .on('*') سأفعل ذلك

أنا -1 في EE2

إنه يضيف مزيدًا من الانتفاخ إلى الكود ، نحتاج أيضًا إلى دعمه من جانب العميل. مما يعني أنه سيتعين علينا شحن مكتبة إضافية بحجم 11.8 كيلوبايت (مصغرة ~ 3.5 كيلوبايت). ولكن مع سوق الهاتف المحمول القادم ، أود توفير أكبر قدر ممكن من البايت.

إذا كان الأمر يتعلق فقط بالحصول على حرف بدل / التقاط جميع المستمعين .. فيجب أن يتم ذلك عن طريق تجاوز وظيفة الإرسال الحالية التي تقوم فقط باستدعاء إضافي واحد لمستمع all . سيكون هذا مثل تغيير 3-5 LOC (باستثناء التعليقات ؛)). ويجب إخفاؤه خلف قفل التفضيل لأنه يؤثر على الأداء. يعد EventEmitting مسارًا سريعًا للشفرة ويجب أن يكون دائمًا مثاليًا وسريعًا قدر الإمكان. ستؤدي إضافة أحرف البدل إلى تدهور الأداء.

من المؤكد أن تجميع كل شيء هو الجزء الأكثر أهمية ، فمن السهل بما يكفي تشغيل الحدث بعد ذلك إذا لزم الأمر

لا تهتم حقًا بأحرف البدل ، أو EE2 ، ولكن طريقة لاعتراض كل الأحداث أمر لا بد منه.

إذا كان EE2 ... يضيف. on ('*') سأقوم بإجراء +1 لذلك

TJ أنت مجنون أخي ...

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

هذا من README لـ EE2. بطبيعة الحال ، "فو". هو اختياري.

إذا تخلص EE2 من أسماء الطرق الغريبة

أنا موافق.

pyrotechnick ، 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 أهمية هذا مرة أخرى. أود أن أرى هذا في الإصدار القادم.

هذا لا يعمل لأنني ما زلت لا أستطيع الاتصال بالحدث. في تطبيقي ، لا يعرف الخادم اسم الغرفة من العميل. لذلك أريد أن أكون قادرًا على الرد على جميع الرسائل في أي غرفة ومعرفة اسم الغرفة التي تم إرسال الرسالة عليها بشكل مثالي.

أضف دعمًا للتعبير العادي للأحداث .. وبهذه الطريقة يمكن اكتشاف نطاقات من الأفعال والأسماء.

+1

+1

+1

+1

+1

سأكون مغرمًا بطريقة عالمية فائقة تتعامل مع كل شيء

io.set ('global_listener'، function (namespace، event، args، emit) {
// افعل شيئًا بناءً على حدث مساحة الاسم والوسيطات
// يمكنني أو لا يمكنني استدعاء emit () لاستدعاء مستمعي الحدث المرتبطين بمساحة الاسم تلك والحدث
}) ؛

io.set ('global_authorization'، function (namespace، handshakeData، callback) {
// بناءً على مساحة الاسم وبيانات المصافحة أو قبول الاتصال أو عدم قبوله
}) ؛

كنت بحاجة إلى باعث يدعم أدوات التقاط كل شيء أ. لا. socket.on("*") ، عملت مع العميل ، ومازال خفيف الوزن. لذلك أخذت باعث visionmedia من UI Kit https://github.com/HenrikJoreteg/wildemitter

تضمين التغريدة
قد نضيف "*" من المربع إلى https://github.com/component/emitter.
أيضًا ، سوف يقوم هذا الباعث بتشغيل المقبس التالي. يتضمن اختصار off إلى removeListener وهو أمر جيد: D

اوه رائع!

+1

++

+1

+1

+1

+1

+ = 1

+1

+1

+1

+1

هل عمل أي شخص تجاه هذا حتى الآن؟ أي نوع من الممرات؟

لديّ حلًا من نوع _ يعمل بشكل جيد بما فيه الكفاية للأغراض التي احتجناها من أجلها ، ولكنه ليس حلاً كاملاً لأحرف البدل ... يشبه إلى حد كبير تنفيذ "*"

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

+1

+1

+1

+1

+1

+1

أكره أن أترك تعليقًا لا يساهم في أي شيء ذي معنى ، ولكن هذا مطلوب منذ عامين ، وقد قيل بالفعل كل شيء بناء. وبالتالي...

+1

سيكون من السهل إلى حد ما إضافة userland ، لا أرى الحاجة إلى وجوده في قاعدة التعليمات البرمجية الأساسية. إذا كان بإمكاني المساعدة في أي خطافات لتسهيل توسيع وظيفة باعث الحدث دون الكثير من ترقيع القرود ، فسأفعل ذلك بكل سرور.

كيف سيتم تنفيذ ذلك في أرض المستخدم؟ كل الحلول التي رأيتها تضمنت تزييف قاعدة الشفرة ، وقد ربط بعض الأشخاص بمكتبات مختلفة تمامًا.

في حالتي ، أحتاج فقط إلى عبارة بسيطة وبسيطة "التقط كل شيء تمامًا في وظيفة واحدة" ، ولكن لا يبدو أن دعم RegEx (بالنسبة لشخص لم ينظر إلى المصدر عن كثب) صعبًا للغاية ، وسيكون بالتأكيد مفيدًا بشكل لا يصدق . أستخدم التعبيرات النمطية في مسارات Express.JS الخاصة بي طوال الوقت ؛ سيكون من الجيد أن تكون قادرًا على فعل الشيء نفسه في socket.io.

ستبقى طبقة / بروتوكول النقل دون تغيير. يمكنك ببساطة تجاوز "إصدار" على كلا الطرفين ليس فقط لإجراء بحث على الخريطة ولكن بحث أكثر شمولاً (يعتمد على regexp).

اقتراحات التنفيذ السريع:

  • تجاوز on للاحتفاظ ببنية بيانات خاصة للتعبيرات العادية عند العثور على "*" في اسم الحدث
  • تجاوز emit لإجراء الحالة السريعة أولاً (بحث منتظم على الخريطة) ، ثم انتقل من خلال المستمعين "*" ومعرفة ما إذا كانوا متطابقين.

من الواضح أن هذا لا يتطلب شوكة. ما قصدته بالخطافات هو أنه من المحتمل أن نجد حلاً لعدم طلب ترقيع القرود ، لكن بالنظر إلى هاتين الطريقتين هما طريقتان بسيطتان جدًا ، لا أعتبر هذه مشكلة كبيرة.

بدافع الفضول فقط ، لا يمكننا تجاوز المقبس فقط. Manager.prototype.onClientMessage from userland؟

لقد فعلت ذلك وعملت بشكل جيد ، في العقدة ، لا توجد تغييرات على وحدة socket.io. ليست جميلة جدًا ومن المحتمل أن تنكسر ولكنك على الأقل تتجنب التفرع.

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

لا يمكن للمرء ببساطة إضافة process.EventEmitter = require('eventemitter2').EventEmitter2 مكان ما قبل أن يكون socket.io مطلوبًا؟ يبدو هذا عمل بالنسبة لي...

إن فتح النموذج الأولي ليس بالتأكيد إصلاحًا لأرض المستخدم. أتفهم عدم الرغبة في تنفيذ دعم regex كامل أو أي شيء آخر غير أن المقبس البسيط على ('*') سيقطع شوطًا طويلاً.

هذه التذكرة عمرها الآن سنتان.

هل هناك أي خطط لمعالجتها ، حيث من الواضح أنها ميزة مفيدة؟

إذا كانت الإجابة لا ، أود أن أشركها وأضيفها بنفسي.
لكنني أفضل القيام بذلك فقط إذا كان من المحتمل أن يتم دمجها في البخار.

هل يمكن لأي مطورين الإجابة على هذا من فضلك؟

بالاتفاق مع جميع التعليقات تقريبًا ، يمكن أن تكون الأشياء الفاخرة أكثر أو أقل إثارة للجدل ، ولكن سيكون من الجيد جذب كل شيء. يمكن للمستخدمين القيام بذلك بأنفسهم ، ولكن الإجراء المحدد مسبقًا سيكون أكثر نظافة.

إنه لأمر مخز أن هذا غير موجود.

إنه موجود بالفعل ، راجع الرابط الذي نشره شخص ما في وقت سابق
http://stackoverflow.com/questions/8832414/overriding-socket-ios-emit-and-on/8838225

أنا أستخدم هذا ، وهو يعمل بشكل رائع :)

+1

قم بعمل ترقيع القرد لشيء بسيط مثل هذا يبدو ، بالنسبة لي ، شيء مثل ممارسة سيئة ، ومع ذلك ، أعتقد أنه لا ينبغي استخدام أي تطبيق كبير ، شيء بسيط مثل Backbone.Events سيكون كافياً لمعظم المطورين في هذه المشكلة ، أظن. (على الرغم من أن Backbone لا تستخدم "*" ، ولكن "all" للحدث العالمي ، فإن تمرير اسم الحدث الذي تم استدعاؤه في الأصل ، وهو أفضل ما يمكن فعله). (إنه مجرد اقتراح ، مع ذلك) =)

شخصيًا +1 إلى طريقة RegExp ، يبدو الأمر أكثر جافا سكريبت ووحدة تحكم أقل مقارنةً بحرف البدل "*" .

ولكن مثل أحدث الأصوات ، تبدو الوظيفة الشاملة أكثر ملاءمة.

لست متأكدًا مما إذا كانت هذه مشكلة في الواقع socket.io tho.

واجهة برمجة تطبيقات مجمدة لإلقاء اللوم على المنظمة البحرية الدولية.

: +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 نفسه. لا أرى أي حجة لتركها باستثناء "هذه ليست الطريقة التي تتم بها الأمور هنا" ، وهي ليست حجة جيدة أبدًا.

الحجة هي أننا نحاول العمل تمامًا مثل العقدة EventEmitter ، والعقدة لا تحتوي على هذا ، لذلك ستصبح "socket.io-ism". كانت هناك مناقشات مستفيضة في Node حول إضافتها ولم تنجح.

chevex بينما كان هذا هو شعوري في الأصل أيضًا ، فإن دعم البرامج الوسيطة الجديد يجعل من السهل جدًا إضافة نفسك. بالنظر إلى socketio-wildcard كمثال ، فإنه من السهل جدًا استيراده واستخدامه ؛ من المحتمل أن ينتهي الأمر إلى أن تكون مثل express.js حيث توجد بضع قطع من البرامج الوسيطة التي أقوم بتضمينها دائمًا.

هذه حجج أفضل بكثير. أعتقد أنك لا تريد أن يتصرف EventEmitter بشكل مختلف عن العقدة افتراضيًا. و @ DanH42 أفترض أيضًا أنك محق في أن زيادتها باستخدام البرامج الوسيطة أكثر منطقية بالنسبة لأولئك الذين يحتاجون إليها. أسحب بياني :)

إذا كان EventEmitter الخاص بالعقدة فقط يدعم أحرف البدل خارج الصندوق.

: +1:

أرى أنني فاتني هذه المشكلات ، لقد بدأت إصدارًا جديدًا بشأن إعادة توجيه الأحداث:
https://github.com/Automattic/socket.io/issues/1715
يتضمن طريقتين للتعامل مع جميع الأحداث من socket.io 1.0 دون تغيير مصدره.

أنا فقط أريد هذا من أجل التصحيح. ليس لدي الصلاحية لإضافة أو تعديل المكتبات في مشروعنا. :تنهد:

+1
في بعض الأحيان ، تحتاج إلى معرفة كل الأحداث التي يتم نشرها!

+1

  • 1

انتهى بي الأمر باستخدام وحدة socketio-wildcard الخاصة بـ

شكرا مات! لقد تعرضت للغرق ولكن آمل أن أحصل على عطلة نهاية الأسبوع لأقوم ببعض
تحسينات

مرسل من الايفون الخاص بي

في 6 كانون الثاني (يناير) 2015 ، الساعة 8:30 صباحًا ، كتب Matt Fletcher [email protected] :

انتهى بي الأمر باستخدام NathanGRomano https://github.com/NathanGRomano
أحداث socketio https://www.npmjs.com/package/socket.io-events module ؛ هو - هي
تبدو الطريقة الأكثر شفافية (باستخدام البرامج الوسيطة) وتعمل بشكل جيد
جيد بالنسبة لي. لكن [image:: +1:] للحصول على هذا في جوهر!

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/Automattic/socket.io/issues/434#issuecomment -68864750.

+1

+1

++++++

سيكون 1+ مفيدًا في التصحيح.

إذا كان الأمر يتعلق بشخص ما يعمل فقط على هذا ، أود أن أجربه. سأحتاج إلى البعض لتعلم قاعدة الرموز socket.io ، وربما سأقضي بعض الوقت في البحث عن تطبيقات أخرى من هذا القبيل. ما هي أفكارك حول أنماط regex؟ بطئ جدا؟ بالطبع ، لن أضيع وقتي إذا لم يكن هناك شيء يمكن اعتباره من أجل الدمج (لا يهمني إذا تم رفض تطبيقي ، ولكن إذا لم يكن هناك اهتمام ، فلماذا أزعجني ، أليس كذلك؟). سوف المشرف يرجى تقديم المشورة؟

لقد كتبت مكتبة socket.io-events. لقد غمرتني في العمل والحاجة
لمسها مرة أخرى. أود أن أؤيد الشكر بها

في يوم السبت ، 25 يوليو 2015 ، كتب John Manko [email protected] :

إذا كان الأمر يتعلق بشخص ما يعمل فقط على هذا ، فأنا أود أن أعطيها
لقطة. سأحتاج إلى بعض لتعلم قاعدة الرموز socket.io ، وأنا على الأرجح
قضاء بعض الوقت في البحث عن تطبيقات أخرى من هذا القبيل. ما هي الخاصة بك
أفكار حول أنماط regex؟ بطئ جدا؟ بالطبع ، لن أضيع
الوقت إذا لم يكن هناك شيء يمكن اعتباره للدمج (لا أفعل
أهتم إذا تم رفض تطبيقي ، ولكن إذا لم تكن هناك مصلحة ، فلماذا
عناء ، أليس كذلك؟). سوف المشرف يرجى تقديم المشورة؟

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/socketio/socket.io/issues/434#issuecomment -124901706.

+1

+1 هذه المشكلة مستمرة منذ 5 سنوات. لماذا لم يتم إضافة دعم أحرف البدل مرة أخرى؟

+1

+1

+1

+1

+666

+1

يا رفاق ، بجدية. الكل يريد هذه الميزة - أعتقد أنهم حصلوا عليها. دعنا نتوقف جميعًا عن الإضافات ، من فضلك؟ أفضل تلقي بريد إلكتروني للتحديث عندما يكون هناك بعض التقدم الفعلي في المشكلة.

ومع ذلك ، من المفيد معرفة أن الكثير من الناس مهتمون.
أعتقد أنه من الناحية المثالية ، يجب أن يكون لدى GitHub نظام تصويت؟

قد يكون نظام التصويت رائعًا ، ولكن لا يبدو أنه من المحتمل حدوثه في أي وقت قريب.

أعتقد أن المشكلة تكمن في أنه تم نشر حل عدة مرات الآن ، ولكن تم تمريره بعيدًا عن العرض نظرًا لوجود جميع تعليقات 1+.

تعمل وحدة socketio-wildcard بشكل جيد بالنسبة لي (من المسلم به أنني لم أقم بالتحديث إلى أحدث عقدة حتى الآن).
سيكون من المفيد أن يشرح أحد لماذا هذا الليب غير مناسب؟

نعم ، يعمل socketio-wildcard بشكل جيد تمامًا ، لكنه لا يزال اعتمادًا إضافيًا بسيطًا جدًا لدرجة أنه سيكون من الجيد تقديمه في جوهره وإنهاء موضوع المشكلة بالكامل مرة واحدة وإلى الأبد. كما أنه يزيل أي مجال للارتباك فيما يتعلق بأفضل وحدة خارجية يمكن استخدامها (غالبًا ما تحمل اسمًا مشابهًا). توافق أيضًا على أنه سيكون من الجيد أن يكون لدى GitHub نظام تصويت ، إذا كانت هناك طريقة يمكننا التصويت عليها فقط ...!

قد أكون غبيًا ، لكن ليس لدي أدنى فكرة عن كيفية إعداد socketio-wildcard مع كائنات عميل IO. يجب أن يتم تضمين هذا بجدية - بجدية - في جوهر. إذا كان المشرفون على socket.io لا يريدون القيام بذلك ، فيجب على شخص ما أن يتفرع من هذا المشروع ويمكننا جميعًا الانتقال إلى هناك ، لأن هذا أمر مثير للسخرية ولدي بصراحة ثقة صفرية في socket.io الآن.

أتفهم أن المشرفين ليسوا مضطرين لقبول كل عرض ، لكن هذا؟ هذا فقط يحيرني تماما. أحسنت.

@ n2l Liquid ليس من الواضح أن هذا يجب أن يكون في جوهره ، لكن المناقشة مرحب بها. على سبيل المثال ، لا يوجد مصدر آخر لانبعاث أحداث العقدة يتصرف بهذه الطريقة ، على الرغم من إجراء مناقشة هناك أيضًا.

تضمين التغريدة

ليس من الواضح أن هذا يجب أن يكون في جوهره ، لكن المناقشة مرحب بها

هل يمكننا إجراء مناقشة حول هذا بعد ذلك؟

أستطيع أن أفهم وجهة نظرك أن هذا النوع من الباعث ليس شائعًا بالضرورة في عالم العقدة ، لكنه يعتمد على ما تحاول تحقيقه ...
هل الفكرة هي الالتزام الصارم بالاتفاقيات ، أو توفير مكتبة مفيدة حقًا؟

يبدو من الواضح أن العديد من مستخدمي socket.io يتعثرون حقًا دون أن تكون هذه الميزة جوهرية ، ويبدو من المعقول أن يتوقع المستخدم أنها يجب أن تكون كذلك.

أو بعبارة أخرى ، ما هي الحجج لعدم توفير هذه الميزة في socket.io؟
حتى إذا لم يكن التنفيذ "صحيحًا في الكتاب المدرسي" ، فإنه سينتج عنه طريقة قياسية لتنفيذ معالجات "catchall" هذه في socket.io ، بدلاً من اضطرار الأشخاص إلى اللجوء إلى الكثير من المكتبات والطرق المختلفة.
يؤدي توجيه الأشخاص إلى جهة خارجية أو حل بديل إلى تجزئة الأشياء فقط ، ويجعل الأمر أكثر هشاشة عند محاولة الحفاظ على قاعدة بيانات تستخدم socket.io

أفضل كثيرًا وجود طريقة رسمية للتعامل مع الحزم العامة ، ثم إذا كانت بحاجة إلى تغيير لاحقًا ، على الأقل يمكن أن يكون هناك إجراء ترحيل موصى به ، بدلاً من مجرد تركه للمستخدم ليجد طريقه الخاص عبر البرية

rauchg أعتقد أن الطريقة الرائعة لتنفيذ ذلك socket.use(function(data,next){..}) تلتقط جميع الأحداث على المقبس ، ويتم تمرير الدالة التالية () التي تمرر التحكم من المجمع إلى مجموعات لاحقة أو معالجات الأحداث الافتراضية .

هذه هي الطريقة التي أستخدم بها socket.io الآن لأنني كنت بحاجة إلى طريقة للحد من كمية الأحداث القادمة في الدقيقة ، والتي أعتقد أنها حالة استخدام شائع. شكرا لقراءة 2 سنت.

أحب حل @ Michael77 أكثر من غيره. لا تلمس واجهات باعث الحدث أو التنفيذ ، بل إنها تسمح بأشياء أكثر مما نطلبه هنا (على سبيل المثال ، رسالة @ Michael77 تخنق التنفيذ ومن يعرف ماذا أيضًا).

أعلم أن هناك وظيفة وسيطة / استخدام في socket.io ، لكنها غير قابلة للاستخدام في مكتبة العميل ، ولست متأكدًا مما إذا كانت تخدم نفس الغرض.

carpii هناك دائمًا أسباب وجيهة لعدم دعم شيء ما: إضافة التعقيد وتقليل الألفة. هذه الميزة تتحقق من كليهما.

تعجبني فكرة socket.use كثيرًا ، علاوة على ذلك يمكن للمرء بسهولة تنفيذ امتداد حرف البدل على العميل.

شكرًا لك @ carpii @ Michael77 @ n2l Liquid لتعليقاتك على هذا راجع للشغل.

rauchg ، أنا آسف لأنني قلت تلك الأشياء السيئة حول socket.io. كنت أمضي يوما سيئا. شكرا لك على هذا المشروع. قد لا يكون مثاليًا (حتى الآن) ، لكنه بالتأكيد مفيد جدًا.

أيضا: https://github.com/hden/socketio-wildcard/issues/13

نرحب بملاحظات @ n2l Liquid _all_ - شكرًا لك (وإلى hden على هذا الإصلاح السريع على socket.io-wildcard ).

يبدو أن scoketio-wildcard حلاً صالحًا تمامًا. لقد وجدت نفسي أيضًا أرغب في الحصول على اسم الحدث في رد الاتصال ، حتى أتمكن من لف مستمع المقبس ونشر الأحداث من خلال الغلاف ، بدلاً من تعريض المقبس مباشرةً لبقية التطبيق الخاص بي. ما أفهمه هو أن هذا سيتطلب Event Emitter 2 إذا أردت القيام بذلك باستخدام حرف بدل. هل هذا مجرد شيء سخيف ، أفضل لكشف المقبس مباشرة؟ شيء ما يعتمد على الاستماع إلى "newListener" في الغلاف (ولكن لا تعرف كيفية تشغيل حدث مأخذ التوصيل ، فقط كيفية تسجيل حدث مأخذ التوصيل استنادًا إلى وظائف الاستدعاء التي تسجل حدثًا جديدًا في الغلاف)؟ أي شخص آخر مهتم بالقدرة على الوصول إلى اسم الحدث داخل رد الاتصال؟

akotlar اسم الحدث متاح في رد الاتصال إذا كنت تستخدم scoketio-wildcard.

آه بفضل! قد يكون من المفيد تحديد ذلك في الملف التمهيدي socket.io-wildcard.

كيف الحال؟
+1 مقابل on("*", function () { لكل من العميل والخادم

+1 طوال الطريق

@ alexey-sh @ emin93 إذا كنت تفضل قراءة المستند من https://github.com/hden/socketio-wildcard ، نعم من الممكن القيام بذلك لكل من العميل والخادم.

hden شكرًا ونعم لقد رأيت ذلك وأنا

يمكن معالجتها في منطق التطبيق باستخدام اسم حدث واحد لجميع الأحداث:

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

+1 على الرغم من إغلاق المشكلة.

+ 💯 فرقعة!

+1 !!!!

الرجاء استخدام socket.use .

هل هناك طريقة للربط بآلية PING / PONG الخاصة بـ engine.io باستخدام socket.use ()؟

أواجه مشكلة حيث يفقد العديد من المستخدمين الاتصال ، وعلى الرغم من تسجيل الدخول على الخادم بشكل مكثف ، إلا أنه يقول فقط إنهم قطعوا الاتصال بسبب مهلة Ping.

أرغب في تسجيل حزم PING / PONG ، ولكن يبدو أن socket.use () يمكنه فقط ربط رسائل حدث المستخدم عالية المستوى ، وليس البروتوكول الأساسي لـ engine.io

+1

+1

+1 منذ 2011؟ إنهم لا يفعلون ذلك. :(

مرة أخرى ، تمت إضافة 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);
هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات