Quali sono gli svantaggi dell’uso della chiamata sincrona ajax?

Questa domanda potrebbe sicuramente essere applicata a jQuery ma in questo caso mi riferisco a Prototype. Nel documento Prototype che dice

Dal momento che l’uso sincrono è piuttosto inquietante, e solitamente di cattivo gusto, dovresti evitare di cambiarlo. Sul serio.

Non sono sicuro di quali siano gli svantaggi dell’utilizzo di una chiamata sincrona ajax. Sembra che ci siano molti casi in cui è necessario attendere il ritorno della chiamata (senza utilizzare le funzioni di callback specifiche). Ad esempio, attualmente utilizzo Prototype’s onSuccess, onFailure and onComplete per gestire il resto del codice.

Tuttavia, i servizi Web che uso (tutti in-house) coprono la maggior parte dei progetti e mi è stato assegnato il compito di creare un codice più riutilizzabile. Un esempio potrebbe essere una class cliente che restituisce le proprietà del cliente. Un semplice esempio (tieni presente che sto solo mostrando le funzioni di base per mantenerlo semplice):

 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(); } }); 

Quindi, usando quella semplice class posso fare quanto segue in qualsiasi progetto per ottenere le informazioni del cliente.

 var customer = new Customer(1); //now I have the customer info document.write(customer.customerInfo.firstName); 

L’utilizzo del codice precedente non stamperà il nome del cliente. Ciò è dovuto al fatto che la chiamata ajax è asincrona. Eseguirà il document.write indipendentemente document.write fatto che il servizio web abbia riportato o meno i dati del cliente. Ma non voglio fare nulla finché i dati non sono tornati e la variabile del cliente è impostata. Per risolvere questo problema, ho impostato la chiamata ajax su sincrono in modo che il browser non continui fino al new Customer(1); è finito.

Questo metodo sembra funzionare (impostazione asincrona su false) ma leggere i documenti di Prototype mi dà una pausa. Qual è l’inconveniente di utilizzare questo metodo? C’è un altro modo per farlo, più efficiente, ecc?

Gradirò ogni feedback.

Ti ricordiamo che JavaScript è a thread singolo

Una chiamata IO sincrona BLOCCA L’INTERO FILO

Una soluzione semplice consiste nell’utilizzare la programmazione in stile asincrono mediante callback.

 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); }); 

Bene, oltre al fatto che non è JavaScript, ha effetti piacevoli come COMPLETAMENTE BLOCCARE L’interfaccia utente del browser . Questo non è un problema minore.

Ha fatto qualche ricerca, ha trovato cose interessanti. Prototipo di basi “asincrone” al di fuori di XMLHttpRequest.open. Secondo Wikipedia , questo non è qualcosa che non è una parte richiesta delle specifiche e impedirà “onreadystatechange”.

La maggior parte delle persone disapprova le chiamate sincrone ajax perché bloccherà l’interfaccia finché non sarà completata, in quanto non consentirà al codice di continuare fino al completamento. Immagina di poter dire una balbuzie nell’interfaccia.

Beh, non trovo che sia un problema bloccare l’interfaccia utente se l’utente sta generando un’immagine di caricamento mentre è in corso la chiamata sincrona. Potrebbe essere lo stesso di inviare il modulo.