Fehlerbehandlung und Ladezustände

Bisher ging unsere App stillschweigend davon aus, dass JEDE Magento-Anfrage klappt – in der Praxis läuft ein abgelaufener Token, eine falsche SKU oder ein kurzzeitig nicht erreichbarer Shop früher oder später auf.

Die drei häufigsten Fehlerfälle bei der Magento API

Fehlerfall	Ursache & Umgang
401 Unauthorized	Der Access Token ist ungültig oder (beim Admin-Token aus Kapitel 3) abgelaufen. Lösung: neuen Token holen, oder auf den nicht-ablaufenden Integration-Token aus Kapitel 5 wechseln.
404 Not Found	Die angefragte SKU existiert nicht (mehr) – z. B. weil ein Produkt im Admin gelöscht wurde, während ein Nutzer noch den alten Link geöffnet hat.
Netzwerkfehler (kein HTTP-Status)	Der Shop ist gerade nicht erreichbar (Wartungsmodus, Netzwerkproblem) – `fetch()` selbst wirft in diesem Fall einen Fehler, BEVOR überhaupt ein `response.status` existiert.

magentoFetch() mit differenzierter Fehlerbehandlung

src/api/magentoApi.js

// ... BASE_URL, ACCESS_TOKEN, PAGE_SIZE ...

export class MagentoApiFehler extends Error {
  constructor(nachricht, status) {
    super(nachricht);
    this.name = 'MagentoApiFehler';
    this.status = status;
  }
}

async function magentoFetch(path) {
  let response;
  try {
    response = await fetch(`${BASE_URL}${path}`, {
      headers: { Authorization: `Bearer ${ACCESS_TOKEN}` },
    });
  } catch {
    throw new MagentoApiFehler('Shop nicht erreichbar. Prüfen Sie Ihre Internetverbindung.', 0);
  }

  if (response.status === 401) {
    throw new MagentoApiFehler('Zugang abgelaufen oder ungültig. Bitte Token erneuern.', 401);
  }
  if (response.status === 404) {
    throw new MagentoApiFehler('Produkt nicht gefunden.', 404);
  }
  if (!response.ok) {
    throw new MagentoApiFehler(`Unerwarteter Fehler: ${response.status}`, response.status);
  }

  return response.json();
}

Die eigene MagentoApiFehler-Klasse trägt zusätzlich den HTTP-Status – so kann die aufrufende Komponente per instanceof/error.status unterscheiden, WELCHE Meldung sie anzeigt, statt für jeden Fehler denselben generischen Text zu zeigen.

ProductDetailPage.jsx mit Fehler- und Ladezustand

src/pages/ProductDetailPage.jsx

import { useEffect, useState } from 'react';
import { useParams, Link } from 'react-router-dom';
import {
  fetchProductBySku,
  leseCustomAttribute,
  ermittleProduktbild,
  ermittleLagerbestand,
} from '../api/magentoApi';

function ProductDetailPage() {
  const { sku } = useParams();
  const [produkt, setProdukt] = useState(null);
  const [ladend, setLadend] = useState(true);
  const [fehler, setFehler] = useState(null);

  useEffect(() => {
    setLadend(true);
    setFehler(null);
    async function laden() {
      try {
        const data = await fetchProductBySku(sku);
        setProdukt(data);
      } catch (error) {
        setFehler(error.message);
      } finally {
        setLadend(false);
      }
    }
    laden();
  }, [sku]);

  if (ladend) {
    return <p>Lade Produkt...</p>;
  }

  if (fehler) {
    return (
      <div>
        <p>⚠ {fehler}</p>
        <Link to="/">Zurück zur Produktliste</Link>
      </div>
    );
  }

  const beschreibung = leseCustomAttribute(produkt, 'description');
  const bildUrl = ermittleProduktbild(produkt);
  const { aufLager, menge } = ermittleLagerbestand(produkt);

  return (
    <div>
      {bildUrl && <img src={bildUrl} alt={produkt.name} width="300" />}
      <h1>{produkt.name}</h1>
      <p>SKU: {produkt.sku}</p>
      <p>{produkt.price} €</p>
      <p>{aufLager ? `Auf Lager (${menge} Stück)` : 'Ausverkauft'}</p>
      {beschreibung && <div dangerouslySetInnerHTML={{ __html: beschreibung }} />}
    </div>
  );
}

export default ProductDetailPage;

Das try/catch/finally-Muster stellt sicher, dass ladend in JEDEM Fall (Erfolg ODER Fehler) am Ende auf false steht – ohne finally würde die App bei einem Fehler ewig im Ladezustand hängen bleiben.

Testen Sie es absichtlich: einen Fehler provozieren

Tipp: Ändern Sie die URL manuell zu einer SKU, die nicht existiert (z. B. /products/DOES-NOT-EXIST) – Sie sollten jetzt die 404-Fehlermeldung samt Rücksprung-Link sehen, statt einer abstürzenden weißen Seite. Setzen Sie testweise auch eine falsche VITE_MAGENTO_ACCESS_TOKEN in .env, um den 401-Fall zu sehen (Dev-Server danach neu starten).