ReactJS: pärast Chrome CORS-i pistikprogrammi lisamist ebaõnnestus töötlemata tagasilükkamise (tüübiviga) toomine

API vigade käsitlemine Reactis: CORS-i pistikprogrammi väljakutsed

API-dega töötamisel ReactJS, puutuvad arendajad sageli kokku mitmesuguste andmete toomisega seotud väljakutsetega, eriti kui tegemist on kolmanda osapoole API-dega. Üks levinud probleem on tõrge "Haldamata tagasilükkamine (TypeError): toomine ebaõnnestus". See viga võib ilmneda isegi populaarsete API-de (nt Swiggy restoraninimekirja API) kasutamisel, mida paljud arendajad kasutavad oma veebirakenduste täiustamiseks.

Sel juhul võib CORS-i Chrome'i laienduse lisamine tunduda mõistlik lahendus piiravatest brauserireeglitest mööda hiilimiseks. Siiski võib see probleemi lahendamise asemel tuua kaasa uusi komplikatsioone. Kui kasutate oma arenduskeskkonnas CORS-i pistikprogrammi ja teie API-päringud nurjuvad varsti pärast laadimist, võib teil tekkida probleem, kus pistikprogramm läheb vastuollu brauseri päringute käsitlemise käitumisega.

Päritoluüleste päringute haldamise ja tõrkeotsingu mõistmine CORS-i vead ReactJS-is on sujuva arendusprotsessi jaoks hädavajalik. API-del, nagu Swiggy's, on sageli paigas turvakihid, nagu CORS, mis kontrollivad volitamata klientide juurdepääsu. Need piirangud võivad põhjustada vigu, mida tuleb korralikult kõrvaldada.

Selles juhendis uurime, miks see viga ilmneb, eriti pärast CORS-i pistikprogrammi lisamist Chrome'i. Swiggy API-ga töötades arutame ka selle lahendamise strateegiaid Reageerige rakendusi.

Lahenduste selgitamine CORS-i probleemidele Reactis Swiggy API-ga

Esimeses lahenduses lõime a Node.js taustaprogramm, mis kasutab Swiggy API-lt restoraniandmete toomisel CORS-i probleemist kõrvalehoidmiseks Expressi. CORS-i reegel takistab brauseritel teha päringuid teisele domeenile, kui see domeen seda ei luba. Lihtsa serveri loomisel saame toimida keskmise kihina kliendi ja API vahel, hankides andmeserveri poolelt ja tagastades selle Reacti esiotsa. See meetod väldib CORS-i vigu, kuna päring pärineb kliendirakendusega samast päritolust.

Expressi taustaprogramm seadistab kohandatud päised, eriti Access-Control-Allow-Origin, mis võimaldab meie kliendil taotleda ressursse ilma CORS-i piiranguteta. Swiggy API toomiskutse tehakse serveripoolne ja andmed tagastatakse JSON-vormingus. Seda lähenemisviisi peetakse tootmiskeskkondades sageli turvalisemaks ja tõhusamaks, kuna see peidab API võtmed või tundlikku teavet. Lisaks tagab try-catch'i kasutamine õige vigade käsitlemise, kuvades kasutajasõbralikke veateateid, kui API ei reageeri.

Teises lahenduses muudame kliendipoolse React-koodi toomistaotlust. See meetod hõlmab kohandatud päiste lisamist toomiskutsele, tagades, et taotlus on enne API-le jõudmist õigesti vormindatud. Me kasutame Reacti useEffect konks API-kutse käivitamiseks komponendi paigaldamisel. Asünkroonimisfunktsioon ootab API vastust, teisendab selle JSON-iks ja käsitleb vigu, kui päring ebaõnnestub. Selle lahendusega on siiski probleeme CORS-iga, kui API ei luba brauseritelt otse päringuid teha.

Lõpuks kasutame kolmandas lahenduses kolmanda osapoole teenust nimega CORS-Anywhere. See on vahevarateenus, mis aitab ajutiselt CORS-i piirangutest mööda minna, suunates API päringu nende serveri kaudu ümber. Kuigi see lahendus võib töötada arenduskeskkondades, ei ole see turvariskide ja välisteenustest sõltuvuse tõttu tootmises soovitatav. See toob kaasa ka jõudluse üldkulud, kuna see lisab andmete toomise protsessile täiendava kihi. Selle meetodi kasutamine võib olla testimise ajal mugav, kuid seda tuleks turvakaalutlustel tootmises vältida.

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;

CORS-i probleemide tõrkeotsing API taotlustes

Üks Reacti rakenduse vea „Toomine ebaõnnestus” põhjuseid, eriti kui kasutate kolmanda osapoole API-sid, nagu Swiggy, on CORS (Päritolu ressursside jagamine) piirangud. CORS on turvafunktsioon, mis takistab veebirakendustel teha päringuid teisele domeenile kui see, kust neid teenindati. Sel juhul lükkab Swiggy API taotluse tagasi, kuna see pärineb teisest domeenist (teie rakendus React). See on eriti problemaatiline, kui hankite andmeid API-delt, mis ei toeta selgesõnaliselt ristpäritolu taotlusi.

Levinud lahendus on kasutada brauserilaiendeid, nagu Chrome'i laiendus „Luba CORS”. Sellised laiendused võivad aga viia ebajärjekindlate tulemusteni. Selle põhjuseks on asjaolu, et nad manipuleerivad brauseri taseme seadeid, mis ei sünkrooni alati API taotlustega korralikult. Neid pistikprogramme tuleks ideaalis kasutada ainult arendamiseks, mitte tootmiskeskkondades. Tootmise jaoks oleks turvalisem ja usaldusväärsem lähenemisviis taustapuhverserveri kasutamine, mis taotleb andmeid teie rakenduse React nimel, nagu on näha varem pakutud lahendustes.

Teine aspekt, mida tuleb kaaluda, on vigade tõhus käsitlemine. Kuigi CORS-probleemid on veateate „Toomine nurjus” sage põhjus, võivad selle vea põhjuseks olla ka muud tegurid, nagu võrgu ebastabiilsus, valed API URL-id või serveri seisak. Seetõttu on oluline rakendada tugev vigade käsitlemine oma koodis, eriti kui töötate kolmanda osapoole API-dega. Õige veakäsitlusmehhanism aitab probleemi tõhusamalt siluda ja annab kasutajasõbralikke sõnumeid, kui midagi läheb valesti.