Там какая-либо причина состоит в том, чтобы использовать синхронный XMLHttpRequest?

Я использую синхронные вызовы при разработке кода - что бы вы ни делали во время переключения запроса на сервер и с сервера, это может заслонить причину ошибки.

Когда он работает, я делаю его асинхронным, но я пытаюсь включить таймер прерывания и обратные вызовы сбоев, потому что никогда не знаешь...

Что произойдет, если вы делаете синхронный вызов в производственном коде?

Небо падает.

Нет серьезно, пользователь не любит заблокированный браузер.

Это просто. foo (@ {$ args})

Попробуйте http://github.com/yrashk/rbmodexcl , который предоставляет метод unnestend .

Я бы сказал, что если вы рассматриваете возможность блокировки браузера пользователя во время выполнения запроса, то обязательно используйте синхронный запрос.

Если сериализация запросов является вашей целью, то это может быть выполнено с использованием асинхронных запросов, если обратный вызов onComplete предыдущего запроса инициируется следующей строкой.

XMLHttpRequest традиционно используется для асинхронных запросов. Иногда (для отладки или специфической бизнес-логики) необходимо изменить все/несколько асинхронных вызовов на одной странице для синхронизации.

Вы хотели бы сделать это, не меняя всего в своем JS-коде. Флаг async/sync дает такую возможность, и если он разработан правильно, вам нужно изменить только одну строку в коде/изменить значение одной переменной var во время выполнения.

Иногда у вас есть действие, которое зависит от других. Например, действие B может быть запущена только в том случае, если A закончен. Синхронный подход обычно используется для избежания состояний расы . Иногда используя синхронный вызов - это более простая реализация, создавая сложную логику для проверки каждого состояния ваших асинхронных вызовов, которые зависят друг над другом.

Проблема с этим подходом заключается в том, что вы «блокируете» браузер пользователя, пока действие не будет завершено (до возврата запроса, отделки, загрузки и т. Д.). Так что будьте осторожны при использовании его.

Я использую его для проверки имени пользователя, во время проверки, что имя пользователя уже не существует.

Я знаю, что было бы лучше сделать это асинхронно, но тогда я должен использовать другой код для данного конкретного правила проверки. Я лучше объясню. В моей настройке валидации используются некоторые функции валидации, которые возвращают true или false, в зависимости от того, являются ли данные валидными.

Так как функция должна возвращаться, я не могу использовать асинхронные техники, поэтому я просто делаю это синхронно и надеюсь, что сервер ответит достаточно быстро, чтобы быть не слишком заметным. Если бы я использовал обратный вызов AJAX, то мне пришлось бы обрабатывать оставшуюся часть выполнения иначе, чем другими методами валидации.

Обновление:

Приведенное ниже намекает, но безуспешно в доставке, что с появлением улучшенной обработки асинхронных запросов действительно нет причин для использования синхронных запросов, кроме случаев намерения намеренно блокировать действия пользователей до тех пор, пока запрос завершен - звучит злонамеренно :)

Хотя это может показаться плохим, могут быть случаи, когда важно, чтобы запрос (или серия запросов) выполнялся до того, как пользователь покинет страницу или до того, как будет выполнено действие - блокирование выполнения другого кода (например, предотвращение нажатия кнопки «Назад»), возможно, может уменьшить количество ошибок / обслуживания для плохо спроектированной системы; при этом, я никогда не видел его в дикой природе и подчеркиваю, что этого следует избегать.

Библиотеки, такие как Promise , симулируют синхронность, объединяя процессы в цепочку через обратные вызовы. Это соответствует большинству потребностей разработки, когда желательно иметь упорядоченные неблокирующие события, которые позволяют браузерам сохранять отзывчивость для пользователя (хороший UX).

Как указано в документации Mozilla , бывают случаи, когда вам необходимо использовать синхронные запросы; однако также указан обходной путь, использующий маяк (недоступный в IE / Safari) в таких случаях. Хотя это экспериментально, но если оно когда-либо достигнет стандарта, то, возможно, забьет гвоздь в гроб синхронных запросов.

Вы захотите выполнять синхронные вызовы при любом виде обработки, подобной транзакции, или там, где необходим любой порядок операций.

Например, предположим, вы хотите настроить событие для выхода из системы после воспроизведения песни. Если сначала произойдет выход из системы, песня никогда не будет воспроизводиться. Это требует синхронизации запросов.

Другой причиной может быть работа с WebService, особенно при выполнении математических операций на сервере.

Пример: Сервер имеет переменную со значением 1.

  Шаг (1) Выполните обновление: добавьте 1 к переменной
Шаг (2) Выполните обновление: установите переменную в степени 3
Конечное значение: переменная равна 8

Если шаг (2) выполняется первым, то конечное значение равно 2, а не 8; поэтому порядок работы имеет значение и необходима синхронизация.

В очень редких случаях синхронный вызов может быть оправдан на обычном примере из реальной жизни. Возможно, если щелкнуть логин, а затем щелкнуть часть сайта, которая требует, чтобы пользователь вошел в систему.

Как говорили другие, это будет связывать ваш браузер, поэтому держитесь подальше от него, где можете.

Однако вместо синхронных вызовов пользователи часто хотят остановить событие, которое загружается в данный момент, а затем выполнить другую операцию. В некотором смысле это синхронизация, поскольку первое событие завершается до начала второго. Для этого используйте метод abort () для объекта соединения xml.

Я вижу, как можно использовать синхронные запросы XHR, когда ресурс в переменном местоположении должен быть загружен раньше других статических ресурсов на странице, которые зависят от первого ресурса для полноценного функционирования. Фактически, я реализую такой запрос XHR в своем собственном небольшом подпроекте, тогда как ресурсы JavaScript находятся в различных местах на сервере в зависимости от набора определенных параметров. Последующие ресурсы JavaScript полагаются на эти переменные ресурсы, и такие файлы ДОЛЖНЫ быть гарантированы для загрузки до загрузки других зависимых файлов, что делает приложение единым.

Эта идея действительно расширяет ответ vol7ron. Процедуры, основанные на транзакциях, на самом деле единственное время, когда должны выполняться синхронные запросы. В большинстве других случаев лучшей альтернативой являются асинхронные вызовы, при которых после вызова DOM обновляется по мере необходимости. Во многих случаях, например, в пользовательских системах, вы можете заблокировать определенные функции для «неавторизованных пользователей» до тех пор, пока они сами по себе не вошли в систему. Эти функции после асинхронного вызова разблокируются с помощью процедуры обновления DOM.

Я должен наконец сказать, что я согласен с точками зрения большинства людей по этому поводу: по возможности следует избегать синхронных запросов XHR, поскольку из-за того, как он работает, браузер блокируется синхронными вызовами. При реализации синхронных запросов они должны выполняться таким образом, чтобы браузер обычно был заблокирован, в любом случае, скажем, в разделе HEAD до фактической загрузки страницы.