Socket.io: Добавить поддержку подстановочных знаков для событий

согласовано.

EventEmitter2

+1
Это позволило бы нам создавать фильтры, причем не для всех событий.

• другая зависимость
• должен быть отражен на стороне клиента (код?)
• следует ли вызывать catchall перед определенным событием? или в порядке определения? требуется разъяснение
• только поведение синхронизации - не лучше ли ввести собственные фильтры _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/commit/2107ff00f3ddf2d781d3e3c3b7dfb1fc990f7ec5

Филиал находится по адресу: https://github.com/einaros/socket.io/commits/ee2.

Мысли приветствуются.

если EE2 избавится от странных имен методов и добавит .on('*') я бы добавил, что

Я -1 на EE2

Это добавляет коду больше раздувания, нам также нужно поддерживать его на стороне клиента. Это означает, что нам придется отправить дополнительную библиотеку 11,8 КБ (уменьшенная ~ 3,5 КБ). Но с приближением мобильного рынка я хотел бы сэкономить как можно больше байтов.

Если на самом деле речь идет только о наличии подстановочного знака / перехвата всех слушателей ... Тогда это должно быть сделано путем переопределения существующей функции emit, которая просто выполняет один дополнительный вызов слушателя all . Это было бы как изменение 3–5 LOC (без учета комментариев;)). И должен быть скрыт за блокировкой предпочтений, поскольку это влияет на производительность. EventEmitting - это горячий код, который всегда должен быть максимально оптимальным и быстрым. Добавление подстановочных знаков снизит производительность.

все, безусловно, является более важной частью, достаточно легко включить мероприятие после этого, если это необходимо

На самом деле меня не волнуют подстановочные знаки или EE2, но способ перехвата всех событий является обязательным.

если EE2 ... добавляет .on ('*'), я бы добавил +1 к этому

TJ ты сумасшедший брат ...

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

Это из README EE2. Естественно, что "foo." не является обязательным.

если EE2 избавится от странных имен методов

Я согласен.

@pyrotechnick the .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 . Это слишком медленно?

Могу я еще раз отметить важность этого. Я бы хотел увидеть это в следующем выпуске.

Кто-то разместил здесь решение: http://stackoverflow.com/questions/8832414/overriding-socket-ios-emit-and-on/8838225

Это не работает, потому что я все еще не могу подключиться к мероприятию. В моем приложении сервер не знает имя комнаты от клиента. Поэтому я хочу иметь возможность отвечать на все сообщения для любой комнаты и, в идеале, узнавать имя комнаты, в которую было отправлено сообщение.

Добавьте поддержку регулярных выражений для событий ... таким образом, можно перехватывать диапазоны глаголов и существительных.

+1

+1

+1

+1

+1

Мне бы понравился суперглобальный метод, который справится со всем

io.set ('global_listener', функция (пространство имен, событие, аргументы, испускать) {
// делаем что-то на основе события и аргументов пространства имен
// Я могу или не могу вызвать emit () для вызова слушателей событий, связанных с этим пространством имен и этим событием
});

io.set ('global_authorization', функция (пространство имен, handshakeData, обратный вызов) {
// на основе пространства имен и handshakeData принимает или не принимает соединение
});

Мне нужен был эмиттер, поддерживающий всеохватывающее. ла. socket.on("*") , работал над клиентом, но по-прежнему был легковесным. Поэтому я взял эмиттер @visionmedia из UI Kit и немного расширил его. Возможно, он бы подошел для этого достойно. Итак, чего это стоит. Я просто оставлю это здесь: https://github.com/HenrikJoreteg/wildemitter

@HenrikJoreteg
Мы могли бы добавить "*" прямо из коробки к https://github.com/component/emitter.
Кроме того, этот эмиттер будет питать следующий socket.io. Он включает в себя ярлык 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

Ненавижу оставлять комментарий, который не вносит ничего значимого, но его просили уже 2 года, и все конструктивное уже было сказано. Так...

+1

Это было бы довольно легко добавить в пользовательскую среду, я не вижу необходимости иметь это в основной кодовой базе. Если я могу помочь с какими-либо перехватчиками, чтобы упростить расширение функциональности эмиттера событий без слишком большого количества исправлений обезьяны, я с радостью это сделаю.

Как это будет реализовано в пользовательском пространстве? Все решения, которые я видел, включают разветвление кодовой базы, а некоторые люди вообще связались с разными библиотеками.

В моем случае мне нужна только простая и понятная фраза «поймать абсолютно все в одной функции», но поддержка RegEx не кажется (парню, который не слишком внимательно следил за исходным кодом) слишком сложной и, безусловно, была бы невероятно полезной. . Я постоянно использую регулярные выражения в маршрутах Express.JS; Было бы неплохо сделать то же самое в socket.io.

Транспортный уровень / протокол останется неизменным. Вы бы просто переопределили 'emit' на обоих концах, чтобы не просто выполнять поиск по карте, а выполнять более полный (на основе регулярных выражений) поиск.

Предложения по быстрой реализации:

• Переопределите on чтобы поддерживать специальную структуру данных для регулярных выражений, когда в имени события встречается '*'
• Переопределите emit чтобы сначала выполнить быстрый случай (регулярный поиск по карте), затем просмотрите "*" слушателей и посмотрите, совпадают ли они.

Очевидно, для этого не требуется вилка. Под хуками я имел в виду то, что мы потенциально можем найти решение, которое не требует исправления обезьяны, но, учитывая, что эти два довольно простых метода, я не считаю это большой проблемой.

Просто из любопытства, не могли бы мы просто переопределить socket.Manager.prototype.onClientMessage из пользовательского пространства?

Я сделал это и работал нормально, в узле без изменений в модуле socket.io. Не очень красиво и, вероятно, сломается, но, по крайней мере, вы избежите разветвления.

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

Нельзя ли просто добавить где-нибудь process.EventEmitter = require('eventemitter2').EventEmitter2 до того, как потребуется socket.io? Мне кажется, это работает ...

Открытие прототипа определенно не является исправлением со стороны пользователя. Я понимаю, что не хочу реализовывать полную поддержку регулярных выражений или что-то еще, кроме простого socket.on ('*'), будет иметь большое значение.

Этому билету исполнилось 2 года.

Есть ли планы решить эту проблему, поскольку это явно полезная функция?

Если ответ отрицательный, я бы хотел разветвляться и сам добавлять.
Но я бы предпочел сделать это только в том случае, если его снова объединят upsteam.

Могут ли разработчики ответить на это, пожалуйста?

Согласен почти со всеми комментариями, модные вещи могут быть более или менее спорными, но все же было бы неплохо. Пользователи могут сделать это сами, но предопределенная процедура была бы чище.

Жаль, что этого не существует.

Он существует, см. Ссылку, которую кто-то опубликовал ранее
http://stackoverflow.com/questions/8832414/overriding-socket-ios-emit-and-on/8838225

Я использую это, и он отлично работает :)

+1

Исправление обезьяны к чему-то простому, как мне кажется, чем-то вроде плохой практики, однако я думаю, что не следует использовать какую-то большую реализацию, для большинства разработчиков в этом вопросе будет достаточно чего-то простого, например Backbone.Events , Думаю. (хотя Backbone не использует «*», а «all» для глобального события, передавая имя события, которое изначально вызывается, что является лучшим решением). (это всего лишь предложение) =)

Лично +1 к способу RegExp, он кажется более Javascript и менее удобным по сравнению с подстановочным знаком "*" .

Но, как и в случае с последними голосами, функция «всеохватывающего» кажется более подходящей.

Не уверен, что это действительно проблема socket.io.

В замороженном 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. Я не вижу аргументов в пользу исключения этого, кроме того, что «здесь все не так», что никогда не является хорошим аргументом.

Аргумент состоит в том, что мы пытаемся работать так же, как узел EventEmitter , а узел его не имеет, поэтому он стал бы «socket.io-ism». В Node велись обширные дискуссии о его добавлении, но ничего не вышло.

@chevex Хотя изначально я

Это гораздо лучшие аргументы. Я думаю, вы не хотите, чтобы EventEmitter по умолчанию вел себя иначе, чем node. И @ DanH42 Я также полагаю, что вы правы в том, что расширение его с помощью промежуточного программного обеспечения имеет больше смысла для тех, кто в нем нуждается. Отзываю свое заявление :)

Если бы только EventEmitter узла поддерживал подстановочные знаки из коробки.

: +1:

Я вижу, что пропустил эту проблему, я начал новую проблему с пересылкой событий:
https://github.com/Automattic/socket.io/issues/1715
Он включает два способа обработки всех событий из socket.io 1.0 без изменения его источника.

Я просто хочу это для отладки. У меня нет полномочий добавлять или изменять библиотеки в нашем проекте. : sob:

+1
Иногда вам нужно знать все распространяющиеся события!

+1

• 1

В итоге я использовал модуль socketio-wildcard от

Спасибо, Мэтт! Я был подавлен, но я надеюсь провести выходные, чтобы немного поработать.
улучшения

отправлено из моего Айфона

6 января 2015 г. в 8:30 Мэтт Флетчер [email protected] написал:

В итоге я использовал @NathanGRomano https://github.com/NathanGRomano
модуль socketio-events https://www.npmjs.com/package/socket.io-events ; Это
кажется наиболее прозрачным методом (с использованием промежуточного программного обеспечения) и вполне работает
приятно для меня. Но [image:: +1:] для того, чтобы вставить это в ядро!

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/Automattic/socket.io/issues/434#issuecomment -68864750.

+1

+1

++++++

+1 пригодится для отладки.

Если дело в том, что кто-то просто над этим работает, я бы хотел попробовать. Мне понадобится кое-что, чтобы изучить кодовую базу socket.io, и я, вероятно, потрачу некоторое время на изучение других подобных реализаций. Что вы думаете о шаблонах регулярных выражений? Слишком медленно? Конечно, я не собираюсь тратить свое время, если это не то, что будет рассматриваться для слияния (меня не волнует, будет ли моя реализация отклонена, но если нет интереса, тогда зачем беспокоиться, верно?). Сопровождающий, пожалуйста, посоветует?

Я написал библиотеку socket.io-events. Я был завален работой и нуждами
прикоснуться к нему снова. Я хотел бы поддержать признательность этим

В субботу, 25 июля 2015 г., Джон Манко [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 у меня хорошо работает (по общему признанию, я еще не обновился до последней версии).
Было бы полезно, если бы кто-нибудь мог объяснить, почему эта библиотека не подходит?

Да, socketio-wildcard работает отлично, но это все еще дополнительная зависимость, которая настолько проста, что было бы неплохо ввести ее в ядро ​​и просто завершить всю эту

Я могу показаться глупым, но я понятия не имею, как настроить socketio-wildcard с клиентскими объектами ввода-вывода. Это должно быть серьезно, серьезно_ включено в ядро. Если сопровождающие socket.io не хотят этого делать, кто-то должен просто разветвить этот проект, и мы все сможем туда переехать, потому что это просто смешно, и я, честно говоря, сейчас не доверяю socket.io.

Я понимаю, что сопровождающие не обязаны принимать каждое предложение, но это? Это меня совершенно сбивает с толку. Путь к работе.

@ n2liquid не так ясно, что это должно быть в ядре, но обсуждение приветствуется. Например, ни один другой эмиттер событий Node не ведет себя подобным образом, даже несмотря на то, что там тоже обсуждалось, когда.

@rauchg

не так ясно, что это должно быть в ядре, но обсуждение приветствуется

Не могли бы мы тогда обсудить это?

Я могу понять вашу точку зрения, что этот вид эмиттера не обязательно распространен в мире узлов, но это зависит от того, чего вы пытаетесь достичь ....
Является ли идея строго придерживаться соглашений или предоставить действительно полезную библиотеку?

Кажется очевидным, что многие пользователи socket.io действительно спотыкаются без этой функции в ядре, и пользователю кажется разумным ожидать, что так и должно быть.

Или, другими словами, каковы аргументы, чтобы НЕ предоставлять эту функцию в socket.io?
Даже если реализация не является «правильной по учебнику», это приведет к стандартному способу реализации этих «улавливающих» обработчиков в socket.io, вместо того, чтобы людям приходилось прибегать к множеству различных библиотек и методов.
Направление людей к сторонней библиотеке или обходному пути только фрагментирует вещи и делает их еще более уязвимыми при попытке поддерживать кодовую базу, которая использует socket.io

Я бы предпочел, чтобы существовал формальный способ обработки перехватывающих пакетов, а затем, если его нужно будет изменить позже, по крайней мере, может быть рекомендованная процедура миграции, вместо того, чтобы просто оставлять ее для пользователя, чтобы найти свой собственный маршрут через пустыню.

@rauchg Я думаю, что классный способ реализовать это - иметь функцию socket.use(function(data,next){..}) которая улавливает все события в сокете и передаёт функцию next (), которая передает управление от catchall к последующим уловкам или обработчикам событий по умолчанию .

Вот как я использую socket.io прямо сейчас, потому что мне нужен был способ ограничить количество событий, приходящих в минуту, что, как я считаю, является распространенным вариантом использования. Спасибо, что прочитали мои 2 цента.

Мне больше всего нравится решение @ Michael77 . Он не затрагивает интерфейсы или реализацию генератора событий и даже допускает больше вещей, чем мы просим здесь (например, реализация регулирования сообщений

Я знаю, что в socket.io есть функция промежуточного программного обеспечения / использования, но ее нельзя использовать в клиентской библиотеке, и я не уверен, служит ли она той же цели.

@carpii всегда есть веские причины, чтобы _не_ что-то поддерживать: добавление сложности, сокращение знакомства. Эта функция проверяет оба.

Мне очень нравится идея socket.use , помимо которой можно легко реализовать расширение с подстановочными знаками на клиенте.

Спасибо @carpii @ Michael77 @ n2liquid за ваш отзыв об этом, кстати.

@rauchg , мне жаль, что я сказал плохие вещи о socket.io. У меня был плохой день. Спасибо за этот проект; Возможно, он не идеален (пока), но, безусловно, очень полезен.

Также: https://github.com/hden/socketio-wildcard/issues/13

@ n2liquid _все_ отзывы приветствуются - спасибо (и @hden за это быстрое исправление в socket.io-wildcard ).

scoketio-wildcard кажется вполне допустимым решением. Я также обнаружил, что хочу получить имя события в обратном вызове, чтобы я мог обернуть прослушиватель сокета и распространять события через оболочку, а не напрямую подвергать сокет остальной части моего приложения. Насколько я понимаю, для этого потребовался бы Event Emitter 2, если бы я хотел сделать это с помощью подстановочного знака. Это что-то глупое, лучше сразу открыть сокет? Что-то основанное на прослушивании 'newListener' в оболочке (но не знаю, как запускать событие сокета, только как зарегистрировать событие сокета на основе вызывающих функций, регистрирующих новое событие в оболочке)? Кто-нибудь еще заинтересован в возможности доступа к имени события в обратном вызове?

@akotlar Имя события доступно в обратном вызове, если вы используете scoketio-wildcard.

Ах, спасибо! Это может быть полезно указать в файле readme socket.io-wildcard.

как дела?
+1 за on("*", function () { как для клиента, так и для сервера

+1 полностью

@ alexey-sh @ emin93 Если вы любезно прочтете документ с https://github.com/hden/socketio-wildcard , да, это возможно как для клиента, так и для сервера.

@hden Спасибо, да, я это видел и уже использую. Но это дополнительная зависимость, и ничто не говорит против ее интеграции непосредственно в ядро ​​Socket.IO, поэтому она получает от меня +1.

Его можно обработать в логике приложения, используя одно имя события для всех событий:

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);