Upravljanje napak Axios pri uporabi ozadja Spring Boot za pridobivanje podatkov API-ja po ID-ju v Vite+React

Reševanje napak pri pridobivanju API-ja na podlagi ID-ja v Vite+React s pomladnim zagonom

Pri gradnji sodobnih spletnih aplikacij je pridobivanje podatkov iz zalednega API-ja kritična naloga. V sprednjem delu Vite+React je integracija z zadnjim delom Spring Boot v večini primerov brezhibna. Vendar pa lahko naletite na posebne težave pri pridobivanju podatkov po ID-ju, zlasti pri uporabi Axios.

Pogosta težava se pojavi, ko zahteve, ki delujejo neposredno prek URL-jev v brskalniku, ne uspejo, ko so priklicane iz sprednjega dela. Ena taka napaka se pojavi pri pridobivanju podatkov o izdelku po ID-ju iz zaledja Spring Boot. To stanje lahko privede do napak, ki so pogosto povezane z neujemajočimi se vrstami podatkov.

V tem članku se bomo osredotočili na pogosto napako, do katere pride pri pridobivanju izdelkov po ID-ju z uporabo Axios. Napaka se običajno prikaže kot »400 Bad Request« v sprednjem delu in kaže na neuspešno pretvorbo vrste podatkov v zadnjem delu. Raziskali bomo vzrok te težave in njeno rešitev.

Z obravnavo te težave boste pridobili globlje razumevanje ravnanja s pretvorbami vrst med sprednjim in zadnjim delom. To bo izboljšalo vašo integracijo API-ja v aplikacijah Vite+React med delom z zaledji Spring Boot.

Razumevanje integracije Axios Fetch in Spring Boot

Koda čelnega vmesnika, ki sem jo posredoval, uporablja Reagiraj in Axios pridobiti podatke o izdelku od a Pomladni škorenj backend. Kritična točka je pridobivanje podatkov po ID-ju, kar vključuje dinamično upravljanje poti z useParams v Reactu. The useParams hook zajame ID izdelka iz URL-ja, ki se nato posreduje v komponento, da sproži operacijo pridobivanja. Ta ID je treba pretvoriti v celo število z uporabo parseInt da bi se izognili neusklajenosti med sprednjim in zadnjim delom, zagotovite, da se v zaledje Spring Boot pošlje pravilen tip podatkov.

Axios izvede zahtevo GET za zaledni API z uporabo končne točke: http://localhost:8080/api/products/{id}. Zaledje je strukturirano tako, da pričakuje celoštevilsko vrednost za ID izdelka. Če ID ni pravilno pretvorjen, zaledje vrže napako pri pretvorbi tipa, kar povzroči težavo »400 Bad Request«. Dnevnik napak zaledja jasno navaja, da vrednosti niza ni uspelo pretvoriti v celo število, zato je bistveno, da pred zahtevo pretvorite ID na sprednjem delu.

V zaledju Spring Boot je ProductController razred ima preslikano končno točko /izdelki/{id}. To ureja @PathVariable opombo, ki parameter poti poveže z argumentom metode. To zagotavlja, da krmilnik pravilno sprejme ID izdelka, posredovan v URL-ju. Krmilnik pa pokliče storitveni sloj, da pridobi podrobnosti o izdelku iz baze podatkov z uporabo ProductService razred. Pravilno ravnanje z PathVariable in servisna logika je ključnega pomena pri preprečevanju napak pri neujemanju tipov.

Pri testiranju tako sprednji del kot zadnji del uporabljata testiranje enote, da preverita, ali rešitev deluje v različnih okoljih. V sprednjem delu, Šala se uporablja za norčevanje iz zahtev Axios in zagotavlja, da komponenta pravilno upodobi pridobljene podatke o izdelku. Podobno uporablja zaledje MockMvc da preizkusite vedenje končne točke API-ja in preverite, ali so ob posredovanju veljavnih ID-jev vrnjeni pravilni podatki o izdelku. Z vključitvijo testov lahko razvijalci zagotovijo, da koda deluje po pričakovanjih, kar zmanjša možnosti napak med proizvodnjo.

import React, { useEffect, useState } from "react";
import { useParams } from "react-router-dom";
import axios from "../axios";
const Product = () => {
  const { id } = useParams();
  const [product, setProduct] = useState(null);
  useEffect(() => {
    const fetchProduct = async () => {
      try {
        // Parse id to an integer to avoid "NaN" errors
        const productId = parseInt(id, 10);
        const response = await axios.get(`http://localhost:8080/api/products/${productId}`);
        setProduct(response.data);
      } catch (error) {
        console.error("Error fetching product:", error);
      }
    };
    fetchProduct();
  }, [id]);
  if (!product) {
    return <h2 className="text-center">Loading...</h2>;
  }
  return (
    <div>
      <h1>{product.name}</h1>
      <p>{product.description}</p>
    </div>
  );
};
export default Product;

import org.springframework.web.bind.annotation.*;
import java.util.List;
@RestController
@RequestMapping("/api")
public class ProductController {
  @Autowired
  private ProductService productService;
  @GetMapping("/products/{id}")
  public Product getProduct(@PathVariable int id) {
    return productService.getProductById(id);
  }
}

import { render, screen, waitFor } from '@testing-library/react';
import axios from 'axios';
import Product from './Product';
jest.mock('axios');
test('fetches and displays product', async () => {
  axios.get.mockResolvedValue({ data: { name: 'Product1', description: 'A sample product' } });
  render(<Product />);
  await waitFor(() => expect(screen.getByText('Product1')).toBeInTheDocument());
});

@RunWith(SpringRunner.class)
@WebMvcTest(ProductController.class)
public class ProductControllerTest {
  @Autowired
  private MockMvc mockMvc;
  @Test
  public void testGetProductById() throws Exception {
    mockMvc.perform(get("/api/products/1"))
      .andExpect(status().isOk())
      .andExpect(jsonPath("$.name").value("Product1"));
  }
}

Odpravljanje napak pri pridobivanju na podlagi ID-ja v Axios in Spring Boot

Drugi kritični vidik pridobivanja podatkov iz zalednega API-ja vključuje rokovanje odzivi na napake graciozno. Pri obravnavanju poizvedb na podlagi ID-ja v vmesniku Vite+React je možnost, da strežnik vrne napako, kot je 400 Slaba zahteva ali pa je neujemanje vrste pogosto. Bistveno je razumeti, kako predvideti in upravljati te napake v sprednjem delu, da zagotovimo nemoteno uporabniško izkušnjo. V našem primeru razčlenjevanje parameter ID pravilna uporaba JavaScripta je ključni korak, vendar obstajajo tudi dodatni premisleki za globalno obravnavanje izjem.

Pri zahtevnejših aplikacijah nastavitev meje napak v Reactu lahko pomaga zajeti te vrste napak, ne da bi zrušil celotno aplikacijo. To vključuje uporabo React's componentDidCatch metoda življenjskega cikla ali kljuke meje napak v komponentah, ki temeljijo na funkcijah. Obravnavanje napak v ozadju s pravilnim prikazovanjem informativnih sporočil uporabniku lahko prepreči frustracije in zmedo, ko klici API-ja ne uspejo. Ta metoda je še posebej uporabna za odkrivanje težav, kot so neveljavni ID-ji ali izdelki, ki niso na voljo.

Poleg tega lahko implementacija beleženja tako na sprednji kot zadnji strani pomaga razvijalcem prepoznati ponavljajoče se težave in optimizirati delovanje. Na primer, sledenje, kako pogosto se pojavljajo določene napake med zahtevami za pridobivanje API-ja, lahko razkrije osnovne napake ali neučinkovitosti. Spremljanje teh dogodkov z orodjem, kot je Stražar ali prek storitev beleženja po meri zagotavlja, da jih lahko takoj obravnavate. Ta praksa bistveno izboljša zanesljivost in vzdržljivost vaše aplikacije skozi čas.