web-dev-qa-db-fra.com

L'option async de la méthode jQuery.ajax () est déconseillée, et maintenant?

Depuis jQuery 1.8, l'utilisation de async:false in jQuery.ajax () is obsolète .
Mais combien de pages Web avez-vous vues avec un "écran de chargement" alors qu'il y a une communication en cours AJAX en arrière-plan? J'en ai probablement vu des milliers.

Mon cas est que j'écris une application mobile qui doit charger un fichier de langue. Et au début, je charge le fichier de langue et je récupère le texte des boutons et autres éléments de l'interface graphique du fichier de langue.

C'est vraiment mauvais pour moi. Parce que si le fichier de langue est manquant, l'interface graphique ne devrait pas apparaître. Alors, comment puis-je le résoudre? Mettre tout mon code dans le rappel success? Cela ne me semble pas être une bonne pratique de codage. Puis-je le résoudre d'une autre manière?

jqueryajaxmobile
48
Juw

La solution consiste à ajouter manuellement une superposition pour empêcher l'utilisateur d'interagir avec l'interface, puis à la supprimer une fois la requête AJAX terminée).

$(function() {
    show_overlay();        

    $.ajax({
        // Query to server
    }).done(function() {
        // Verify good data
        // Do stuff
        remove_overlay();
    });
});
34
Jørgen R

J'ai lu le discussion officielle dans le ticket sur la dépréciation de ce paramètre et voici ce que j'ai compris:

  • Le problème est que l'implémentation Promise s ( 1 ) pour la synchronisation AJAX leur donne des frais généraux.

  • Il existe des tonnes de cas d'utilisation réels de la synchronisation AJAX, par exemple conservation de l'état avant le déchargement de la page. Par conséquent, cette fonctionnalité restera, mais la façon dont vous l'utilisez peut changer.

  • La solution la plus proche (atterrir dans 1.8?) Est de prendre en charge uniquement les rappels (mais pas les promesses) lorsque async est false.

Pour conclure : Continuez à utiliser async: false Si vous le devez, mais méfiez-vous de ses inconvénients (blocage de VM). Ne vous inquiétez pas, une alternative vous sera proposée si cette fonction est supprimée $.ajax() .

29
Infeligo

Je parierais que beaucoup de ces milliers de pages ne bloquent pas réellement l'interface utilisateur en attendant l'appel AJAX. Au lieu de cela, ils obscurcissent probablement l'interface utilisateur avec l'attente écran au moment de l'appel, puis supprimez-le sur un gestionnaire de réponse.

Il existe de nombreuses façons de masquer l'interface utilisateur (vous pouvez même simplement utiliser une boîte de dialogue d'interface utilisateur jQuery définie sur Modal et sans boutons d'échappement ou de fermeture), je vous laisse donc le soin de décider. Mais la disposition du code ressemblerait à ceci:

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

        }
    }); 
}

Je suis sûr qu'il existe plusieurs façons d'atteindre cet ordre d'événements, mais c'est l'idée générale. Le blocage de l'interface utilisateur n'a jamais été vraiment l'intention, et j'imagine que c'était une décision encore plus difficile pour jQuery de inclure cette fonctionnalité que de supprimer la. Il est censé être asynchrone.

3
David

Pourquoi utiliseriez-vous ajax pour obtenir ce fichier? Il suffit de l'inclure à l'aide d'une balise script.

Dans tous les cas, vous ne mettez pas tout votre code dans onSuccess - à la place, vous appelez une seule fonction qui démarre votre code.

0
Ariel