fetch : La fin de $.ajax()

Dans le lot d'améliorations et de nouveautés apportées par ES2015 il y a la méthode fetch. On va y consacrer cet article.

La méthode fetch est une nouvelle façon de faire des appels AJAX en Javascript. Vous pouvez vous dire que l'on peut faire de l'AJAX depuis bien longtemps en Javascript et que ça marche très bien.

Vous avez raison ! Mais le but de cette méthode est de simplifier le développement, d'améliorer les performances et l'expérience utilisateur.

Avant EcmaScript 2015

Les méthodes pour faire de l'AJAX avant ES2015 sont XMLHttpRequest, $.ajax et quelques autres méthodes customs similaires utilisant XMLHttpRequest en interne.

Prenons en exemple la récupération d'une simple page HTML, sans gestion d'erreur.

Avec XMLHttpRequest :

let req = new XMLHttpRequest()
let res = ''
req.open('GET', 'https://mindsers.blog/', true)
req.onreadystatechange = (e) => {
  if (req.readyState === 4) {
     if(req.status === 200) {
      res = `Web page: ${req.responseText}`
     }
  }
}
req.send(null)

Le même exemple avec jQuery :

let res = ''
$.ajax('https://mindsers.blog/')
.done((msg) => {
  res = `Web page: ${msg}`
})

jQuery, vaillant compagnon du développeur JS pendant des années, a beaucoup simplifié l'utilisation de l'AJAX.

Notre problème avec jQuery c'est qu'il prend de la place et quand une ressource prend de la place, elle prend aussi du temps à se charger, consomme de la data, etc... Bref, dans le monde du web front, soit mince ou soit indispensable.

fetch, le $.ajax natif

Le $.ajax est bien, il est la réponse de la communauté à des problématiques précises. Le XMLHttpRequest était complexe, verbeux et générait du code dupliqué.

$.ajax fait partie de la library jQuery. Et le but premier et unique de jQuery et de pallier aux faiblesses de Javascript pour le rendre plus simple et accessible (gestion de la rétro compatibilité, surcharge du langage, etc).

Lors de l'implémentation d'ES2015, Ecma International s'est appuyé sur ce qu'a fait la communauté pendant ces dernières années pour proposer des solutions natives. fetch en est l'exemple.

fetch fait des promesses

fetch respecte la norme des Promises. Elle en retourne une pour vous fournir le résultat attendu.

let result = ''
fetch('https://mindsers.blog/')
  .then(res => res.text()) // on récupère le corps au format text. 
  .then(text => {
    result = `Web page: ${text}`
  })

Sous sa forme promesse, fetch ressemble beaucoup à $.ajax dans son utilisation. Je noterais quand même que le code est ici beaucoup plus formalisé, propre.

Dans des cas plus complexes de traitement des données reçues, on appréciera le formalisme de fetch. Et surtout sa simplicité.

fetch avec async/await

fetch ne vous a pas encore tout dit. Vous n'êtes pas obligé de l'utiliser avec des promesses.

Certains ne se sont toujours pas fait à l'asynchronicité de Javascript. Ecrire du code qui ne va pas forcément s'exécuter dans l'ordre où on l'a écrit peut être troublant pour beaucoup d'entre nous.

Grâce aux mots clés async et await, vous allez pouvoir écrire du code asynchrone comme s'il s'agissait de code synchrone à l'intérieur de votre fonction notée async.

async function getPage(url) {
  let res = await fetch(url)
  let text = await res.text()
  return text
}

getPage('https://mindsers.blog/').then(result => {
  console.log(result)
})

Le mot clé await indique que je veux attendre le résultat du fetch avant de passer à l'instruction suivante.

La fonction getPage() étant notée comme asynchrone, elle retourne automatiquement une promise contenant votre valeur de retour.

Attention : les mots clés async et await ne font pas partie de la specification ES2015 mais de celle de ES2016

Pourquoi passer à fetch ?

J'ai envie de vous dire: "Pourquoi pas ?". C'est un peu juste comme conclusion ? Ok.

On a déjà évoqué l'intérêt d'avoir des solutions natives aux problèmes que nous rencontrons en front. Il en va des performances de notre application. Une solution aussi efficace en natif que celle apportée par une librairie tierce doit donc être privilégiée.

Pour rappel :

moins de temps de transfert (server -> client)
moins de temps d'exécution
simplicité d'utilisation similaire
pas de problème de mise à jour de dépendances

Et puis au-delà de ça, il faut toujours préférer apprendre le langage plutôt que les frameworks. Surtout dans un écosystème changeant comme Javascript en ce moment. Un framework ou une librairie aura toujours une durée de vie inférieure au langage sur lequel il est basé.

Avec des connaissances du langage vous pourrez toujours changer de librairie au besoin.

Je pousse clairement à l'apprentissage du pur JS, car je trouve que trop de gens connaissent jQuery sans connaitre Javascript. C'est désolant, mais on s'éloigne du sujet de cet article...