2011-06-29 26 views
5

Esta pregunta seguramente podría aplicarse a jQuery, pero en este caso me refiero a Prototype. En el documento se dice Prototipo,¿Cuáles son los inconvenientes de utilizar la llamada ajax sincrónica?

Dado que el uso síncrono es bastante inquietante gusto, y por lo general mal, que debe evitar cambiar esto. Seriamente.

No estoy seguro de los inconvenientes de utilizar una llamada ajax sincrónica. Parece que hay muchos casos en los que debe esperar a que vuelva la llamada (sin utilizar las funciones de devolución de llamada específicas). Por ejemplo, actualmente uso Prototype's onSuccess, onFailure and onComplete para manejar el resto del código.

Sin embargo, los servicios web que uso (todo internamente) abarcan la mayoría de los proyectos y me han encargado crear más código reutilizable. Un ejemplo sería una clase de cliente que devuelve las propiedades del cliente. Un ejemplo sencillo (hay que tener en cuenta que sólo estoy mostrando las funciones básicas que sea sencillo):

Customer = Class.create({ 

    initialize: function(customerId) { 

     new Ajax.Request('some-url', { 
      method: 'get', 
      parameters: { 
       customerId: customerId 
      }, 
      onSuccess: this.setCustomerInfo.bind(this) 
     } 

    }, 

    setCustomerInfo: function(response) { 

     //for the sake of this example I will leave out the JSON validation 

     this.customerInfo = response.responseText.evalJSON(); 

    } 

}); 

Por lo tanto, el uso de esa clase simple que puede hacer lo siguiente en cualquier proyecto para obtener la información del cliente.

var customer = new Customer(1); 

//now I have the customer info 
document.write(customer.customerInfo.firstName); 

El uso del código anterior no imprimirá el nombre del cliente. Esto se debe a que la llamada ajax es asincrónica. Ejecutará el document.write independientemente de si el servicio web devolvió o no los datos del cliente. Pero no quiero hacer nada hasta que los datos vuelvan y la variable del cliente esté configurada. Para solucionarlo, establecí la llamada ajax en modo sincrónico para que el navegador no continúe hasta que finalice el new Customer(1);.

Este método parece funcionar (configuración asíncrona a falso), pero leer los documentos del prototipo me da pausa. ¿Cuál es el inconveniente de usar este método? ¿Hay otra forma de hacerlo, más eficiente, etc.?

Agradecería cualquier comentario.

Respuesta

2

La mayoría de las personas desaprueban las llamadas ajax sincrónicas porque congelarán la IU hasta que se complete, ya que no permitirá que el código continúe hasta que se complete. Me da por tartamudear en la interfaz, supongo que podrías decir.

+0

A continuación, voy a fruncir el ceño y aprender a codificar mejor :) – traviss0

6

Bueno, además del hecho de que es muy no JavaScript, tiene efectos tan agradables como bloqueando completamente EL NAVEGADOR DE IU. Ese no es un problema menor.

Investigué un poco, encontré cosas geniales. El prototipo se basa en "asincrónico" fuera de XMLHttpRequest.open. De acuerdo con Wikipedia, esto no es algo que no es una parte requerida de la especificación y evitará "onreadystatechange".

10

Vamos a recordarle que JavaScript está un único subproceso

Una llamada IO sincrónica BLOQUES el hilo completo

Una solución simple es utilizar la programación asincrónica utilizando el estilo devoluciones de llamada.

Customer = Class.create({  
    initialize: function(customerId, cb) { 
     new Ajax.Request('some-url', { 
      method: 'get', 
      parameters: { 
       customerId: customerId 
      }, 
      onSuccess: (function() { 
       this.setCustomerInfo.apply(this, arguments); 
       cb.apply(this, arguments); 
      }).bind(this) 
     } 
    }, 
    setCustomerInfo: function(response) { 
     //for the sake of this example I will leave out the JSON validation 
     this.customerInfo = response.responseText.evalJSON(); 
    } 
}); 

var c = new Customer(1, function() { 
    document.write(customer.customerInfo.firstName); 
}); 
2

Bueno, no me parece que es un problema para bloquear la interfaz de usuario si el usuario está generando una imagen de carga, mientras que la llamada sincrónica se hace. Podría ser lo mismo que enviar el formulario.

+0

El problema es que el usuario no puede distinguir * en absoluto * si el navegador se bloquea porque hubo un problema o si se trata de un comportamiento normal. Por lo general, cuando una aplicación ya no responde a la entrada, asumo que de alguna manera se colgó. –

Cuestiones relacionadas