La conception modulaire du SDK Firebase JS vous offre un contrôle bien plus important sur la façon dont votre application est créée. Cette flexibilité vous permet d'adapter vos dépendances à votre plate-forme et d'optimiser la taille de votre offre groupée en supprimant les fonctionnalités dont vous n'avez pas besoin.
Il existe deux manières d'initialiser la bibliothèque Auth : la fonction getAuth() et la fonction initializeAuth() . Le premier, getAuth() , fournit tout ce dont votre application a besoin pour profiter de toutes les fonctionnalités offertes par la bibliothèque Auth. L’inconvénient est qu’il récupère beaucoup de code potentiellement inutilisé par votre application. Il peut également extraire du code qui n'est tout simplement pas pris en charge sur la plate-forme que vous ciblez, ce qui entraîne des erreurs. Pour éviter ces problèmes, vous pouvez utiliser initializeAuth() , qui prend une carte des dépendances. La fonction getAuth() appelle simplement initializeAuth() avec toutes les dépendances spécifiées. Pour illustrer, voici l'équivalent de getAuth() sur les environnements de navigateur :
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,
});
Adaptation de vos dépendances
Toutes les applications n’utilisent pas la famille de fonctions signInWithPopup ou signInWithRedirect . De nombreuses applications n'auront pas besoin de la flexibilité offerte par indexedDB , ou n'auront pas besoin de la capacité de prendre en charge à la fois indexedDB et localStorage si l'un d'entre eux n'est pas disponible. Dans ces cas, la méthode getAuth() par défaut inclut une grande partie du code inutilisé qui augmente la taille des bundles sans raison. Au lieu de cela, ces applications peuvent adapter leurs dépendances. Par exemple, si votre application utilise uniquement l'authentification par lien de courrier électronique et que localStorage est suffisant (parce que vous n'utilisez pas de scripts Web ou de service worker), vous pouvez supprimer une grande partie du code en initialisant Auth comme ceci :
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
});
Avec ce code, vous avez supprimé trois grandes dépendances dont votre application n'a pas besoin, réduisant ainsi considérablement la quantité de bande passante utilisée par vos utilisateurs lorsqu'ils visitent votre site.
Considérations spécifiques à la plate-forme
Dans de nombreux cas, vous devez définir manuellement les dépendances Auth afin d'éviter les erreurs lors de l'initialisation. La fonction getAuth() suppose une plateforme spécifique. Pour le point d'entrée par défaut, il s'agit d'un environnement de navigateur et pour le point d'entrée Cordova, il s'agit d'un environnement Cordova. Mais parfois, les besoins de votre application particulière entrent en conflit avec ces hypothèses. Pour les scripts Web et Service Worker, par exemple, l'implémentation par défaut getAuth() extrait le code qui lit à partir de l'objet window , ce qui provoquera des erreurs. Dans ces cas, il est nécessaire d'adapter vos dépendances. Le code suivant est approprié pour initialiser la bibliothèque Auth dans un contexte 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
});
Ce code demande à Auth de s'initialiser avec la persistance indexedDB (qui est disponible dans les contextes de travail) et omet la dépendance popupRedirectResolver , qui suppose qu'un contexte DOM est disponible.
Il existe d'autres raisons pour lesquelles vous pouvez définir manuellement des dépendances sur certaines plates-formes. En définissant le champ popupRedirectResolver dans l'initialisation Auth, dans certains cas, la bibliothèque effectuera un travail supplémentaire sur l'initialisation. Sur les navigateurs mobiles, la bibliothèque ouvrira automatiquement une iframe sur votre domaine Auth de manière préventive. Ceci est fait pour rendre l'expérience transparente pour la plupart des utilisateurs, mais cela peut avoir un impact sur les performances en chargeant du code supplémentaire dès le démarrage de l'application. Ce comportement peut être évité en utilisant initializeAuth() et en transmettant manuellement la dépendance browserPopupRedirectResolver aux fonctions qui en ont besoin :
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 nous avions fourni browserPopupRedirectResolver dans les dépendances de initializeAuth() , le troisième paramètre de l'appel à signInWithRedirect() n'aurait pas été nécessaire. Mais en déplaçant directement cette dépendance vers l’appel à signInWithRedirect() , l’impact initial sur les performances lors de l’initialisation est supprimé. Le déplacement de la dépendance comporte des compromis, mais l'important est que vous puissiez prendre des décisions concernant ces compromis en initialisant manuellement la bibliothèque.
Quand utiliser l'initialisation personnalisée
Pour récapituler, l'initialisation personnalisée vous donne un contrôle bien plus grand sur l'utilisation du SDK Auth par votre application. La fonction standard getAuth() est idéale pour démarrer et sert la plupart des cas d'utilisation. Pour la plupart des applications, getAuth() peut suffire. Mais il existe de nombreuses raisons pour lesquelles vous souhaiterez (ou devrez) passer à la gestion manuelle des dépendances :
- Pour les applications pour lesquelles la taille du bundle et les temps de chargement sont extrêmement importants, l'initialisation d'authentification personnalisée peut potentiellement réduire plusieurs kilo-octets de données. Il peut également réduire les temps de chargement initiaux en déplaçant les dépendances au moment de l'utilisation plutôt qu'au moment de l'initialisation.
- Pour le code qui s'exécute dans des contextes non-DOM (comme les Web et les service Workers),
initializeAuth()doit être utilisé pour éviter les erreurs.