Если это вообще не связанные приложения, то все равно беспокоиться не о чем) Сама переменная в localStorage называется уникально, словарь выглядит так:
Но есть о чем задуматься. Вероятно, нужен "механизм фонового взаимодействия" вновь открываемых вкладок, у которых создается новый инстанс TabsBroadcast. Я подумаю об этом. Спасибо!
Так же замечу, что если на новой фоновой вкладке будет открыта вкладка с новым экземпляром TabsBroadcast у которой стоит флаг "emitByPrimaryOnly: true", то она ничего отправить никому не сможет. Это вы верно подметили. Но при этом, она не считается Primary, а значит она никакие активности не должна выполнять в принципе (не открываются WebSocket, не получает SSE, ничего не дергает по API).
Замечание хорошее, спасибо что изучали код и пытались его понять! Объясняю:
1) Механизм создания нескольких экземпляров TabsBroadcast нужен для того, чтобы объединять несколько приложений внутри одного веб-сайта. Поэтому можно создавать бесконечное количество инстансов, каждый из которых будет обмениваться сообщениями между собой. 2) А вот primaryTabId - это сущность, связанная с вкладками браузера (в каждой из которых работает N инстансов). При закрытии или переключении вкладок браузера все N инстансов должны будут изменить режим Primary\Slave. Т.е. переменная относится к общему для всех инстансов механизму переключения режима активности.
Спасибо за комментарий! Я вовсе не считаю, что авторы addEventListener — “душные старпёры”, а сам я — “король лаконичности”. Разные стили и названия отражают разные подходы и эпохи в развитии JavaScript и веб-стандартов. addEventListener в свое время ввел более формальный и универсальный способ подписки на события, а короткие методы вроде on стали популярны благодаря более “цепочечному” стилю кода в фреймворках и библиотеках. В итоге каждый разработчик выбирает то, что ему удобнее и понятнее в контексте конкретного проекта. Я просто поделился своим взглядом — он, конечно, не единственно верный. Но рад, что статья вызвала интерес и дискуссию!
BroadcastChannel - сам по себе решает задачу лишь обмена сообщениями между вкладками, но не решает проблему гонки и синхронизации между ними. Мое решение делает "главной" лишь одну вкладку и с нее, допустим, общается с бекендом и сервисами, поднимает WebSocket, принимает SSE и т.п., рассказывая другим вкладкам о результатах.
Кажется, что именно для этого и нужен Habr - делится мнениями и отрезвлять воспаленные умы) Про *hipster не слышал, почему-то не попадался на глаза, но в целом, это ровно то, о чем я подумал в ночь 1 Января)
Хм… да, вот здесь я ошибся. Не знал о таком поведение localStorage. Если открыть один и тот же домен в нескольких! окнах!, то и LS у них будет общий. приношу извинения за смуту. Занятная механика)
Это решение породит куда больше проблем. В браузерах есть событие о том, что пользователь сделала вкладку аквтивной или ушел с нее. Т.е. мы можем открывать и закрывать соединения, а вот на сервере активные клиенты все равно будут какое-то время существовать и им будет все отдаваться в сокеты. Они будут умирать через некое время, что в моменте может порождать большое количество мертвых, но активных соединений. Это же даёт возможность при переключении их вкладки во вкладку быстро положить даже самый сильный бекенд
Допустим, это twitch. У меня открыта главная страница со списком стримов, вторая на втором мониторе с активным стоимость, который я смотрю и ещё одна на фоне, я просто хочу посмотреть, что там происходит.
Или же это сайт-биржа. Я слежу сразу за несколькими котировками валюты в реалтайме
Вот как. Если мы выйдем из гибернации и сторедж будет пустой, то произойдет инициализация подключения. И будет работать механизм конкуренции вкладок. Та, кто первая успеет вызвать коннект, та и станет главной.
Можно. И надо хранить массив открытых вкладок там же. А при закрытии одной из них пробегать счета по всем и сравнивать их по timestamp. Если вкладок >10 это уже будет дольше, чем мой вариант.
Проблема в том, что умирающая вкладка не знает ничего о других. О их количестве и есть ли они вообще. В свою очередь Secondary не знают ничего друг о друге.
Можно хранить массив из времени создания всех вкладок, но это более ресурсоемкая задача — гонять массивы
У меня проблема была в том, что на Хабре я не смог ничего подобного найти, а разобраться самому во всех тонкостях работы такой большой библиотеки сложновато
Если это вообще не связанные приложения, то все равно беспокоиться не о чем) Сама переменная в localStorage называется уникально, словарь выглядит так:
Вряд ли кто-то сможет их перепутать и позаимствовать)
Но есть о чем задуматься. Вероятно, нужен "механизм фонового взаимодействия" вновь открываемых вкладок, у которых создается новый инстанс
TabsBroadcast. Я подумаю об этом. Спасибо!Так же замечу, что если на новой фоновой вкладке будет открыта вкладка с новым экземпляром
TabsBroadcastу которой стоит флаг "emitByPrimaryOnly: true", то она ничего отправить никому не сможет. Это вы верно подметили. Но при этом, она не считается Primary, а значит она никакие активности не должна выполнять в принципе (не открываются WebSocket, не получает SSE, ничего не дергает по API).Замечание хорошее, спасибо что изучали код и пытались его понять! Объясняю:
1) Механизм создания нескольких экземпляров
TabsBroadcastнужен для того, чтобы объединять несколько приложений внутри одного веб-сайта. Поэтому можно создавать бесконечное количество инстансов, каждый из которых будет обмениваться сообщениями между собой.2) А вот
primaryTabId- это сущность, связанная с вкладками браузера (в каждой из которых работает N инстансов). При закрытии или переключении вкладок браузера все N инстансов должны будут изменить режим Primary\Slave. Т.е. переменная относится к общему для всех инстансов механизму переключения режима активности.Спасибо за комментарий! Я вовсе не считаю, что авторы
addEventListener— “душные старпёры”, а сам я — “король лаконичности”. Разные стили и названия отражают разные подходы и эпохи в развитии JavaScript и веб-стандартов.addEventListenerв свое время ввел более формальный и универсальный способ подписки на события, а короткие методы вродеonстали популярны благодаря более “цепочечному” стилю кода в фреймворках и библиотеках. В итоге каждый разработчик выбирает то, что ему удобнее и понятнее в контексте конкретного проекта. Я просто поделился своим взглядом — он, конечно, не единственно верный. Но рад, что статья вызвала интерес и дискуссию!BroadcastChannel - сам по себе решает задачу лишь обмена сообщениями между вкладками, но не решает проблему гонки и синхронизации между ними. Мое решение делает "главной" лишь одну вкладку и с нее, допустим, общается с бекендом и сервисами, поднимает WebSocket, принимает SSE и т.п., рассказывая другим вкладкам о результатах.
Да, библиотека моя, я давно ее веду, с 2018 года в разных реализациях. Спасибо за теплые слова, это мотивирует!)
Кажется, что именно для этого и нужен Habr - делится мнениями и отрезвлять воспаленные умы)
Про *hipster не слышал, почему-то не попадался на глаза, но в целом, это ровно то, о чем я подумал в ночь 1 Января)
Всем спасибо, думаю, тема закрыта раньше времени)
Это решение породит куда больше проблем. В браузерах есть событие о том, что пользователь сделала вкладку аквтивной или ушел с нее. Т.е. мы можем открывать и закрывать соединения, а вот на сервере активные клиенты все равно будут какое-то время существовать и им будет все отдаваться в сокеты. Они будут умирать через некое время, что в моменте может порождать большое количество мертвых, но активных соединений. Это же даёт возможность при переключении их вкладки во вкладку быстро положить даже самый сильный бекенд
… с активным стримом...
Допустим, это twitch. У меня открыта главная страница со списком стримов, вторая на втором мониторе с активным стоимость, который я смотрю и ещё одна на фоне, я просто хочу посмотреть, что там происходит.
Или же это сайт-биржа. Я слежу сразу за несколькими котировками валюты в реалтайме
Вот как. Если мы выйдем из гибернации и сторедж будет пустой, то произойдет инициализация подключения. И будет работать механизм конкуренции вкладок. Та, кто первая успеет вызвать коннект, та и станет главной.
Можно. И надо хранить массив открытых вкладок там же. А при закрытии одной из них пробегать счета по всем и сравнивать их по timestamp. Если вкладок >10 это уже будет дольше, чем мой вариант.
Можно хранить массив из времени создания всех вкладок, но это более ресурсоемкая задача — гонять массивы
Именно для этого мы здесь и собрались, чтобы находить лучшие решения)