Запустить и остановить отправленные сервером уведомления о событиях - PullRequest
Новая
       10

Запустить и остановить отправленные сервером уведомления о событиях

2 голосов
/ 10 мая 2011

У меня есть 3 отправленных сервером события, доступных на странице. Только один для просмотра в любое время. Я хотел бы остановить слушателя на 2 из 3 потоков событий, когда 1 из них активен. У меня есть тестирование оператора switch, для которого видно, но я не могу передать source.close () моему событию напрямую, так как оно похоронено в функции: 

var firstEventSource = function() { 
    var eventSrc = new EventSource('firstSTREAM.php');
    eventSrc.addEventListener('message', onMessageHandler);
};

Я надеялся, что у меня будет меньше открытых соединений с сервером, особенно с непросмотренными данными. Если у вас есть лучшее предложение, я весь слух!

Best

T * 1008

Ответы [ 2 ]

4 голосов
/ 29 ноября 2011 
function onMessageHandler(event) {
  if ("your want to close that EventSource") {
    event.target.close();
  }
}
2 голосов
/ 17 августа 2012

На этот вопрос сложно ответить без контекста, но я сделаю все возможное.

Вы можете представить ресурс события как канал, по которому вы отправляете все свои сообщения, и клиент слушаетдля конкретных событий - эффективное мультиплексирование: 

var handler = console.log.bind(console)
  , events  = new EventSource("/events")

events.addEventListener("new-friend", handler)
events.addEventListener("new-message", handler)
events.addEventListener("new-notification", handler)

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

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

/* Assuming jquery is available and with the following html:
 * <a class="stream" href="/friends>Friends</a>
 * <a class="stream" href="/messages>Messages</a>
 * <a class="stream" href="/notifications>Notifications</a>
 */

var currentEvents
  , handler = console.log.bind(console)

$("a.stream").on("click", function() {
    $el = $(this)

    currentEvents && currentEvents.close()

    currentEvents = new EventSource($el.attr("href"))

    currentEvents.addEventListener("message", handler)

    return false
})

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

...