Posso usare Intlayer senza un provider globale?

    Sì. getIntlayer e getDictionary sono semplici funzioni che non richiedono alcun provider, e anche useIntlayer funziona fuori da un provider.

    ts
    import { getIntlayer } from "intlayer";

const { title } = getIntlayer("app"); // Nessuna locale passata

    Quale locale viene usata?

    Una locale passata esplicitamente ha sempre la precedenza. Altrimenti, la locale viene risolta in questo ordine:

    1. La locale della richiesta corrente, sul server, quando un'integrazione Intlayer la gestisce: i middleware di express-intlayer, fastify-intlayer, hono-intlayer, adonis-intlayer, elysia-intlayer, remix-intlayer e astro-intlayer, o IntlayerProvider nei React Server Components.
    2. La locale salvata nel browser (cookie, localStorage, sessionStorage), quella che il tuo selettore di lingua rende persistente.
    3. La defaultLocale della tua configurazione.

    Ogni richiesta viene risolta dai propri cookie e header, e conservata in un contesto dedicato alla richiesta. Utenti simultanei con locale diverse non condividono mai la locale.

    La stessa risoluzione si applica a getDictionary, alle chiamate riscritte dall'ottimizzazione del build, e a useIntlayer e useDictionaryDynamic renderizzati fuori da un provider.

    ottimizzazione del build

    Server Components di Next.js

    Su Next.js, la locale della richiesta è leggibile solo in modo asincrono, tramite headers() e cookies(). Usa getIntlayerAsync, che la attende come fa getLocale() di next-intlayer/server:

    getIntlayerAsync
    tsx
    import { getIntlayerAsync } from "intlayer";

export const generateMetadata = async () => {
  const { title } = await getIntlayerAsync("app"); // Locale della richiesta

  return { title };
};

    Leggere gli header porta la route al rendering dinamico. Quando IntlayerProvider fornisce già la locale, gli header non vengono letti e la route resta statica.

    Performance: con o senza provider

    Il contenuto è lo stesso. La differenza riguarda la reattività e il costo di rendering.

    Con un providerSenza provider
    Cambio di localeI componenti vengono ri-renderizzati sul posto, senza ricaricareNulla viene ri-renderizzato; la nuova locale compare alla chiamata successiva (navigazione, ricaricamento)
    Costo di una letturaLettura del contesto e sottoscrizione alla localeUna chiamata di funzione memoizzata, stesso oggetto per la stessa key + locale
    Costo di un cambioNuovo rendering di ogni consumerNessuno
    Rendering sul serverServer e browser renderizzano la stessa localeFuori da un'integrazione di richiesta, il server renderizza la defaultLocale e il browser quella salvata: possibile hydration mismatch
    BundleIl codice del providerCirca 100 byte (gzip) per leggere la locale salvata, in cache fino al cambio successivo

    Tieni il provider per le app interattive che cambiano locale sul posto o renderizzano sul server. Fanne a meno per backend, script, pagine statiche la cui locale viene dall'URL (passala esplicitamente) o codice che legge il contenuto una sola volta.

    Vedi getIntlayer per maggiori dettagli.

    getIntlayer