Que se passe-t-il si j'envoie une demande Ajax et modifier immédiatement la page (par exemple, suivez le lien) avant que la demande ne revienne? Je veux dire que je suppose que l'objet XHR envoie une demande au site Web, mais elle est supprimée (puisque la page est modifiée) avant que la réponse ne soit récupérée, alors que la réponse doit-elle être envoyée?
Je pose cette question parce que je J'ai un problème étrange avec mon site web. J'ai une page qui charge des messages du magasin de données via une demande AJAX. Si avant que la charge soit terminée, je clique sur un lien, je reçois l'onerror de jquery.ajax appelé! Je ne sais pas pourquoi cela se produit.
EDIT : Ceci est mon appel à Ajax. Dans le cas normal, le rappel du succès est appelé. Mais quand je clique sur un lien, le rappel d'erreur est appelé! Je pense à quelque chose, pourrait-il être dû au fait que les données doivent être formatées comme JSON, mais la demande est coupée au milieu, les données sont donc considérées comme non valides provoquant une jQuery d'appeler le rappel d'erreur ?! Mais alors pourquoi les demandes sont coupées au milieu?
5 Réponses :
Vous seriez pas de chance. Vous n'auriez pas de rappel pour revenir. La réponse AJAX serait perdue. Dans ce cas, je mettrais un bloqueur sur la page. C'est assez courant, afin d'éviter un autre clic. Blocker rien de plus que le gros masque qui "pose sur" tout le navigateur. Cela pourrait également avoir une icône d'attente.
C'est la réponse raisonnable, mais je reçois l'appel d'Onerror ?! Si je ne change pas la page, la demande fonctionne parfaitement bien, il n'ya donc aucune raison d'être appelée Onerror.
Ouais .... Je pense à ça maintenant ... c'est un étrange. Je me demande si la réponse revient à la recherche de son rappel .. Mais on pourrait toujours penser que cela "mourir". Ceci est intéressant-- Pouvez-vous le reproduire avec une page très simple? Je serais curieux.
@Pomater je vous ai donné un uppote sur question-- C'est intéressant. Va regarder à nouveau dans un peu.
Le comportement semble être lorsque l'utilisateur quitte une page, toutes les demandes AJAX exceptionnelles complètes avec 0 comme statut. JQuery interpréter cela comme une erreur, c'est pourquoi il appelle le gestionnaire d'erreurs. Dans votre gestionnaire d'erreur, vous pouvez appeler la même fonction que votre gestionnaire de succès appelle si xhr.status == 0, sinon exécutez le comportement d'erreur souhaité.
La solution à ce problème est simple, tout ce que vous avez à faire est si la demande est en cours d'exécution et si l'utilisateur clique sur un autre lien, vous devez alerter l'utilisateur que la demande est sous traitement, veuillez patienter
Pour y parvenir, vous devez conserver un sémaphore, définissez ce sémaphore avant de tirer une demande et de la réinitialiser à la fin de cette demande. En cliquant sur chaque lien (qui modifie la page) appelez une méthode qui vérifie le sémaphore et s'il est défini, la méthode donne à l'utilisateur ci-dessus à l'utilisateur. De cette façon, jusqu'à ce que la demande complète, l'utilisateur ne puisse changer de page et votre problème de demande d'abandon serait résolu
J'espère que cela répond à la question.
L'astuce consiste à vérifier les en-têtes de réponse dans l'objet XMLHTTTPRequest. S'il n'y a pas d'en-têtes de réponse (chaîne nulle ou vide, selon le navigateur), le serveur n'a pas encore répondu. Cela signifie que l'utilisateur a été abandonné.
$.ajax({
url: "url-to-go-here",
success: function() {
},
error: function(xhr, textStatus, errorThrown) {
if(!isUserAborted(xhr)) {
console.log("Ajax Error")
}
}
});
function isUserAborted(xhr) {
return !xhr.getAllResponseHeaders();
}
Vérification de ! Xhr.getallResponseheers () peut ne pas fonctionner dans tous les navigateurs. Il peut retourner un objet vide même lorsqu'il n'y a pas d'en-têtes dans la réponse, vous devrez donc vérifier également les objets vides. Sinon, cela fonctionne comme un charme et devrait être accepté comme la bonne réponse.
J'ai vu une réponse ailleurs sur les interwebs pour vérifier xhr.state () === "rejeté" . Est une méthode plus valable que la suivante?
Je devais faire face au même problème quelques jours il y a quelques jours. Semble que ce n'est pas si compliqué à traiter .. Nous devrions distinguer la météo que c'est une erreur Ajax d'une sorte ou d'un utilisateur abandonne la demande. Bien sûr Nous n'avons pas d'événement spécifique à partir d'un objet XHR .. C'est pourquoi une erreur Ajax est livrée avec une exception ... Combinaison d'objet XHR et de valeur d'exception que nous pouvons résoudre ce problème.