Personaliza tus dependencias de Auth

El diseño modular del SDK de Firebase JS te brinda un control mucho mayor sobre cómo se compila tu app. Esta flexibilidad te permite adaptar las dependencias para tu plataforma y optimizar el tamaño del paquete mediante la eliminación de las funciones que no necesitas.

Hay dos maneras de inicializar la biblioteca de Auth: la función getAuth() y la función initializeAuth(). La primera opción, getAuth(), proporciona todo lo que tu app necesita para aprovechar todas las funciones que ofrece la biblioteca de Auth. La desventaja es que incorpora una gran cantidad de código que tu app podría no usar. También es posible que inserte código que simplemente no es compatible con la plataforma que usas, lo que genera errores. Para evitar estos problemas, puedes usar initializeAuth(), que utiliza un mapa de dependencias. La función getAuth() simplemente llama a initializeAuth() con todas las dependencias especificadas. A modo de ejemplo, este es el equivalente a getAuth() en entornos 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,
});

Adapta tus dependencias

No todas las apps usan las familias signInWithPopup o signInWithRedirect de funciones. Muchas apps no necesitarán la flexibilidad que proporciona indexedDB o no necesitarán la capacidad de admitir indexedDB y localStorage, en caso de que una no esté disponible. En estos casos, el valor predeterminado getAuth() incluye una gran cantidad de código sin usar que aumenta el tamaño de los paquetes sin motivo. En cambio, estas apps pueden adaptar sus dependencias. Por ejemplo, si tu app solo usa autenticación mediante vínculo de correo electrónico y basta con localStorage (porque no usas secuencias de comandos web o de service worker), puedes quitar mucho sobredimensionamiento de código si inicializas Auth como se indica a continuación:

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
});

Con este código, quitaste tres dependencias grandes que tu app no necesita, lo que reduce significativamente el ancho de banda que utilizan los usuarios cada vez que visitan tu sitio.

Consideraciones específicas de la plataforma

En muchos casos, debes definir de forma manual las dependencias de Auth para evitar errores en la inicialización. La función getAuth() presupone que hay una plataforma específica. Para el punto de entrada predeterminado, es un entorno de navegador, y para el punto de entrada de Cordova, es un entorno de Cordova. Pero, a veces, las necesidades de tu aplicación en particular entran en conflicto con estas suposiciones. Para las secuencias de comandos web y de service worker, por ejemplo, la implementación predeterminada de getAuth() incorpora código que lee desde el objeto window, lo que generará errores. En esos casos, es necesario adaptar tus dependencias. El siguiente código es apropiado para inicializar la biblioteca de Auth en un 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 le indica a Auth que se inicialice con la persistencia indexedDB (que está disponible en los contextos de trabajadores) y omite la dependencia popupRedirectResolver, que presupone que hay un contexto DOM disponible.

Existen otras razones para definir dependencias de forma manual en ciertas plataformas. Cuando se define el campo popupRedirectResolver en la inicialización de Auth, en algunos casos, la biblioteca realizará trabajo adicional en la inicialización. En los navegadores para dispositivos móviles, la biblioteca abrirá automáticamente y de forma preventiva un iframe a tu dominio de Auth. Esto se hace a fin de que la experiencia sea fluida para la mayoría de los usuarios, pero puede afectar el rendimiento cargando código adicional justo cuando se inicia la app. Este comportamiento se puede evitar si usas initializeAuth() y pasas de forma manual la dependencia browserPopupRedirectResolver a las funciones que la necesitan:

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);

Si hubiéramos proporcionado browserPopupRedirectResolver en las dependencias a initializeAuth(), el tercer parámetro de la llamada a signInWithRedirect() no habría sido necesario. Sin embargo, si se mueve esa dependencia directamente a la llamada a signInWithRedirect(), se quita el hit inicial de rendimiento durante la inicialización. Mover la dependencia conlleva hacer concesiones, pero lo importante es que puedes tomar decisiones sobre esas concesiones si inicializas la biblioteca de forma manual.

Cuándo usar la inicialización personalizada

Para resumir, la inicialización personalizada te brinda un control mucho mayor sobre el uso que la app hace del SDK de Auth. La función estándar getAuth() sirve para comenzar y es útil para la mayoría de los casos de uso. Para la mayoría de las apps, es posible que getAuth() sea todo lo que necesitas. Sin embargo, hay muchos motivos por los que tal vez quieras (o necesites) cambiarte a la administración manual de dependencias:

  • En el caso de las apps en las que el tamaño del paquete y los tiempos de carga son muy importantes, la inicialización de Auth personalizada puede reducir potencialmente muchos kilobytes de datos. También puede reducir los tiempos de carga iniciales, trasladando las dependencias al tiempo del uso en lugar del tiempo de inicialización.
  • Para evitar errores en el código que se ejecuta en contextos que no pertenecen al DOM (como entornos web y service workers), se debe usar initializeAuth().