Posso usar o Intlayer sem um provider global?

    Sim. getIntlayer e getDictionary são funções simples que não precisam de nenhum provider, e useIntlayer também funciona fora de um.

    ts
    import { getIntlayer } from "intlayer";

const { title } = getIntlayer("app"); // Nenhum locale passado

    Qual locale é usado?

    Um locale passado explicitamente sempre tem prioridade. Caso contrário, o locale é resolvido nesta ordem:

    1. O locale da requisição atual, no servidor, quando uma integração do Intlayer a trata: os middlewares de express-intlayer, fastify-intlayer, hono-intlayer, adonis-intlayer, elysia-intlayer, remix-intlayer e astro-intlayer, ou o IntlayerProvider nos React Server Components.
    2. O locale armazenado no navegador (cookie, localStorage, sessionStorage), aquele que o seu seletor de idioma persiste.
    3. O defaultLocale da sua configuração.

    Cada requisição é resolvida a partir dos seus próprios cookies e headers, e mantida em um escopo próprio da requisição. Usuários simultâneos com locales diferentes nunca compartilham o locale.

    A mesma resolução se aplica a getDictionary, às chamadas reescritas pela otimização do build, e a useIntlayer e useDictionaryDynamic renderizados fora de um provider.

    otimização do build

    Server Components do Next.js

    No Next.js, o locale da requisição só pode ser lido de forma assíncrona, por headers() e cookies(). Use getIntlayerAsync, que o aguarda da mesma forma que getLocale() de next-intlayer/server:

    getIntlayerAsync
    tsx
    import { getIntlayerAsync } from "intlayer";

export const generateMetadata = async () => {
  const { title } = await getIntlayerAsync("app"); // Locale da requisição

  return { title };
};

    Ler os headers faz a rota passar para renderização dinâmica. Quando o IntlayerProvider já fornece o locale, os headers não são lidos e a rota continua estática.

    Performance: com ou sem provider

    O conteúdo é o mesmo. A diferença está na reatividade e no custo de renderização.

    Com um providerSem provider
    Troca de localeOs componentes são renderizados novamente no lugar, sem recarregarNada é renderizado novamente; o novo locale aparece na próxima chamada (navegação, recarregamento)
    Custo de uma leituraLeitura do contexto e inscrição no localeUma chamada de função memoizada, mesmo objeto para a mesma key + locale
    Custo de uma trocaNova renderização de cada consumidorNenhum
    Renderização no servidorO servidor e o navegador renderizam o mesmo localeFora de uma integração de requisição, o servidor renderiza o defaultLocale e o navegador o armazenado: possível hydration mismatch
    BundleO código do providerCerca de 100 bytes (gzip) para ler o locale armazenado, em cache até a próxima troca

    Mantenha o provider em apps interativos que trocam de locale no lugar ou renderizam no servidor. Dispense-o em backends, scripts, páginas estáticas cujo locale vem da URL (passe-o explicitamente) ou código que lê o conteúdo uma única vez.

    Veja getIntlayer para mais detalhes.

    getIntlayer