El diseño modular del SDK de Firebase JS te brinda un control mucho mayor sobre cómo se construye tu aplicación. Esta flexibilidad le permite adaptar sus dependencias a su plataforma y optimizar el tamaño de su paquete eliminando funciones que no necesita.
Hay dos formas de inicializar la biblioteca Auth: la función getAuth() y la función initializeAuth() . El primero, getAuth() , proporciona todo lo que su aplicación necesita para aprovechar todas las funciones que ofrece la biblioteca de autenticación. La desventaja es que extrae una gran cantidad de código que su aplicación potencialmente no utiliza. También puede introducir código que simplemente no es compatible con la plataforma a la que se dirige, lo que genera errores. Para evitar estos problemas, puedes usar initializeAuth() , que toma un mapa de dependencias. La función getAuth() simplemente llama initializeAuth() con todas las dependencias especificadas. Para ilustrar, aquí está 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,
});
Adaptando sus dependencias
No todas las aplicaciones utilizan la familia de funciones signInWithPopup o signInWithRedirect . Muchas aplicaciones no necesitarán la flexibilidad que proporciona indexedDB , o no necesitarán la capacidad de admitir tanto indexedDB como localStorage en caso de que uno no esté disponible. En estos casos, el getAuth() predeterminado incluye una gran cantidad de código no utilizado que aumenta el tamaño del paquete sin ningún motivo. En cambio, estas aplicaciones pueden adaptar sus dependencias. Por ejemplo, si su aplicación solo usa autenticación de enlace de correo electrónico y localStorage es suficiente (porque no está usando scripts web o de trabajadores de servicios), puede eliminar una gran cantidad de código inicializando Auth de esta manera:
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, ha eliminado tres grandes dependencias que su aplicación no necesita, reduciendo significativamente la cantidad de ancho de banda que utilizan sus usuarios cada vez que visitan su sitio.
Consideraciones específicas de la plataforma
En muchos casos, es necesario definir manualmente las dependencias de autenticación para evitar errores durante la inicialización. La función getAuth() asume una plataforma específica. Para el punto de entrada predeterminado, es un entorno de navegador y para el punto de entrada Cordova, es un entorno Cordova. Pero a veces las necesidades de su aplicación particular chocan con estos supuestos. Para scripts de trabajadores web y de servicios, por ejemplo, la implementación predeterminada getAuth() extrae código que se lee desde el objeto window , lo que provocará errores. En esos casos, es necesario adaptar sus dependencias. El siguiente código es apropiado para inicializar la biblioteca de autenticación en un contexto de trabajador de servicio:
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 indica a Auth que se inicialice con persistencia indexedDB (que está disponible en contextos de trabajo) y omite la dependencia popupRedirectResolver , que supone que hay un contexto DOM disponible.
Existen otras razones por las que podría definir manualmente dependencias en determinadas plataformas. Al definir el campo popupRedirectResolver en la inicialización de autenticación, en algunos casos la biblioteca realizará trabajo adicional en la inicialización. En los navegadores móviles, la biblioteca abrirá automáticamente un iframe para su dominio de autenticación de forma preventiva. Esto se hace para que la experiencia sea perfecta para la mayoría de los usuarios, pero puede afectar el rendimiento al cargar código adicional justo cuando se inicia la aplicación. Este comportamiento se puede evitar utilizando initializeAuth() y pasando manualmente 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 de initializeAuth() , el tercer parámetro en la llamada a signInWithRedirect() no habría sido necesario. Pero al mover esa dependencia a la llamada a signInWithRedirect() directamente, se elimina el impacto inicial en el rendimiento durante la inicialización. Hay ventajas y desventajas que conlleva mover la dependencia, pero lo importante es que usted puede tomar decisiones sobre esas ventajas inicializando manualmente la biblioteca.
Cuándo utilizar la inicialización personalizada
En resumen, la inicialización personalizada le brinda un control mucho mayor sobre el uso del SDK de autenticación por parte de su aplicación. La función estándar getAuth() es buena para comenzar y sirve para la mayoría de los casos de uso. Para la mayoría de las aplicaciones, getAuth() puede ser todo lo que necesita. Pero hay muchas razones por las que es posible que desee (o necesite) cambiar a la gestión de dependencias manual:
- Para aplicaciones donde el tamaño del paquete y los tiempos de carga son extremadamente importantes, la inicialización de autenticación personalizada puede reducir potencialmente muchos kilobytes de datos. También puede reducir los tiempos de carga iniciales moviendo las dependencias al tiempo de uso en lugar del tiempo de inicialización.
- Para el código que se ejecuta en contextos que no son DOM (como trabajadores web y de servicios), se debe utilizar
initializeAuth()para evitar errores.