web-dev-qa-db-fra.com

Comprendre ce que crée Axios

On m'a demandé de faire un appel API pour envoyer des données.

Sur Click in vue, je tirais cet événement

async facebookDataToSend () {
  let campaignID = await this.$store.getters['CurrentInstance/id']
  this.$axios.post(process.env.API_BASE_URL + 'faceeBookCampaign', { campaignID: campaignID }, { withCredentials: true })
},

Mais ensuite, on m'a dit d'utiliser des fonctions API qui existent déjà dans certains fichiers xyz.js.

Mon fichier xyz.js ressemble à ceci ..

const rest = {
  something: axios.create({
    baseURL: process.env.API_BASE_URL,
    withCredentials: true
  }),
  setClient: function (client) {
    this.something = axios.create({
      baseURL: process.env.API_BASE_URL,
      withCredentials: true,
      params: {
        __somethingClient: client
      }
    })
    this.client = client
  }
}

Ici, je ne peux pas comprendre comment puis-je utiliser cette instance pour faire un appel api J'ai donc vu le code où ils ont déjà fait l'appel api et vu quelque chose comme ça

const API = {
  url: '/whateverHtml/',
        method: 'post',
        withCredentials: true,
        data: {
          'schemaType': 'something-event', // TODO FIXME
          'field': 'description', // TODO FIXME
          'html': this.model[this.field.key]
        }
api.something.request(API).then(result => {

Et je n'ai pas pu comprendre le code. Pour commencer

Qu'est-ce que la demande? Je ne vois aucune méthode ni propriété dans something dans ma variable rest

deuxième pourquoi utilisent-ils withCredentials: true dans leur API objet alors qu'ils ont déjà configuré la propriété comme true dans rest object]

Quels sont les avantages de l'utilisation de axios.create({ c'est-à-dire ce qu'ils font que ce que j'ai fait au départ this.$axios.post(

javascriptvue.jsaxiosquasar
3
anny123

request est une méthode définie par axios. Lien vers docs .

request vous permet de faire un appel HTTP avec le verbe de votre choix (POST, GET, DELETE, PUT). Axios appelle probablement request depuis toutes les autres méthodes d'assistance (get, post), mais il s'agit d'un détail d'implémentation. L'un des avantages de l'utilisation de request est que vous n'avez pas à coder en dur le verbe HTTP (POST, GET ...) et que vous pouvez le définir au moment de l'exécution en fonction de votre entrée.

Je vois 2 raisons pour lesquelles ils définiraient withCredentials:

  • setClient peut être appelé ou non avant something
  • pour plus de clarté: il suffit de regarder la définition de something pour se rendre compte que le client utilise des informations d'identification et vous n'avez pas besoin d'informations supplémentaires sur le fonctionnement de rest.

Je ne pense pas que la demande d'utilisation de something se résume aux avantages de axios.$post contre axios.create. C'est probablement plus lié à la façon d'organiser votre code.

Quelques avantages d'utiliser un module séparé par rapport à l'appel direct de axios

  • lorsque vous appelez directement axios, vous ajoutez constamment l'url de base, lorsque vous utilisez un module pour votre REST, l'URL de base est cachée et facilite sans doute la lecture de votre code
  • vous pouvez créer d'autres options dans config et vous assurer qu'elles sont utilisées. Par exemple, vous pouvez avoir un jeton d'accès, le module peut stocker ce jeton et toujours ajouté à toute demande. Lorsque vous appelez axios à la main, vous devez vous en souvenir
  • vous êtes découplé des axios (dans une certaine mesure) (1). Lorsque vous utilisez un module, vous ne vous souciez pas vraiment si ce sont des axios qui font les requêtes ou non.
  • Vous pouvez ajouter plus d'appels d'API au module que vous pourrez réutiliser à l'avenir. Je m'attends à ce que le fichier xyz grandisse dans le temps et que votre appel à faceeBookCampaign finisse par être une méthode sur la variable rest. Il est plus logique de finir par utiliser this.client et non something mais cela dépend des développeurs.
  • il conserve tous les appels à l'API REST en un seul endroit, ce qui vous permet de créer un SDK pour cette API qui, au fur et à mesure de la croissance du projet, peut avoir son propre cycle de vie.

(1) Je dis que l'ID vous dissocie dans une certaine mesure car il y a une sémantique qui doit être conservée pour que tout fonctionne. L'objet renvoyé doit avoir une méthode de demande qui accepte un objet de configuration. La configuration doit se conformer à la même structure que celle souhaitée par axios. Mais, vous pouvez toujours écrire un adaptateur pour cela, donc vous êtes en fait découplé des axios.

2
Radu Diță

request prend ici une configuration et retourne une promesse. Je suppose que cette approche est généralement adoptée lorsque vous souhaitez réutiliser un objet de demande créé à l'aide de create (du moins à mon sens).

Je pense que la méthode request est utilisée pour remplacer la configuration initiale par une nouvelle définie dans API. Et, le double withCredentials devrait être un oubli. OU, parce que l'API définit un nouvel objet de configuration, donc lorsqu'il est défini sans withCredentials, il écraserait la configuration de create.

Par conséquent, il ressemble à son spécifié deux fois.

0
tyskr