Pull to refresh

Comments 13

И в этом нам не сможет помочь никто кроме этих SharedWorker'ов.

Я бы не был столь категоричным — есть localStorage. Другое дело, что SharedWorker удобнее, потому что создаёт события. Для неподдерживающих браузеров можно эмулировать периодическим опросом localStorage.
Тогда уж sessionStorage. И да, *Storage тоже рассылают события, так что опрашивать совершенно не нужно.
Можно довольно просто реализовать общение между вкладками через localStorage, обеспечивая при этом псевдомонопольный режим использования вебсокет коннекта, другое дело что это костыль :) Проверять головную вкладку на состояние здоровья (может юзер ее уже закрыл) можно через простешие пинги так же через локальное хранилище, раз в секунду, например. А выбирать следующую вкладку, которая станет хостом для остальных можно реализовав стек в том же хранилище %) вобщем если заморочиться и если очень хочется то можно и сейчас использовать, не дожидаясь нормальной поддержки прелести из топика :)
Самое странное в этих вокрерах то, что там есть событие на подключение, но нету события на отключение клиента (закрытия вкладки). Поэтому мы можем только копить соединения, а узнать какие из них уже закрыты — нет.

Кстати, возможность отладки появилась в последних версиях хрома — blog.chromium.org/2012/04/debugging-web-workers-with-chrome.html
м, точно — будут же зависать такие соединения на сервере, и есть ресурсы.
мб в будущих версиях какой-нибудь unload сделают.
проверил сейчас свой пример с вебсокетами — хоть и нет события на отключение клиента, а вебсокет закрывается нормально, по событию 'close' (console.log если там поставить, оно выводится по закрытию вкладки).
Я немного не по то, я про комуникацию шаредворкера с вкладками. Что бы собирать массив коннекшенов (ака «вкладок»), для этого у воркера есть событие connect. Но у него нету события disconnect, что бы эти коннекшены можно было выкидывать из общего пула.
Sign up to leave a comment.

Articles