web-dev-qa-db-fra.com

Y at-il des raisons d’utiliser axios à la place de ES6 fetch

J'ai étudié la documentation d'axios et d'ES6 fetch que les deux sont assez similaires et ont subi une forte influence de $ .ajax et de ses raccourcis.

Le principal avantage d’axios est la prise en charge du navigateur.

Ai-je raison de dire que si j'utilise babel-polyfill - il n'y a aucune raison d'utiliser axios?

javascriptecmascript-6axios
23
Sasha Kos

Quelques raisons d'utiliser Axios sur Fetch:

  1. Capacité à suivre les progrès de la demande

C'est plus une question entre XMLHttpRequest (qui alimente axios) ou Fetch API.

Fetch API ne fournit actuellement aucun moyen d’être averti de la progression de la demande, une fonctionnalité qui alimente le mécanisme de retour d’information pour les téléchargements de fichiers volumineux, par exemple.

Axios, de son côté, intègre cette fonctionnalité:

axios.post('/api', data, {
    onUploadProgress: ({ total, loaded }) => {
        // update progress
    }),
})
  1. La gestion des erreurs

Lorsque votre système retourne le code de réponse 500 Internal Server Error, fetch ne le traitera pas différemment de 200 OK.

Ceci est un inconvénient dans la plupart des cas puisque toutes vos hypothèses précédentes sur ce à quoi une réponse ressemblerait ne sont plus valides.

Le plus souvent, lorsque vous recevez une réponse erronée du serveur, vous souhaitez interrompre le pipeline de traitement dès que possible et passer à un cas de traitement d'erreur.

fetch(url)
    .then(reponse => {
        if (!(status >= 200 && status < 300)) {
            return Promise.reject(new Error("Invalid response status"));
        }

        return response;
    })
    .then(response => response.json())
    .then(/* normal processing */)
    .catch(/* error handling */);

Ce n'est pas difficile à faire, mais vous voudrez probablement capturer cette logique sous une certaine abstraction pour éviter les répétitions, ce qui nous rapproche encore plus de l'abstraction des API Web, Axios.

Axios agit de manière saine et rejette la promesse si la réponse renvoie un statut erroné. Ce comportement est personnalisable comme le sont la plupart des choses avec axios.

  1. Essai

Axios a moxios , chercher a fetch-mock .

Ces deux bibliothèques sont excellentes, mais selon mon expérience, fetch-mock Nécessitait une configuration supplémentaire pour que Jest utilise une récupération fictive par rapport à une version polyfilled.

J'aime aussi le fait que moxios.wait() renvoie une promesse qui sera résolue après la mise en correspondance de la demande.

  1. Autres fonctionnalités offertes par Axios

Par exemple, vous pouvez configurer un intercepteur qui ajoutera une clé api à tous les paramètres de requête ou surveillera les requêtes actives pour afficher un écran de chargement.

Les raisons d’utiliser une option plutôt que l’autre peuvent varier selon les besoins réels.

Si vous devez surveiller les progrès, utilisez Axios (ou XMLHttpRequest).

Si vous écrivez un opérateur de service, utilisez Fetch.

Sinon, utilisez ce qui vous convient le mieux.

29
mpontus

Cette:

fetch('https://jsonplaceholder.typicode.com/posts', {
    method: 'POST',
    body: JSON.stringify({
      title,
      body
    })
  }).then((res) => {
    if (res.ok) {
      return res.json()
    }

    throw new Error(res.responseText);

  })
  .then((data) => console.log(data))
  .catch((err) => console.log(err))

peut essentiellement être exprimé par axios avec ceci:

axios.post('https://jsonplaceholder.typicode.com/posts', {
    title,
    body
  }).then((data) => console.log(data))
  .catch((err) => console.log(err))

Donc en substance:

  1. Pas besoin de faire res.json(), res.text() etc
  2. Pas besoin de manipuler res.ok Pour intercepter des erreurs de statut non 200 dans la promesse réelle catch gestionnaire.
  3. Inutile de formaliser la charge utile, elle est gérée par défaut par axios.

Dans l’ensemble, axios est plus simple et plus simple à utiliser, du point de vue de la conception, pour la gestion des demandes.

12
Karen Grigoryan