javascript - example - xmlhttprequest open
¿Hay alguna razón para usar una XMLHttpRequest sincrónica? (18)
Actualizar:
Lo siguiente insinuó, pero no fue exitoso, que con el advenimiento de un mejor manejo asincrónico de solicitudes, realmente no hay razón para usar solicitudes síncronas, a menos que intente bloquear deliberadamente a los usuarios hasta que se complete una solicitud, suena malicioso: )
Aunque puede sonar mal, puede haber ocasiones en las que es importante que una solicitud (o una serie de solicitudes) ocurra antes de que un usuario abandone la página o antes de que se realice una acción, bloqueando la ejecución de otro código (por ejemplo, impedir el botón Atrás). posiblemente reducir errores / mantenimiento para un sistema mal diseñado; Dicho esto, nunca lo he visto en la naturaleza y acentúo que debe evitarse.
Las bibliotecas, como promise , fingen la sincronicidad encadenando procesos a través de devoluciones de llamada. Esto se adapta a la mayoría de las necesidades de desarrollo donde se desea tener eventos ordenados y no bloqueantes que permitan a los navegadores mantener la capacidad de respuesta del usuario (buen UX).
Como se indica en los documentos de Mozilla, hay casos en los que debe usar solicitudes sincrónicas; sin embargo, también se incluye una solución que utiliza beacon (no disponible en IE / Safari) para tales casos. Si bien esto es experimental, si alguna vez alcanza la aceptación de estándares, posiblemente podría poner un clavo en el ataúd de solicitudes sincrónicas.
Desea realizar llamadas sincrónicas en cualquier tipo de procesamiento tipo transacción, o donde sea que sea necesario un orden de operación.
Por ejemplo, supongamos que quieres personalizar un evento para desconectarte después de reproducir una canción. Si la operación de cierre de sesión ocurre primero, entonces la canción nunca se reproducirá. Esto requiere sincronizar las solicitudes.
Otra razón sería cuando se trabaja con un servicio web, 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 8Si el paso (2) ocurre primero, entonces el valor final es 2, no 8; por lo tanto, el orden de operación importa y la sincronización es necesaria.
Hay muy pocas veces que una llamada síncrona puede justificarse en un ejemplo común en el mundo real. Quizás al hacer clic en iniciar sesión y luego al hacer clic en una parte del sitio que requiere que un usuario inicie sesión.
Como han dicho otros, atará tu navegador, así que aléjate de él donde puedas.
Sin embargo, en lugar de llamadas sincrónicas, a menudo los usuarios desean detener un evento que se está cargando actualmente y luego realizar alguna otra operación. En cierto modo, se trata de 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.
Parece que la mayoría de las personas realiza solicitudes asíncronas con XMLHttpRequest pero, obviamente, el hecho de que exista la posibilidad 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?
¿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.
A partir de 2015, las aplicaciones de escritorio de JavaScript son cada vez 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 mucho sentido complicar el código con asincrónico. Por supuesto, puede haber casos en que async es el camino a seguir (solicitando contenido de Internet, cargando archivos realmente grandes o una gran cantidad de archivos en un solo lote), pero la sincronización funciona bien (y es mucho más fácil de usar) .
A veces tienes una acción que depende de los demás. Por ejemplo, la acción B solo se puede iniciar si A termina. El enfoque sincrónico generalmente se usa para evitar condiciones de carrera . A veces, el uso de una llamada síncrona es una implementación más simple y luego crea una lógica compleja para verificar cada estado de las llamadas asincrónicas que dependen entre sí.
El problema con este enfoque es que "bloquea" el navegador del usuario hasta que la acción finalice (hasta que la solicitud regrese, finalice, cargue, etc.). Así que ten cuidado cuando lo uses.
Acabo de tener una situación en la que las solicitudes asíncronas de una lista de URL llamadas en sucesión utilizando forEach (y un bucle for) provocarían que se cancelaran las solicitudes restantes. Cambié a sincrónico y funcionan según lo previsto.
Bueno, esta es una buena razón. Quería hacer una solicitud http y, dependiendo del 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 haga clic en () se ignora. Sincrónico xhr guardó 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();
}
});
}
Creo que se volverán más populares a medida que avancen los estándares HTML 5. Si se da acceso a una aplicación web a los trabajadores de la web, podría prever que los desarrolladores que utilizan un trabajador web dedicado hagan solicitudes sincrónicas, como dijo Jonathan, para garantizar que una solicitud suceda antes que la otra. Con la situación actual de un hilo, es un diseño menos que ideal, ya que bloquea hasta que se complete la solicitud.
Diría que si considera bloquear el navegador del usuario mientras la solicitud es aceptable, entonces seguro usar una solicitud sincrónica.
Si su objetivo es la serialización de las solicitudes, esto se puede lograr utilizando solicitudes asíncronas, haciendo que la devolución de llamada onComplete de su solicitud anterior active el siguiente en línea.
Firefox (y probablemente todos los navegadores que no sean IE) no admite async XHR timeOut.
Los WebWorkers HTML5 admiten tiempos de espera. Por lo tanto, es posible que desee envolver la solicitud XHR de sincronización a WebWorker con tiempo de espera para implementar XHR asincrónico con comportamiento de tiempo de espera excedido.
Hay muchos casos del mundo real donde bloquear la IU es exactamente el comportamiento deseado.
Tome una aplicación con múltiples campos y algunos campos deben ser validados por una llamada xmlhttp a un servidor remoto que proporciona como entrada el valor de este campo y otros valores de campos.
En el modo síncrono, la lógica es simple, el bloqueo experimentado por el usuario es muy corto y no hay problema.
En el modo asíncrono, el usuario puede cambiar los valores de cualquier otro campo mientras se valida la inicial. Estos cambios desencadenarán otras llamadas xmlhttp con valores del campo inicial aún no validados. ¿Qué sucede si la validación inicial falló? Puro desastre Si el modo de sincronización queda obsoleto y prohibido, la lógica de la aplicación se convierte en una pesadilla. Básicamente, la aplicación debe volver a escribirse para administrar bloqueos (por ejemplo, desactivar otros elementos durante los procesos de validación). La complejidad del código aumenta tremendamente. De lo contrario, puede producirse una falla lógica y, en última instancia, la corrupción de datos.
Básicamente, la pregunta es: ¿qué es más importante, la experiencia de UI no bloqueada o el riesgo de corrupción de datos? La respuesta debe permanecer con el desarrollador de la aplicación, no con el W3C.
Lo uso para validar un nombre de usuario, durante la comprobación de que el nombre de usuario ya no existe.
Sé que sería mejor hacerlo asincrónicamente, pero luego debería usar un código diferente para esta regla de validación en particular. Yo 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.
Como la función tiene que regresar, no puedo usar técnicas asíncronas, por lo que la sincronizo y espero que el servidor responda lo suficientemente rápido como para no ser demasiado notorio. Si utilicé 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.
Puedo ver un uso para solicitudes de XHR síncronas que se deben usar cuando un recurso en una ubicación de variable debe cargarse antes que otros recursos estáticos en la página que dependen del primer recurso para funcionar por completo. De hecho, estoy implementando una solicitud de XHR en un pequeño subproyecto mío, mientras que los recursos de JavaScript residen en ubicaciones variables en el servidor, dependiendo de un conjunto de parámetros específicos. Los recursos posteriores de JavaScript dependen de esos recursos variables y DEBE garantizarse que dichos archivos se carguen antes de que se carguen los otros archivos dependientes, lo que hace que la aplicación sea completa.
Esa base de ideas realmente se expande en la respuesta de Vol7ron. Los procedimientos basados en transacciones son realmente el único momento en que se deben realizar solicitudes sincrónicas. En la mayoría de los demás 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 hayan iniciado sesión per se. Estas características, después de la llamada asincrónica, se desbloquean mediante un procedimiento de actualización de DOM.
Finalmente, tendré que decir que estoy de acuerdo con los puntos de la mayoría de las personas sobre el tema: 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. Cuando se implementan solicitudes sincrónicas, deben realizarse de una manera en la que normalmente el navegador esté bloqueado, de todos modos, por ejemplo, en la sección HEAD antes de que realmente se cargue la página.
Razón:
Digamos que tiene una aplicación ajax que necesita hacer media docena. Http puede cargar varios datos del servidor antes de que el usuario pueda hacer alguna interacción.
Obviamente quieres que esto se active desde la carga.
Las llamadas sincrónicas funcionan muy bien para esto sin ninguna complejidad añadida al código. Es simple y directo.
Retirarse:
El único inconveniente es que su navegador se bloquea hasta que se cargan todos los datos o se produce un tiempo de espera. En cuanto a la aplicación ajax en cuestión, esto no es un problema porque la aplicación no sirve de nada hasta que todos los datos iniciales se carguen de todos modos.
¿Alternativa?
Sin embargo, muchos navegadores bloquean todas las ventanas / pestañas cuando el javascript está ocupado en alguno de ellos, lo cual es un estúpido problema de diseño del navegador, pero como resultado el bloqueo en redes posiblemente lentas no es cortés si evita que los usuarios usen otras pestañas. mientras espera que cargue la página ajax.
Sin embargo, parece que los enlaces sincrónicos se han eliminado o restringido de los navegadores recientes de todos modos. No estoy seguro si eso se debe a que alguien decidió que siempre eran malos, o si los escritores de los navegadores estaban confundidos por el borrador de WC Working sobre el tema.
http://www.w3.org/TR/2012/WD-XMLHttpRequest-20120117/#the-open-method lo hace parecer (ver sección 4.7.3) no tiene permitido establecer un tiempo de espera cuando usa el modo de bloqueo . Me parece contra intuitivo: cuando uno bloquea a IO, es educado establecer un tiempo de espera razonable, entonces, ¿por qué permitir el bloqueo io pero no con un tiempo de espera especificado por el usuario?
Mi opinión es que el bloqueo de IO 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, esa es una falla de diseño del navegador. Es una pena que la vergüenza se debe. Pero es perfectamente aceptable en algunos casos que una pestaña o ventana individual no responda durante un par de segundos (es decir, mediante el bloqueo de IO / HTTP GET) en algunas situaciones, por ejemplo, en la carga de la página, quizás una gran cantidad de datos debe estar antes de poder hacer cualquier cosa de todos modos. A veces, el código de bloqueo implementado correctamente es la forma más limpia de hacerlo.
Por supuesto, se puede obtener una función equivalente en este caso usando http asincrónico, pero ¿qué clase de rutina tonta se requiere?
Supongo que intentaré algo en esta línea:
En la carga de documentos, haga lo siguiente: 1: Configure 6 variables de indicador "Hecho" globales, inicializadas en 0. 2: Ejecute las 6 copias de fondo (Asumiendo que el orden no importó)
Luego, las devoluciones de llamadas de finalización para cada uno de los 6 http get establecerían sus respectivas banderas de "Hecho". Además, cada devolución de llamada verificaría todas las demás banderas hechas para ver si todos los 6 HTTP obtenidos se habían completado. La última devolución de llamada para completar, al ver que todos los demás se habían completado, llamaría a la función REAL init, que luego configuraría todo, ahora que todos los datos fueron recuperados.
Si el orden de la búsqueda importó, o si el servidor web no pudo aceptar varias solicitudes al mismo tiempo, entonces necesitaría algo como esto:
En onload (), se lanzará el primer http get. En su devolución de llamada, se lanzaría el segundo. En su devolución de llamada, el tercero, y así sucesivamente, con cada devolución de llamada iniciando el siguiente HTTP GET. Cuando el último volviera, llamaría a la rutina real init ().
Utilizo llamadas sincrónicas al desarrollar código; cualquier cosa que haya hecho mientras la solicitud estaba yendo y viniendo del servidor puede oscurecer la causa de un error.
Cuando está funcionando, lo hago de forma asíncrona, pero intento incluir un temporizador aborto y devoluciones de llamada fallidas, porque nunca se sabe ...
jQuery usa AJAX síncrono internamente en algunas circunstancias. Al insertar HTML que contiene scripts, el navegador no los ejecutará. Los scripts deben ser ejecutados manualmente. Estas secuencias de comandos pueden adjuntar manejadores de clics. Supongamos que un usuario hace clic en un elemento antes de que se adjunte el controlador y la página no funcione como se esperaba. Por lo tanto, para evitar condiciones de carrera, se usará AJAX sincrónico para obtener esos scripts. Debido a que AJAX sincrónico efectivamente bloquea todo lo demás, puede estar seguro de que los scripts y eventos se ejecutan en el orden correcto.
XMLHttpRequest se usa tradicionalmente para solicitudes asincrónicas. Algunas veces (para la depuración, o lógica de negocios específica) le gustaría cambiar todas / varias de las llamadas asíncronas en una página para sincronizar.
Te gustaría hacerlo sin cambiar todo en tu código JS. El indicador async / sync le otorga esa capacidad, y si está diseñado correctamente, solo necesita cambiar una línea en su código / cambiar el valor de una var durante el tiempo de ejecución.
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 doSomething es sincrónico, esto se imprimiría:
Hello, World!
Got result!
Goodbye cruel world!
Por el contrario, si doSomething es asincrónico , esto se imprimiría:
Hello, World!
Goodbye cruel world!
Got result!
Debido a que la función que hace algo está funcionando asincrónicamente, regresa antes de que se termine el trabajo. ¡Entonces solo obtenemos el resultado después de imprimir Goodbye cruel world!
Si dependemos del resultado de una llamada asincrónica, 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 dos o tres cosas deban suceder en orden no es razón para hacerlas de forma síncrona (aunque el código de sincronización es más fácil para la mayoría de las personas).
¿POR QUÉ USAR SYNCHRONOUS XMLHTTPREQUEST?
Hay algunas situaciones en las que necesita el resultado antes de que se complete la función llamada. Considera 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 línea console.info ) y necesitamos cambiar la lives función para preguntarle al servidor ... No hay manera de que podamos hacer una solicitud asíncrona al servidor desde dentro de nuestras lives y aún tener nuestra respuesta antes de que la lives complete Entonces, no sabríamos si devolver true o false . La única forma de obtener el resultado antes de que la función finalice es haciendo una solicitud sincrónica.
Como Sami Samhuri menciona en su respuesta, un escenario muy real donde puede necesitar una respuesta a su solicitud de servidor antes de que termine su función es el evento onbeforeunload , ya que es la última función de su aplicación que se ejecutará antes de que se cierre la ventana.
NO NECESITO LLAMADAS DE SINCRONIZACIÓN, PERO LAS UTILIZO EN CUALQUIER FORMA, PORQUE SON MÁS FÁCILES
Por favor no. Las llamadas sincrónicas bloquean su navegador y hacen que la aplicación no responda. Pero tienes razón. El código asíncrono es más difícil. Sin embargo, hay una manera de hacer que lidiar con eso sea mucho más fácil. No es tan fácil como el código de sincronización, pero se está acercando: Promise s.
Aquí hay un ejemplo: dos llamadas asincrónicas deben completarse satisfactoriamente 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 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.''));
}
});
}
Ver también: Escribir mejor JavaScript con promesas .
Los XHR sincrónicos son útiles para guardar datos de usuario. Si maneja el evento beforeunload , puede cargar datos en el servidor a medida que el usuario cierra la página.
Si esto se hizo usando la opción asincrónica, la página podría cerrarse antes de que la solicitud finalice. Hacer esto sincrónicamente asegura que la solicitud se complete o falle de una manera esperada.