Axiose vigade haldamine Spring Boot taustaprogrammi kasutamisel API andmete toomiseks ID järgi Vite+Reactis

ID-põhiste API toomise vigade lahendamine rakenduses Vite+React koos Spring Bootiga

Kaasaegsete veebirakenduste loomisel on taustarakenduse API-st andmete toomine kriitiline ülesanne. Vite+Reacti esiprogrammis on Spring Booti taustaprogrammiga integreerimine enamikul juhtudel sujuv. Siiski võib teil tekkida spetsiifilisi probleeme ID alusel andmete toomisel, eriti Axiose kasutamisel.

Levinud probleem tekib siis, kui otse brauseris URL-ide kaudu töötavad päringud ebaõnnestuvad, kui need käivitatakse kasutajaliidesest. Üks selline tõrge ilmneb tooteandmete toomisel ID järgi Spring Booti taustaprogrammist. Selline olukord võib põhjustada tõrkeid, mis on sageli seotud mittevastavate andmetüüpidega.

Selles artiklis keskendume tavalisele veale, mis ilmneb Axiose abil ID alusel toodete toomisel. Viga kuvatakse tavaliselt eesprogrammis kui "400 halb taotlus" ja viitab andmetüübi ebaõnnestunud teisendamisele taustaprogrammis. Uurime nii selle probleemi põhjust kui ka lahendust.

Selle probleemi lahendamisega saate sügavama arusaamise esi- ja taustaprogrammi vaheliste tüübikonversioonide käsitlemisest. See parandab teie API-integratsiooni Vite+Reacti rakendustes Spring Booti taustaprogrammidega töötamise ajal.

Axios Fetch ja Spring Boot integratsiooni mõistmine

Kasutab minu esitatud kasutajaliidese koodi Reageerige ja Axios tooteandmete hankimiseks a Kevadsaabas tagaprogramm. Kriitiline punkt on andmete toomine ID abil, mis hõlmab dünaamilist marsruudi haldamist UseParams in React. The UseParams konks hõivab URL-ist toote ID, mis seejärel edastatakse toomistoimingu käivitamiseks komponendile. See ID tuleb teisendada täisarvuks kasutades parseInt et vältida ebakõlasid eesmise ja taustaprogrammi vahel, tagades õige andmetüübi saatmise Spring Booti taustaprogrammi.

Axios täidab GET-päringu taustaprogrammi API-le, kasutades lõpp-punkti: http://localhost:8080/api/products/{id}. Taustaprogramm on üles ehitatud nii, et toote ID jaoks on täisarvuline väärtus. Kui ID-d ei teisendata õigesti, annab taustaprogramm tüübiteisendusvea, mis viib probleemini "400 halb taotlus". Taustaprogrammi vealogis on selgelt kirjas, et stringi väärtust täisarvuks teisendada ei õnnestunud, mistõttu on oluline ID enne päringu esitamist esiprogrammis teisendada.

Spring Booti taustaprogrammis on Tootekontroller klassil on lõpp-punkt vastendatud /tooted/{id}. Sellega tegeleb @PathVariable annotatsioon, mis seob tee parameetri meetodi argumendiga. See tagab, et kontroller võtab URL-is edastatud toote ID õigesti vastu. Kontroller omakorda kutsub teeninduskihti, et hankida andmebaasist toote üksikasjad, kasutades Tooteteenus klass. Õige käsitsemine PathVariable ja teenindusloogika on tüübi mittevastavuse vigade ärahoidmisel ülioluline.

Testimiseks kasutavad nii esi- kui ka taustaprogramm üksuse testimist, et kontrollida, kas lahendus töötab erinevates keskkondades. Esiküljel Naljakas kasutatakse Axiose taotluste pilkamiseks, tagades, et komponent renderdab hangitud tooteandmed õigesti. Samamoodi kasutab taustaprogramm MockMvc API lõpp-punkti käitumise testimiseks, kontrollides, kas kehtivate ID-de edastamisel tagastatakse õiged tooteandmed. Testide kaasamisega saavad arendajad tagada, et kood toimib ootuspäraselt, vähendades vigade tõenäosust tootmise ajal.

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

ID-põhiste toomisvigade ületamine Axios ja Spring Bootis

Teine oluline aspekt taustarakenduse API-st andmete toomisel on käsitlemine vea vastused graatsiliselt. Vite+Reacti kasutajaliideses ID-põhiste päringute käsitlemisel on võimalus, et server tagastab vea, nagu 400 halb taotlus või tüübi mittevastavus on tavaline. Sujuva kasutuskogemuse tagamiseks on oluline mõista, kuidas neid vigu kasutajaliideses ennetada ja hallata. Meie näites sõelutakse ID parameeter JavaScripti õige kasutamine on oluline samm, kuid erandite globaalsel käsitlemisel tuleb arvestada ka täiendavate kaalutlustega.

Keerulisemates rakendustes seadistamine vigade piirid React aitab seda tüüpi vigu tabada ilma kogu rakenduse kokkujooksmiseta. See hõlmab Reacti kasutamist komponentDidCatch elutsükli meetod või veapiiri konksud funktsioonipõhistes komponentides. Taustaprogrammi vigade käsitlemine kasutajale informatiivsete sõnumite õige kuvamise kaudu võib vältida pettumust ja segadust, kui API-kutsed ebaõnnestuvad. See meetod on eriti kasulik selliste probleemide tuvastamiseks nagu kehtetud ID-d või kättesaamatud tooted.

Lisaks võib logimise rakendamine nii esi- kui ka taustaprogrammis aidata arendajatel tuvastada korduvaid probleeme ja optimeerida jõudlust. Näiteks võib API toomise päringute ajal teatud vigade sageduse jälgimine paljastada aluseks olevad vead või ebatõhusused. Nende sündmuste jälgimine sellise tööriistaga nagu Sentry või kohandatud logiteenuste kaudu, mis tagab, et saate nendega kiiresti tegeleda. See praktika parandab aja jooksul oluliselt teie rakenduse töökindlust ja hooldatavust.