jQuery.ajax() la méthode asynchrone option obsolète, que faire maintenant?
De jQuery 1.8, l'utilisation de async:false
dans jQuery.ajax() est obsolète.
Mais combien de pages avez-vous vu avec un "écran de chargement" alors qu'il y est un AJAX en cours de communication dans le fond? J'ai probablement vu des milliers d'entre eux.
Mon cas, c'est que je suis en train d'écrire une application mobile qui doit charger un fichier de langue. Et au début, j'ai charger le fichier de langue et j'ai récupérer le texte des boutons et d'autres éléments graphiques de la langue de fichier.
C'est vraiment mauvais pour moi. Car si la langue de fichier est manquant, l'interface graphique ne devrait pas apparaître. Alors, comment puis-je le résoudre? Mettre tout mon code dans le success
de rappel? Qui n'a pas l'air comme une bonne pratique de codage pour moi. Puis-je le résoudre d'une autre manière?
- Vous pouvez faire de nouvelles fonctions. Et d'appeler ces fonctions dans le onSuccess gestionnaire. Il est encore visible comme ça
- N'est-ce pas la synchronisation est obsolète?
async=false
est " sync 😉- Il m'a fallu plusieurs lectures pour cliquez qui. Au début, j'étais comme "euh?" et j'étais comme "ermahgerd!"
Vous devez vous connecter pour publier un commentaire.
La solution est d'ajouter manuellement une superposition d'empêcher l'utilisateur d'interagir avec l'interface, puis le retirer une fois la requête AJAX est fait.
show_overlay()
est une fonction hypothétique qui affiche un élément qui obscurcit l'interface, comme un div qui remplit la fenêtre avec un grand z-index avec un peu de contenu.$().html(data)
?(async function() {await $.getScript(), ....})()
travaille pour qui.J'ai lu le officiels de discussion dans le billet sur la désapprobation de ce paramètre et voici ce que j'ai compris:
Le problème est que la mise en œuvre de Promesses (Un) pour la synchronisation AJAX donne des frais généraux.
Il y a des tonnes de monde réel de cas d'utilisation de la synchronisation AJAX, par exemple, en préservant l'état avant que la page ne se décharger. Par conséquent, cette fonctionnalité va rester, mais la façon dont vous l'utilisez peut changer.
Le plus proche de la solution (atterrissage en 1.8?) est de ne soutenir que les rappels (mais pas les Promesses) lorsque
async
estfalse
.De conclure: Gardez à l'aide de
async: false
si vous devez, mais méfiez-vous de ses inconvénients (blocage de la VM). Ne vous inquiétez pas, il vous sera fourni une alternative si cette fonctionnalité n'est jamais retiré$.ajax()
.Je serais prêt à parier que de nombreux de ces 1000 pages ne fait pas de bloquer l'INTERFACE utilisateur lors de l'attente de l'appel AJAX. Au lieu de cela, ils ont probablement obscur de l'INTERFACE utilisateur avec l'écran en attente au moment de l'appel, puis retirer que sur une réponse du gestionnaire.
Il existe de nombreuses façons de masquer l'INTERFACE utilisateur (vous pouvez même utiliser un simple jQuery Dialogue de l'INTERFACE utilisateur qui est configuré pour et Modal a pas de fuite ou de fermer les boutons), je vais donc laisser cette décision à vous. Mais la mise en page du code pourrait être quelque chose comme ceci:
Je suis sûr qu'il y a de multiples façons de réaliser que l'ordre des é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 encore plus difficile la décision de jQuery pour inclure de la fonctionnalité que de supprimer il. Il est destiné à être asynchrone.
Pourquoi voudriez-vous utiliser ajax pour obtenir ce fichier? Il suffit d'inclure l'aide d'un
script
tag.Dans tous les cas, vous ne mettez pas tout votre code dans le onSuccess - au lieu de cela vous appelez une fonction unique à partir de là que commence votre code en cours d'exécution.