Beheersing van React Suspense: Globale Applicaties Optimaliseren met Gedeeld Resourcepoolbeheer voor het Laden van Data

In het uitgestrekte en onderling verbonden landschap van moderne webontwikkeling is het bouwen van performante, schaalbare en veerkrachtige applicaties van het grootste belang, vooral wanneer men een diverse, wereldwijde gebruikersgroep bedient. Gebruikers op verschillende continenten verwachten naadloze ervaringen, ongeacht hun netwerkomstandigheden of de capaciteiten van hun apparaat. React blijft ontwikkelaars in staat stellen om aan deze hoge verwachtingen te voldoen met zijn innovatieve functies. Een van de meest transformerende toevoegingen is React Suspense, een krachtig mechanisme dat is ontworpen om asynchrone operaties, voornamelijk het ophalen van data en code splitting, te orkestreren op een manier die een soepelere, gebruiksvriendelijkere ervaring biedt.

Hoewel Suspense inherent helpt bij het beheren van de laadstatussen van individuele componenten, komt de ware kracht naar voren wanneer we intelligente strategieën toepassen op hoe data wordt opgehaald en gedeeld binnen een hele applicatie. Dit is waar Resource Pool Management voor het gezamenlijk laden van data niet alleen een best practice wordt, maar een kritieke architectonische overweging. Stel je een applicatie voor waar meerdere componenten, misschien op verschillende pagina's of binnen één dashboard, allemaal hetzelfde stukje data nodig hebben – het profiel van een gebruiker, een lijst met landen of realtime wisselkoersen. Zonder een samenhangende strategie zou elk component zijn eigen identieke dataverzoek kunnen initiëren, wat leidt tot redundante netwerkoproepen, verhoogde serverbelasting, tragere applicatieprestaties en een suboptimale ervaring voor gebruikers wereldwijd.

Deze uitgebreide gids duikt diep in de principes en praktische toepassingen van het benutten van React Suspense in combinatie met robuust resourcepoolbeheer. We zullen onderzoeken hoe u uw data-ophaallaag kunt architectureren om efficiëntie te garanderen, redundantie te minimaliseren en uitzonderlijke prestaties te leveren, ongeacht de geografische locatie of netwerkinfrastructuur van uw gebruikers. Bereid u voor om uw aanpak van het laden van data te transformeren en het volledige potentieel van uw React-applicaties te ontsluiten.

React Suspense Begrijpen: Een Paradigmaverschuiving in Asynchrone UI

Voordat we ons verdiepen in resource pooling, laten we een duidelijk begrip van React Suspense vaststellen. Traditioneel gezien omvatte het afhandelen van asynchrone operaties in React het handmatig beheren van laad-, fout- en datastatussen binnen componenten, wat vaak leidde tot een patroon dat bekend staat als "fetch-on-render." Deze aanpak kon resulteren in een cascade van laad-spinners, complexe conditionele renderinglogica en een minder dan ideale gebruikerservaring.

React Suspense introduceert een declaratieve manier om React te vertellen: "Hé, dit component is nog niet klaar om te renderen omdat het op iets wacht." Wanneer een component opschort (bijv. tijdens het ophalen van data of het laden van een code split chunk), kan React de rendering pauzeren, een fallback-UI tonen (zoals een spinner of een skeletscherm) die is gedefinieerd door een bovenliggende <Suspense>-grens, en vervolgens de rendering hervatten zodra de data of code beschikbaar is. Dit centraliseert het beheer van de laadstatus, waardoor de componentlogica schoner wordt en UI-overgangen soepeler verlopen.

Het kernidee achter Suspense voor Data Fetching is dat data-ophaalbibliotheken direct kunnen integreren met de renderer van React. Wanneer een component probeert data te lezen die nog niet beschikbaar is, "gooit" de bibliotheek een promise. React vangt deze promise op, schort het component op en wacht tot de promise is opgelost voordat de render opnieuw wordt geprobeerd. Dit elegante mechanisme stelt componenten in staat om "data-agnostisch" hun databehoeften te declareren, terwijl de Suspense-grens de wachtstatus afhandelt.

De Uitdaging: Redundante Data-ophaling in Globale Applicaties

Hoewel Suspense lokale laadstatussen vereenvoudigt, lost het niet automatisch het probleem op van meerdere componenten die onafhankelijk van elkaar dezelfde data ophalen. Denk aan een wereldwijde e-commerce applicatie:

• Een gebruiker navigeert naar een productpagina.
• Het <ProductDetails /> component haalt productinformatie op.
• Tegelijkertijd heeft een <RecommendedProducts /> zijbalkcomponent mogelijk ook enkele attributen van hetzelfde product nodig om gerelateerde items voor te stellen.
• Een <UserReviews /> component kan de beoordelingsstatus van de huidige gebruiker ophalen, wat het gebruikers-ID vereist – data die al door een bovenliggend component is opgehaald.

In een naïeve implementatie kan elk van deze componenten zijn eigen netwerkverzoek voor dezelfde of overlappende data initiëren. De gevolgen zijn aanzienlijk, vooral voor een wereldwijd publiek:

• Verhoogde Latentie en Langzamere Laadtijden: Meerdere verzoeken betekenen meer round-trips over potentieel lange afstanden, wat latentieproblemen verergert voor gebruikers die ver van uw servers verwijderd zijn.
• Hogere Serverbelasting: Uw backend-infrastructuur moet dubbele verzoeken verwerken en beantwoorden, wat onnodige resources verbruikt.
• Verspilde Bandbreedte: Gebruikers, vooral die op mobiele netwerken of in regio's met dure data-abonnementen, verbruiken meer data dan nodig.
• Inconsistente UI-Statussen: Er kunnen race conditions optreden waarbij verschillende componenten licht verschillende versies van "dezelfde" data ontvangen als er updates plaatsvinden tussen de verzoeken.
• Verminderde Gebruikerservaring (UX): Flikkerende content, vertraagde interactiviteit en een algemeen gevoel van traagheid kunnen gebruikers afschrikken, wat wereldwijd leidt tot hogere bounce rates.
• Complexe Client-Side Logica: Ontwikkelaars nemen vaak hun toevlucht tot ingewikkelde memoization- of state-managementoplossingen binnen componenten om dit te beperken, wat de complexiteit verhoogt.

Dit scenario onderstreept de noodzaak van een meer geavanceerde aanpak: Resourcepoolbeheer.

Introductie van Resourcepoolbeheer voor Gedeeld Data Laden

Resourcepoolbeheer, in de context van React Suspense en het laden van data, verwijst naar de systematische aanpak van het centraliseren, optimaliseren en delen van data-ophaaloperaties en hun resultaten binnen een applicatie. In plaats van dat elk component onafhankelijk een dataverzoek initieert, fungeert een "pool" of "cache" als tussenpersoon, die ervoor zorgt dat een bepaald stuk data slechts één keer wordt opgehaald en vervolgens beschikbaar wordt gesteld aan alle aanvragende componenten. Dit is analoog aan hoe databaseverbindingspools of threadpools werken: hergebruik bestaande resources in plaats van nieuwe te creëren.

De primaire doelen van het implementeren van een gedeelde resourcepool voor het laden van data zijn:

• Elimineer Redundante Netwerkverzoeken: Als data al wordt opgehaald of recent is opgehaald, bied dan de bestaande data of de lopende promise van die data aan.
• Verbeter de Prestaties: Verminder de latentie door data vanuit de cache te serveren of door te wachten op een enkel, gedeeld netwerkverzoek.
• Verbeter de Gebruikerservaring: Lever snellere, consistentere UI-updates met minder laadstatussen.
• Verminder de Serverbelasting: Verlaag het aantal verzoeken dat uw backend-services bereikt.
• Vereenvoudig de Componentlogica: Componenten worden eenvoudiger en hoeven alleen hun databehoeften te declareren, zonder zich zorgen te maken over hoe of wanneer de data wordt opgehaald.
• Beheer de Datalevenscyclus: Bied mechanismen voor data-revalidatie, -invalidatie en garbage collection.

Wanneer geïntegreerd met React Suspense, kan deze pool de promises van lopende data-ophalingen bevatten. Wanneer een component probeert data uit de pool te lezen die nog niet beschikbaar is, retourneert de pool de lopende promise, waardoor het component opschort. Zodra de promise is opgelost, zullen alle componenten die op die promise wachten, opnieuw renderen met de opgehaalde data. Dit creëert een krachtige synergie voor het beheren van complexe asynchrone stromen.

Strategieën voor Effectief Beheer van Gedeelde Data-laadbronnen

Laten we verschillende robuuste strategieën verkennen voor het implementeren van gedeelde resourcepools voor het laden van data, variërend van aangepaste oplossingen tot het gebruik van volwassen bibliotheken.

1. Memoization en Caching in de Datalag

In zijn eenvoudigste vorm kan resource pooling worden bereikt door middel van client-side memoization en caching. Dit houdt in dat de resultaten van dataverzoeken (of de promises zelf) worden opgeslagen in een tijdelijk opslagmechanisme, waardoor toekomstige identieke verzoeken worden voorkomen. Dit is een fundamentele techniek die ten grondslag ligt aan meer geavanceerde oplossingen.

Aangepaste Cache-implementatie:

U kunt een eenvoudige in-memory cache bouwen met JavaScript's Map of WeakMap. Een Map is geschikt voor algemene caching waarbij sleutels primitieve typen of objecten zijn die u beheert, terwijl WeakMap uitstekend is voor caching waarbij sleutels objecten zijn die mogelijk door garbage collection worden opgeruimd, waardoor de gecachte waarde ook kan worden opgeruimd.

            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); // Verwijder item als fetch is mislukt
      throw error;
    });

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

// Voorbeeldgebruik met Suspense
let userData = null;
function readUser(userId) {
  if (userData === null) {
    const promise = fetchWithCache(`/api/users/${userId}`);
    promise.then(data => (userData = data));
    throw promise; // Suspense zal deze promise opvangen
  }
  return userData;
}

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

            

              
                Copy
              
            
          

Dit eenvoudige voorbeeld laat zien hoe een gedeelde dataCache promises kan opslaan. Wanneer readUser meerdere keren wordt aangeroepen met dezelfde userId, retourneert het ofwel de gecachte promise (als deze nog loopt) of de gecachte data (als deze is opgelost), waardoor redundante fetches worden voorkomen. De belangrijkste uitdaging bij aangepaste caches is het beheren van cache-invalidatie, -revalidatie en geheugenlimieten.

2. Gecentraliseerde Data Providers en React Context

Voor applicatie-specifieke data die mogelijk gestructureerd is of complexer state management vereist, kan React Context dienen als een krachtige basis voor een gedeelde data provider. Een centraal provider-component kan de logica voor het ophalen en cachen van data beheren en een consistente interface bieden voor onderliggende componenten om data te consumeren.

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

const UserContext = createContext(null);

const userResourceCache = new Map(); // Een gedeelde cache voor 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(); // Zal opschorten als data niet gereed is

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

export function useUser() {
  const context = useContext(UserContext);
  if (context === null) {
    throw new Error('useUser moet binnen een UserProvider worden gebruikt');
  }
  return context;
}

// Gebruik in componenten:
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'; // Neem aan dat dit uit auth context of prop komt
  return (
    <Suspense fallback={<div>Gebruikersdata laden...</div>}>
      <UserProvider userId={currentUserId}>
        <UserGreeting />
        <UserAvatar />
        <!-- Andere componenten die gebruikersdata nodig hebben -->
      </UserProvider>
    </Suspense>
  );
}

            

              
                Copy
              
            
          

In dit voorbeeld haalt UserProvider de gebruikersdata op met een gedeelde cache. Alle onderliggende componenten die UserContext consumeren, krijgen toegang tot hetzelfde gebruikerobject (zodra het is opgelost) en zullen opschorten als de data nog wordt geladen. Deze aanpak centraliseert het ophalen van data en levert het declaratief aan een hele sub-boom.

3. Gebruikmaken van Data-ophaalbibliotheken met Suspense-ondersteuning

Voor de meeste wereldwijde applicaties kan het handmatig bouwen van een robuuste, voor Suspense geschikte data-ophaaloplossing met uitgebreide caching, revalidatie en foutafhandeling een aanzienlijke onderneming zijn. Dit is waar gespecialiseerde bibliotheken uitblinken. Deze bibliotheken zijn specifiek ontworpen om een resourcepool van data te beheren, naadloos te integreren met Suspense en geavanceerde functies out-of-the-box te bieden.

a. SWR (Stale-While-Revalidate)

Ontwikkeld door Vercel, is SWR een lichtgewicht data-ophaalbibliotheek die snelheid en reactiviteit vooropstelt. Het kernprincipe, "stale-while-revalidate," betekent dat het eerst de data uit de cache retourneert (stale), vervolgens deze opnieuw valideert door een fetch-verzoek te sturen, en ten slotte update met de verse data. Dit zorgt voor onmiddellijke UI-feedback terwijl de versheid van de data wordt gegarandeerd.

SWR bouwt automatisch een gedeelde cache (resourcepool) op basis van de verzoeksleutel. Als meerdere componenten useSWR('/api/data') gebruiken, zullen ze allemaal dezelfde gecachte data en dezelfde onderliggende fetch-promise delen, waardoor de resourcepool impliciet wordt beheerd.

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

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

function UserProfile({ userId }) {
  // SWR deelt automatisch de data en handelt Suspense af
  const { data: user } = useSWR(`/api/users/${userId}`, fetcher, { suspense: true });
  return <h2>Welkom, {user.name}</h2>;
}

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

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

            

              
                Copy
              
            
          

In dit voorbeeld, als UserProfile en UserSettings op de een of andere manier exact dezelfde gebruikersdata opvragen (bijv. beide vragen /api/users/current op), zorgt SWR ervoor dat er maar één netwerkverzoek wordt gedaan. De suspense: true optie stelt SWR in staat om een promise te gooien, waardoor React Suspense de laadstatussen kan beheren.

b. React Query (TanStack Query)

React Query is een meer omvattende bibliotheek voor data ophalen en state management. Het biedt krachtige hooks voor het ophalen, cachen, synchroniseren en bijwerken van server-state in uw React-applicaties. React Query beheert ook inherent een gedeelde resourcepool door query-resultaten op te slaan in een globale cache.

De functies omvatten achtergrond-refetching, intelligente retries, paginering, optimistische updates en diepe integratie met React DevTools, waardoor het geschikt is voor complexe, data-intensieve wereldwijde applicaties.

            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 wordt 5 minuten als vers beschouwd
    }
  }
});

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

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

function UserDashboard({ userId }) {
  return (
    <div>
      <h3>Gebruikersdashboard</h3>
      <UserInfoDisplay userId={userId} />
      <!-- Potentieel andere componenten die gebruikersdata nodig hebben -->
    </div>
  );
}

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

            

              
                Copy
              
            
          

Hier zal useQuery met dezelfde queryKey (bijv. ['user', 'user789']) toegang krijgen tot dezelfde data in de cache van React Query. Als een query onderweg is, zullen volgende aanroepen met dezelfde sleutel wachten op de lopende promise zonder nieuwe netwerkverzoeken te initiëren. Deze robuuste resource pooling wordt automatisch afgehandeld, wat het ideaal maakt voor het beheren van gedeeld data laden in complexe wereldwijde applicaties.

c. Apollo Client (GraphQL)

Voor applicaties die GraphQL gebruiken, is Apollo Client een populaire keuze. Het wordt geleverd met een geïntegreerde genormaliseerde cache die fungeert als een geavanceerde resourcepool. Wanneer u data ophaalt met GraphQL-query's, slaat Apollo de data op in zijn cache, en volgende query's voor dezelfde data (zelfs als ze anders gestructureerd zijn) zullen vaak vanuit de cache worden bediend zonder een netwerkverzoek.

Apollo Client ondersteunt ook Suspense (experimenteel in sommige configuraties, maar wordt snel volwassen). Door de useSuspenseQuery hook te gebruiken (of useQuery voor Suspense te configureren), kunnen componenten profiteren van de declaratieve laadstatussen die Suspense biedt.

            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 }) {
  // De cache van Apollo Client fungeert als de resourcepool
  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 }) {
  // Een ander component dat mogelijk overlappende data gebruikt
  // De cache van Apollo zorgt voor efficiënt ophalen
  const { data } = useSuspenseQuery(GET_PRODUCT_DETAILS, {
    variables: { productId },
  });
  const { product } = data;
  return (
    <div>
      <h3>Klanten vonden ook leuk voor {product.name}</h3>
      <!-- Logica om gerelateerde producten weer te geven -->
    </div>
  );
}

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

import { queryClient } from './queryClientConfig'; // Neem aan dat queryClient is geëxporteerd
import { fetchUserDetails } from './api'; // Neem aan dat API-functie bestaat

// Voorbeeld: Gebruikersdata prefetchen bij 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>
  );
}

// Wanneer het UserProfile-component rendert, is de data waarschijnlijk al in de 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(); // Slaat promises of opgeloste data/resources op
    this.subscribers = new Map(); // Houdt bij welke componenten op een resource wachten
  }

  // Een resource verkrijgen (data, WebSocket-verbinding, 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); // Stel wachtende componenten op de hoogte
        },
        (e) => {
          status = 'error';
          result = e;
          this.notifySubscribers(key, e); // Stel op de hoogte van de fout
          this.pool.delete(key); // Ruim mislukte resource op
        }
      );
    
    const resourceWrapper = { read() {
      if (status === 'pending') throw suspender;
      if (status === 'error') throw result;
      return result;
    }};

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

  // Voor scenario's waarin resources expliciet moeten worden vrijgegeven (bijv. WebSockets)
  release(key) {
    if (this.pool.has(key)) {
      // Voer opruimlogica uit specifiek voor het resourcetype
      // bijv. this.pool.get(key).close();
      this.pool.delete(key);
      this.subscribers.delete(key);
    }
  }

  // Mechanisme om componenten te abonneren/informeren (vereenvoudigd)
  // In een reëel scenario zou dit waarschijnlijk React's context of een custom hook omvatten
  notifySubscribers(key, data) {
    // Implementeer daadwerkelijke notificatielogica, bijv. forceer update van abonnees
  }
}

// Globale instantie of doorgegeven via Context
const globalResourceManager = new ResourcePoolManager();

// Gebruik met een custom hook voor Suspense
function useResource(key, fetcherFn) {
  const resourceWrapper = globalResourceManager.acquire(key, fetcherFn);
  return resourceWrapper.read(); // Zal opschorten of data retourneren
}

// Componentgebruik:
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 voor 10 minuten
      refetchOnWindowFocus: false, // Voor wereldwijde apps is minder agressief refetchen wellicht wenselijk
    },
  },
});

const fetchCategories = async () => {
  console.log('Nieuwscategorieën ophalen...'); // Wordt slechts één keer gelogd
  const res = await fetch('/api/news/categories');
  if (!res.ok) throw new Error('Kon categorieën niet ophalen');
  return res.json();
};

const fetchHeadlinesByCategory = async (category) => {
  console.log(`Koppen ophalen voor: ${category}`); // Wordt per categorie gelogd
  const res = await fetch(`/api/news/headlines?category=${category}`);
  if (!res.ok) throw new Error(`Kon koppen niet ophalen voor ${category}`);
  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;
  
  // Dit zou koppen ophalen voor de trending categorie, en de categoriedata delen
  const { data: trendingHeadlines } = useQuery({ 
    queryKey: ['headlines', trendingCategory], 
    queryFn: () => fetchHeadlinesByCategory(trendingCategory),
  });

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

function AppContent() {
  return (
    <div>
      <h1>Wereldwijde Nieuwshub</h1>
      <div style={{ display: 'grid', gridTemplateColumns: '1fr 1fr', gap: '20px' }}>
        <section>
          <h2>Beschikbare Categorieën</h2>
          <CategorySelector />
        </section>
        <section>
          <TrendingTopics />
        </section>
      </div>
    </div>
  );
}

function App() {
  return (
    <QueryClientProvider client={queryClient}>
      <Suspense fallback={<div>Wereldwijde nieuwsdata laden...</div>}>
        <AppContent />
      </Suspense>
    </QueryClientProvider>
  );
}
```