C'è qualche motivo per utilizzare un XMLHttpRequest sincrono?

Sembra che quasi tutti facciano richieste asincrone con XMLHttpRequest, ma ovviamente il fatto che ci sia la possibilità di fare richieste sincrone indica che potrebbe esserci un motivo valido per farlo. Allora quale potrebbe essere questo motivo valido?

Penso che potrebbero diventare più popolari con il progredire degli standard HTML 5. Se a un'applicazione web viene concesso l'accesso ai web worker, potrei prevedere che gli sviluppatori utilizzino un web worker dedicato per effettuare richieste sincrone, come ha detto Jonathan, per garantire che una richiesta avvenga prima dell'altra. Con la situazione attuale di un thread, è un progetto tutt'altro che ideale in quanto si blocca fino al completamento della richiesta.

Gli XHR sincroni sono utili per il salvataggio dei dati utente. Se gestisci l' beforeunloadevento puoi caricare i dati sul server non appena l'utente chiude la pagina.

Se ciò fosse fatto utilizzando l'opzione asincrona, la pagina potrebbe chiudersi prima che la richiesta venga completata. In questo modo in modo sincrono, si garantisce che la richiesta venga completata o non riesca nel modo previsto.

Aggiornare:

Quanto segue ha accennato - ma non ha avuto successo nel consegnare - che con l'avvento di una migliore gestione delle richieste asincrone, non c'è davvero alcun motivo per utilizzare richieste sincrone, a meno che non si intenda bloccare intenzionalmente gli utenti dal fare qualsiasi cosa fino al completamento di una richiesta - suona dannoso: )

Sebbene ciò possa sembrare negativo, potrebbero esserci momenti in cui è importante che una richiesta (o una serie di richieste) si verifichi prima che un utente lasci una pagina, o prima che venga eseguita un'azione - il blocco dell'esecuzione di altro codice (ad esempio, impedire il pulsante Indietro) potrebbe possibilmente ridurre errori / manutenzione per un sistema mal progettato; detto questo, non l'ho mai visto in natura e sottolinea che dovrebbe essere evitato.

Le biblioteche, come la promessa , fingono la sincronicità concatenando i processi tramite callback. Ciò si adatta alla maggior parte delle esigenze di sviluppo in cui si desidera avere eventi ordinati e non bloccanti che consentano ai browser di mantenere la reattività per l'utente (buona UX).

Come indicato nei documenti di Mozilla, ci sono casi in cui è necessario utilizzare richieste sincrone; tuttavia, è elencata anche una soluzione alternativa che utilizza il beacon (non disponibile in IE / Safari) in questi casi. Sebbene questo sia sperimentale, se mai raggiungerà l'accettazione degli standard, potrebbe forse mettere un chiodo nella bara della richiesta sincrona.

Si desidera eseguire chiamate sincrone in qualsiasi tipo di elaborazione simile a una transazione o ovunque sia necessario un ordine di operazione.

Ad esempio, supponiamo che tu voglia personalizzare un evento per disconnetterti dopo aver riprodotto una canzone. Se l'operazione di logout avviene per prima, il brano non verrà mai riprodotto. Ciò richiede la sincronizzazione delle richieste.

Un altro motivo potrebbe essere quando si lavora con un WebService, soprattutto quando si eseguono operazioni matematiche sul server.

Esempio: il server ha una variabile con valore 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

Se il passaggio (2) si verifica per primo, il valore finale è 2, non 8; quindi l'ordine delle operazioni è importante e la sincronizzazione è necessaria.

Ci sono pochissime volte in cui una chiamata sincrona può essere giustificata in un esempio comune del mondo reale. Forse quando si fa clic su login e quindi si fa clic su una parte del sito che richiede l'accesso di un utente.

Come altri hanno già detto, vincolerà il tuo browser, quindi stai lontano da esso dove puoi.

Invece di chiamate sincrone, tuttavia, spesso gli utenti desiderano interrompere un evento in fase di caricamento e quindi eseguire qualche altra operazione. In un certo senso questa è sincronizzazione, poiché il primo evento viene chiuso prima che inizi il secondo. Per fare ciò, usa il metodo abort () sull'oggetto connessione xml.

Direi che se consideri il blocco del browser dell'utente mentre la richiesta viene completata in modo accettabile, usa sicuramente una richiesta sincrona.

Se il tuo obiettivo è la serializzazione delle richieste, puoi farlo utilizzando richieste asincrone, facendo in modo che il callback onComplete della tua richiesta precedente attivi la successiva in linea.

Esistono molti casi del mondo reale in cui il blocco dell'interfaccia utente è esattamente il comportamento desiderato.

Prendi un'app con più campi e alcuni campi devono essere convalidati da una chiamata xmlhttp a un server remoto fornendo come input il valore di questo campo e altri valori di campo.

In modalità sincrona la logica è semplice, il blocco sperimentato dall'utente è brevissimo e non ci sono problemi.

In modalità asincrona, l'utente può modificare i valori di qualsiasi altro campo durante la convalida di quello iniziale. Queste modifiche attiveranno altre chiamate xmlhttp con valori dal campo iniziale non ancora convalidati. Cosa succede se la convalida iniziale fallisce? Puro casino. Se la modalità di sincronizzazione diventa obsoleta e vietata, la logica dell'applicazione diventa un incubo da gestire. Fondamentalmente l'applicazione deve essere riscritta per gestire i blocchi (es. Disabilitare altri elementi durante i processi di convalida). La complessità del codice aumenta enormemente. In caso contrario, potrebbe verificarsi un errore logico e, in ultima analisi, il danneggiamento dei dati.

Fondamentalmente la domanda è: cosa è più importante, l'esperienza dell'interfaccia utente non bloccata o il rischio di danneggiamento dei dati? La risposta dovrebbe rimanere con lo sviluppatore dell'applicazione, non il W3C.

Posso vedere un utilizzo per le richieste XHR sincrone da utilizzare quando una risorsa in una posizione variabile deve essere caricata prima che altre risorse statiche nella pagina che dipendono dalla prima risorsa funzionino completamente. In effetti, sto implementando una tale richiesta XHR in un mio piccolo sottoprogetto mentre le risorse JavaScript risiedono in posizioni variabili sul server a seconda di un insieme di parametri specifici. Le risorse JavaScript successive si basano su quelle risorse variabili e DEVE essere garantito il caricamento di tali file prima che vengano caricati gli altri file dipendenti, rendendo così l'intera applicazione.

Quella base dell'idea si espande davvero sulla risposta di vol7ron. Le procedure basate sulle transazioni sono davvero l'unico momento in cui devono essere effettuate richieste sincrone. Nella maggior parte degli altri casi, le chiamate asincrone sono la migliore alternativa in cui, dopo la chiamata, il DOM viene aggiornato secondo necessità. In molti casi, come i sistemi basati sugli utenti, alcune funzionalità potrebbero essere bloccate agli "utenti non autorizzati" fino a quando questi non hanno effettuato l'accesso di per sé. Tali funzionalità, dopo la chiamata asincrona, vengono sbloccate tramite una procedura di aggiornamento DOM.

Devo infine dire che sono d'accordo con i punti della maggior parte delle persone in materia: ove possibile, le richieste XHR sincrone dovrebbero essere evitate poiché, con il modo in cui funziona, il browser si blocca con le chiamate sincrone. Quando si implementano richieste sincrone, dovrebbero essere eseguite in un modo in cui il browser sarebbe normalmente bloccato, ad esempio nella sezione HEAD prima che si verifichi effettivamente il caricamento della pagina.

A partire dal 2015 le app javascript desktop stanno diventando più popolari. Di solito in queste app quando si caricano file locali (e caricarli utilizzando XHR è un'opzione perfettamente valida), la velocità di caricamento è così veloce che non ha senso complicare eccessivamente il codice con async. Ovviamente potrebbero esserci casi in cui l'asincronia è la strada da percorrere (richiesta di contenuto da Internet, caricamento di file molto grandi o un numero enorme di file in un singolo batch), ma per il resto la sincronizzazione funziona bene (ed è molto più facile da usare) .

jQuery utilizza internamente AJAX sincrono in alcune circostanze. Quando si inserisce HTML che contiene script, il browser non li eseguirà. Gli script devono essere eseguiti manualmente. Questi script possono allegare gestori di clic. Supponiamo che un utente faccia clic su un elemento prima che il gestore venga allegato e la pagina non funzioni come previsto. Pertanto, per evitare condizioni di competizione, verrà utilizzato AJAX sincrono per recuperare quegli script. Poiché AJAX sincrono blocca efficacemente tutto il resto, può essere certo che script ed eventi vengano eseguiti nell'ordine corretto.

Motivo:

Supponiamo che tu abbia un'applicazione ajax che necessita di una mezza dozzina di http per caricare vari dati dal server prima che l'utente possa eseguire qualsiasi interazione.

Ovviamente vuoi che questo venga attivato da onload.

Le chiamate sincrone funzionano molto bene per questo senza alcuna complessità aggiuntiva al codice. È semplice e diretto.

Inconveniente:

L'unico inconveniente è che il browser si blocca fino a quando tutti i dati non vengono caricati o si verifica un timeout. Per quanto riguarda l'applicazione ajax in questione, questo non è un grosso problema perché l'applicazione non è di alcuna utilità finché tutti i dati iniziali non vengono comunque caricati.

Alternativa?

Tuttavia molti browser bloccano tutte le finestre / schede quando javascript è occupato in una di esse, il che è uno stupido problema di progettazione del browser, ma di conseguenza il blocco su reti potenzialmente lente non è educato se impedisce agli utenti di utilizzare altre schede in attesa del caricamento della pagina ajax.

Tuttavia, sembra che i get sincroni siano stati comunque rimossi o limitati dai browser recenti. Non sono sicuro che sia perché qualcuno ha deciso che erano sempre cattivi, o se gli autori di browser erano confusi dal WC Working Draft sull'argomento.

http://www.w3.org/TR/2012/WD-XMLHttpRequest-20120117/#the-open-method fa sembrare che (vedi sezione 4.7.3) non ti sia permesso impostare un timeout quando usi la modalità di blocco . Mi sembra contro intuitivo: ogni volta che si blocca l'IO, è educato impostare un timeout ragionevole, quindi perché consentire il blocco di io ma non con un timeout specificato dall'utente?

La mia opinione è che il blocco dell'IO abbia un ruolo vitale in alcune situazioni, ma deve essere implementato correttamente. Sebbene non sia accettabile per una scheda o una finestra del browser bloccare tutte le altre schede o finestre, si tratta di un difetto di progettazione del browser. Peccato dove è dovuta la vergogna. Ma in alcuni casi è perfettamente accettabile che una singola scheda o finestra non risponda per un paio di secondi (cioè utilizzando il blocco IO / HTTP GET) in alcune situazioni - ad esempio, al caricamento della pagina, forse molti dati deve essere prima che qualsiasi cosa possa essere fatta comunque. A volte il codice di blocco implementato correttamente è il modo più pulito per farlo.

Ovviamente la funzione equivalente in questo caso può essere ottenuta utilizzando http gets asincroni, ma che tipo di routine è richiesta?

Immagino che proverei qualcosa in questo senso:

Al caricamento del documento, eseguire le seguenti operazioni: 1: impostare 6 variabili flag globali "Fatto", inizializzate a 0. 2: eseguire tutti e 6 i risultati in background (supponendo che l'ordine non abbia importanza)

Quindi, i callback di completamento per ciascuno dei 6 get http imposteranno i rispettivi flag "Done". Inoltre, ogni callback controllerebbe tutti gli altri flag di completamento per vedere se tutti e 6 gli HTTP vengono completati. L'ultimo callback per completare, dopo aver visto che tutti gli altri erano stati completati, avrebbe chiamato la funzione REAL init che avrebbe quindi impostato tutto, ora che i dati erano stati recuperati.

Se l'ordine di recupero fosse importante o se il server web non fosse in grado di accettare più richieste contemporaneamente, allora avresti bisogno di qualcosa del genere:

In onload (), verrebbe lanciato il primo http get. Nel suo callback, verrebbe lanciato il secondo. Nel suo callback, il terzo - e così via e così via, con ogni callback che avvia il successivo HTTP GET. Quando l'ultimo tornava, chiamava la vera routine init ().

Cosa succede se effettui una chiamata sincrona nel codice di produzione?

Il cielo cade.

No seriamente, all'utente non piace un browser bloccato.

Lo utilizzo per validare un nome utente, durante il controllo che il nome utente non esista già.

So che sarebbe meglio farlo in modo asincrono, ma poi dovrei usare un codice diverso per questa particolare regola di convalida. Spiego meglio. La mia configurazione di convalida utilizza alcune funzioni di convalida, che restituiscono vero o falso, a seconda che i dati siano validi.

Poiché la funzione deve tornare, non posso usare tecniche asincrone, quindi lo rendo sincrono e spero che il server risponda abbastanza prontamente da non essere troppo evidente. Se usassi un callback AJAX, dovrei gestire il resto dell'esecuzione in modo diverso dagli altri metodi di convalida.

A volte hai un'azione che dipende dagli altri. Ad esempio, l'azione B può essere avviata solo se A è terminata. L'approccio sincrono viene solitamente utilizzato per evitare condizioni di gara . A volte l'utilizzo di una chiamata sincrona è un'implementazione più semplice, quindi la creazione di una logica complessa per controllare ogni stato delle chiamate asincrone che dipendono l'una dall'altra.

Il problema con questo approccio è che "blocchi" il browser dell'utente fino al termine dell'azione (fino a quando la richiesta non ritorna, termina, carica, ecc.). Quindi fai attenzione quando lo usi.

Uso chiamate sincrone durante lo sviluppo del codice: qualunque cosa tu abbia fatto mentre la richiesta era in pendenza da e verso il server può oscurare la causa di un errore.

Quando funziona, lo rendo asincrono, ma cerco di includere un timer di interruzione e callback di errore, perché non si sa mai ...

SYNC vs ASYNC: qual è la differenza?

Fondamentalmente si riduce a questo:

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

Quando doSomethingè sincrono, verrà stampato:

Hello, World!
Got result!
Goodbye cruel world!

Al contrario, se doSomethingè asincrono , verrà stampato:

Hello, World!
Goodbye cruel world!
Got result!

Poiché la funzione doSomethingsta eseguendo il suo lavoro in modo asincrono, ritorna prima che il suo lavoro sia finito. Quindi otteniamo il risultato solo dopo la stampaGoodbye cruel world!

Se dipendiamo dal risultato di una chiamata asincrona, dobbiamo inserire il codice dipendente nella richiamata:

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

In quanto tale, il fatto che due o tre cose debbano accadere non è un motivo per farle in modo sincrono (sebbene il codice di sincronizzazione sia più facile con cui lavorare per la maggior parte delle persone).

PERCHÉ USARE XMLHTTPREQUEST SINCRONO?

Ci sono alcune situazioni in cui è necessario il risultato prima che la funzione chiamata venga completata. Considera questo scenario:

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

Supponiamo di non avere alcun controllo sul codice chiamante (la console.infolinea) e di dover cambiare funzione livesper chiedere al server ... Non c'è modo di fare una richiesta asincrona al server dall'interno livese avere ancora la nostra risposta prima che sia livescompletata. Quindi non sapremmo se tornare trueo false. L'unico modo per ottenere il risultato prima del completamento della funzione è eseguire una richiesta sincrona.

Come Sami Samhurimenzionato nella sua risposta, uno scenario molto reale in cui potresti aver bisogno di una risposta alla tua richiesta del server prima che la tua funzione termini è l' onbeforeunloadevento, poiché è l'ultima funzione della tua app che verrà mai eseguita prima che la finestra venga chiusa.

NON HO BISOGNO DI CHIAMATE SYNCH, MA LE USO COMUNQUE IN QUANTO SONO PIÙ FACILI

Per favore non farlo. Le chiamate sincrone bloccano il browser e fanno sentire l'app non risponde. Ma hai ragione. Il codice asincrono è più difficile. C'è, tuttavia, un modo per renderlo molto più semplice. Non è facile come il codice di sincronizzazione, ma si sta avvicinando: Promise s.

Ecco un esempio: due chiamate asincrone dovrebbero essere completate correttamente prima che possa essere eseguito un terzo segmento di codice:

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

Ecco come implementeresti 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.'));
    }
  });
}

Vedi anche: Scrivi JavaScript migliore con promesse .

XMLHttpRequestè tradizionalmente utilizzato per le richieste asincrone. A volte (per il debug o per una logica aziendale specifica) si desidera modificare tutte / molte delle chiamate asincrone in una pagina per la sincronizzazione.

Ti piacerebbe farlo senza cambiare tutto nel tuo codice JS. Il flag async / sync ti dà quella capacità e, se progettato correttamente, devi solo cambiare una riga nel tuo codice / cambiare il valore di uno vardurante il tempo di esecuzione.

Firefox (e probabilmente tutti i browser non IE) non supporta timeOut XHR asincrono.

1. Discussione su Stackoverflow
2. Mozilla Firefox XMLHttpRequest

I WebWorker HTML5 supportano i timeout. Quindi, potresti voler avvolgere la richiesta di sincronizzazione XHR su WebWorker con timeout per implementare XHR di tipo asincrono con comportamento di timeout.

Ho appena avuto una situazione in cui le richieste asincrone per un elenco di URL chiamati in successione utilizzando forEach (e un ciclo for) causavano l'annullamento delle richieste rimanenti. Sono passato al sincrono e funzionano come previsto.

L'utilizzo di richieste HTTP sincrone è una pratica comune nel settore della pubblicità mobile.

Le aziende (note anche come "editori") che creano applicazioni spesso pubblicano annunci per generare entrate. Per questo installano SDK pubblicitari nella loro app. Ne esistono molti (MoPub, Ogury, TapJob, AppNext, Google Ads AdMob).

Questi SDK pubblicheranno annunci in una visualizzazione web.

Quando si offre un annuncio a un utente, deve essere un'esperienza fluida , soprattutto durante la riproduzione di un video. Non dovrebbe esserci buffering o caricamento in nessun momento.

Per risolvere questo problema precachingviene utilizzato. Dove i media (foto / video / ecc.) Vengono caricati in modo sincrono sullo sfondo della visualizzazione web.

Perché non farlo in modo asincrono?

1. Questo fa parte di uno standard accettato a livello globale
2. L'SDK ascolta l' onloadevento per sapere quando l'annuncio è "pronto" per essere offerto all'utente

Con la deprecazione di XMLHttpRequests sincrono , molto probabilmente l'attività pubblicitaria sarà costretta a modificare lo standard in futuro a meno che non sia possibile determinare un altro modo.

L'XHR sincrono può essere molto utile per lo sviluppo di strumenti interni e / o framework (non di produzione). Immagina, ad esempio, di voler caricare una libreria di codice in modo sincrono al primo accesso, in questo modo:

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

Prima di innervosirti e rigurgitare ciecamente il male di eval, tieni presente che questo è solo per i test locali. Per le build di produzione, _draw sarebbe già impostato.

Quindi, il tuo codice potrebbe assomigliare a questo:

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

Questo è solo un esempio di qualcosa che sarebbe impossibile fare senza sincronizzare XHR. Potresti caricare questa libreria in anticipo, sì, o fare una promessa / richiamata, ma non potresti caricare la lib in modo sincrono senza sync XHR. Pensa a quanto questo tipo di cose potrebbe ripulire il tuo codice ...

I limiti a ciò che puoi fare con questo per strumenti e framework (in esecuzione localmente) sono limitati solo dalla tua immaginazione. Tuttavia, sembra che l'immaginazione sia un po 'limitata nel mondo JavaScript.

Bene, ecco una buona ragione. Volevo fare una richiesta http quindi, a seconda del risultato, chiamare click () su un input type = file. Questo non è possibile con xhr asincrono o fetch. Il callback perde il contesto "azione utente", quindi la chiamata click () viene ignorata. Xhr sincrono ha salvato la mia pancetta.

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