La opción asíncrona del método jQuery.ajax () está en desuso, ¿y ahora qué?

A partir de jQuery 1.8, el uso de async:false en jQuery.ajax () está en desuso .
¿Pero cuántas páginas web ha visto con una “pantalla de carga” mientras hay una comunicación AJAX en proceso en el fondo? Probablemente he visto miles de ellos.

Mi caso es que estoy escribiendo una aplicación móvil que necesita cargar un archivo de idioma. Y al principio cargo el archivo de idioma y recupero el texto de los botones y otros elementos de GUI del archivo de idioma.

Esto es realmente malo para mi Porque si falta el archivo de idioma, la GUI no debería aparecer. Entonces, ¿cómo lo resuelvo? ¿Poner todo mi código en la callback success ? Eso no me parece una buena práctica de encoding. ¿Puedo resolverlo de otra manera?

La solución es agregar manualmente una superposición para evitar que el usuario interactúe con la interfaz, y luego eliminarla una vez que la consulta AJAX haya finalizado.

 $(function() { show_overlay(); $.ajax({ // Query to server }).done(function() { // Verify good data // Do stuff remove_overlay(); }); }); 

Leí la discusión oficial en el boleto sobre la desaprobación de este parámetro y aquí está lo que entendí:

  • El problema es que la implementación de Promise s ( 1 ) para sincronizar AJAX les da una sobrecarga.

  • Hay toneladas de casos de uso de AJAX de sincronización en el mundo real, por ejemplo, preservando el estado antes de descargar la página. Por lo tanto, esta funcionalidad permanecerá, pero la forma en que la use puede cambiar.

  • La solución más cercana (¿aterrizando en 1.8?) Es admitir solo devoluciones de llamadas (pero no las Promesas) cuando async es false .

Para concluir : sigue usando async: false si es necesario, pero ten cuidado con sus inconvenientes (locking de VM). No se preocupe, se le proporcionará una alternativa si alguna vez se elimina esta función de $.ajax() .

Apuesto a que muchas de esas páginas no bloquean la interfaz de usuario mientras esperan la llamada AJAX. En su lugar, es probable que oculten la interfaz de usuario con la pantalla de espera en el momento en que se realiza la llamada y luego elimine eso en un controlador de respuesta.

Hay muchas formas de ocultar la interfaz de usuario (incluso puedes usar un diálogo de interfaz de usuario de jQuery configurado en Modal y no tiene botones de escape o de cierre), así que te dejaré esa decisión. Pero el diseño del código sería algo como esto:

 var someFunction = function () { // any pre-conditions to the logic // obscure the UI here $.ajax({ url: 'ajax/test.html', success: function(data) { // handle the response // show the UI again }, error: function(data) { // handle the response // show the UI again } }); } 

Estoy seguro de que hay múltiples formas de lograr ese orden de eventos, pero esa es la idea general. El locking de la interfaz de usuario nunca fue realmente la intención, y me imagino que fue una decisión aún más difícil para jQuery incluir esa característica que eliminarla . Está destinado a ser asincrónico.

¿Por qué usaría ajax para obtener este archivo? Simplemente inclúyalo usando una etiqueta de script .

En cualquier caso, no coloque todo su código en el onSuccess, sino que llama a una función desde allí que inicia el código en ejecución.