web-dev-qa-db-fra.com

Angulaire: Http vs fetch api

Bien que je comprenne la façon dont Angular fait AJAX requêtes, je préfère utiliser l'API Fetch intégrée parce que je n'ai pas à m'abonner et à me désinscrire juste pour faire 1 demande simple. J'ai essayé de l'utiliser dans mon angular et elle n'a généré aucune erreur, la page n'a pas été rechargée (toujours un SPA), tout a bien fonctionné. Je suppose qu'il y a un temps et lieu pour tout.

Cette:

window.fetch('/api/get_post_by_id/1').then(r => r.json()).then(j => { console.log(j); });

Est plus simple que cela:

const obs = this.http.get('/api');
obs.subscribe(() => { ... });
obs.unsubscribe();

Fondamentalement, ma question est la suivante: est-ce mal d'utiliser l'API Fetch lors du développement d'applications Angular?

Merci!

javascriptangulartypescripthttp
8
ryanwaite28

Comme tout outil que vous rencontrez pendant le développement, chaque outil présente des avantages et des inconvénients et il est bon de réfléchir à la raison pour laquelle un outil est utilisé.

Lorsque nous jetons un œil à HttpClient, cela simplifiait à l'origine le gâchis qui était XMLHttpRequest. De la même manière que $.ajax L'a fait à l'origine, HttpClient était la "solution angulaire". Il a suivi l'idéologie de tout ce qui est un observable qui a des avantages (vous pouvez le mélanger et le faire correspondre avec d'autres observables) et des inconvénients (cela ajoute beaucoup de ballonnement).

Avantages de HttpClient

  • Il permet un mélange et une correspondance faciles de deux observables (par exemple, supposons que vous ayez un observable qui retourne plusieurs fois et une demande d'API qui retourne une fois et que vous souhaitiez compresser les deux ensemble, c'est trivialement facile à faire). Bien sûr, pour transformer une promesse en observable, il suffit d'importer from depuis rxjs
  • Si vous oubliez d'ajouter une abstraction - toutes les demandes passant par une couche apiService - vous pouvez toujours utiliser un intercepteur pour obtenir des résultats similaires par magie.
  • Cela augmentera la courbe d'apprentissage pour les nouveaux développeurs Angular, rendant ainsi votre travail plus spécial.
  • HttpClient fait de la magie pour vous, comme une nouvelle tentative automatique des requêtes.

Avantages de fetch

Important: Tout le code lié à la récupération suppose que vous créez une abstraction très simple (par exemple apiService dans ces exemples). Cela revient à configurer un intercepteur dans HttpClient- land.

  • C'est la nouvelle norme de l'industrie. Une fois que vous le savez, il peut être utilisé n'importe où (très probablement une fois Angular et React die - qui à un moment donné, il sera - fetch sera probablement encore là).
  • Il simplifie le travail avec les travailleurs du service car les objets Request et Response sont les mêmes que ceux que vous utilisez dans votre code normal.

  • Les requêtes HTTP retournent généralement une seule fois (bien sûr, vous pouvez charger un fichier morceau par morceau, mais c'est une exception très rare à la règle). fetch est construit autour de la norme (valeurs de retour uniques), pas de l'exception (plusieurs valeurs de retour), et retourne donc un Promise plutôt qu'un type de type flux. L'avantage qui en résulte est qu'il fonctionne bien avec toutes les nouvelles fonctionnalités linguistiques pertinentes telles que async et await. Comparer:

    try {
    const posts = await this.apiService.get('/posts');
    // work with posts
} catch (error) {
    // handle error
}
console.log('this happens after the request completes');

    avec

    this.http.get('/posts')
    .subscribe(posts => {
        // work with posts
    })
    .catch(error => {
        // work with error
    });
console.log('this happens before the request completes');

    (bien sûr, vous pouvez également toPromise chaque observable qui se terminera (ou ajouter .pipe(take(1)), mais c'est franchement un tas de code superflu (que j'utilise encore souvent)))

  • Il simplifie l'intégration de nouvelles personnes. Lorsque vous voyez une demande telle que

    this.apiService.get('/posts');

    un développeur de n'importe quel framework peut venir cliquer avec le bouton droit sur .get et vérifier la définition de la fonction où des éléments tels qu'un domaine et un en-tête d'authentification ajoutés seront clairement définis.

    D'un autre côté, quand un développeur voit

    this.http.get('/posts')

    Il n'a aucun moyen de découvrir facilement si et où la demande pourrait être modifiée à moins qu'ils ne connaissent la magie spécifique de Angular. C'est l'une des raisons pour lesquelles Angular est considéré comme ayant une courbe d'apprentissage abrupte.

  • Il n'y a aucun risque qu'il y ait de la magie dont vous n'êtes pas au courant, comme une nouvelle tentative automatique de requêtes qui peut se retrouver dans la même requête se déclenchant 4 fois sur le serveur et vous n'avez aucune idée de comment cela est possible.

Cravate complète

  • Je ne vois vraiment pas en quoi les types sont une différence, car la saisie d'une valeur de retour à partir de n'importe quelle méthode peut être effectuée. <Model>this.apiService.get('/posts') fonctionne parfaitement bien.

Conclusion

Personnellement, je recommanderais fortement à quiconque d'utiliser fetch avec une couche d'abstraction. Il en résulte un code plus facile à lire (même un junior qui n'a jamais vu async et await est capable de le lire) et même si vous êtes dans une situation rare où votre apiService doit revenir plusieurs fois, vous êtes toujours complètement libre de le faire, car vous avez le contrôle total. Et en général, vous ne devez pas utiliser la norme (fetch) si l'alternative offre des avantages significatifs. Même si c'était un lien parfait en termes d'avantages et d'inconvénients, cela ne vaut probablement pas la peine d'aller pour une solution "spécifique au cadre".

HttpClient ne semble tout simplement pas offrir d'avantages tangibles au-delà d'un gain de quelques minutes lors de la configuration initiale du projet où vous n'avez pas besoin de configurer une couche d'abstraction pour les demandes d'API.

4
David Mulder
this.http.get('/api').subscribe(j => console.log(j));

Vous l'avez rendu trop compliqué, c'est tout ce dont vous avez besoin et c'est similaire au code que vous avez pour window.fetch. Vous pouvez utiliser la version générique et elle sera tapée dans l'interface attendue, ce qui la rendra encore plus facile.

this.http.get<IModel>('/api').subscribe(j => console.log(j));

Il n'y a pas besoin de unsubscribe et vous n'avez besoin de pipe + map que si vous voulez transformer le résultat au préalable. L'appel de json() était requis pour le "vieux" HttpModule qui a été remplacé par ( techniquement étendu par ) HttpClient à partir de la version 4.3

Et si vous préférez toujours Promise à un Observable, vous pouvez toujours appeler toPromise().

this.http.get('/api').toPromise().then(j => console.log(j));

Voir aussi HttpClient

est-il incorrect d'utiliser l'API Fetch lors du développement d'applications Angular?

Ce n'est pas faux mais il y a des raisons de ne pas le faire. Vous pouvez injecter HttpClient et écrire des tests unitaires complets pour divers scénarios, URL, verbes Http, etc. Faire de même si vous avez utilisé window.fetch Tout au long de votre code devient beaucoup plus difficile. HttpClient est également plus riche en ce que vous pouvez utiliser le système de type pour vos résultats. Les objets observables sont également plus riches en fonctionnalités que les promesses, ce qui peut être utile dans des scénarios plus complexes comme le séquencement des appels lors de la gestion de plusieurs microservices ou l'annulation d'un appel si une entrée utilisateur supplémentaire est reçue.

Il y a donc plusieurs raisons d'utiliser le HttpClient et je ne peux pas penser à une seule, à part que c'est une petite courbe d'apprentissage.

7
Igor