Разумеется, я взял цифру с количеством статистики с потолка, тут извините (т.к. никогда не занимался разработкой софта с подобной функциональностью). Но как вы верно подметили, бóльшую часть времени занимает транспортировка пакетов и обработка данных, поэтому невозможно прогнозировать, с какой скоростью вернётся ответ. Если вы ожидаете этого ответа перед закрытием, то вы «задерживаете» пользователя на непрогнозируемый период времени.
На мой взяглд, несколько странный подход. А если данных будет оч. много, вы заставите пользователя ждать? Я пробыл на сайте 1 час и уходя у меня накопился 1Мб данных, которые надо отправить на сервер. Предположим, я нахожусь на даче и использую 3G телефона, который берёт «на добром слове». Вы заблокируете мне весь браузер, пока я не передам 1Мб по 3G? Вы маньяк!
Разнообразные «тепловые карты», отслеживающие посетителя на сайте и т.п. посылают данные отнюдь не в момент закрытия вкладки.
Хорошие вопросы! Увы, автор оригинального поста не затрагивает их. Но, немного порывшись в спеках, можно без труда на них ответить:
— Могу ли я отправить/получить файл?
Да, без проблем
— Могу ли я следить за прогрессом выполнения запроса?
Проще говоря, нет. Будет только состояние Promise'a, при выполнении которого (Promise'а) у вас будет Stream-объект с финальным статусом. Соответственно, на данный момент так же невозможно отследить % загрузки файла.
— Могу ли я сделать синхронный запрос?
Нет, и не факт, что это может быть доступно в дальнейшем. Но, лично я не вижу профита в этой опции. Если в данный момент можно установить XHR флаг «выполнись синхронно», то ничего не мешает сделать это асинхронно и вызывать др. функции в цепочке Promise'ов, как это сделано в примере с цепочками Promise'ов.
Можете привести простой пример, когда возникает необходимость отправить запрос синхронно и блокировать поток обработки UI до ответа онного? И чем такое решение лучше, чем асинхронный запрос?
Да, мы действительно обычно знаем, какие данные нужно отобразить и как они изменятся. Но тут акцент не на это, просто два разных подхода к решению задач: angular просит нас указывать ему, каким образом у нас будут изменяться данные, на основе чего он выбирает оптимальный путь к отображению этих данных (обновление связанного с данными DOM элемента или полная перерисовка). React же не требует от программиста дополнительных инструкций — он просто построит виртуальный DOM для новых данных и сравнит его с текущим (иногда можно ешё на этапе получения данных проверить на наличие изменений и установить shouldComponentUpdate на false в случае отсутствия онных. Это отменит процесс построения вирт. DOM и нахождения разницы между ним и текущим состоянием). Оба подходы имеют право на жизнь и существенно не влияют на скорость или качество разработки ПО (разве что косвенно).
Согласен, как я ни старался затюнить пример с React'ом, выше 50-55 операций в секунду (а не fps, к слову), не получается. Angular light на этом же примере показывает 55-60 операций в секунду. Посмотрим, может получится достать исходники Райана чтобы сравнить…
Можно попробовать воссоздать подобный тест. Судя по тому, что это написано для мониторинга серверов Facebook, вряд ли у нас будет открытый исходный код.
Когда вы говорите о 100 строках, вы подразумеваете возможность изменения данных каждой ячейки раз в секунду? Есть ли в ваших таблицах зависимости между полями?
aav Не соглашусь с вами — таблица из 100 строк с временем обновления в 1 секунду должна просто летать, а у angular'а начинаются проблемы уже на этом моменте. Я не считаю это каким-то надуманным кейсом. Как и говорит сам Райан, это их реальный кейс: кластер на 100 серверов и они хотят отслеживать изменение их состояний так быстро, как это возможно.
Fesor Пока сам не попробуешь — не узнаешь, я согласен. Но не думаю, что facebook будет подделывать тесты и подставлять свою репутацию ради пятиминутного видео сравнения производительности.
lega Я не думаю, что просадка происходит из-за обновления DOM'а, скорее из-за dirty-checking'а (о чём, кстати, говорит Райан Флоранс на видео).
Вот видео с конференции React.conf, которая была несколько дней назад (смотреть с 02:30), где можно посмотреть в сравнении ember.js, angular.js и react.js для большого количества динамически обновляющихся данных и поставить точку в споре о производительности.
Полностью согласен. По факту вы генерируете DOM дерево. Никакого HTML в JS нет и в помине. JSX так же опционален, как и любой другой препроцессор([coffee,type,pure]script). Смущает XML-синтаксис в JS — пишите в объектной нотации, кто ж запрещает?
По-моему статья вообще ничего не объясняет. Весь её смысл — в первом предложении: «Несколько дней назад Facebook анонсировал React Native — React, который транслируется в композицию нативных элементов мобильных приложений вместо DOM». Дальше про то, что вы можете использовать любой язык, который будет транслироваться в JS (но это не так, если вы хотите использовать JSX) и об общей концепции React. Где там хоть строчка о том, зачем это нужно и почему это лучше PhoneGap, например?
Разнообразные «тепловые карты», отслеживающие посетителя на сайте и т.п. посылают данные отнюдь не в момент закрытия вкладки.
— Могу ли я отправить/получить файл?
Да, без проблем
— Могу ли я следить за прогрессом выполнения запроса?
Проще говоря, нет. Будет только состояние Promise'a, при выполнении которого (Promise'а) у вас будет Stream-объект с финальным статусом. Соответственно, на данный момент так же невозможно отследить % загрузки файла.
— Могу ли я сделать синхронный запрос?
Нет, и не факт, что это может быть доступно в дальнейшем. Но, лично я не вижу профита в этой опции. Если в данный момент можно установить XHR флаг «выполнись синхронно», то ничего не мешает сделать это асинхронно и вызывать др. функции в цепочке Promise'ов, как это сделано в примере с цепочками Promise'ов.
— Менеджер пакетов
— А как его поставить?
— Через npm
— А что такое npm?
— Менеджер пакетов…
Мне кажется, уже давно все используют npm + browserify / webpack
Я написал Флорансу и он любезно поделился ссылкой на демки: github.com/ryanflorence/reactconf-2015-HYPE/tree/master/demos
(Создал новый тред, т.к. в том уже невозможно писать из-за вложенности)
Когда вы говорите о 100 строках, вы подразумеваете возможность изменения данных каждой ячейки раз в секунду? Есть ли в ваших таблицах зависимости между полями?
Fesor Пока сам не попробуешь — не узнаешь, я согласен. Но не думаю, что facebook будет подделывать тесты и подставлять свою репутацию ради пятиминутного видео сравнения производительности.
lega Я не думаю, что просадка происходит из-за обновления DOM'а, скорее из-за dirty-checking'а (о чём, кстати, говорит Райан Флоранс на видео).