Des rappels ou des promesses pour une nouvelle bibliothèque javascript côté client?

Question

Depuis 2017, toutes les versions actuelles des navigateurs Web prennent en charge les promesses ES6.

Si je devais maintenant créer une bibliothèque javascript côté navigateur, quels sont les avantages et les inconvénients (ou des considérations connexes) de l'utilisation de fonctions de style de rappel par rapport à l'utilisation de promesses? Est-ce toujours une option d'envisager d'utiliser des rappels?

Remarque: les opérations de la bibliothèque étant liées aux E/S, les opérations asynchrones s'intègrent bien, donc je ne pense pas que les opérations synchrones soient une option.

Answer 1

Eh bien, vous devriez bien sûr utiliser des promesses. C'est juste un cadre conceptuel bien meilleur pour gérer les choses asynchrones. Si vous ne le faites pas, la première chose que feront 90% de vos utilisateurs est d'envelopper vos API de toute façon, et vous ne voulez pas les faire faire ça, n'est-ce pas?

En théorie, vous pouvez adopter l'approche bimode consistant à avoir la présence ou l'absence d'un paramètre callback pour contrôler si une API particulière se comporte en mode rappel ou en mode promesse. De nombreuses bibliothèques ayant des racines dans les jours avant la promesse prennent cette route. Il est douteux que vous vouliez adopter cette approche pour une nouvelle bibliothèque.

Vous pouvez envoyer votre bibliothèque avec la possibilité d'intégrer une bibliothèque de promesses au choix de l'utilisateur, au cas où il n'aime pas, ou ne peut pas utiliser, des promesses natives. L'utilisateur initialise votre bibliothèque avec quelque chose comme initNcasasLibrary(Promise). Ou vous pouvez simplement demander à votre utilisateur de vous assurer que Promise est disponible en veillant à inclure un polyfill s'il cible les navigateurs qui ne l'ont peut-être pas.