Kann ich Intlayer ohne globalen Provider verwenden?

    Ja. getIntlayer und getDictionary sind einfache Funktionen, die keinen Provider benötigen, und useIntlayer funktioniert auch außerhalb eines Providers.

    ts
    import { getIntlayer } from "intlayer";
    
    const { title } = getIntlayer("app"); // Keine Locale übergeben
    

    Welche Locale wird verwendet?

    Eine explizit übergebene Locale hat immer Vorrang. Andernfalls wird die Locale in dieser Reihenfolge aufgelöst:

    1. Die Locale der aktuellen Anfrage, auf dem Server, wenn eine Intlayer-Integration sie verarbeitet: die Middlewares von express-intlayer, fastify-intlayer, hono-intlayer, adonis-intlayer, elysia-intlayer, remix-intlayer und astro-intlayer oder IntlayerProvider in React Server Components.
    2. Die im Browser gespeicherte Locale (Cookie, localStorage, sessionStorage), die dein Sprachumschalter speichert.
    3. Die defaultLocale deiner Konfiguration.

    Jede Anfrage wird aus ihren eigenen Cookies und Headern aufgelöst und in einem anfragespezifischen Kontext gehalten. Gleichzeitige Nutzer mit unterschiedlichen Locales teilen sich nie eine Locale.

    Dieselbe Auflösung gilt für getDictionary, für die von der Build-Optimierung umgeschriebenen Aufrufe sowie für useIntlayer und useDictionaryDynamic, wenn sie außerhalb eines Providers gerendert werden.

    Next.js Server Components

    In Next.js ist die Locale der Anfrage nur asynchron lesbar, über headers() und cookies(). Verwende getIntlayerAsync, das auf sie genauso wartet wie getLocale() aus next-intlayer/server:

    tsx
    import { getIntlayerAsync } from "intlayer";
    
    export const generateMetadata = async () => {
      const { title } = await getIntlayerAsync("app"); // Locale der Anfrage
    
      return { title };
    };
    

    Das Lesen der Header schaltet die Route auf dynamisches Rendering um. Stellt IntlayerProvider die Locale bereits bereit, werden die Header nicht gelesen und die Route bleibt statisch.

    Performance: mit oder ohne Provider

    Der Inhalt ist derselbe. Der Unterschied betrifft Reaktivität und Rendering-Kosten.

    Mit ProviderOhne Provider
    Locale-WechselKomponenten werden direkt neu gerendert, ohne NeuladenNichts wird neu gerendert; die neue Locale erscheint beim nächsten Aufruf (Navigation, Neuladen)
    Kosten eines LesezugriffsKontextzugriff und Abonnement der LocaleEin memoisierter Funktionsaufruf, dasselbe Objekt für dieselbe key + locale
    Kosten eines WechselsNeues Rendern jedes KonsumentenKeine
    Server-RenderingServer und Browser rendern dieselbe LocaleAußerhalb einer Anfrage-Integration rendert der Server die defaultLocale und der Browser die gespeicherte Locale: möglicher Hydration-Mismatch
    BundleDer Provider-CodeEtwa 100 Byte (gzip), um die gespeicherte Locale zu lesen, zwischengespeichert bis zum nächsten Wechsel

    Behalte den Provider für interaktive Apps, die die Locale direkt wechseln oder auf dem Server rendern. Verzichte darauf bei Backends, Skripten, statischen Seiten, deren Locale aus der URL kommt (übergib sie explizit), oder Code, der Inhalte nur einmal liest.

    Siehe getIntlayer für weitere Details.