React Suspense meistern: Globale Anwendungen mit der Verwaltung gemeinsamer Ressourcenpools für das Laden von Daten optimieren

In der riesigen und vernetzten Landschaft der modernen Webentwicklung ist die Erstellung performanter, skalierbarer und widerstandsfähiger Anwendungen von größter Bedeutung, insbesondere wenn eine vielfältige, globale Benutzerbasis bedient wird. Benutzer auf allen Kontinenten erwarten nahtlose Erlebnisse, unabhängig von ihren Netzwerkbedingungen oder Gerätefähigkeiten. React befähigt Entwickler mit seinen innovativen Funktionen weiterhin, diese hohen Erwartungen zu erfüllen. Zu den transformativsten Ergänzungen gehört React Suspense, ein leistungsstarker Mechanismus, der entwickelt wurde, um asynchrone Operationen – hauptsächlich Datenabruf und Code-Splitting – so zu orchestrieren, dass eine reibungslosere und benutzerfreundlichere Erfahrung entsteht.

Während Suspense von Natur aus dabei hilft, die Ladezustände einzelner Komponenten zu verwalten, entfaltet sich die wahre Stärke, wenn wir intelligente Strategien darauf anwenden, wie Daten in einer gesamten Anwendung abgerufen und geteilt werden. Hier wird das Ressourcenpool-Management für das gemeinsame Laden von Daten nicht nur zu einer bewährten Vorgehensweise, sondern zu einer kritischen architektonischen Überlegung. Stellen Sie sich eine Anwendung vor, in der mehrere Komponenten, vielleicht auf verschiedenen Seiten oder innerhalb eines einzigen Dashboards, alle dasselbe Datenelement benötigen – das Profil eines Benutzers, eine Liste von Ländern oder Echtzeit-Wechselkurse. Ohne eine kohärente Strategie könnte jede Komponente ihre eigene identische Datenanforderung auslösen, was zu redundanten Netzwerkaufrufen, erhöhter Serverlast, langsamerer Anwendungsleistung und einer suboptimalen Erfahrung für Benutzer weltweit führt.

Dieser umfassende Leitfaden befasst sich eingehend mit den Prinzipien und praktischen Anwendungen der Nutzung von React Suspense in Verbindung mit einem robusten Ressourcenpool-Management. Wir werden untersuchen, wie Sie Ihre Datenabrufschicht so gestalten können, dass Effizienz gewährleistet, Redundanz minimiert und eine außergewöhnliche Leistung erbracht wird, unabhängig vom geografischen Standort oder der Netzwerkinfrastruktur Ihrer Benutzer. Bereiten Sie sich darauf vor, Ihren Ansatz zum Laden von Daten zu transformieren und das volle Potenzial Ihrer React-Anwendungen zu erschließen.

React Suspense verstehen: Ein Paradigmenwechsel bei asynchronen UIs

Bevor wir uns mit dem Ressourcen-Pooling befassen, wollen wir ein klares Verständnis von React Suspense schaffen. Traditionell umfasste die Handhabung asynchroner Operationen in React die manuelle Verwaltung von Ladezuständen, Fehlerzuständen und Datenzuständen innerhalb von Komponenten, was oft zu einem Muster führte, das als "Fetch-on-Render" bekannt ist. Dieser Ansatz konnte zu einer Kaskade von Ladeanimationen, komplexer bedingter Rendering-Logik und einer weniger idealen Benutzererfahrung führen.

React Suspense führt eine deklarative Möglichkeit ein, React mitzuteilen: "Hey, diese Komponente ist noch nicht bereit zum Rendern, weil sie auf etwas wartet." Wenn eine Komponente suspends (z. B. während des Datenabrufs oder des Ladens eines Code-Split-Chunks), kann React das Rendern unterbrechen, eine Fallback-UI (wie eine Ladeanimation oder einen Skeleton-Screen) anzeigen, die durch eine übergeordnete <Suspense>-Grenze definiert ist, und dann das Rendern fortsetzen, sobald die Daten oder der Code verfügbar sind. Dies zentralisiert die Verwaltung des Ladezustands, macht die Komponentenlogik sauberer und die UI-Übergänge flüssiger.

Die Kernidee hinter Suspense für den Datenabruf ist, dass Datenabrufbibliotheken direkt mit dem Renderer von React integriert werden können. Wenn eine Komponente versucht, Daten zu lesen, die noch nicht verfügbar sind, "wirft" die Bibliothek ein Promise. React fängt dieses Promise, setzt die Komponente aus und wartet, bis das Promise aufgelöst wird, bevor es den Render-Vorgang erneut versucht. Dieser elegante Mechanismus ermöglicht es Komponenten, ihre Datenanforderungen "datenagnostisch" zu deklarieren, während die Suspense-Grenze den Wartezustand handhabt.

Die Herausforderung: Redundanter Datenabruf in globalen Anwendungen

Während Suspense lokale Ladezustände vereinfacht, löst es nicht automatisch das Problem, dass mehrere Komponenten die gleichen Daten unabhängig voneinander abrufen. Betrachten wir eine globale E-Commerce-Anwendung:

• Ein Benutzer navigiert zu einer Produktseite.
• Die Komponente <ProductDetails /> ruft Produktinformationen ab.
• Gleichzeitig benötigt eine Sidebar-Komponente <RecommendedProducts /> möglicherweise auch einige Attribute des gleichen Produkts, um verwandte Artikel vorzuschlagen.
• Eine Komponente <UserReviews /> könnte den Bewertungsstatus des aktuellen Benutzers abrufen, wofür die Benutzer-ID erforderlich ist – Daten, die bereits von einer übergeordneten Komponente abgerufen wurden.

In einer naiven Implementierung könnte jede dieser Komponenten ihre eigene Netzwerkanfrage für die gleichen oder überlappenden Daten auslösen. Die Konsequenzen sind erheblich, insbesondere für ein globales Publikum:

• Erhöhte Latenz und langsamere Ladezeiten: Mehrere Anfragen bedeuten mehr Roundtrips über potenziell große Entfernungen, was Latenzprobleme für Benutzer verschärft, die weit von Ihren Servern entfernt sind.
• Höhere Serverlast: Ihre Backend-Infrastruktur muss doppelte Anfragen verarbeiten und beantworten, was unnötige Ressourcen verbraucht.
• Verschwendete Bandbreite: Benutzer, insbesondere in Mobilfunknetzen oder in Regionen mit teuren Datentarifen, verbrauchen mehr Daten als nötig.
• Inkonsistente UI-Zustände: Race Conditions können auftreten, bei denen verschiedene Komponenten leicht unterschiedliche Versionen der "gleichen" Daten erhalten, wenn zwischen den Anfragen Aktualisierungen stattfinden.
• Reduzierte Benutzererfahrung (UX): Flackernder Inhalt, verzögerte Interaktivität und ein allgemeines Gefühl der Trägheit können Benutzer abschrecken und zu höheren Absprungraten weltweit führen.
• Komplexe clientseitige Logik: Entwickler greifen oft auf komplizierte Memoization- oder Zustandsverwaltungslösungen innerhalb von Komponenten zurück, um dies zu mildern, was die Komplexität erhöht.

Dieses Szenario unterstreicht die Notwendigkeit eines ausgefeilteren Ansatzes: Ressourcenpool-Management.

Einführung des Ressourcenpool-Managements für gemeinsames Datenladen

Ressourcenpool-Management bezieht sich im Kontext von React Suspense und Datenladen auf den systematischen Ansatz, Datenabrufoperationen und ihre Ergebnisse in einer Anwendung zu zentralisieren, zu optimieren und zu teilen. Anstatt dass jede Komponente unabhängig eine Datenanforderung initiiert, fungiert ein "Pool" oder "Cache" als Vermittler, der sicherstellt, dass ein bestimmtes Datenelement nur einmal abgerufen und dann allen anfragenden Komponenten zur Verfügung gestellt wird. Dies ist analog zur Funktionsweise von Datenbankverbindungspools oder Thread-Pools: Wiederverwendung bestehender Ressourcen anstelle der Erstellung neuer.

Die Hauptziele bei der Implementierung eines gemeinsamen Ressourcenpools für das Datenladen sind:

• Redundante Netzwerkanfragen eliminieren: Wenn Daten bereits abgerufen werden oder kürzlich abgerufen wurden, stellen Sie die vorhandenen Daten oder das laufende Promise dieser Daten bereit.
• Leistung verbessern: Reduzieren Sie die Latenz, indem Sie Daten aus dem Cache bereitstellen oder auf eine einzige, gemeinsame Netzwerkanfrage warten.
• Benutzererfahrung verbessern: Liefern Sie schnellere, konsistentere UI-Updates mit weniger Ladezuständen.
• Serverbelastung reduzieren: Verringern Sie die Anzahl der Anfragen an Ihre Backend-Dienste.
• Komponentenlogik vereinfachen: Komponenten werden einfacher, da sie nur ihre Datenanforderungen deklarieren müssen, ohne sich darum zu kümmern, wie oder wann die Daten abgerufen werden.
• Datenlebenszyklus verwalten: Bereitstellung von Mechanismen für die Neuvalidierung, Invalidierung und Garbage Collection von Daten.

Wenn dieser Pool mit React Suspense integriert wird, kann er die Promises laufender Datenabrufe halten. Wenn eine Komponente versucht, Daten aus dem Pool zu lesen, die noch nicht verfügbar sind, gibt der Pool das ausstehende Promise zurück, wodurch die Komponente in den Suspense-Zustand versetzt wird. Sobald das Promise aufgelöst ist, werden alle Komponenten, die auf dieses Promise warten, mit den abgerufenen Daten neu gerendert. Dies schafft eine starke Synergie für die Verwaltung komplexer asynchroner Abläufe.

Strategien für effektives Management von gemeinsamen Datenlade-Ressourcen

Lassen Sie uns mehrere robuste Strategien zur Implementierung gemeinsamer Datenlade-Ressourcenpools untersuchen, von benutzerdefinierten Lösungen bis hin zur Nutzung ausgereifter Bibliotheken.

1. Memoization und Caching auf der Datenebene

Im einfachsten Fall kann Ressourcen-Pooling durch clientseitige Memoization und Caching erreicht werden. Dies beinhaltet das Speichern der Ergebnisse von Datenanfragen (oder der Promises selbst) in einem temporären Speichermechanismus, um zukünftige identische Anfragen zu verhindern. Dies ist eine grundlegende Technik, die fortgeschritteneren Lösungen zugrunde liegt.

Benutzerdefinierte Cache-Implementierung:

Sie können einen einfachen In-Memory-Cache mit JavaScripts Map oder WeakMap erstellen. Eine Map eignet sich für allgemeines Caching, bei dem Schlüssel primitive Typen oder von Ihnen verwaltete Objekte sind, während WeakMap hervorragend für Caching geeignet ist, bei dem Schlüssel Objekte sind, die möglicherweise von der Garbage Collection erfasst werden, sodass auch der zwischengespeicherte Wert erfasst werden kann.

            const dataCache = new Map();

function fetchWithCache(url, options) {
  if (dataCache.has(url)) {
    return dataCache.get(url);
  }

  const promise = fetch(url, options)
    .then(response => {
      if (!response.ok) {
        throw new Error(`HTTP error! status: ${response.status}`);
      }
      return response.json();
    })
    .catch(error => {
      dataCache.delete(url); // Remove entry if fetch failed
      throw error;
    });

  dataCache.set(url, promise);
  return promise;
}

// Example usage with Suspense
let userData = null;
function readUser(userId) {
  if (userData === null) {
    const promise = fetchWithCache(`/api/users/${userId}`);
    promise.then(data => (userData = data));
    throw promise; // Suspense will catch this promise
  }
  return userData;
}

function UserProfile({ userId }) {
  const user = readUser(userId);
  return <h2>Willkommen, {user.name}</h2>;
}
            

              
                Copy
              
            
          

Dieses einfache Beispiel zeigt, wie ein gemeinsamer dataCache Promises speichern kann. Wenn readUser mehrmals mit der gleichen userId aufgerufen wird, gibt es entweder das zwischengespeicherte Promise (falls noch nicht abgeschlossen) oder die zwischengespeicherten Daten (falls aufgelöst) zurück und verhindert so redundante Abrufe. Die größte Herausforderung bei benutzerdefinierten Caches ist die Verwaltung der Cache-Invalidierung, Neuvalidierung und Speicherlimits.

2. Zentralisierte Datenanbieter und React Context

Für anwendungsspezifische Daten, die möglicherweise strukturiert sind oder eine komplexere Zustandsverwaltung erfordern, kann React Context als leistungsstarke Grundlage für einen gemeinsamen Datenanbieter dienen. Eine zentrale Anbieterkomponente kann die Abruf- und Caching-Logik verwalten und eine konsistente Schnittstelle für Kindkomponenten zum Konsumieren von Daten bereitstellen.

            import React, { createContext, useContext, useState, useEffect } from 'react';

const UserContext = createContext(null);

const userResourceCache = new Map(); // A shared cache for user data promises

function getUserResource(userId) {
  if (!userResourceCache.has(userId)) {
    let status = 'pending';
    let result;
    const suspender = fetch(`/api/users/${userId}`)
      .then(response => response.json())
      .then(
        (r) => {
          status = 'success';
          result = r;
        },
        (e) => {
          status = 'error';
          result = e;
        }
      );
    userResourceCache.set(userId, { read() {
      if (status === 'pending') throw suspender;
      if (status === 'error') throw result;
      return result;
    }});
  }
  return userResourceCache.get(userId);
}

export function UserProvider({ children, userId }) {
  const userResource = getUserResource(userId);
  const user = userResource.read(); // Will suspend if data is not ready

  return (
    <UserContext.Provider value={user}>
      {children}
    </UserContext.Provider>
  );
}

export function useUser() {
  const context = useContext(UserContext);
  if (context === null) {
    throw new Error('useUser must be used within a UserProvider');
  }
  return context;
}

// Usage in components:
function UserGreeting() {
  const user = useUser();
  return <p>Hallo, {user.firstName}!</p>;
}

function UserAvatar() {
  const user = useUser();
  return <img src={user.avatarUrl} alt={user.name + " avatar"} />;
}

function Dashboard() {
  const currentUserId = 'user123'; // Assume this comes from auth context or prop
  return (
    <Suspense fallback={<div>Benutzerdaten werden geladen...</div>}>
      <UserProvider userId={currentUserId}>
        <UserGreeting />
        <UserAvatar />
        <!-- Andere Komponenten, die Benutzerdaten benötigen -->
      </UserProvider>
    </Suspense>
  );
}
            

              
                Copy
              
            
          

In diesem Beispiel ruft UserProvider die Benutzerdaten mithilfe eines gemeinsamen Caches ab. Alle Kindkomponenten, die UserContext verwenden, greifen auf dasselbe Benutzerobjekt zu (sobald es aufgelöst ist) und werden in den Suspense-Zustand versetzt, wenn die Daten noch geladen werden. Dieser Ansatz zentralisiert den Datenabruf und stellt ihn deklarativ in einem Teilbaum bereit.

3. Nutzung von Suspense-fähigen Datenabrufbibliotheken

Für die meisten globalen Anwendungen kann die Entwicklung einer robusten, Suspense-fähigen Datenabruflösung mit umfassendem Caching, Neuvalidierung und Fehlerbehandlung ein erheblicher Aufwand sein. Hier glänzen dedizierte Bibliotheken. Diese Bibliotheken sind speziell dafür konzipiert, einen Ressourcenpool von Daten zu verwalten, sich nahtlos in Suspense zu integrieren und erweiterte Funktionen standardmäßig bereitzustellen.

a. SWR (Stale-While-Revalidate)

Entwickelt von Vercel, ist SWR eine leichtgewichtige Datenabrufbibliothek, die Geschwindigkeit und Reaktivität priorisiert. Ihr Kernprinzip, "stale-while-revalidate", bedeutet, dass sie zuerst die Daten aus dem Cache zurückgibt (stale), sie dann durch Senden einer Fetch-Anfrage neu validiert und schließlich mit den frischen Daten aktualisiert. Dies bietet sofortiges UI-Feedback und gewährleistet gleichzeitig die Aktualität der Daten.

SWR erstellt automatisch einen gemeinsamen Cache (Ressourcenpool) basierend auf dem Anfrageschlüssel. Wenn mehrere Komponenten useSWR('/api/data') verwenden, teilen sie sich alle dieselben zwischengespeicherten Daten und dasselbe zugrunde liegende Fetch-Promise und verwalten so den Ressourcenpool implizit.

            import useSWR from 'swr';
import React, { Suspense } from 'react';

const fetcher = (url) => fetch(url).then((res) => res.json());

function UserProfile({ userId }) {
  // SWR will automatically share the data and handle Suspense
  const { data: user } = useSWR(`/api/users/${userId}`, fetcher, { suspense: true });
  return <h2>Willkommen, {user.name}</h2>;
}

function UserSettings() {
  const { data: user } = useSWR(`/api/users/current`, fetcher, { suspense: true });
  return (
    <div>
      <p>E-Mail: {user.email}</p>
      <!-- Weitere Einstellungen -->
    </div>
  );
}

function App() {
  return (
    <Suspense fallback={<div>Benutzerprofil wird geladen...</div>}>
      <UserProfile userId="123" />
      <UserSettings />
    </Suspense>
  );
}
            

              
                Copy
              
            
          

In diesem Beispiel, wenn UserProfile und UserSettings irgendwie genau die gleichen Benutzerdaten anfordern (z. B. beide fordern /api/users/current an), stellt SWR sicher, dass nur eine Netzwerkanfrage gestellt wird. Die Option suspense: true ermöglicht es SWR, ein Promise zu werfen, wodurch React Suspense die Ladezustände verwalten kann.

b. React Query (TanStack Query)

React Query ist eine umfassendere Bibliothek für Datenabruf und Zustandsverwaltung. Sie bietet leistungsstarke Hooks zum Abrufen, Cachen, Synchronisieren und Aktualisieren des Serverzustands in Ihren React-Anwendungen. React Query verwaltet auch von Natur aus einen gemeinsamen Ressourcenpool, indem es Abfrageergebnisse in einem globalen Cache speichert.

Zu seinen Funktionen gehören Hintergrund-Refetching, intelligente Wiederholungsversuche, Paginierung, optimistische Updates und eine tiefe Integration mit den React DevTools, was es für komplexe, datenintensive globale Anwendungen geeignet macht.

            import { useQuery, QueryClient, QueryClientProvider } from '@tanstack/react-query';
import React, { Suspense } from 'react';

const queryClient = new QueryClient({ 
  defaultOptions: { 
    queries: { 
      suspense: true,
      staleTime: 1000 * 60 * 5, // Data is considered fresh for 5 minutes
    }
  }
});

const fetchUserById = async (userId) => {
  const res = await fetch(`/api/users/${userId}`);
  if (!res.ok) throw new Error('Failed to fetch user');
  return res.json();
};

function UserInfoDisplay({ userId }) {
  const { data: user } = useQuery({ queryKey: ['user', userId], queryFn: () => fetchUserById(userId) });
  return <div>Benutzer: <b>{user.name}</b> ({user.email})</div>;
}

function UserDashboard({ userId }) {
  return (
    <div>
      <h3>Benutzer-Dashboard</h3>
      <UserInfoDisplay userId={userId} />
      <!-- Potenziell andere Komponenten, die Benutzerdaten benötigen -->
    </div>
  );
}

function App() {
  return (
    <QueryClientProvider client={queryClient}>
      <Suspense fallback={<div>Anwendungsdaten werden geladen...</div>}>
        <UserDashboard userId="user789" />
      </Suspense>
    </QueryClientProvider>
  );
}
            

              
                Copy
              
            
          

Hier greift useQuery mit demselben queryKey (z. B. ['user', 'user789']) auf dieselben Daten im Cache von React Query zu. Wenn eine Abfrage läuft, warten nachfolgende Aufrufe mit demselben Schlüssel auf das laufende Promise, ohne neue Netzwerkanfragen zu initiieren. Dieses robuste Ressourcen-Pooling wird automatisch gehandhabt und ist ideal für die Verwaltung des gemeinsamen Datenladens in komplexen globalen Anwendungen.

c. Apollo Client (GraphQL)

Für Anwendungen, die GraphQL verwenden, ist Apollo Client eine beliebte Wahl. Er verfügt über einen integrierten normalisierten Cache, der als ausgeklügelter Ressourcenpool fungiert. Wenn Sie Daten mit GraphQL-Abfragen abrufen, speichert Apollo die Daten in seinem Cache, und nachfolgende Abfragen für dieselben Daten (selbst wenn sie unterschiedlich strukturiert sind) werden oft aus dem Cache bedient, ohne eine Netzwerkanfrage zu stellen.

Apollo Client unterstützt auch Suspense (in einigen Konfigurationen experimentell, aber schnell ausgereift). Durch die Verwendung des useSuspenseQuery-Hooks (oder die Konfiguration von useQuery für Suspense) können Komponenten die deklarativen Ladezustände nutzen, die Suspense bietet.

            import { ApolloClient, InMemoryCache, ApolloProvider, useSuspenseQuery, gql } from '@apollo/client';
import React, { Suspense } from 'react';

const client = new ApolloClient({
  uri: 'https://your-graphql-api.com/graphql',
  cache: new InMemoryCache(),
});

const GET_PRODUCT_DETAILS = gql`
  query GetProductDetails($productId: ID!) {
    product(id: $productId) {
      id
      name
      description
      price
      currency
    }
  }
`;

function ProductDisplay({ productId }) {
  // Apollo Client's cache acts as the resource pool
  const { data } = useSuspenseQuery(GET_PRODUCT_DETAILS, {
    variables: { productId },
  });
  const { product } = data;
  return (
    <div>
      <h2>{product.name} ({product.currency} {product.price})</h2>
      <p>{product.description}</p>
    </div>
  );
}

function RelatedProducts({ productId }) {
  // Another component using potentially overlapping data
  // Apollo's cache will ensure efficient fetching
  const { data } = useSuspenseQuery(GET_PRODUCT_DETAILS, {
    variables: { productId },
  });
  const { product } = data;
  return (
    <div>
      <h3>Kunden gefiel auch für {product.name}</h3>
      <!-- Logic to display related products -->
    </div>
  );
}

function App() {
  return (
    <ApolloProvider client={client}>
      <Suspense fallback={<div>Produktinformationen werden geladen...</div>}>
        <ProductDisplay productId="prod123" />
        <RelatedProducts productId="prod123" /> 
      </Suspense>
    </ApolloProvider>
  );
}
```

import { queryClient } from './queryClientConfig'; // Assume queryClient is exported
import { fetchUserDetails } from './api'; // Assume API function

// Example: Prefetching user data on mouse hover
function UserLink({ userId, children }) {
  const handleMouseEnter = () => {
    queryClient.prefetchQuery({ queryKey: ['user', userId], queryFn: () => fetchUserDetails(userId) });
  };

  return (
    <a href={`/users/${userId}`} onMouseEnter={handleMouseEnter}>
      {children}
    </a>
  );
}

// When UserProfile component renders, data is likely already in cache:
// function UserProfile({ userId }) {
//   const { data: user } = useQuery({ queryKey: ['user', userId], queryFn: () => fetchUserDetails(userId), suspense: true });
//   return <h2>{user.name}</h2>;
// }
            

              
                Copy
              
            
          

            class ResourcePoolManager {
  constructor() {
    this.pool = new Map(); // Stores promises or resolved data/resources
    this.subscribers = new Map(); // Tracks components waiting for a resource
  }

  // Acquire a resource (data, WebSocket connection, etc.)
  acquire(key, resourceFetcher) {
    if (this.pool.has(key)) {
      return this.pool.get(key);
    }

    let status = 'pending';
    let result;
    const suspender = resourceFetcher()
      .then(
        (r) => {
          status = 'success';
          result = r;
          this.notifySubscribers(key, r); // Notify waiting components
        },
        (e) => {
          status = 'error';
          result = e;
          this.notifySubscribers(key, e); // Notify with error
          this.pool.delete(key); // Clean up failed resource
        }
      );
    
    const resourceWrapper = { read() {
      if (status === 'pending') throw suspender;
      if (status === 'error') throw result;
      return result;
    }};

    this.pool.set(key, resourceWrapper);
    return resourceWrapper;
  }

  // For scenarios where resources need explicit release (e.g., WebSockets)
  release(key) {
    if (this.pool.has(key)) {
      // Perform cleanup logic specific to the resource type
      // e.g., this.pool.get(key).close();
      this.pool.delete(key);
      this.subscribers.delete(key);
    }
  }

  // Mechanism to subscribe/notify components (simplified)
  // In a real scenario, this would likely involve React's context or a custom hook
  notifySubscribers(key, data) {
    // Implement actual notification logic, e.g., force update subscribers
  }
}

// Global instance or passed via Context
const globalResourceManager = new ResourcePoolManager();

// Usage with a custom hook for Suspense
function useResource(key, fetcherFn) {
  const resourceWrapper = globalResourceManager.acquire(key, fetcherFn);
  return resourceWrapper.read(); // Will suspend or return data
}

// Component usage:
function FinancialDataWidget({ stockSymbol }) {
  const data = useResource(`stock-${stockSymbol}`, () => fetchStockData(stockSymbol));
  return <p>{stockSymbol}: {data.price}</p>;
}
            

              
                Copy
              
            
          

import React, { Suspense } from 'react';
import { useQuery, QueryClient, QueryClientProvider } from '@tanstack/react-query';

const queryClient = new QueryClient({
  defaultOptions: {
    queries: {
      suspense: true,
      staleTime: 1000 * 60 * 10, // Cache for 10 minutes
      refetchOnWindowFocus: false, // For global apps, might want less aggressive refetching
    },
  },
});

const fetchCategories = async () => {
  console.log('Nachrichtenkategorien werden abgerufen...'); // Wird nur einmal protokolliert
  const res = await fetch('/api/news/categories');
  if (!res.ok) throw new Error('Kategorien konnten nicht abgerufen werden');
  return res.json();
};

const fetchHeadlinesByCategory = async (category) => {
  console.log(`Schlagzeilen werden für ${category} abgerufen`); // Wird pro Kategorie protokolliert
  const res = await fetch(`/api/news/headlines?category=${category}`);
  if (!res.ok) throw new Error(`Schlagzeilen für ${category} konnten nicht abgerufen werden`);
  return res.json();
};

function CategorySelector() {
  const { data: categories } = useQuery({ queryKey: ['newsCategories'], queryFn: fetchCategories });
  return (
    <ul>
      {categories.map((category) => (
        <li key={category.id}>{category.name}</li>
      ))}
    </ul>
  );
}

function TrendingTopics() {
  const { data: categories } = useQuery({ queryKey: ['newsCategories'], queryFn: fetchCategories });
  const trendingCategory = categories.find(cat => cat.isTrending)?.name || categories[0]?.name;
  
  // This would fetch headlines for the trending category, sharing the category data
  const { data: trendingHeadlines } = useQuery({ 
    queryKey: ['headlines', trendingCategory], 
    queryFn: () => fetchHeadlinesByCategory(trendingCategory),
  });

  return (
    <div>
      <h3>Trend-Nachrichten in {trendingCategory}</h3>
      <ul>
        {trendingHeadlines.slice(0, 3).map((headline) => (
          <li key={headline.id}>{headline.title}</li>
        ))}
      </ul>
    </div>
  );
}

function AppContent() {
  return (
    <div>
      <h1>Globaler Nachrichten-Hub</h1>
      <div style={{ display: 'grid', gridTemplateColumns: '1fr 1fr', gap: '20px' }}>
        <section>
          <h2>Verfügbare Kategorien</h2>
          <CategorySelector />
        </section>
        <section>
          <TrendingTopics />
        </section>
      </div>
    </div>
  );
}

function App() {
  return (
    <QueryClientProvider client={queryClient}>
      <Suspense fallback={<div>Globale Nachrichtendaten werden geladen...</div>}>
        <AppContent />
      </Suspense>
    </QueryClientProvider>
  );
}
```