Qu'utilisiez-vous avant l'apparition de Promise?

Avant l'apparition de Promise, les callbacks étaient largement utilisés.

L'essence des callbacks :

Une fonction est passée à une autre en tant qu'argument et s'exécute après la fin d'une opération spécifique.

Exemple :

// Exemple d'appel à une opération asynchrone avec callback
function fetchData(callback) {
  setTimeout(() => {
    const data = "Des données";
    callback(null, data); // Le premier argument est une erreur, le second est le résultat
  }, 1000);
}

fetchData((err, data) => {
  if (err) {
    console.error("Erreur lors de la récupération des données:", err);
  } else {
    console.log("Données reçues:", data);
  }
});

Inconvénients de l'utilisation exclusive des callbacks :

• Callback Hell (Enfer des callbacks) : La chaîne d'opérations asynchrones imbriquées conduit à un code très imbriqué et difficile à lire.
• Difficultés dans la gestion des erreurs : Il faut passer et vérifier les erreurs à chaque niveau d'imbrication.
• Absence d'une approche standardisée : Différentes bibliothèques pouvaient utiliser différentes conventions pour les callbacks.

Approches alternatives avant Promise :

Avant l'apparition de Promise, en plus des callbacks "purs", on utilisait des bibliothèques et des modèles pour gérer l'asynchronie, tels que :

• Bibliothèques asynchrones : Par exemple, async (pour Node.js, mais aussi utilisable dans le navigateur). Offraient des utilitaires pour gérer les flux asynchrones (exécution parallèle, exécution séquentielle).
• Modèle Publisher/Subscriber (Pub/Sub) : Pour des scénarios d'interaction plus complexes.
• Émetteurs d'événements : Dans Node.js et dans l'environnement navigateur (par exemple, EventEmitter).

Cependant, les callbacks restaient la base pour de nombreuses opérations asynchrones. Promise a fourni une manière plus structurée, unifiée et lisible de travailler avec l'asynchronie, éliminant de nombreux problèmes du "Callback Hell".