¿Hay alguna razón para utilizar XMLHttpRequest sincrónico?

Parece que la mayoría de las personas realizan solicitudes asincrónicas con XMLHttpRequest, pero obviamente el hecho de que exista la capacidad de realizar solicitudes sincrónicas indica que podría haber una razón válida para hacerlo. Entonces, ¿cuál podría ser esa razón válida?

Creo que podrían volverse más populares a medida que avanzan los estándares HTML 5. Si una aplicación web tiene acceso a los trabajadores web, podría prever que los desarrolladores utilicen un trabajador web dedicado para realizar solicitudes sincrónicas, como dijo Jonathan, para garantizar que una solicitud suceda antes que otra. Con la situación actual de un hilo, es un diseño menos que ideal, ya que se bloquea hasta que se completa la solicitud.

Los XHR síncronos son útiles para guardar datos de usuario. Si maneja el beforeunloadevento, puede cargar datos en el servidor cuando el usuario cierra la página.

Si esto se hiciera usando la opción async, entonces la página podría cerrarse antes de que se complete la solicitud. Hacer esto sincrónicamente asegura que la solicitud se complete o falle de la manera esperada.

Actualizar:

Lo siguiente insinuó, pero no tuvo éxito en la entrega, que con la llegada de un mejor manejo de solicitudes asíncronas, realmente no hay razón para usar solicitudes síncronas, a menos que tenga la intención de bloquear intencionalmente a los usuarios para que no hagan nada hasta que se complete una solicitud, suena malicioso: )

Aunque esto puede sonar mal, puede haber ocasiones en las que sea importante que se produzca una solicitud (o una serie de solicitudes) antes de que un usuario abandone una página o antes de que se realice una acción; bloquear la ejecución de otro código (p. Ej., Impedir el botón de retroceso) podría posiblemente reducir errores / mantenimiento para un sistema mal diseñado; Dicho esto, nunca lo he visto en estado salvaje y enfatizo que debe evitarse.

Las bibliotecas, como la promesa , fingen la sincronicidad encadenando procesos mediante devoluciones de llamada. Esto se adapta a la mayoría de las necesidades de desarrollo en las que se desea tener eventos ordenados y sin bloqueo que permitan a los navegadores retener la capacidad de respuesta del usuario (buena UX).

Como se indica en los documentos de Mozilla, hay casos en los que debe utilizar solicitudes sincrónicas; sin embargo, también se incluye una solución alternativa que usa baliza (no disponible en IE / Safari) para tales casos. Si bien esto es experimental, si alguna vez alcanza la aceptación de los estándares, posiblemente podría poner un clavo en el ataúd de la solicitud sincrónica.

Querrá realizar llamadas sincrónicas en cualquier tipo de procesamiento similar a una transacción, o donde sea necesario cualquier orden de operación.

Por ejemplo, supongamos que desea personalizar un evento para cerrar la sesión después de reproducir una canción. Si la operación de cierre de sesión ocurre primero, la canción nunca se reproducirá. Esto requiere sincronizar las solicitudes.

Otra razón sería cuando se trabaja con un WebService, especialmente cuando se realizan operaciones matemáticas en el servidor.

Ejemplo: el servidor tiene una variable con valor de 1.

 Step (1) Perform Update: add 1 to variable
 Step (2) Perform Update: set variable to the power of 3
 End Value: variable equals 8

Si el Paso (2) ocurre primero, entonces el valor final es 2, no 8; por lo tanto, el orden de operación importa y se necesita sincronización.

Hay muy pocas ocasiones en las que una llamada sincrónica puede justificarse en un ejemplo común del mundo real. Quizás al hacer clic en iniciar sesión y luego hacer clic en una parte del sitio que requiere que un usuario inicie sesión.

Como han dicho otros, bloqueará su navegador, así que manténgase alejado de él donde pueda.

Sin embargo, en lugar de llamadas síncronas, a menudo los usuarios desean detener un evento que se está cargando actualmente y luego realizar alguna otra operación. En cierto modo, esto es sincronización, ya que el primer evento se cierra antes de que comience el segundo. Para hacer esto, use el método abort () en el objeto de conexión xml.

Yo diría que si considera bloquear el navegador del usuario mientras la solicitud se completa aceptable, entonces asegúrese de usar una solicitud sincrónica.

Si su objetivo es la serialización de solicitudes, entonces esto se puede lograr utilizando solicitudes asíncronas, haciendo que la devolución de llamada onComplete de su solicitud anterior active la siguiente en línea.

Hay muchos casos del mundo real en los que bloquear la interfaz de usuario es exactamente el comportamiento deseado.

Tome una aplicación con varios campos y algunos campos deben ser validados por una llamada xmlhttp a un servidor remoto proporcionando como entrada el valor de este campo y otros valores de campos.

En modo síncrono, la lógica es sencilla, el bloqueo que experimenta el usuario es muy corto y no hay problema.

En modo asíncrono, el usuario puede cambiar los valores de cualquier otro campo mientras se valida el inicial. Estos cambios activarán otras llamadas xmlhttp con valores del campo inicial aún no validados. ¿Qué sucede si falla la validación inicial? Puro lío. Si el modo de sincronización queda obsoleto y prohibido, la lógica de la aplicación se convierte en una pesadilla de manejar. Básicamente, la aplicación debe ser reescrita para administrar bloqueos (por ejemplo, deshabilitar otros elementos durante los procesos de validación). La complejidad del código aumenta enormemente. No hacerlo puede provocar fallas lógicas y, en última instancia, corrupción de datos.

Básicamente, la pregunta es: ¿qué es más importante, la experiencia de IU no bloqueada o el riesgo de corrupción de datos? La respuesta debería quedar en manos del desarrollador de la aplicación, no del W3C.

Puedo ver un uso para las solicitudes XHR síncronas que se usarán cuando un recurso en una ubicación variable debe cargarse antes que otros recursos estáticos en la página que dependen del primer recurso para funcionar completamente. De hecho, estoy implementando una solicitud XHR de este tipo en un pequeño subproyecto propio, mientras que los recursos de JavaScript residen en ubicaciones variables en el servidor según un conjunto de parámetros específicos. Los recursos de JavaScript subsiguientes dependen de esos recursos variables y se DEBE garantizar que dichos archivos se carguen antes de que se carguen los otros archivos dependientes, completando así la aplicación.

La base de esa idea realmente se expande en la respuesta de Vol7ron. Los procedimientos basados ​​en transacciones son realmente el único momento en el que se deben realizar solicitudes sincrónicas. En la mayoría de los otros casos, las llamadas asíncronas son la mejor alternativa en la que, después de la llamada, el DOM se actualiza según sea necesario. En muchos casos, como los sistemas basados ​​en el usuario, puede tener ciertas funciones bloqueadas para "usuarios no autorizados" hasta que, per se, inicien sesión. Estas funciones, después de la llamada asincrónica, se desbloquean mediante un procedimiento de actualización DOM.

Finalmente, tendría que decir que estoy de acuerdo con los puntos de la mayoría de las personas al respecto: siempre que sea posible, se deben evitar las solicitudes XHR sincrónicas ya que, con la forma en que funciona, el navegador se bloquea con llamadas sincrónicas. Al implementar solicitudes sincrónicas, deben hacerse de una manera en la que el navegador normalmente estaría bloqueado, de todos modos, por ejemplo, en la sección HEAD antes de que se cargue la página.

A partir de 2015, las aplicaciones javascript de escritorio se están volviendo más populares. Por lo general, en esas aplicaciones cuando se cargan archivos locales (y cargarlos con XHR es una opción perfectamente válida), la velocidad de carga es tan rápida que no tiene sentido complicar demasiado el código con async. Por supuesto, puede haber casos en los que async sea el camino a seguir (solicitar contenido de Internet, cargar archivos realmente grandes o una gran cantidad de archivos en un solo lote), pero de lo contrario, la sincronización funciona bien (y es mucho más fácil de usar) .

jQuery usa AJAX síncrono internamente en algunas circunstancias. Al insertar HTML que contiene scripts, el navegador no los ejecutará. Los scripts deben ejecutarse manualmente. Estos scripts pueden adjuntar controladores de clic. Suponga que un usuario hace clic en un elemento antes de que se adjunte el controlador y la página no funcionaría según lo previsto. Por lo tanto, para evitar condiciones de carrera, se usaría AJAX sincrónico para recuperar esos scripts. Debido a que AJAX sincrónico bloquea efectivamente todo lo demás, puede estar seguro de que los scripts y eventos se ejecutan en el orden correcto.

Razón:

Digamos que tiene una aplicación ajax que necesita hacer media docena de http para cargar varios datos desde el servidor antes de que el usuario pueda hacer cualquier interacción.

Obviamente, desea que esto se active desde una carga.

Las llamadas sincrónicas funcionan muy bien para esto sin ninguna complejidad adicional al código. Es simple y sencillo.

Retirarse:

El único inconveniente es que su navegador se bloquea hasta que se cargan todos los datos o se agota el tiempo de espera. En cuanto a la aplicación ajax en cuestión, esto no es un gran problema porque la aplicación no sirve de nada hasta que se cargan todos los datos iniciales de todos modos.

¿Alternativa?

Sin embargo, muchos navegadores bloquean todas las ventanas / pestañas cuando el javascript está ocupado en cualquiera de ellos, lo cual es un problema estúpido de diseño del navegador, pero como resultado, el bloqueo en redes posiblemente lentas no es educado si evita que los usuarios usen otras pestañas mientras espera que se cargue la página ajax.

Sin embargo, parece que de todos modos se han eliminado o restringido los get síncronos de los navegadores recientes. No estoy seguro de si eso se debe a que alguien decidió que siempre eran malos, o si los escritores de navegadores estaban confundidos por el Borrador de trabajo de WC sobre el tema.

http://www.w3.org/TR/2012/WD-XMLHttpRequest-20120117/#the-open-method hace que parezca (consulte la sección 4.7.3) que no se le permite establecer un tiempo de espera cuando se usa el modo de bloqueo . Me parece contrario a la intuición: siempre que uno bloquea IO, es de buena educación establecer un tiempo de espera razonable, así que ¿por qué permitir el bloqueo de io pero no con un tiempo de espera especificado por el usuario?

Mi opinión es que el bloqueo de E / S tiene un papel vital en algunas situaciones, pero debe implementarse correctamente. Si bien no es aceptable que una pestaña o ventana del navegador bloquee todas las demás pestañas o ventanas, eso es un defecto de diseño del navegador. Vergüenza donde se debe la vergüenza. Pero es perfectamente aceptable en algunos casos que una pestaña o ventana individual no responda durante un par de segundos (es decir, usando el bloqueo de IO / HTTP GET) en algunas situaciones, por ejemplo, en la carga de la página, tal vez una gran cantidad de datos debe ser antes de que se pueda hacer algo de todos modos. A veces, el código de bloqueo implementado correctamente es la forma más limpia de hacerlo.

Por supuesto, la función equivalente en este caso se puede obtener usando http asincrónicos, pero ¿qué tipo de rutina tonta se requiere?

Supongo que probaría algo como esto:

Al cargar el documento, haga lo siguiente: 1: Configure 6 variables de marca global "Listo", inicializadas en 0. 2: Ejecute los 6 valores de fondo (asumiendo que el orden no importa)

Luego, las devoluciones de llamada de finalización para cada uno de los 6 get http establecerían sus respectivos indicadores "Listo". Además, cada devolución de llamada verificaría todas las demás marcas realizadas para ver si se habían completado los 6 HTTP get. La última devolución de llamada para completar, al ver que todas las demás se habían completado, llamaría a la función de inicio REAL que luego configuraría todo, ahora que todos los datos fueron recuperados.

Si el orden de búsqueda importara, o si el servidor web no pudo aceptar varias solicitudes al mismo tiempo, necesitaría algo como esto:

En onload (), se lanzaría el primer http get. En su devolución de llamada, se lanzaría el segundo. En su devolución de llamada, la tercera, y así sucesivamente, con cada devolución de llamada iniciando el siguiente HTTP GET. Cuando regresara el último, llamaría a la rutina init () real.

¿Qué sucede si realiza una llamada sincrónica en el código de producción?

El cielo se cae.

No, en serio, al usuario no le gusta un navegador bloqueado.

Lo uso para validar un nombre de usuario, durante la verificación de que el nombre de usuario no existe todavía.

Sé que sería mejor hacerlo de forma asincrónica, pero luego debería usar un código diferente para esta regla de validación en particular. Te lo explico mejor. Mi configuración de validación usa algunas funciones de validación, que devuelven verdadero o falso, dependiendo de si los datos son válidos.

Dado que la función tiene que regresar, no puedo usar técnicas asincrónicas, así que simplemente lo hago sincrónico y espero que el servidor responda lo suficientemente rápido como para no ser demasiado notorio. Si usara una devolución de llamada AJAX, entonces tendría que manejar el resto de la ejecución de manera diferente a los otros métodos de validación.

A veces tienes una acción que depende de otras. Por ejemplo, la acción B solo puede iniciarse si A finaliza. El enfoque sincrónico se usa generalmente para evitar condiciones de carrera . A veces, usar una llamada síncrona es una implementación más simple que luego crear una lógica compleja para verificar cada estado de sus llamadas asíncronas que dependen unas de otras.

El problema con este enfoque es que "bloquea" el navegador del usuario hasta que finaliza la acción (hasta que la solicitud regresa, finaliza, carga, etc.). Así que tenga cuidado al usarlo.

Utilizo llamadas síncronas cuando desarrollo código; lo que sea que hiciste mientras la solicitud se desplazaba hacia y desde el servidor puede ocultar la causa de un error.

Cuando está funcionando, lo hago asincrónico, pero trato de incluir un temporizador de aborto y devoluciones de llamada de falla, porque nunca se sabe ...

SYNC vs ASYNC: ¿Cuál es la diferencia?

Básicamente se reduce a esto:

console.info('Hello, World!');
doSomething(function handleResult(result) {
    console.info('Got result!');
});
console.info('Goodbye cruel world!');

Cuando doSomethinges sincrónico, esto se imprimiría:

Hello, World!
Got result!
Goodbye cruel world!

Por el contrario, si doSomethinges asíncrono , se imprimiría:

Hello, World!
Goodbye cruel world!
Got result!

Debido a que la función doSomethingestá haciendo su trabajo de forma asincrónica, regresa antes de que termine su trabajo. Entonces solo obtenemos el resultado después de imprimirGoodbye cruel world!

Si dependemos del resultado de una llamada asíncrona, debemos colocar el código dependiente en la devolución de llamada:

console.info('Hello, World!');
doSomething(function handleResult(result) {
    console.info('Got result!');
    if (result === 'good') {
        console.info('I feel great!');
    }
    else {
        console.info('Goodbye cruel world!');
    }
});

Como tal, el solo hecho de que deban suceder 2 o tres cosas en orden no es motivo para hacerlo sincrónicamente (aunque el código de sincronización es más fácil de trabajar para la mayoría de las personas).

¿POR QUÉ USAR XMLHTTPREQUEST SINCRÓNICO?

Hay algunas situaciones en las que necesita el resultado antes de que se complete la función llamada. Considere este escenario:

function lives(name) {
    return (name !== 'Elvis');
}
console.info('Elvis ' + (lives('Elvis') ? 'lives!' : 'has left the building...');

Supongamos que no tenemos control sobre el código de llamada (la console.infolínea) y necesitamos cambiar la función livespara preguntar al servidor ... No hay forma de que podamos hacer una solicitud asíncrona al servidor desde dentro livesy aún tener nuestra respuesta antes de que se livescomplete. Entonces no sabríamos si regresar trueo false. La única forma de obtener el resultado antes de que se complete la función es mediante una solicitud sincrónica.

Como se Sami Samhurimenciona en su respuesta, un escenario muy real en el que puede necesitar una respuesta a la solicitud de su servidor antes de que finalice su función es el onbeforeunloadevento, ya que es la última función de su aplicación que se ejecutará antes de que se cierre la ventana.

NO NECESITO LLAMADAS SINCRONIZADAS, PERO LAS UTILIZO DE CUALQUIER MANERA PORQUE SON MÁS FÁCILES

Por favor no lo hagas. Las llamadas sincrónicas bloquean su navegador y hacen que la aplicación no responda. Pero tienes razón. El código asincrónico es más difícil. Sin embargo, hay una manera de hacer que lidiar con esto sea mucho más fácil. No es tan fácil como sincronizar el código, pero se está acercando: Promise s.

A continuación, se muestra un ejemplo: dos llamadas asincrónicas deben completarse con éxito antes de que se ejecute un tercer segmento de código:

var carRented = rentCar().then(function(car){
  gasStation.refuel(car);
});

var hotelBooked = bookHotel().then(function(reservation) {
  reservation.confirm();
});

Promise.all([carRented, hotelBooked]).then(function(){
  // At this point our car is rented and our hotel booked.
  goOnHoliday();
});

Así es como lo implementaría bookHotel:

function bookHotel() {
  return new Promise(function(resolve, reject){
    if (roomsAvailable()) {
      var reservation = reserveRoom();
      resolve(reservation);
    }
    else {
      reject(new Error('Could not book a reservation. No rooms available.'));
    }
  });
}

Consulte también: Escriba mejor JavaScript con promesas .

XMLHttpRequestse utiliza tradicionalmente para solicitudes asincrónicas. A veces (para depuración o lógica empresarial específica) le gustaría cambiar todas o varias de las llamadas asíncronas en una página para sincronizarlas.

Le gustaría hacerlo sin cambiar todo en su código JS. El indicador async / sync le brinda esa capacidad, y si está diseñado correctamente, solo necesita cambiar una línea en su código / cambiar el valor de uno vardurante el tiempo de ejecución.

Firefox (y probablemente todos los navegadores que no son IE) no es compatible con XHR timeOut asíncrono.

1. Discusión de Stackoverflow
2. Mozilla Firefox XMLHttpRequest

Los WebWorkers de HTML5 admiten tiempos de espera. Por lo tanto, es posible que desee ajustar la solicitud de sincronización XHR a WebWorker con tiempo de espera para implementar XHR de tipo asíncrono con comportamiento de tiempo de espera.

Acabo de tener una situación en la que las solicitudes asincrónicas para una lista de URL llamadas en sucesión usando forEach (y un bucle for) provocarían la cancelación de las solicitudes restantes. Cambié a síncronos y funcionan según lo previsto.

El uso de solicitudes HTTP sincrónicas es una práctica común en el negocio de la publicidad móvil.

Las empresas (también conocidas como "Editores") que crean aplicaciones suelen ejecutar anuncios para generar ingresos. Para ello, instalan SDK de publicidad en su aplicación. Existen muchos (MoPub, Ogury, TapJob, AppNext, Google Ads AdMob).

Estos SDK servirán anuncios en una vista web.

Cuando se sirve un anuncio a un usuario, tiene que ser una experiencia fluida , especialmente cuando se reproduce un video. No debe haber almacenamiento en búfer o carga en ningún momento.

Para solucionar esto precachingse utiliza. Donde los medios (imágenes / videos / etc.) se cargan sincrónicamente en segundo plano de la vista web.

¿Por qué no hacerlo de forma asincrónica?

1. Esto es parte de un estándar aceptado a nivel mundial
2. El SDK escucha el onloadevento para saber cuándo el anuncio está "listo" para ser servido al usuario.

Con la desaprobación de XMLHttpRequests síncronas , es muy probable que el negocio publicitario se vea obligado a cambiar el estándar en el futuro, a menos que se pueda determinar otra forma.

Synchronous XHR puede ser muy útil para el desarrollo de marcos y / o herramientas internas (que no sean de producción). Imagine, por ejemplo, que desea cargar una biblioteca de códigos sincrónicamente en el primer acceso, así:

get draw() 
{
    if (!_draw)
    {
       let file;
       switch(config.option)
       {
           case 'svg':
              file = 'svgdraw.js';
              break;
           case 'canvas':
              file = 'canvasdraw.js';
              break;
           default:
              file = 'webgldraw.js';
       }

       var request = new XMLHttpRequest();
       request.open('GET', file, false);
       request.send(null);
       _draw = eval(request.responseText);
    }

    return _draw;
}

Antes de ponerse nervioso y regurgitar ciegamente los males de eval, tenga en cuenta que esto es solo para pruebas locales. Para las compilaciones de producción, _draw ya estaría configurado.

Entonces, su código podría verse así:

foo.drawLib.draw.something(); //loaded on demand

Este es solo un ejemplo de algo que sería imposible de hacer sin sincronizar XHR. Puede cargar esta biblioteca por adelantado, sí, o hacer una promesa / devolución de llamada, pero no puede cargar la biblioteca sincrónicamente sin sincronizar XHR. Piense en cuánto podría limpiar su código este tipo de cosas ...

Los límites de lo que puede hacer con esto para herramientas y marcos (que se ejecutan localmente) solo están limitados por su imaginación. Sin embargo, parece que la imaginación es un poco limitada en el mundo de JavaScript.

Bueno, aquí hay una buena razón. Quería hacer una solicitud http y luego, según el resultado, llamar a click () en un tipo de entrada = archivo. Esto no es posible con xhr asincrónico o fetch. La devolución de llamada pierde el contexto "acción del usuario", por lo que la llamada click () se ignora. Xhr sincrónico salvó mi tocino.

onclick(event){
    //here I can, but I don't want to.
    //document.getElementById("myFileInput").click();
    fetch("Validate.aspx", { method : "POST", body: formData, credentials: "include" })
    .then((response)=>response.json())
    .then(function (validResult) {
        if (validResult.success) {
            //here, I can't.
            document.getElementById("myFileInput").click();
        }
    });
}