Gestionarea erorilor Axios atunci când utilizați backend-ul Spring Boot pentru a prelua datele API după ID în Vite+React

Rezolvarea erorilor de preluare API bazate pe ID în Vite+React cu Spring Boot

Când construiți aplicații web moderne, preluarea datelor dintr-un API backend este o sarcină critică. Într-o interfață Vite+React, integrarea cu un backend Spring Boot este fără probleme în majoritatea cazurilor. Cu toate acestea, este posibil să întâmpinați probleme specifice la preluarea datelor după ID, în special când utilizați Axios.

O problemă comună apare atunci când solicitările care funcționează direct prin adrese URL din browser eșuează atunci când sunt invocate de pe front-end. O astfel de eroare apare la preluarea datelor de produs prin ID dintr-un backend Spring Boot. Această situație poate duce la erori, adesea legate de tipuri de date nepotrivite.

În acest articol, ne vom concentra pe o eroare frecventă întâlnită la preluarea produselor prin ID folosind Axios. Eroarea apare de obicei ca „400 Bad Request” în front-end și indică o conversie eșuată a tipului de date în backend. Vom explora atât cauza acestei probleme, cât și soluția ei.

Rezolvând această problemă, veți obține o înțelegere mai profundă a gestionării conversiilor de tip între frontend și backend. Acest lucru vă va îmbunătăți integrarea API-ului în aplicațiile Vite+React în timp ce lucrați cu backend-uri Spring Boot.

Înțelegerea integrării Axios Fetch și Spring Boot

Codul frontend pe care l-am furnizat folosește Reacţiona şi Axios pentru a prelua date despre produse de la a Cizme de primăvară backend. Punctul critic este preluarea datelor prin ID, care implică gestionarea dinamică a rutei cu useParams în React. The useParams hook captează ID-ul produsului de la adresa URL, care este apoi transmis în componentă pentru a declanșa operația de preluare. Acest ID trebuie convertit într-un număr întreg folosind parseInt pentru a evita nepotrivirile între front-end și backend, asigurându-vă că tipul de date corect este trimis către backend-ul Spring Boot.

Axios efectuează solicitarea GET către API-ul backend folosind punctul final: http://localhost:8080/api/products/{id}. Backend-ul este structurat pentru a aștepta o valoare întreagă pentru ID-ul produsului. Dacă ID-ul nu este convertit corect, backend-ul afișează o eroare de conversie de tip, ceea ce duce la problema „400 Bad Request”. Jurnalul de erori al backend-ului afirmă în mod clar că nu a reușit să convertească valoarea șirului într-un număr întreg, motiv pentru care este esențial să convertiți ID-ul de pe front-end înainte de a face cererea.

În backend-ul Spring Boot, ProductController clasa are un punct final mapat la /produse/{id}. Acest lucru este gestionat de @PathVariable adnotare, care leagă parametrul cale la argumentul metodei. Acest lucru asigură că ID-ul produsului transmis în adresa URL este primit corect de controler. Controlorul, la rândul său, apelează stratul de servicii pentru a prelua detaliile produsului din baza de date folosind ProductService clasă. Manipularea corectă a PathVariable iar logica serviciului este crucială în prevenirea erorilor de nepotrivire de tip.

Pentru testare, atât front-end-ul, cât și backend-ul folosesc testarea unitară pentru a valida că soluția funcționează în diferite medii. În front-end, Glumă este folosit pentru a bate joc de cererile Axios, asigurându-se că componenta redă corect datele despre produs preluate. În mod similar, backend-ul folosește MockMvc pentru a testa comportamentul punctului final API, verificând dacă datele corecte ale produsului sunt returnate atunci când sunt transmise ID-uri valide. Încorporând teste, dezvoltatorii se pot asigura că codul funcționează conform așteptărilor, reducând șansele de erori în timpul producției.

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"));
  }
}

Depășirea erorilor de preluare bazate pe ID în Axios și Spring Boot

Un alt aspect critic al preluării datelor dintr-un API backend implică manipularea răspunsuri de eroare graţios. Când aveți de-a face cu interogări bazate pe ID într-un frontend Vite+React, este posibil ca serverul să returneze o eroare precum 400 Solicitare greșită sau o nepotrivire de tip este comună. Este esențial să înțelegeți cum să anticipați și să gestionați aceste erori în interfață pentru a asigura o experiență fluidă pentru utilizator. În exemplul nostru, analizând parametru ID utilizarea corectă a JavaScript este un pas cheie, dar există și considerații suplimentare pentru gestionarea excepțiilor la nivel global.

În aplicații mai complexe, configurarea limite de eroare în React poate ajuta la capturarea acestor tipuri de erori fără a bloca întreaga aplicație. Aceasta implică utilizarea lui React componentDidCatch metoda ciclului de viață sau cârligele de limita de eroare în componentele bazate pe funcții. Gestionarea erorilor de backend prin afișarea corectă a mesajelor informative pentru utilizator poate preveni frustrarea și confuzia atunci când apelurile API eșuează. Această metodă este utilă în special pentru a detecta probleme precum ID-uri nevalide sau produse indisponibile.

În plus, implementarea logării atât pe front-end, cât și pe backend poate ajuta dezvoltatorii să identifice problemele recurente și să optimizeze performanța. De exemplu, urmărirea frecvenței cu care apar anumite erori în timpul solicitărilor de preluare API poate dezvălui erori sau ineficiențe subiacente. Monitorizarea acestor evenimente cu un instrument precum Santinelă sau prin intermediul serviciilor de logare personalizate vă asigură că le puteți aborda cu promptitudine. Această practică îmbunătățește semnificativ fiabilitatea și mentenabilitatea aplicației dvs. în timp.