ReactJS: După adăugarea pluginului Chrome CORS, respingerea netratată (TypeError) nu a putut fi preluată

Gestionarea erorilor API în React: provocări pentru pluginul CORS

Când lucrați cu API-uri în ReactJS, dezvoltatorii se confruntă adesea cu diverse provocări legate de preluarea datelor, în special atunci când au de-a face cu API-uri terțe. O problemă comună care apare este eroarea „Respingere netratată (Eroare de tip): Preluare eșuată”. Această eroare poate apărea chiar și atunci când se utilizează API-uri populare, cum ar fi API-ul Swiggy’s restaurant list, pe care mulți dezvoltatori îl folosesc pentru a-și îmbunătăți aplicațiile web.

În acest caz, adăugarea unei extensii CORS Chrome poate părea o soluție viabilă pentru a ocoli politicile restrictive ale browserului. Cu toate acestea, poate introduce noi complicații în loc să rezolve problema. Dacă utilizați un plugin CORS în mediul dvs. de dezvoltare, iar solicitările dvs. API eșuează la scurt timp după încărcare, s-ar putea să întâmpinați o problemă în care pluginul intră în conflict cu comportamentul de gestionare a cererilor al browserului.

Înțelegerea modului de gestionare a cererilor de origine încrucișată și de depanare erori CORS în ReactJS este esențial pentru un proces de dezvoltare fără probleme. API-urile precum Swiggy au adesea straturi de securitate, cum ar fi CORS, pentru a controla accesul de la clienții neautorizați. Aceste restricții pot duce la erori care trebuie abordate în mod corespunzător.

În acest ghid, vom explora de ce apare această eroare, în special după adăugarea unui plugin CORS în Chrome. Vom discuta, de asemenea, strategii pentru a o rezolva în timp ce lucrăm cu API-ul Swiggy în dvs Reacţiona aplicatii.

Explicarea soluțiilor pentru problemele CORS în React with Swiggy API

În prima soluție, am creat un Node.js backend folosind Express pentru a ocoli problema CORS atunci când preiau datele restaurantului din API-ul Swiggy. Politica CORS împiedică browserele să facă cereri către un alt domeniu, cu excepția cazului în care acel domeniu o permite. Prin crearea unui server simplu, putem acționa ca un strat mijlociu între client și API, preluând partea serverului de date și returnând-o la front-end-ul React. Această metodă evită erorile CORS, deoarece cererea provine din aceeași origine ca și aplicația client.

Backend-ul Express setează anteturi personalizate, în special Acces-Control-Permite-Origine, care permite clientului nostru să solicite resursele fără a se confrunta cu restricțiile CORS. Apelul de preluare la API-ul lui Swiggy se face pe partea serverului, iar datele sunt returnate în format JSON. Această abordare este adesea considerată mai sigură și mai performantă în mediile de producție, deoarece ascunde cheile API sau informațiile sensibile. În plus, utilizarea try-catch asigură gestionarea corectă a erorilor, afișând mesaje de eroare ușor de utilizat dacă API-ul nu răspunde.

În a doua soluție, modificăm cererea de preluare pe codul React de la partea clientului. Această metodă implică adăugarea antetelor personalizate în apelul de preluare, asigurându-se că cererea este formatată corect înainte de a ajunge la API. Folosim React's useEffect cârlig pentru a declanșa apelul API atunci când componenta se montează. Funcția asincronă așteaptă răspunsul API, îl convertește în JSON și gestionează erorile dacă solicitarea eșuează. Cu toate acestea, această soluție se confruntă în continuare cu probleme CORS dacă API-ul nu permite solicitări de origine încrucișată de la browsere direct.

În cele din urmă, în a treia soluție, folosim un serviciu terță parte numit CORS-Anywhere. Acesta este un serviciu middleware care ajută temporar la ocolirea restricțiilor CORS prin redirecționarea cererii API prin serverul lor. Deși această soluție poate funcționa în medii de dezvoltare, nu este recomandată pentru producție din cauza riscurilor de securitate și a dependenței de servicii externe. De asemenea, introduce o suprasarcină de performanță, deoarece adaugă un strat suplimentar procesului de preluare a datelor. Utilizarea acestei metode poate fi convenabilă în timpul fazelor de testare, dar ar trebui evitată în producție din motive de securitate.

const express = require('express');
const fetch = require('node-fetch');
const app = express();
const port = 5000;

app.use((req, res, next) => {
  res.setHeader('Access-Control-Allow-Origin', '*');
  res.setHeader('Access-Control-Allow-Methods', 'GET');
  next();
});

app.get('/restaurants', async (req, res) => {
  try {
    const response = await fetch('https://www.swiggy.com/dapi/restaurants/list/v5?lat=23.1685786&lng=79.9338798');
    const data = await response.json();
    res.json(data);
  } catch (err) {
    res.status(500).json({ error: 'Failed to fetch restaurants' });
  }
});

app.listen(port, () => {
  console.log(`Server running on http://localhost:${port}`);
});

import React, { useEffect } from 'react';

const Body = () => {
  async function getRestaurants() {
    try {
      const response = await fetch(
        'https://www.swiggy.com/dapi/restaurants/list/v5?lat=23.1685786&lng=79.9338798',
        { headers: { 'Content-Type': 'application/json' } }
      );

      if (!response.ok) {
        throw new Error('Network response was not ok');
      }

      const data = await response.json();
      console.log(data);
    } catch (error) {
      console.error('Fetch error:', error);
    }
  }

  useEffect(() => {
    getRestaurants();
  }, []);
};

export default Body;

const Body = () => {
  async function getRestaurants() {
    try {
      const response = await fetch(
        'https://cors-anywhere.herokuapp.com/https://www.swiggy.com/dapi/restaurants/list/v5?lat=23.1685786&lng=79.9338798'
      );

      const data = await response.json();
      console.log(data);
    } catch (error) {
      console.error('Error fetching restaurants:', error);
    }
  }

  useEffect(() => {
    getRestaurants();
  }, []);
};

export default Body;

Depanarea problemelor CORS în solicitările API

Unul dintre motivele care stau la baza erorii „Preluare eșuată” într-o aplicație React, în special atunci când se utilizează API-uri terță parte, cum ar fi Swiggy, este CORS restricții (Partajarea resurselor între origini). CORS este o caracteristică de securitate care restricționează aplicațiile web să facă cereri către un alt domeniu decât cel de la care au fost deservite. În acest caz, API-ul Swiggy respinge cererea deoarece provine dintr-un domeniu diferit (aplicația dvs. React). Acest lucru este deosebit de problematic atunci când preluați date de la API-uri care nu acceptă în mod explicit solicitările de origine încrucișată.

O soluție comună este utilizarea extensiilor de browser, cum ar fi extensia Chrome „Permiteți CORS”. Cu toate acestea, astfel de extensii pot duce la rezultate inconsecvente. Acest lucru se datorează faptului că manipulează setările la nivel de browser care nu se sincronizează întotdeauna corect cu solicitările API. În mod ideal, aceste plugin-uri ar trebui utilizate numai pentru dezvoltare și nu în medii de producție. Pentru producție, o abordare mai sigură și mai fiabilă ar fi utilizarea unui server proxy backend care solicită datele în numele aplicației dvs. React, așa cum se vede în soluțiile furnizate mai devreme.

Un alt aspect de luat în considerare este gestionarea eficientă a erorilor. În timp ce problemele CORS sunt o cauză obișnuită a erorilor „Preluare eșuată”, alți factori, cum ar fi instabilitatea rețelei, adresele URL incorecte ale API sau timpul de nefuncționare al serverului, ar putea duce, de asemenea, la această eroare. Prin urmare, este important să implementați gestionarea robustă a erorilor în codul dvs., mai ales când lucrați cu API-uri terțe. Un mecanism adecvat de gestionare a erorilor va ajuta la depanarea mai eficientă a problemei și va oferi mesaje ușor de utilizat atunci când ceva nu merge bine.