O design modular do Firebase JS SDK oferece muito mais controle sobre como seu aplicativo é criado. Essa flexibilidade permite que você personalize suas dependências para sua plataforma e otimize o tamanho do pacote eliminando recursos desnecessários.
Existem duas maneiras de inicializar a biblioteca Auth: a função getAuth() e a função initializeAuth() . O primeiro, getAuth() , fornece tudo o que seu aplicativo precisa para aproveitar todos os recursos que a biblioteca Auth tem a oferecer. A desvantagem é que ele extrai muito código que potencialmente não é utilizado pelo seu aplicativo. Ele também pode extrair código que simplesmente não é compatível com a plataforma que você está almejando, causando erros. Para evitar esses problemas, você pode usar initializeAuth() , que utiliza um mapa de dependências. A função getAuth() simplesmente chama initializeAuth() com todas as dependências especificadas. Para ilustrar, aqui está o equivalente a getAuth() em ambientes de navegador:
import {initializeAuth, browserLocalPersistence, browserPopupRedirectResolver, browserSessionPersistence, indexedDBLocalPersistence} from "firebase/auth";
import {initializeApp} from "firebase/app";
const app = initializeApp({/** Your app config */});
const auth = initializeAuth(app, {
persistence: [indexedDBLocalPersistence, browserLocalPersistence, browserSessionPersistence],
popupRedirectResolver: browserPopupRedirectResolver,
});
Adaptando suas dependências
Nem todos os aplicativos usam a família de funções signInWithPopup ou signInWithRedirect . Muitos aplicativos não precisarão da flexibilidade que indexedDB oferece ou não precisarão da capacidade de suportar indexedDB e localStorage caso um não esteja disponível. Nesses casos, o getAuth() padrão inclui muito código não utilizado que aumenta o tamanho dos pacotes sem motivo. Em vez disso, esses aplicativos podem personalizar suas dependências. Por exemplo, se seu aplicativo usa apenas autenticação de link de e-mail e localStorage é suficiente (porque você não está usando scripts da Web ou de service worker), você pode eliminar muito código inicializando o Auth assim:
import {initializeAuth, browserLocalPersistence} from "firebase/auth";
import {initializeApp} from "firebase/app";
const app = initializeApp({/** Your app config */});
const auth = initializeAuth(app, {
persistence: browserLocalPersistence,
// No popupRedirectResolver defined
});
Com esse código, você removeu três grandes dependências que seu aplicativo não precisa, reduzindo significativamente a quantidade de largura de banda que seus usuários usam sempre que visitam seu site.
Considerações específicas da plataforma
Em muitos casos, você precisa definir manualmente as dependências do Auth para evitar erros na inicialização. A função getAuth() assume uma plataforma específica. Para o ponto de entrada padrão, é um ambiente de navegador e para o ponto de entrada Cordova, é um ambiente Cordova. Mas às vezes as necessidades da sua aplicação específica entram em conflito com essas suposições. Para scripts de trabalho da Web e de serviço, por exemplo, a implementação padrão getAuth() extrai código que lê do objeto window , o que causará erros. Nesses casos, é necessário adequar suas dependências. O código a seguir é apropriado para inicializar a biblioteca Auth em um contexto de service worker:
import {initializeAuth, indexedDBLocalPersistence} from "firebase/auth";
import {initializeApp} from "firebase/app";
const app = initializeApp({/** Your app config */});
const auth = initializeAuth(app, {
persistence: indexedDBLocalPersistence,
// No popupRedirectResolver defined
});
Este código instrui o Auth a inicializar com persistência indexedDB (que está disponível em contextos de trabalho) e omite a dependência popupRedirectResolver , que assume que um contexto DOM está disponível.
Existem outros motivos pelos quais você pode definir dependências manualmente em determinadas plataformas. Ao definir o campo popupRedirectResolver na inicialização do Auth, em alguns casos a biblioteca realizará trabalho adicional na inicialização. Em navegadores móveis, a biblioteca abrirá automaticamente um iframe para o seu domínio Auth preventivamente. Isso é feito para tornar a experiência perfeita para a maioria dos usuários, mas pode afetar o desempenho ao carregar código adicional logo quando o aplicativo é iniciado. Esse comportamento pode ser evitado utilizando initializeAuth() e passando manualmente a dependência browserPopupRedirectResolver para as funções que precisam dela:
import {initializeAuth, browserLocalPersistence, browserPopupRedirectResolver, indexedDBLocalPersistence, signInWithRedirect, GoogleAuthProvider} from "firebase/auth";
import {initializeApp} from "firebase/app";
const app = initializeApp({/** Your app config */});
const auth = initializeAuth(app, {
persistence: [indexedDBLocalPersistence, browserLocalPersistence],
});
// Later
signInWithRedirect(auth, new GoogleAuthProvider(), browserPopupRedirectResolver);
Se tivéssemos fornecido browserPopupRedirectResolver nas dependências para initializeAuth() , o terceiro parâmetro na chamada para signInWithRedirect() não teria sido necessário. Mas, ao mover essa dependência diretamente para a chamada signInWithRedirect() , o impacto inicial no desempenho durante a inicialização é removido. Existem compensações decorrentes da movimentação da dependência, mas a parte importante é que você pode tomar decisões sobre essas compensações inicializando manualmente a biblioteca.
Quando usar a inicialização personalizada
Para recapitular, a inicialização personalizada oferece muito mais controle sobre o uso do Auth SDK pelo seu aplicativo. A função getAuth() padrão é boa para começar e atende à maioria dos casos de uso. Para a maioria dos aplicativos, getAuth() pode ser tudo que você precisa. Mas há muitos motivos pelos quais você pode querer (ou precisar) mudar para o gerenciamento manual de dependências:
- Para aplicativos onde o tamanho do pacote e os tempos de carregamento são extremamente importantes, a inicialização personalizada do Auth pode potencialmente reduzir muitos kilobytes de dados. Ele também pode reduzir o tempo de carregamento inicial , movendo as dependências para o tempo de uso em vez do tempo de inicialização.
- Para código executado em contextos não DOM (como web e service workers),
initializeAuth()deve ser usado para evitar erros.