Inversion de contrôle dans les rappels JavaScript : pourquoi les promesses sont la réponse

Une fonction de rappel est une fonction transmise à une autre fonction en tant qu'argument, qui est ensuite invoquée à l'intérieur de la fonction externe pour effectuer une sorte de routine ou d'action. Il existe deux manières d'appeler le rappel : synchrone et asynchrone. C'est le modèle asynchrone le plus fondamental en Javascript.

Par exemple :

A et B se produisent maintenant, sous le contrôle direct du programme JS principal. Mais C est différé pour se produire plus tard, et sous le contrôle d'une autre partie, dans ce cas, la fonction ajax(..). Fondamentalement, ce type de transfert de contrôle ne pose pas régulièrement beaucoup de problèmes aux programmes.

Cependant, la rareté n’est pas suffisante pour ignorer le problème ou la question. En fait, c’est l’un des problèmes majeurs de la conception basée sur le rappel. Cela tourne autour de l'idée que parfois ajax(..) ou la « partie » à laquelle vous transmettez votre suite de rappel n'est pas une fonction que vous avez écrite ou que vous contrôlez directement. Il s’agit souvent d’un utilitaire fourni par un tiers.

Nous appelons cela « inversion de contrôle » lorsque vous prenez une partie de votre programme et cédez le contrôle de son exécution à un autre tiers. Il existe un « contrat » tacite qui existe entre votre code et l’utilitaire tiers – un ensemble de choses que vous vous attendez à ce qu’elles soient maintenues.

Quel est le problème avec « l’inversion du contrôle » ?

Il existe un exemple pour mieux comprendre ce problème.

Disons que vous créez un site Web de réservation de voyages pour votre entreprise. Vous avez ajouté un bouton « réserver maintenant » qui utilise la fonction createBooking() d'une bibliothèque tierce. Cette fonction traite la réservation puis rappelle votre rappel pour envoyer un email de confirmation au client.

Ce code pourrait ressembler à :

Tout fonctionne parfaitement lors des tests. Les gens commencent à réserver des forfaits de voyage sur votre site Web et tout le monde est satisfait de votre travail. Soudain, un jour, vous recevez un appel de votre patron concernant un problème majeur. Un client a réservé un forfait et a reçu quatre e-mails de confirmation identiques pour une réservation.

Vous commencez à déboguer le problème. Vous examinez la partie du code qui envoie l'e-mail de confirmation, et tout semble correct. Vous enquêtez ensuite plus en profondeur et découvrez que l'utilitaire createBooking() de la bibliothèque tierce a appelé votre fonction de rappel quatre fois, ce qui a entraîné l'envoi de quatre e-mails de confirmation.

Vous contactez l’équipe d’assistance de la bibliothèque tierce et expliquez la situation. Ils vous disent qu'ils n'ont jamais rencontré ce problème auparavant, mais qu'ils le prioriseront et vous répondront. Après une journée, ils vous rappellent avec leurs découvertes. Ils ont découvert qu'un morceau de code expérimental, qui n'était pas censé être mis en ligne, avait amené la fonction createBooking() à appeler le rappel plusieurs fois.

Le problème était de leur côté et ils vous ont assuré qu'il avait été résolu. Ils se sont excusés pour le problème et ont confirmé que le problème ne se reproduirait plus.

Pour éviter tout problème indésirable comme celui-ci après avoir cherché une solution, vous implémentez une simple instruction if comme la suivante, dont l'équipe semble satisfaite :

Mais ensuite l'un des ingénieurs QA demande : « Que se passe-t-il s'ils n'appellent jamais le rappel ? » Oups. Aucun de vous n’y avait pensé !

Vous commencez à penser à toutes les choses possibles qui pourraient mal se passer s'ils vous rappellent. Voici une liste de certains des problèmes :

• Rappelez le rappel trop tôt

• Rappeler le rappel trop tard (ou jamais)

• Appelez le rappel trop peu ou trop de fois (comme le problème dans l'exemple ci-dessus)

• Avalez toutes les erreurs/exceptions qui peuvent survenir

• ...

Vous vous rendrez probablement compte que vous devez implémenter de nombreuses solutions dans votre code pour différentes situations, ce qui rendra le code horrible et sale car il est requis dans chaque rappel passé à un utilitaire.

Promesses

Et si nous pouvions annuler cette inversion de contrôle ? Et si, au lieu de transmettre la suite de notre programme à un autre tiers, nous pouvions nous attendre à ce qu'il nous renvoie la capacité de savoir quand sa tâche se termine, et que notre code puisse alors décider quoi faire ensuite ?

Les promesses offrent un moyen puissant de gérer les opérations asynchrones en JavaScript, résolvant des problèmes tels que l'enfer des rappels et l'inversion de contrôle. Contrairement aux rappels, Promises vous permet de gérer des tâches asynchrones sans renoncer au contrôle de votre code.

Pensez à commander un cheeseburger dans un fast-food. Vous recevez un reçu, une promesse de votre futur cheeseburger. Pendant que vous attendez, vous pouvez faire autre chose, sachant que vous finirez par recevoir votre commande. De même, une promesse en JavaScript représente une valeur future, permettant à votre code de se dérouler sans problème.

Les promesses gèrent également les échecs avec élégance, tout comme vous pourriez être informé si le restaurant est à court de cheeseburgers. Cette structure rend votre code plus lisible et maintenable.

Je ne vais pas approfondir les promesses ici, mais en les utilisant, vous pouvez écrire du code asynchrone plus propre et plus fiable, améliorant ainsi la qualité globale de vos applications JavaScript.

Par exemple, pour le site Web de réservation de voyages que nous avons décrit plus tôt, si l'utilitaire tiers renvoie une promesse, nous pouvons la gérer comme ceci :

Une fois qu'une promesse est résolue (réalisée avec succès), elle le reste pour toujours — elle devient une valeur immuable à ce stade et peut ensuite être observée autant de fois que nécessaire. Cela signifie une promesse résolue, sa valeur résolue peut être consultée ou utilisée plusieurs fois dans votre code sans affecter son état. Cela vous permet de gérer le résultat de l'opération asynchrone dans différentes parties de votre application sans vous soucier de la modification ou de la réévaluation de la promesse.

Les promesses sont une solution pour l'inversion des problèmes de contrôle qui se produisent dans le code de rappel uniquement. Les rappels représentent une inversion de contrôle. Ainsi, l’inversion du modèle de rappel est en fait une inversion de l’inversion ou une désinversion du contrôle. Restaurer le contrôle du code appelant là où nous voulions qu'il soit en premier lieu.

Références

• Vous ne connaissez pas JS : Async & Performance par Kyle Simpson

• developer.mozilla.org

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!