Promise et Fetch

Introduction

Dans les différentes spécifications web, nous avons accès à plusieurs interfaces de type worker. Certaines d’entre elles permettent d’exécuter des actions en tâche de fond : ce sont les web workers. D’autres nous donnent la possibilité de faire communiquer différents contextes de navigation : ce sont les shared workers.

Comme indiqué au chapitre Introduction, la brique primordiale à mettre en place est un fichier JavaScript nommé Service Worker que nous devons créer et implémenter. Utile à la fois pour gérer le mode hors connexion de l’application et pour réceptionner des messages push, ce fichier n’aura aucun impact direct sur le code applicatif.

L’une des plus grandes différences entre ce nouveau fichier JavaScript et ceux de l’application, c’est sa durée de vie. En effet, il est actif indépendamment du reste de l’application. Il est par exemple fonctionnel même si l’utilisateur ferme l’onglet affichant l’application. Grâce à cela, nous pouvons réengager l’utilisateur, l’inviter à revenir sur l’application en la réveillant via une notification, par exemple. Cela ne veut pas dire que le fichier restera actif ad vitam aeternam ; il se terminera de lui-même si le navigateur détecte...

Objet Promise

1. Présentation

Lors de l’écriture d’une application JavaScript, quel que soit le framework ou la librairie utilisé, la gestion de l’asynchronisme est primordiale pour, par exemple, envoyer une requête HTTP, lire un fichier ou encore tout simplement écouter l’événement click sur l’un des boutons d’une page HTML. Pour cela, l’une des premières solutions est d’utiliser des callbacks.

Dans l’exemple ci-après, la méthode readFile de Node.js permettant de lire un fichier est utilisée. La fonction, passée en paramètre, est appelée une fois la lecture du fichier terminée. Tous les callbacks des API de Node.js respectent la même signature : l’éventuelle erreur comme premier paramètre, suivi du résultat du traitement asynchrone.

const fs = require('fs'); 
const pathToFile = process.argv[2]; 
 
fs.readFile(pathToFile, (err, data) => { 
  if(err){ 
    console.error(err); 
    return; 
  } 
  console.log(data.toString()); 
}) ;

Mais il résulte de cette syntaxe un inconvénient majeur quand nous exécutons plusieurs fonctions asynchrones les unes à la suite des autres. Le niveau d’imbrication qui en découle complexifie la lisibilité du code. Nous arrivons rapidement à la syntaxe que nous avons l’habitude d’appeler une callback hell.

Dans l’exemple suivant, nous lisons trois fichiers séquentiellement. La lecture de ce code se complexifie à chaque callback ajouté.

 const fs = require('fs'); 
const pathToFile = process.argv[2]; 
 
fs.readFile(pathToFile, (err, data1) => { 
  if(err){ 
     console.error(err); 
     return; 
  } 
 
  fs.readFile(data1.toString(), (err, data2) => { 
     if(err){ 
        console.error(err); 
        return; 
     } 
     fs.readFile(data2.toString()...

API Fetch

Lorsque nous développons une application JavaScript, il y a de fortes chances que nous ayons besoin de récupérer des données depuis le serveur via une API REST. L’API JavaScript Fetch est basée sur l’objet Promise présenté précédemment. Elle permet d’envoyer des requêtes HTTP vers un serveur. Nous pouvons définir cette API comme le successeur de XMLHttpRequest que nous utilisions au bon vieux temps.

Dans l’exemple suivant, nous envoyons une requête vers https://mon-serveur/api/books en utilisant l’objet JavaScript XMLHttpRequest. Cette requête utilise le verbe HTTP GET. Si le statut HTTP de la réponse est égal à 200, nous affichons le corps de la réponse, grâce à la propriété responseText, sinon nous faisons appel à la méthode console.error.

const req = new XMLHttpRequest(); 
req.open('GET', 'https://mon-serveur/api/books', false); 
req.send(null); 
 
if (req.status === 200) { 
  console.log(req.responseText); 
} else { 
  console.error(req.status); 
}

Si nous souhaitons par exemple envoyer exactement la même requête en utilisant l’API Fetch, nous pouvons écrire l’appel suivant :

fetch('https://mon-serveur/api/books');

La méthode...

Application fil rouge

À l’heure actuelle, les données affichées dans l’application sont définies directement dans le code de l’application. Nous allons à présent faire une requête HTTP permettant de récupérer le jeu de données et ainsi générer l’interface graphique en fonction de son contenu.

Pour le moment, la donnée que nous manipulons afin de construire la page est définie directement dans le code source de l’application, dans le fichier script.js. En effet, dans ce fichier figure une variable json contenant une liste de repositories GitHub. Chaque objet de ce tableau respecte la structure des objets retournés par l’API GitHub.

const json = [ ... ] ;

Nous itérons ensuite sur ce tableau, afin de générer le rendu HTML. L’utilisation des données est réalisée dans la méthode generateUI.

document.addEventListener("DOMContentLoaded", function() { 
  generateUI(json); 
});

À la place de cette variable json, nous allons à présent faire une requête vers l’API de GitHub pour récupérer les vraies données.

Pour commencer, nous supprimons la variable json.

Ensuite, lors de l’événement DOMContentLoaded, nous faisons une requête vers l’API de GitHub en utilisant le endpoint...