Лимит не я контролирую, это данность и она не изменится. Понятия не имею, в чем логика.
«делать на реальные объекты: пользователя, страницу (ту, которая по URL), модули» — это общие слова, напрочь лишенные смысла. На какие, по-вашему, объекты распространяется подписка, о которой говорю я?
Сервер и так не готовит ничего бесконечное кол-во раз. Нотификации рассылаются отдельной подсистемой, которая при приходе события поднимает живые подписки и в них пишет данные. В одной подписке может быть несколько совершенно разных событий задействовано и каждая вкладка подписывается только на нужные ей лично.
Про Ваш юз-кейс — вы часто открывали 30 окон одного сайта? И нет, ничего не сломается, подписки будут убиваться в неактивных вкладках и создаваться в активных.
У Вас есть опыт создания подобных приложений? Игр, чатов, мессенджеров? Серверных частей для этого? Или Вы просто умозрительно рассказываете?
Сервер все может ;) но лимит есть лимит. У вас есть другие варианты, как обходить ограничение в 30 подписок, если не убивать их при закрытии окон? Поделитесь :) мультиплексирование всех событий через одну подписку в одной вкладке и распространение этого в другие вкладки не предлагать, уже проходили. Каждая вкладка должна иметь свой личный канал для нотификаций.
Есть сервер, на нем происходят некие события (упрощенно — меняется онлайн статус людей, им присылают сообщения, их сообщения меняют статус и т.д.), сервер по запросу клиента создает трекинг этих событий и отправляет клиенту пуш-нотификации. Если клиент допустим 5 минут не присылал хартбиты, то подписка удаляется, но также есть возможность удалить ее принудительно, если клиент считает, что в ней нет надобности. Это сугубо опциональная процедура, однако, если клиент начинает держать слишком много подписок — сервер это пресечет. Поэтому в интересах клиента ее уничтожить, если клиент 100% знает, что подписка более не нужна.
«Повесив пользователю браузер» — 200мс при закрытии страницы никто никогда не заметит. Если дольше — то случится таймаут и страница все равно закроется.
Какие далеко идущие выводы — до перезагрузки сервера… Смешно )
Асинхронный запрос в таком случае убивается моментально, до сервера не доходит. Освободить подписку значит сказать серверу, чтобы тот перестал пушить события по данной подписке.
А чтоб долго не ждать можно таймаут поставить, мне же по большому счету все равно, каков результат, мне надо сервер пнуть, чтоб тот подписку освободил, а для этого достаточно, чтоб запрос на него просто попал и будь что будет.
У меня был проект, где перед закрытием окна надо было освободить подписку на серверные события, потому что там был лимит на 30 штук. И если этого не делать — то они быстро кончались. Если процесс умер — бог с ним, но по возможности — почему бы не прибрать за собой?
TypeScript дает ощутимые преимущества во время разработки, а в результате все равно компилируется в обычный JS и использоваться может ровно так же, как и до этого.
Но зато вместе с TypeScript приходят и .d.ts файлы (см. проект DefinitelyTyped), которые даже при работе со скомпилированной JS версией в нормальных редакторах дают прекрасный автокомплит.
Когда ж у меня найдется время Ваши атомы потестировать…
У меня есть просьба — можно статью о том, как использовать атомы в приложении на React, а еще лучше — с учетом Flux. По-моему, отлично бы вписалось. Например чтоб можно было сравнить с github.com/facebook/flux/tree/master/examples/flux-chat.
А что теперь будет с Aurelia? Автор кажется сильно напирал на его AtScript'овость. Учитывая наличие Angular 2 основанном на TypeScript у автора Aurelia большая проблема, если он конечно еще не слился с вышеназванными.
Например, вы могли бы рассказать о статистике на Вашем не-абстрактном проекте, Вашей не-абстрактной сборке на Вашем не-абстрактном компьютере. Например, как это сделал standy.
Проект весит 20 мегабайт… тут знаете ли приходится выдумывать всякое, и как разделить его на динамически подгружаемые модули и как собрать максимально быстро.
Вы забываете, что размер проекта тоже растет. На проекте более тысячи файлов. И SSD есть почти у всех девелоперов, коих по последним подсчетам более ста человек. Вы так замечательно все додумываете, колкие фразочки пишете, а по существу ничего так толком и не сказали.
В последнее время я для себя решил эту проблему банально через пулл реквесты авторам, если меня что-то не устраивает в коде их проекта. Даже если режектнут — я свой форк всегда могу держать в живом состоянии.
На проекте используются requirejs плагины, а также не весь сайт собирается разом, он разбит на составные части, у которых собственный билд-процесс. Чтобы все нормально перевести на вебпак и протестировать придется потратить некоторое время, поэтому на данный момент я провожу анализ, стоит ли игра свеч.
Вот я по этой самой причине (сборка дольше 3 секунд) и пришел к выводу, что я хочу все компилировать прямо в браузере, потому как пару раз ловил неприятные баги от того, что после переключения в браузер что-то успело собраться, а что-то нет.
«делать на реальные объекты: пользователя, страницу (ту, которая по URL), модули» — это общие слова, напрочь лишенные смысла. На какие, по-вашему, объекты распространяется подписка, о которой говорю я?
Сервер и так не готовит ничего бесконечное кол-во раз. Нотификации рассылаются отдельной подсистемой, которая при приходе события поднимает живые подписки и в них пишет данные. В одной подписке может быть несколько совершенно разных событий задействовано и каждая вкладка подписывается только на нужные ей лично.
Про Ваш юз-кейс — вы часто открывали 30 окон одного сайта? И нет, ничего не сломается, подписки будут убиваться в неактивных вкладках и создаваться в активных.
У Вас есть опыт создания подобных приложений? Игр, чатов, мессенджеров? Серверных частей для этого? Или Вы просто умозрительно рассказываете?
«Повесив пользователю браузер» — 200мс при закрытии страницы никто никогда не заметит. Если дольше — то случится таймаут и страница все равно закроется.
Какие далеко идущие выводы — до перезагрузки сервера… Смешно )
Но зато вместе с TypeScript приходят и .d.ts файлы (см. проект DefinitelyTyped), которые даже при работе со скомпилированной JS версией в нормальных редакторах дают прекрасный автокомплит.
У меня есть просьба — можно статью о том, как использовать атомы в приложении на React, а еще лучше — с учетом Flux. По-моему, отлично бы вписалось. Например чтоб можно было сравнить с github.com/facebook/flux/tree/master/examples/flux-chat.