Qu'est-ce qu'une demande AJAX cachée?
J'ai remarqué une augmentation de l'utilisation de requêtes AJAX cachées conçues pour que l'action d'un utilisateur semble se produire immédiatement. Je ferai référence à ce type de demande AJAX comme non bloquant. C'est une demande AJAX faite sans que l'utilisateur sache que cela se produit, elle est effectuée en arrière-plan et son fonctionnement est silencieux ( il n'y a pas de message détaillé indiquant la réussite de l'appel AJAX ). L’objectif est de faire croire à l’opération que cela s’est produit immédiatement alors qu’elle n’a pas vraiment fini.
Voici des exemples de requêtes AJAX non bloquantes;
- L'utilisateur clique sur supprimer dans une collection d'e-mails. Les éléments disparaissent immédiatement de leur boîte de réception et ils peuvent continuer avec d'autres opérations. Pendant ce temps, une demande AJAX traite la suppression des éléments en arrière-plan.
- L'utilisateur remplit un formulaire pour les nouveaux enregistrements. Clics enregistrer. Le nouvel élément apparaît immédiatement dans la liste. L'utilisateur peut continuer à ajouter de nouveaux enregistrements.
Pour clarifier, voici des exemples de blocage de demandes AJAX;
- L'utilisateur clique sur supprimer dans une collection d'e-mails. Un curseur en sablier apparaît. La demande AJAX est faite et quand elle répond, le curseur sablier est désactivé. L'utilisateur doit attendre une seconde pour que l'opération soit terminée.
- L'utilisateur remplit un formulaire pour les nouveaux enregistrements. Clics enregistrer. Le formulaire devient gris avec un chargeur AJAX animé. Un message s'affiche "Vos données ont été enregistrées" et le nouvel enregistrement apparaît dans la liste.
La différence entre les deux scénarios ci-dessus réside dans le fait qu'une configuration AJAX non bloquante ne fournit pas d'informations en retour sur une opération en cours d'exécution, contrairement à une configuration AJAX bloquante.
Le risque de demandes cachées AJAX
Le plus grand risque de ce style de demande AJAX est que l'application Web puisse se trouver dans un état complètement différent en cas d'échec de la demande AJAX.
Par exemple, un exemple non bloquant;
- L'utilisateur sélectionne un tas de courriels. Clique sur le bouton Supprimer. L'opération semble se produire immédiatement (les éléments disparaissent de la liste). L'utilisateur clique ensuite sur le bouton de composition et commence à taper un nouvel email. C'est à ce moment que le code JavaScript découvre que la demande AJAX a échoué. Le script peut afficher un message d'erreur, mais c'est vraiment inutile en ce moment.
Alternativement, un exemple bloquant;
- L'utilisateur sélectionne un tas de courriels. Clique sur le bouton Supprimer. Voit un sablier, mais l'opération échoue. Ils reçoivent un message d'erreur disant "erreur. Bla bla bla". Ils sont renvoyés à la liste des e-mails et ils ont toujours sélectionné les e-mails qu'ils voulaient supprimer. Ils pourraient tenter de les supprimer à nouveau.
Il existe également d'autres risques techniques liés à l'exécution de requêtes AJAX non bloquantes. L'utilisateur peut fermer le navigateur, accéder à un autre site Web et à un autre emplacement du site Web actuel, ce qui rend tout contexte de réponse d'erreur inexact.
Alors, pourquoi devient-il si populaire?
Facebook, Google, Microsoft, etc., etc., etc., tous ces grands domaines utilisent de plus en plus des requêtes AJAX non bloquantes pour faire en sorte que les opérations apparaissent comme étant exécutées instantanément. J'ai également constaté une augmentation du nombre d'éditeurs de formulaires dépourvus de bouton de sauvegarde ou d'envoi . Dès que vous quittez un champ ou appuyez sur enter. La valeur est enregistrée. Il n'y a pas de message de profil ou de sauvegarde mis à jour .
Les demandes AJAX ne sont pas une certitude et ne devraient pas être traitées avec autant de succès tant qu'elles ne sont pas terminées, mais de nombreuses applications Web majeures fonctionnent exactement comme cela.
Ces sites Web qui utilisent des appels AJAX non bloquants pour simuler des applications réactives prennent-ils un risque inutile au détriment d'une parution rapide?
Est-ce un modèle de conception que nous devrions tous suivre pour rester compétitifs?