Comprendre pourquoi Fetch nécessite d'attendre deux fois✨

L'API fetch de JavaScript est largement utilisée pour effectuer des requêtes HTTP, mais il peut être un peu difficile de comprendre pourquoi elle nécessite parfois deux instructions d'attente. Si vous avez déjà travaillé avec fetch, vous avez peut-être rencontré un code comme celui-ci :

const response = await fetch('https://api.example.com/data');
const data = await response.json();

Décomposons cela et comprenons pourquoi ce modèle est nécessaire. ?

Le processus de récupération en deux étapes ?️

L'API fetch est conçue pour gérer les requêtes réseau de manière asynchrone, mais son comportement est divisé en deux étapes principales :

1. Récupérer la réponse ?

   • Lorsque vous appelez fetch, il renvoie une promesse qui se résout en objet Response une fois la requête réseau terminée.
   • Cette étape ne traite pas le corps de la réponse ; cela garantit uniquement que la demande a abouti et que les en-têtes sont disponibles.

2. Lecture du corps de réponse ?

   • L'objet Response a des méthodes telles que .json(), .text() et .blob() pour lire le contenu réel.
   • Ces méthodes renvoient également des promesses car la lecture du corps est asynchrone. Ceci est nécessaire pour gérer efficacement des charges utiles volumineuses sans bloquer le thread principal.

Que se passe-t-il pendant la première attente ? ⏳

Lorsque vous écrivez const réponse = wait fetch(url);, voici ce qui se passe :

1. Demande réseau envoyée : ?

   • Le navigateur initie une requête HTTP vers l'URL spécifiée.
   • Cela implique de résoudre le nom de domaine, d'établir une connexion TCP et d'envoyer les en-têtes et le corps HTTP (pour les requêtes POST).

2. Métadonnées de réponse reçues : ?

   • L'appel de récupération est résolu une fois que le serveur répond avec la ligne d'état (par exemple, HTTP/1.1 200 OK) et les en-têtes. À ce point:
     • Le statut (par exemple, 200, 404 ou 500) et le texte d'état (par exemple, « OK » ou « Not Found ») sont disponibles.
     • Les en-têtes de réponse tels que Content-Type, Content-Length et tous les en-têtes personnalisés envoyés par le serveur sont accessibles.

3. Objet de réponse créé : ?️

   • Le navigateur construit un objet Response qui contient des métadonnées sur la réponse. Cela comprend :
     • En-têtes : Accessible via Response.headers, qui vous permet d'inspecter des en-têtes spécifiques comme Content-Type ou Authorization.
     • Corps : À ce stade, le corps n'a pas été entièrement lu ou analysé : il reste sous forme de flux lisible.

Par exemple, si le serveur renvoie :

   HTTP/1.1 200 OK
   Content-Type: application/json
   Content-Length: 123

   {"message": "Hello, world!"}

L'objet Réponse contiendra :

• statut : 200 ✅
• statusText : "OK" ✅
• en-têtes : une collection itérable d'en-têtes de réponse (par exemple, Content-Type : application/json).
• body : Un flux lisible qui n’a pas encore été analysé.

Que se passe-t-il pendant la deuxième attente ? ?

Lorsque vous écrivez const data = wait réponse.json();, les étapes suivantes se produisent :

1. Lire le flux corporel : ?

   • Le corps de la réponse (toujours sous forme brute) est lu comme un flux. Selon la méthode que vous utilisez, les données brutes sont traitées en conséquence :
     • .json() : analyse le flux au format JSON et renvoie un objet JavaScript.
     • .text() : lit le flux sous forme de chaîne de texte brut.
     • .blob() : lit le flux comme un grand objet binaire.

2. Analyse et résolution : ?

   • La méthode json() analyse les données brutes (par exemple, {"message": "Hello, world!"}) en un objet JavaScript utilisable (par exemple, { message: "Hello, world!" }).
   • Ce processus d'analyse est asynchrone car il implique le traitement de données potentiellement volumineuses.

3. Promesse Résolution : ✅

   • La promesse renvoyée par réponse.json() est résolue en données analysées, qui peuvent ensuite être utilisées dans votre application.

Pourquoi deux instructions wait sont nécessaires ?

Voici la raison pour laquelle vous devez attendre deux fois :

1. Première attente (En attente de la réponse) :

   • L'appel de récupération ne fournit pas immédiatement les données de réponse ; cela vous donne une promesse. Vous devez l'attendre pour obtenir l'objet Response.

2. Deuxième attente (analyse du corps) :

   • La méthode .json() (ou d'autres méthodes de lecture du corps) renvoie une autre promesse. Vous devez attendre cela pour extraire le contenu analysé.

Si vous ignorez l'attente, vous vous retrouverez probablement avec un comportement inattendu :

• Sauter la première attente : Vous travaillerez avec la promesse non résolue au lieu de l'objet Response réel.
• Sauter la deuxième attente : Vous obtiendrez une promesse au lieu des données analysées.

Exemple avec gestion des erreurs ?️

Voici comment gérer correctement les erreurs lorsque vous travaillez avec fetch :

const response = await fetch('https://api.example.com/data');
const data = await response.json();

Pièges courants ⚠️

1. Ne gère pas les erreurs :

   • fetch ne génère pas d'erreur pour les erreurs HTTP telles que 404 ou 500. Vous devez vérifier manuellement réponse.ok ou réponse.status.

2. Sauter la deuxième attente :

   • Oublier d'attendre .json() peut entraîner des bugs lorsque vous travaillez avec une promesse au lieu de données réelles.

3. Confusion entre la récupération et les API plus anciennes :

   • Les développeurs passant d'anciennes API comme XMLHttpRequest peuvent s'attendre à un comportement synchrone, mais la récupération est entièrement basée sur la promesse.

Conclusion ?

Utiliser deux instructions wait avec fetch peut sembler redondant au début, mais c'est le résultat logique de sa conception asynchrone. La première attente garantit que la réponse a été reçue, y compris les en-têtes et les métadonnées, tandis que la seconde attente traite le corps de la réponse. Comprendre ce flux vous aide à écrire du code asynchrone plus fiable et plus maintenable. ?

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!