Комментарии 145
Могу ли я отправить/получить файл?
Могу ли я следить за прогрессом выполнения запроса?
Могу ли я сделать синхронный запрос?
Могу ли я следить за прогрессом выполнения запроса?
Могу ли я сделать синхронный запрос?
Судя по ссылке «Да» в посте — можно отправить файл :)
body: Any body that you want to add to your request: this can be a Blob, BufferSource, FormData, URLSearchParams, or USVString object. Note that a request using the GET or HEAD method cannot have a body.
developer.mozilla.org/en-US/docs/Web/API/GlobalFetch/fetch
Зачем вам синхронный запрос?
Зачем вам синхронный запрос?На глупый вопрос глупый ответ. Синхронный запрос нужен чтоб запрос делался синхронно.
То есть есть мифическая ситуация, в которой на клиенте нужен лок потока выполнения, ради выполнения запроса к серверу?
Почему мифическая?
Вы совершенно исключаете, что могут потребоваться получить/отправить такие данные, без которых не должно происходить никаких действий пользователя с интерфейсом. Если это делать асинхронным запросом, придется городить костыли.
Вы совершенно исключаете, что могут потребоваться получить/отправить такие данные, без которых не должно происходить никаких действий пользователя с интерфейсом. Если это делать асинхронным запросом, придется городить костыли.
Любой лок интерфейса отпугнет пользователя, так что развлекайте его пока идет запрос.
Пугливость пользователя и юзабилити — это вопросы другой плоскости. Мы говорим про технические возможности.
ну… чисто теоретически это может быть даже не пользовательское приложение… И даже без Гуя…
Представил, как диспетчер (у нас веб-интерфейс), что-то там испугался и убежал с рабочего места в поисках развлечений :-D
Веб это не толь «сайтики».
Веб это не толь «сайтики».
Можете привести простой пример, когда возникает необходимость отправить запрос синхронно и блокировать поток обработки UI до ответа онного? И чем такое решение лучше, чем асинхронный запрос?
Когда блокировка гуя не критична или гуя вообще нет. Но при этом нужно сделеть:
— обращение к какому-нибудь API обернутое просто в функцию которая просто возвращает значение, без нагромождения коллбэков или
— запросы в определенной последовательности или даже в цилке, без мороки с deffered или
— в конце концов когда запрашивается модальное окно, то весь вьюпорт браузера обычно закрывают каким-нибудь полупрозрачным слоем, иногда с анимированным прелоадером. Что это как не имитация блокировки пользовательского интерфейса?
— обращение к какому-нибудь API обернутое просто в функцию которая просто возвращает значение, без нагромождения коллбэков или
— запросы в определенной последовательности или даже в цилке, без мороки с deffered или
— в конце концов когда запрашивается модальное окно, то весь вьюпорт браузера обычно закрывают каким-нибудь полупрозрачным слоем, иногда с анимированным прелоадером. Что это как не имитация блокировки пользовательского интерфейса?
— в конце концов когда запрашивается модальное окно, то весь вьюпорт браузера обычно закрывают каким-нибудь полупрозрачным слоем, иногда с анимированным прелоадером. Что это как не имитация блокировки пользовательского интерфейса?
Да, но там еще бывает кнопка «Отмена» или «Закрыть». Может быть еще анимация или полезные советы.
А в вашем случае будет только
висящее окно браузера
— обращение к какому-нибудь API обернутое просто в функцию которая просто возвращает значение, без нагромождения коллбэков или
— запросы в определенной последовательности или даже в цилке, без мороки с deffered
По-моему, уже давно существует тысяча и один способ нормально работать и с callback-ами и с promise-ами и даже с колбасными или кисломолочными изделиями.
Да, подвисание браузера не всегда хорошо, даже почти всегда не хорошо. Можно сделать юзабельнее. Прекрасно это понимаю.
Да, есть возможность заменить синхронные запросы с помощью асинхронных. И есть библиотеки которые делают удобно.
Является ли это достаточными причинами, выпиливать, точнее недореализовывать, в нативной поддержке браузером инструмента, который был до этого и даже использовался?
Я считаю, что нет, не достаточно, синхронные запросы должны быть. Оппоненты считают, что да — достаточно, инструмент этот мало востребован и заменяем, они не могут придумать для чего это надо, значит его быть не должно.
Я считаю, что я ближе к правоте, посколько сюда тянутся воспросы обратной совместимости, переносимости.
Да и вообще, наличие инструмента лучше, чем его отстутствие. Разумеется, с поправкой на то, что реализация этого инстремента не ухудшает браузер. Я не думаю, что Хром станет хуже работать, жрать больше памяти и т.п,. если будет реализованы синхронные запросы.
Да, есть возможность заменить синхронные запросы с помощью асинхронных. И есть библиотеки которые делают удобно.
Является ли это достаточными причинами, выпиливать, точнее недореализовывать, в нативной поддержке браузером инструмента, который был до этого и даже использовался?
Я считаю, что нет, не достаточно, синхронные запросы должны быть. Оппоненты считают, что да — достаточно, инструмент этот мало востребован и заменяем, они не могут придумать для чего это надо, значит его быть не должно.
Я считаю, что я ближе к правоте, посколько сюда тянутся воспросы обратной совместимости, переносимости.
Да и вообще, наличие инструмента лучше, чем его отстутствие. Разумеется, с поправкой на то, что реализация этого инстремента не ухудшает браузер. Я не думаю, что Хром станет хуже работать, жрать больше памяти и т.п,. если будет реализованы синхронные запросы.
для обратной совместимости есть старый добрый XMLHttpRequest, его никто не выкинул, а тут запилили новое апи, всё такое на обещаниях и асинхронное. Если сюда добавить синхронность в чем тогда смысл делать новое апи? тоже самое (promises) можно получить и сейчас в том же jquery
>> Да и вообще, наличие инструмента лучше, чем его отстутствие.
Далеко не всегда. Если инструмент в 90% случаев будут использовать некорректно (т.е. писать синхронный код там, где на самом деле нужен асинхронный, просто потому, что так проще, или потому, что автор увидел синхронный метод первым), то его может быть лучше убрать. Или, по крайней мере, спрятать подальше.
Далеко не всегда. Если инструмент в 90% случаев будут использовать некорректно (т.е. писать синхронный код там, где на самом деле нужен асинхронный, просто потому, что так проще, или потому, что автор увидел синхронный метод первым), то его может быть лучше убрать. Или, по крайней мере, спрятать подальше.
Кстати, изделие не «кобласное», а «англо-средневековое». :)
Ну к примеру у нас есть веб-приложение (SPA), которое в самом начале загрузки должно получить конфиг с сервера, без которого ни один последующий запрос не может выполняться (в конфиге содержатся сопутствующие данные), ни интерфейс не может отрисоваться (в конфиге содержатся языковые литералы и другие настройки интерфейса). Вот мы и делаем синхронный запрос на получения конфига, а в это время крутится прелоудер.
Если можете предложить более простой способ решения задачи, то с удовольствием прочитаю.
А вообще вопрос на мой взгляд ни о чем. Причин делать синхронные запросы ровно столько же, сколько и асинхронные. Все дело в решаемой задаче.
Ещё пример: нужно последовательно выполнить несколько запросов к серверу. Разве это не кейс для использования синхронных запросов?
Если можете предложить более простой способ решения задачи, то с удовольствием прочитаю.
А вообще вопрос на мой взгляд ни о чем. Причин делать синхронные запросы ровно столько же, сколько и асинхронные. Все дело в решаемой задаче.
Ещё пример: нужно последовательно выполнить несколько запросов к серверу. Разве это не кейс для использования синхронных запросов?
Во всех перечисленных случаях прекрасно подойдут асинхронные запросы.
Пусть так, тогда могли бы вы подробнее объяснить в чем прелесть решать синхронную задачу асинхронным методом?
js — однопоточный язык. В нем попросту нельзя использовать ничего синхронного.
Была бы возможность создать отдельный поток и делать синхронные запросы в нем — не было бы никаких проблем с синхронными запросами. Но возникли бы проблемы с синхронизацией потоков и общим доступом к разделяемым ресурсам — потому от дополнительных потоков и отказались.
Была бы возможность создать отдельный поток и делать синхронные запросы в нем — не было бы никаких проблем с синхронными запросами. Но возникли бы проблемы с синхронизацией потоков и общим доступом к разделяемым ресурсам — потому от дополнительных потоков и отказались.
А какая разница однопоточный или нет? Если задача требует блокировки потока, почему я не должен использовать синхронный запрос?
Сегодня вам требуется блокировка потока — а завтра понадобится сделать еще одну цепочку вызовов параллельно. Сразу написать на промизах так же просто, как и написать запросы синхронно — а вот переделывать синхронный код на промизы может оказаться сложно.
Зато на fibers переделывать синхронный код легко и просто, но их почему-то не внедряют в браузеры :-(
Это уже мои риски по рефакторингу. И никак не должно влиять на наличие или отсутствие возможности в самом API. Задачи бывают разные и ни я, ни вы не можем точно описать их множество. Поэтому не вижу ничего плохого в том, что возможность синхронного запроса останется.
А минусующие могут как-то мысль высказать? Даже если человек не прав, смысл тупо минус ставить? Объясните своё мнение.
Объяснение простое — промисы сейчас в тренде.
Ныне миром программирования правят именно тренды. Никому не надо думать, искать лучшее решение, взвешивать плюсы и минусы разных подходов. Сейчас все стараются бежать туда, куда бежит большинство. Пусть даже бегут они в пропасть, но бегут вместе и из пропасти потом будут выбираться тоже вместе. А если бежать самостоятельно, то есть ненулевой шанс тоже оказаться в пропасти, но в которой кроме тебя почти никого не будет и нельзя будет «найти ответ на stackoverflow» или «подключить библиотеку, которая решает проблему, созданную другой библиотекой».
Ещё вчера, все бежали в сторону (X)(HT)ML и ставили минусы всем, кто не закрывал теги. Сейчас же ставят минусы за использование XML в апи, вместо трендового JSON. Промисы тоже скоро выйдут из моды благодаря генераторам и тому подобным реализациям кооперативной многозадачности. Но для длительных операций использование промисов, генераторов и прочих «ждём до завершения» штук — плохое решение, так как исключает возможность следить за прогрессом выполнения задачи. Именно поэтому при грамотной архитектуре fetch должен возвращать не объект Promise, а объект XMLHttpRequest, который уже может реализовывать thenable интерфейс для частного случая «ждём до завершения».
Ныне миром программирования правят именно тренды. Никому не надо думать, искать лучшее решение, взвешивать плюсы и минусы разных подходов. Сейчас все стараются бежать туда, куда бежит большинство. Пусть даже бегут они в пропасть, но бегут вместе и из пропасти потом будут выбираться тоже вместе. А если бежать самостоятельно, то есть ненулевой шанс тоже оказаться в пропасти, но в которой кроме тебя почти никого не будет и нельзя будет «найти ответ на stackoverflow» или «подключить библиотеку, которая решает проблему, созданную другой библиотекой».
Ещё вчера, все бежали в сторону (X)(HT)ML и ставили минусы всем, кто не закрывал теги. Сейчас же ставят минусы за использование XML в апи, вместо трендового JSON. Промисы тоже скоро выйдут из моды благодаря генераторам и тому подобным реализациям кооперативной многозадачности. Но для длительных операций использование промисов, генераторов и прочих «ждём до завершения» штук — плохое решение, так как исключает возможность следить за прогрессом выполнения задачи. Именно поэтому при грамотной архитектуре fetch должен возвращать не объект Promise, а объект XMLHttpRequest, который уже может реализовывать thenable интерфейс для частного случая «ждём до завершения».
По большому счёту я с вами согласен. Что косвенно доказывает и собираемые нами минусы. Ну что ж, пусть я и буду выглядит как аутсайдер, но не устану повторять: каждой задаче своё решение. И если задача подразумевает синхронное решение, то такая возможность должна присутствовать в API.
для синхронных запросов есть XMLHttpRequest если нужно используйте, смысла тащить это в новое api нет
Вы же понимаете, что до появления многоядерности — не было вообще реально параллельных задач? А значит любую задачу можно назвать синхронной. Однако всех устраивает, что операционные системы дают возможность создания процессов, потоков. Языки и виртуальные машины — абстрагирование через события и т.д.
И пока вы не аргументировали, с чего это запрос к внешнему серверу (по сути неконтролируемая нашей системой операция) должен быть синхронным, кроме мнимого удобства программирования (хотя это неправда, ведь любое изменение логики повлечет за собой необходимость менять весь ваш загрузчик).
И пока вы не аргументировали, с чего это запрос к внешнему серверу (по сути неконтролируемая нашей системой операция) должен быть синхронным, кроме мнимого удобства программирования (хотя это неправда, ведь любое изменение логики повлечет за собой необходимость менять весь ваш загрузчик).
А как по-другому гарантировать, что ни одна строчка кода, ни в одном из последующих файлов не выполняться, пока не придёт ответ на первичный запрос к серверу? Если вы поведаете более простое и железо-бетонное решение этой задачи, буду признателен.
В JS нет понятия «последующие файлы». Я вообще с трудом понимаю о чем речь, если о теге script в html (который к файлам отношения никакого не имеет), то советую просто и железно-бетонно ознакомиться с модулями.
Асинхронность никак не связана с потерей последовательности выполнения — это решается на уровне логики вашего приложения в любом языке.
Асинхронность никак не связана с потерей последовательности выполнения — это решается на уровне логики вашего приложения в любом языке.
>> Ещё пример: нужно последовательно выполнить несколько запросов к серверу. Разве это не кейс для использования синхронных запросов?
Это как раз кейс для промисов — строите из них нужную цепочку, вот вам и последовательность.
Это как раз кейс для промисов — строите из них нужную цепочку, вот вам и последовательность.
Промисы тут тоже подойдут, но не понимаю почему все отвергают синхронное решение синхронной задачи? Вы можете пояснить почему синхронные запросы здесь будут хуже чем асинхронные с промисами?
Основная причина — синхронные запросы, если их сделать, будут использоваться не только в таких случаях, но и в других, где на самом деле нужна асинхронность, просто потому, что их проще использовать (а быдлокодеров, которые кодят по шаблонам по принципу «что короче и понятнее», куда больше, чем тех, кто будет разбираться).
А в GUI-приложении, таких случаев на самом деле куда больше, чем тех, где синхронность пойдет. Поэтому, если оставшиеся в меньшинстве случаи можно адекватно покрыть асинхронностью, даже за счет небольшого усложнения кода, то лучше оставить только асинхронные API.
Ну и в вашем конкретном примере, все же может потребоваться выполнять какой-то JS, когда остальное грузится. Анимированный индикатор прогресса, положим, вы сделаете на CSS, а вот какие-нибудь хитрые таймауты — уже нет.
А в GUI-приложении, таких случаев на самом деле куда больше, чем тех, где синхронность пойдет. Поэтому, если оставшиеся в меньшинстве случаи можно адекватно покрыть асинхронностью, даже за счет небольшого усложнения кода, то лучше оставить только асинхронные API.
Ну и в вашем конкретном примере, все же может потребоваться выполнять какой-то JS, когда остальное грузится. Анимированный индикатор прогресса, положим, вы сделаете на CSS, а вот какие-нибудь хитрые таймауты — уже нет.
Анимированный индикатор прогресса, положим, вы сделаете на CSS, а вот какие-нибудь хитрые таймауты — уже нет.
Да и с CSS нет никаких гарантий, что страница тупо не будет «висеть».
Это уже от реализации JS в браузере зависит, нет? В принципе нет никаких причин, по которым JS должен крутиться на том же потоке, что и рендеринг, и обработка ввода.
Это уже от реализации JS в браузере зависит, нет? В принципе нет никаких причин, по которым JS должен крутиться на том же потоке, что и рендеринг, и обработка ввода.
Да 100%, я к тому, что слишком много нюансов ради непонятного использования синхронного запроса.
Покажите-ка мне пожалуйста браузер, в котором JS крутится в «отдельном» потоке от GUI? (Разумеется, не берем в рассчёт веб-воркеры)
12 опера, в некотором роде, так и делает. GIF анимации продолжают работать, страница скролится. Проверил только что. В остальном поведение то же, что и в других браузерах: текст не выделяется и пр.
А каким образом это соотносится? Для меня отображение GIF и скролл страницы не определяет то, что JS работает в отдельном треде.
Ну Chromium и этого не предоставляет :) Loading-анимации зависают, и, тем самым, перестают выполнять свою задачу.
Вот именно эту проблему и стоит решать в первую очередь, а не реализовывать новый апи, с менее богатым функционалом.
Да и эту проблему, если честно, решать тоже не обязательно, а уж тем более в первую очередь. Лучше заняться ES7, с его await, чтобы писать асинхронный код можно было без боли :D (пока что на это претендуют только всякие извращения с генераторами, которые вообще, как мне кажется, не для этого были созданы).
Мне кажется, что ваши опасения это все же перестраховки. Мне не доводилось отмечать рьяное использование синхронных запросов в XMLHttpRequest, да и навряд ли «быдлокодеры» настолько подробно будут изучать документацию, чтобы обратить внимание на какой-нибудь небольшой флажок, позволяющий включить синхронность.
GUI или нет, у меня логика простая — есть задачи асинхронные и асинхронные с признаками синхронности (тут промисы и все такое), а есть чисто синхронные. И если честно, не понимаю зачем исключать эту возможность совсем.
p/s Глянул в код нашего приложения, чтобы освежить в памяти и представил эту его часть на промисах. Ох, как бы там все криво стало из-за этого. Да и цепочку не всегда удается сделать, потому что код, который должен выполняться синхронно, часто в разных классах и даже файлах лежит. Рефакторинг всего этого добра в цепочку промисов обойдется очень дорого при непонятном профите.
GUI или нет, у меня логика простая — есть задачи асинхронные и асинхронные с признаками синхронности (тут промисы и все такое), а есть чисто синхронные. И если честно, не понимаю зачем исключать эту возможность совсем.
p/s Глянул в код нашего приложения, чтобы освежить в памяти и представил эту его часть на промисах. Ох, как бы там все криво стало из-за этого. Да и цепочку не всегда удается сделать, потому что код, который должен выполняться синхронно, часто в разных классах и даже файлах лежит. Рефакторинг всего этого добра в цепочку промисов обойдется очень дорого при непонятном профите.
Я не веб-программист, поэтому мне тяжело сказать конкретно насчет XMLHttpRequest. Но в гуевых приложениях чрезмерное использование синхронных API и игнор асинхронных исторически являются огромной проблемой, из-за которой вы видите пресловутый «бублик» ожидания куда чаще, чем надо. В WinRT, кстати, именно из-за этого практически все API сделали асинхронными без синхронных вариантов, по принципу «не умеешь — научим, не хочешь — заставим».
Асинхронность сама по себе ортогональна последовательному выполнению, кстати. В этом смысле промисы не «сихрноннее» обычных коллбэков. Просто с ними проще делать композицию — не обязательно последовательную.
Насчет кривости кода — это во многом фактор языка. В C# писать асинхронный код стало буквально в разы проще с появлением async/await, который позволяет размотать лапшу из continuation-лямбд в нормальный код, который выглядит абсолютно как синхронный, за исключением этого самого await в точках передачи управления. В ES6 подобное тоже планируется.
Асинхронность сама по себе ортогональна последовательному выполнению, кстати. В этом смысле промисы не «сихрноннее» обычных коллбэков. Просто с ними проще делать композицию — не обязательно последовательную.
Насчет кривости кода — это во многом фактор языка. В C# писать асинхронный код стало буквально в разы проще с появлением async/await, который позволяет размотать лапшу из continuation-лямбд в нормальный код, который выглядит абсолютно как синхронный, за исключением этого самого await в точках передачи управления. В ES6 подобное тоже планируется.
А мне вот доводилось видеть $.ajaxSetup({async:false}) в коде нашего приложения. На вопрос, что это, веб-программист ответил, что «иначе ничего не работает».
Ну и что? Я раньше на полюсах писал и столько мне доводилось видеть говно-кода связанного с тамошними темплейтами и уж там все это кривой было сделано.
Однако, не смотря на то, что я считаю, что темплейты в си++ могли бы быть реализованы более внятным образом и что на действительно красиво их «варить» умеют далеко не все. Но я никогда и думать не думал, что надо их выпилить из языка, только потому что их неправильно используют.
Вам не кажется, что это уж слишком радикально? С синхронными запросами также история.
Однако, не смотря на то, что я считаю, что темплейты в си++ могли бы быть реализованы более внятным образом и что на действительно красиво их «варить» умеют далеко не все. Но я никогда и думать не думал, что надо их выпилить из языка, только потому что их неправильно используют.
Вам не кажется, что это уж слишком радикально? С синхронными запросами также история.
У нас тоже есть веб-приложение, которое должно получить конфиг и подгрузить данные в самом начале. У нас показывается текст, типа «Refreshing data, please wait...». Как только подгрузили, показываем основной интерфейс. Зачем тут синхронный запрос я не оч понимаю. Да и грузится все не одним запросом, а где-то 5 (разные ресурсы), т.ч. еще и быстрее получается за счет параллельности.
Я полностью согласен с mayorovp и int19h, но позвольте мне спросить: в чём проблема инкапсулировать данные в страницу, которую вы отдаете с сервера? Так или иначе вы отдаете хотя бы index-файл с базовой разметкой с сервера, так пусть он сразу содержит данные, которые вам будут нужны при инициализации, не?
html можно намертво зекешировать, чтобы отдавался мгновенно.
Кстати, а ведь все данные, нужные при сразу после загрузки, можно загружать через статический же тег script…
Конечно, но это костыль.
пользователь может открывать ваш сайт несколько раз, то есть открыв его второй третий и т.п. раз от опять будет скачивать 1мб шаблонов, в общем кроме крутящегося кружочка для интернет приложений лучше в таком случае ничего не отдавать в «index.html»
Кстати fetch api презентовано внутри Service Worker которые как раз для сложных случаев кастомного кеширования.
Кстати fetch api презентовано внутри Service Worker которые как раз для сложных случаев кастомного кеширования.
Вы так говорите, как будто закешировать страницу с данными невозможно :)
Данные имеют свойство меняться.
Ну тогда инвалидируйте кеш, в чём проблема?
Расскажите как вы будете инвалидировать этот кэш без запроса к серверу
При следующем запросе данной страницы с сервера я обязательно проверю кеш, а скорее всего, сделаю это воркером, который будет работать на сервере. Но мне кажется я понял, что вы имеете ввиду: если я перейду на др. страницу внутри SPA и вернусь обратно — данные не изменятся. Но тут зависит исключительно от вашей реализации. Хотите — не изменятся, хотите — изменятся, предзагрузка данных не влияет на логику приложения.
Как вы «проверите кеш» или «запустите воркер», если страница ещё не загружена? А если уже загружена, то она уже взята из кэша с возможно устаревшими данными.
Вы правда не знаете, как работают заголовки HTTP, управляющие кешированием?
Когда нужно реализовать SCORM API. Оно синхронное по спеке. Выбора нет.
я делал синхронные запросы для старых браузеров в unload, чтобы они таки доходили до сервера, так что ситуация не очень мифическая.
возможно человек ноду использует, хотя там были либы чтобы делать такие локи для асинхронных штук
возможно человек ноду использует, хотя там были либы чтобы делать такие локи для асинхронных штук
Ели вам нужно было отправить на сервер какую-то статистику перед тем как пользователь покинет страницу, то можно подписаться на события load и error у вновь созданного изображения. И не забыть про таймаут.
На мой взяглд, несколько странный подход. А если данных будет оч. много, вы заставите пользователя ждать? Я пробыл на сайте 1 час и уходя у меня накопился 1Мб данных, которые надо отправить на сервер. Предположим, я нахожусь на даче и использую 3G телефона, который берёт «на добром слове». Вы заблокируете мне весь браузер, пока я не передам 1Мб по 3G? Вы маньяк!
Разнообразные «тепловые карты», отслеживающие посетителя на сайте и т.п. посылают данные отнюдь не в момент закрытия вкладки.
Разнообразные «тепловые карты», отслеживающие посетителя на сайте и т.п. посылают данные отнюдь не в момент закрытия вкладки.
Т.к. я сам отправляю запрос то я знаю сколько данных я отправляю — и да вы ошиблись где-то на 3-6 порядков с 1мб и 10мб соответственно. Да и что можно отправлять в качестве статистики на 1мб я даже представить не могу.
У XmlHttpRequest есть замечательное свойство timeout которое можно поставить в 250мс например и пользователь этого не заметит, даже если запрос отвалится по таймауту (штатное время ответа до 1мс, остальное только сетевые задержки)
У XmlHttpRequest есть замечательное свойство timeout которое можно поставить в 250мс например и пользователь этого не заметит, даже если запрос отвалится по таймауту (штатное время ответа до 1мс, остальное только сетевые задержки)
ну и на всякий случай — где возможно у меня используется developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon
с выходом 39 версии хрома это поддерживают уже больше 70% настольных браузеров
с выходом 39 версии хрома это поддерживают уже больше 70% настольных браузеров
Разумеется, я взял цифру с количеством статистики с потолка, тут извините (т.к. никогда не занимался разработкой софта с подобной функциональностью). Но как вы верно подметили, бóльшую часть времени занимает транспортировка пакетов и обработка данных, поэтому невозможно прогнозировать, с какой скоростью вернётся ответ. Если вы ожидаете этого ответа перед закрытием, то вы «задерживаете» пользователя на непрогнозируемый период времени.
Элементарный пример — посыл запроса перед закрытием окна браузера по событию beforeunload.
Т.е. бизнес-логика такая
«Подвесить пользователю браузер с целью (?) сохранения каких-то данных безо всяких гарантий их сохранения (процесс можно убить, выключить компьютер и т.д.»
И в чем же сакральный смысл сего действия?
«Подвесить пользователю браузер с целью (?) сохранения каких-то данных безо всяких гарантий их сохранения (процесс можно убить, выключить компьютер и т.д.»
И в чем же сакральный смысл сего действия?
У меня был проект, где перед закрытием окна надо было освободить подписку на серверные события, потому что там был лимит на 30 штук. И если этого не делать — то они быстро кончались. Если процесс умер — бог с ним, но по возможности — почему бы не прибрать за собой?
А чтоб долго не ждать можно таймаут поставить, мне же по большому счету все равно, каков результат, мне надо сервер пнуть, чтоб тот подписку освободил, а для этого достаточно, чтоб запрос на него просто попал и будь что будет.
В таком случае вы можете «пнуть» сервер асинхронным запросом.
P.S. Что значит «освободить подписку на серверные события»?
P.S. Что значит «освободить подписку на серверные события»?
Асинхронный запрос в таком случае убивается моментально, до сервера не доходит. Освободить подписку значит сказать серверу, чтобы тот перестал пушить события по данной подписке.
Т.е. бизнес-процесс такой (если я правильно поняла):
На сервере есть некий сервис, который для каждой открытой страницы куда-то (в память?) постоянно сохраняет какие-то новые данные. И они постоянно копятся с единственной возможностью на освобождение ресурсов — повесив пользователю браузер? А если он убьет процесс, то, видимо, вовсе до перезагрузки сервера?
На сервере есть некий сервис, который для каждой открытой страницы куда-то (в память?) постоянно сохраняет какие-то новые данные. И они постоянно копятся с единственной возможностью на освобождение ресурсов — повесив пользователю браузер? А если он убьет процесс, то, видимо, вовсе до перезагрузки сервера?
Есть сервер, на нем происходят некие события (упрощенно — меняется онлайн статус людей, им присылают сообщения, их сообщения меняют статус и т.д.), сервер по запросу клиента создает трекинг этих событий и отправляет клиенту пуш-нотификации. Если клиент допустим 5 минут не присылал хартбиты, то подписка удаляется, но также есть возможность удалить ее принудительно, если клиент считает, что в ней нет надобности. Это сугубо опциональная процедура, однако, если клиент начинает держать слишком много подписок — сервер это пресечет. Поэтому в интересах клиента ее уничтожить, если клиент 100% знает, что подписка более не нужна.
«Повесив пользователю браузер» — 200мс при закрытии страницы никто никогда не заметит. Если дольше — то случится таймаут и страница все равно закроется.
Какие далеко идущие выводы — до перезагрузки сервера… Смешно )
«Повесив пользователю браузер» — 200мс при закрытии страницы никто никогда не заметит. Если дольше — то случится таймаут и страница все равно закроется.
Какие далеко идущие выводы — до перезагрузки сервера… Смешно )
Если клиент допустим 5 минут не присылал хартбиты, то подписка удаляется, но также есть возможность удалить ее принудительно, если клиент считает, что в ней нет надобности.
Это сугубо опциональная процедура, однако, если клиент начинает держать слишком много подписок — сервер это пресечет.
Так в чем смысл этой «отписки»? В том, что сервер не может обеспечить хранение всех подписок по заявленному алгоритму (в течении 5 минут)? Бесполезная трата ресурсов (и клиента, и сервера) на ручную отписку (раз автоматическая все равно будет происходить)?
Ключевой момент — отсутствие гарантий, а значит бессмысленность.
Какие далеко идущие выводы — до перезагрузки сервера… Смешно )
Это была экстраполяция из ваших аргументов. Видите — вам тоже смешно)
Сервер все может ;) но лимит есть лимит. У вас есть другие варианты, как обходить ограничение в 30 подписок, если не убивать их при закрытии окон? Поделитесь :) мультиплексирование всех событий через одну подписку в одной вкладке и распространение этого в другие вкладки не предлагать, уже проходили. Каждая вкладка должна иметь свой личный канал для нотификаций.
Т.е. если я открою 30 вкладок, потом убью процесс (завис компьютер). Через минуту открою его, то ваше приложение тупо не будет работать?
Делюсь. Не делать подписку на вкладки, делать на реальные объекты: пользователя, страницу (ту, которая по URL), модули. Например, подписка для пользователя на этот блок сообщений. Тогда серверу не нужно готовить одно и то же бесконечное (в теории) число раз.
Однако, вы не пояснили в чем логика этого лимита (в 30), возможно, это ограничение заложено в бизнес-процессе? Или это просто этакое желание сэкономить программистов за счет потери клиентов?
Поделитесь :)
Делюсь. Не делать подписку на вкладки, делать на реальные объекты: пользователя, страницу (ту, которая по URL), модули. Например, подписка для пользователя на этот блок сообщений. Тогда серверу не нужно готовить одно и то же бесконечное (в теории) число раз.
Однако, вы не пояснили в чем логика этого лимита (в 30), возможно, это ограничение заложено в бизнес-процессе? Или это просто этакое желание сэкономить программистов за счет потери клиентов?
Лимит не я контролирую, это данность и она не изменится. Понятия не имею, в чем логика.
«делать на реальные объекты: пользователя, страницу (ту, которая по URL), модули» — это общие слова, напрочь лишенные смысла. На какие, по-вашему, объекты распространяется подписка, о которой говорю я?
Сервер и так не готовит ничего бесконечное кол-во раз. Нотификации рассылаются отдельной подсистемой, которая при приходе события поднимает живые подписки и в них пишет данные. В одной подписке может быть несколько совершенно разных событий задействовано и каждая вкладка подписывается только на нужные ей лично.
Про Ваш юз-кейс — вы часто открывали 30 окон одного сайта? И нет, ничего не сломается, подписки будут убиваться в неактивных вкладках и создаваться в активных.
У Вас есть опыт создания подобных приложений? Игр, чатов, мессенджеров? Серверных частей для этого? Или Вы просто умозрительно рассказываете?
«делать на реальные объекты: пользователя, страницу (ту, которая по URL), модули» — это общие слова, напрочь лишенные смысла. На какие, по-вашему, объекты распространяется подписка, о которой говорю я?
Сервер и так не готовит ничего бесконечное кол-во раз. Нотификации рассылаются отдельной подсистемой, которая при приходе события поднимает живые подписки и в них пишет данные. В одной подписке может быть несколько совершенно разных событий задействовано и каждая вкладка подписывается только на нужные ей лично.
Про Ваш юз-кейс — вы часто открывали 30 окон одного сайта? И нет, ничего не сломается, подписки будут убиваться в неактивных вкладках и создаваться в активных.
У Вас есть опыт создания подобных приложений? Игр, чатов, мессенджеров? Серверных частей для этого? Или Вы просто умозрительно рассказываете?
На какие, по-вашему, объекты распространяется подписка, о которой говорю я?
Вы говорите «на вкладки», у каждой вкладки своя персональная подписка на сервере.
Лимит не я контролирую, это данность и она не изменится. Понятия не имею, в чем логика.
Впрочем, если вы не контролируете сервер, то о чем вообще говорить) Я рассуждала с точки зрения нормальной системы, а не когда одна часть — темная кривая лошадка, а другой приходится приспосабливаться при помощи костылей. Однако вопрос про 30 вкладок (или любой другой случай закрытия вкладки без beforeunload), так и остался без ответа.
Про Ваш юз-кейс — вы часто открывали 30 окон одного сайта?
Каждый день, и не 1 сайт, тот же хабр более чем часто. Вконтакте, новостные сайты, почту, да можно сказать большинство часто используемых.
И нет, ничего не сломается, подписки будут убиваться в неактивных вкладках и создаваться в активных.
Через 5 минут?
У Вас есть опыт создания подобных приложений? Игр, чатов, мессенджеров? Серверных частей для этого? Или Вы просто умозрительно рассказываете?
Когда кончаются аргументы?
если вы не контролируете сервер, то о чем вообще говорить
Вот именно.
Вот именно.
Просто признайте: либо проблема неработающих вкладок и «небольших» (на самом деле очень даже больших) 200мс существует, либо никакие «отписки» делать не нужно.
*рука-лицо* что признавать то?
Код на продакшене уже год как работает, в самом начале была проблема с подписками, и эту проблему решили (выше написано как), проблема ушла, саппорт это подтверждает. Клиенты довольны, деньги идут, никто не жалуется.
Код на продакшене уже год как работает, в самом начале была проблема с подписками, и эту проблему решили (выше написано как), проблема ушла, саппорт это подтверждает. Клиенты довольны, деньги идут, никто не жалуется.
То, что конкретно данный костыль никак не относится к теме синхронных запросов, и тем более, к их необходимости в браузерах.
А в вашем случае, можете отнести наличие beforeunload и возможность выполнения в них синхронных запросов к удаче, не факт, что завтра браузеры такую возможность не уберут (как убрали все, что мешает или опасно пользователю).
А в вашем случае, можете отнести наличие beforeunload и возможность выполнения в них синхронных запросов к удаче, не факт, что завтра браузеры такую возможность не уберут (как убрали все, что мешает или опасно пользователю).
Если бы вы хоть немного знали предмет, о котором вы рассуждаете, вы бы знали, что внутри обработчика beforeunload можно выполнить некие действия, чтоб воспрепятствовать уходу пользователя со страницы (например, при наличии несохраненных данных). Действия, выполняемые в рамках обработчика *обязаны* быть синхронными, иначе он отработает и страница благополучно будет выгружена, а все незакрытые соединения принудительно разорваны.
А главное — оно так уже лет 10 работает и вряд ли когда-то поменяется.
Вы это, socket.io не пробовали?
Не проще ли использовать веб-сокеты? По-идее, браузер сам закроет соединения, которые более недоступны.
Безусловно проще. Но их поддержки у сервера нет. И сделать с этим я ничего не могу.
Есть такой сервис pubnub.com, так вот у них все реализовано через лонг-поллинг, они даже веб-сокетную эмуляцию через это написали. Их аргумент следующий, якобы «Protocols, like WebSockets, can get tripped up by cell tower switching, double NAT environments, and even some anti-virus software or proxy boarder authorities.» (источник stackoverflow.com/a/26306148). Это просто к слову.
Неправда. Синхронный запрос нужен, чтобы «вешать» пользовательский интерфейс.
Возможно, мой пример, будет некорректным, и я был бы рад, если бы вы подсказали, как того же самого можно добиться, без синхронного запроса, но на момент реализации, я ответа не нашёл :( Итак:
Суть в том, что если в п.2 сделать асинхронный запрос, то выполнить п.3 будет уже нельзя. Браузер не позволит. А если залочить страницу на всё время п.2, то контекст обработки клика мышью по кнопке сохранится и никаких проблем с безопасностью не возникнет. А пользователю удобно, ровно 1 клик и никакой суеты. Однако, возможна ситуация, когда ответ с сервера затянется или вовсе не придёт. И тогда вкладка по сути заблокируется. Поэтому мне сильно не нравится это решение.
Был бы рад услышать, как этого можно избежать (без превентивного оформления заказа на всякий случай и без доп. сложностей для пользователя).
- Пользователь в форме оплаты кликает на кнопку «оплатить»
- Выполняется синхронный запрос к магазину, который регистрирует заказ и формирует все необходимые данные для перехода к платёжному шлюзу
- Браузер выполняет submit POST-формы к платёжному шлюзу, со всеми необходимыми данными
- Пользователь попадает на страницу платёжного шлюза и оплачивает заказ
Суть в том, что если в п.2 сделать асинхронный запрос, то выполнить п.3 будет уже нельзя. Браузер не позволит. А если залочить страницу на всё время п.2, то контекст обработки клика мышью по кнопке сохранится и никаких проблем с безопасностью не возникнет. А пользователю удобно, ровно 1 клик и никакой суеты. Однако, возможна ситуация, когда ответ с сервера затянется или вовсе не придёт. И тогда вкладка по сути заблокируется. Поэтому мне сильно не нравится это решение.
Был бы рад услышать, как этого можно избежать (без превентивного оформления заказа на всякий случай и без доп. сложностей для пользователя).
Поддерживаю, была ситуация, когда нужно было открытие попапа по клику с подтверждением на сервере. Работало только синхронным запросом, увы.
Вы чего-то не договариваете. Первый раз слышу, чтобы браузер запрещал отправку post формы.
По всей видимости у вас проблема в открытии нового окна через window.open или target="_blank".
Но в этом случае ничто не мешает открыть его сразу же, и потом уже отправлять аяксы, показав при этом юзеру удобный прелоадер в попапе.
По всей видимости у вас проблема в открытии нового окна через window.open или target="_blank".
Но в этом случае ничто не мешает открыть его сразу же, и потом уже отправлять аяксы, показав при этом юзеру удобный прелоадер в попапе.
Похоже, что вы правы. Я попробовал сейчас повторить описанное, и POST запрос в этом же окне без проблем выполнился. И да, действительно, я упустил тот момент (попросту забыл, давно было), что задача была не закрывать вкладку с корзиной, т.е. открыв платёжный шлюз в новой вкладке. Для этого я как раз использовал "_blank". И где-то там у меня и возникли проблемы.
По поводу открытия вкладки сразу, ещё до регистрации заказа, — хорошая идея. Должна сработать. Спасибо. Учту (теперь уже на будущее). Кажется, я что-то подобное пытался провернуть, но у меня не получилось. А в чём была загвоздка уже не помню :( Но скорее всего должно сработать без нареканий. Ведь достаточно того, что браузер позволяет сделать POST-«переход» без каких-либо ограничений.
По поводу открытия вкладки сразу, ещё до регистрации заказа, — хорошая идея. Должна сработать. Спасибо. Учту (теперь уже на будущее). Кажется, я что-то подобное пытался провернуть, но у меня не получилось. А в чём была загвоздка уже не помню :( Но скорее всего должно сработать без нареканий. Ведь достаточно того, что браузер позволяет сделать POST-«переход» без каких-либо ограничений.
Тесты гораздо удобней писать в синхронном стиле, чем в асинхронном.
Динамическая каскадная подгрузка зависимостей во время разработки.
Динамическая каскадная подгрузка зависимостей во время разработки.
Хорошие вопросы! Увы, автор оригинального поста не затрагивает их. Но, немного порывшись в спеках, можно без труда на них ответить:
— Могу ли я отправить/получить файл?
Да, без проблем
— Могу ли я следить за прогрессом выполнения запроса?
Проще говоря, нет. Будет только состояние Promise'a, при выполнении которого (Promise'а) у вас будет Stream-объект с финальным статусом. Соответственно, на данный момент так же невозможно отследить % загрузки файла.
— Могу ли я сделать синхронный запрос?
Нет, и не факт, что это может быть доступно в дальнейшем. Но, лично я не вижу профита в этой опции. Если в данный момент можно установить XHR флаг «выполнись синхронно», то ничего не мешает сделать это асинхронно и вызывать др. функции в цепочке Promise'ов, как это сделано в примере с цепочками Promise'ов.
— Могу ли я отправить/получить файл?
Да, без проблем
— Могу ли я следить за прогрессом выполнения запроса?
Проще говоря, нет. Будет только состояние Promise'a, при выполнении которого (Promise'а) у вас будет Stream-объект с финальным статусом. Соответственно, на данный момент так же невозможно отследить % загрузки файла.
— Могу ли я сделать синхронный запрос?
Нет, и не факт, что это может быть доступно в дальнейшем. Но, лично я не вижу профита в этой опции. Если в данный момент можно установить XHR флаг «выполнись синхронно», то ничего не мешает сделать это асинхронно и вызывать др. функции в цепочке Promise'ов, как это сделано в примере с цепочками Promise'ов.
Спасибо за перевод. То, что возвращаеться stream-объект — это круто, теперь еще один пласт API отпадает для FRP библиотек, которые поддерживают промисы.
И главный вопрос, при наличии проблем с сетью XMLHttpRequest не вызывает callback onerror, и соответственно нет возможности никак обработать ошибку, точнее на такую ошибку не вызывается вообще никакой обработчик. Что нибудь изменилось в этом плане в Fetch API?
Разве спустя определенное время, запрос не отваливается по таймауту?
отваливается, если его установить, но я не могу его установить, так как его нужно будет ставить довольно большой, и смысл в нем теряется. А если поставить маленький, то это сломает те запросы которые не могут быть выполнены быстро.
Мне нужно явно получить, что у меня есть сетевая ошибка, чтобы в таком случае можно было бы например повторить запрос, ну и как минимум собрать информацию о таких ошибках, сейчас я не могу собрать это, только по сообщениям пользователей.
Мне нужно явно получить, что у меня есть сетевая ошибка, чтобы в таком случае можно было бы например повторить запрос, ну и как минимум собрать информацию о таких ошибках, сейчас я не могу собрать это, только по сообщениям пользователей.
А default options можно ли как нибудь запомнить (например всегда передавать заголовок для аутентификации) и использовать для всех последующих запросов?
Да, в ближайшем будующем это будет возможно. Пока можно посмотреть как это будет работать на MDN
Гигантский шаг вперед конечно, но одного меня смущает название? Да в большинстве случаев метод наверняка будет использоваться для подтягивания чего-либо GET запросом, но в случае POST название «fetch()» является ложным.
Согласен, название какое-то неправильное
Не вас одного. Называли бы request, например
request — суть тоже самое, что-то запросить/получить. А универсальным должно быть что-то, означающее равноценный обмен информацией (data exchange?).
Thank you
«Скоуп» — это, надо полагать, область видимости?
Данный код из примера автора, можно упростить:
на:
function status(response) {
if (response.status >= 200 && response.status < 300) {
return Promise.resolve(response)
} else {
return Promise.reject(new Error(response.statusText))
}
}
на:
function status(response) {
// свойство ok = true, когда status в диапазоне 200-299
if (response.ok) {
// не надо лишний раз оборачивать Promise в Promise
return response;
} else {
// здесь можно просто кинуть exception
throw new Error(response.statusText);
}
}
Если Вы уберете Promises, не получится использовать цепочки вызовов, как указано в примере. Но в целом да, можно и так.
Никто убрать обещания не предлагает. Речь идет о вот этом куске кода:
То есть функция status — это один из элементов цепочки. VBauer говорит лишь о том, что внутри функции, которая передается в then, не обязательно возвращать обещание — любое «обычное» значение будет автоматически обернуто в resolve, а любое исключение будет автоматически обернуто в reject.
function status(responce) {
// ...
}
fetch('users.json')
.then(status)
//...
То есть функция status — это один из элементов цепочки. VBauer говорит лишь о том, что внутри функции, которая передается в then, не обязательно возвращать обещание — любое «обычное» значение будет автоматически обернуто в resolve, а любое исключение будет автоматически обернуто в reject.
Читаю и не понимаю в каком мире живут разработчики стандарта...
Невозможно отменить и невозможно получить прогресс — все, можно сразу закапывать, потому что в этих случаях придется использовать XHR и тогда лучше использовать только его. Едиственное достоинство это стримы, но они нужны далеко не всем.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Введение в fetch