Die async-Option der jQuery.ajax () -Methode ist veraltet, was nun?

Ab jQuery 1.8 ist die Verwendung von async:false in jQuery.ajax () veraltet .
Aber wie viele Webseiten haben Sie mit einem “Ladebildschirm” gesehen, während eine laufende AJAX-Kommunikation im Hintergrund läuft? Ich habe wahrscheinlich Tausende von ihnen gesehen.

Mein Fall ist, dass ich eine mobile App schreibe, die eine Sprachdatei laden muss. Und am Anfang lade ich die Sprachdatei und ich erhalte den Text der Schaltflächen und anderer GUI-Elemente aus der Sprachdatei.

Das ist wirklich schlecht für mich. Wenn die Sprachdatei fehlt, sollte die GUI nicht angezeigt werden. Wie löse ich es? Setzen Sie meinen gesamten Code in den success ? Das scheint mir keine gute Programmierpraxis zu sein. Kann ich es anders lösen?

   

    Die Lösung besteht darin, manuell eine Überlagerung hinzuzufügen, um zu verhindern, dass der Benutzer mit der Schnittstelle interagiert, und sie dann zu entfernen, sobald die AJAX-Abfrage abgeschlossen ist.

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

    Ich habe die offizielle Diskussion im Ticket über die Vernachlässigung dieses Parameters gelesen und hier ist, was ich verstanden habe:

    • Das Problem besteht darin, dass die Implementierung von Promise s ( 1 ) für die Synchronisierung von AJAX einen Overhead darstellt.

    • Es gibt Unmengen an realen Anwendungsfällen von Synchronisations-AJAX, zB den Zustand vor dem Entladen der Seite bewahren. Daher bleibt diese functionalität erhalten, aber die Art und Weise, wie Sie sie verwenden, kann sich ändern.

    • Die nächste Lösung (Landung in 1.8?) Ist, nur callbacke (aber nicht die Versprechen) zu unterstützen, wenn async false .

    async: false Verwenden Sie weiterhin async: false wenn Sie müssen, aber seien Sie vorsichtig mit den Nachteilen (Blockierung der VM). Keine Sorge, Sie erhalten eine Alternative, wenn diese function jemals aus $.ajax() .

    Ich würde wetten, dass viele dieser 1000 Seiten die Benutzeroberfläche während des Wartens auf den AJAX-Aufruf nicht wirklich blockieren. Stattdessen verdecken sie wahrscheinlich die Benutzeroberfläche mit dem Wartescreen zum Zeitpunkt des Anrufs und entfernen diese dann auf einem Antworthandler.

    Es gibt viele Möglichkeiten, die Benutzeroberfläche zu verdecken (Sie könnten sogar einfach einen jQuery UI-Dialog verwenden, der auf Modal eingestellt ist und keine Escape- oder Schließen-Schaltflächen hat), also überlasse ich Ihnen diese Entscheidung. Aber das Layout des Codes wäre etwa so:

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

    Ich bin mir sicher, dass es mehrere Möglichkeiten gibt, diese Reihenfolge der Ereignisse zu erreichen, aber das ist die allgemeine Idee. Das Blockieren der Benutzeroberfläche war nie wirklich die Absicht, und ich denke, es war eine noch schwierigere Entscheidung für jQuery, diese function einzuschließen, als sie zu entfernen . Es soll asynchron sein.

    Warum würden Sie Ajax verwenden, um diese Datei zu bekommen? Fügen Sie es einfach mit einem script Tag ein.

    In jedem Fall fügen Sie nicht Ihren gesamten Code in onSuccess ein – stattdessen rufen Sie eine einzelne function von dort auf, die Ihren Code startet.