La conception modulaire du SDK JS Firebase vous permet de mieux contrôler la façon dont votre application est conçue. Cette flexibilité vous permet d'adapter vos dépendances pour votre plate-forme et optimiser la taille du bundle en supprimant les fonctionnalités dont vous n'avez pas besoin.
Il existe deux façons d'initialiser la bibliothèque Auth : la fonction getAuth()
et la fonction initializeAuth()
. La première, getAuth()
, fournit toutes les informations
dont votre application a besoin pour bénéficier de toutes les fonctionnalités de la bibliothèque Auth
à offrir. L'inconvénient est qu'elle récupère une grande quantité de code
inutilisées par votre application. Il peut également récupérer du code qui n'est tout simplement pas pris en charge sur le
sur la plate-forme que vous ciblez, ce qui peut entraîner des erreurs. Pour éviter ces problèmes, vous pouvez
Utilisez initializeAuth()
, qui accepte un mappage de dépendances. getAuth()
appelle simplement initializeAuth()
avec toutes les dépendances spécifiées.
À titre d'exemple, voici l'équivalent de getAuth()
dans 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,
});
Adapter vos dépendances
Toutes les applications n'utilisent pas la famille de composants signInWithPopup
ou signInWithRedirect
fonctions. De nombreuses applications n'auront pas besoin de la flexibilité offerte par indexedDB
ni de la compatibilité avec indexedDB
et localStorage
si l'un d'eux n'est pas disponible. Dans ce cas, le getAuth()
par défaut inclut un grand nombre
code inutilisé qui augmente la taille des lots sans raison. À la place, ces applications peuvent adapter leurs dépendances. Par exemple, si votre application n'utilise qu'un lien envoyé par e-mail
l'authentification et le stockage localStorage sont suffisants (car vous n'utilisez pas
scripts de service worker), vous pouvez éliminer la surcharge de 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, ce qui réduit considérablement la quantité de bande passante utilisée par vos utilisateurs lorsqu'ils visitent votre site.
Considérations propres aux plates-formes
Dans de nombreux cas, vous devez définir manuellement les dépendances Auth afin de
pour éviter les erreurs lors de l'initialisation. La fonction getAuth()
suppose qu'une
Google Cloud. Comme point d'entrée par défaut, il s'agit d'un environnement de navigateur.
Le point d'entrée de Cordoue, c'est l'environnement de Cordoue. Mais parfois,
les besoins des
votre application spécifique sont en contradiction avec ces hypothèses. Pour le Web et les services
scripts de nœud de calcul. Par exemple, l'implémentation par défaut getAuth()
récupère
qui lit depuis l'objet window
, ce qui entraîne des erreurs. Dans ce cas, vous devez 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 nœuds de calcul) et omet la dépendance popupRedirectResolver
.
qui suppose qu'un contexte DOM est disponible.
Il existe d'autres raisons pour lesquelles vous pourriez définir manuellement des dépendances sur certaines
plates-formes. En définissant le champ popupRedirectResolver
lors de l'initialisation d'Auth, la bibliothèque effectue parfois des tâches supplémentaires lors de l'initialisation. Dans les navigateurs mobiles, la bibliothèque ouvre automatiquement un iframe vers votre domaine d'authentification de manière préventive. Cela permet de rendre l'expérience
transparente pour la plupart des
les utilisateurs, mais cela peut affecter les performances en chargeant du code supplémentaire au moment où
démarre. Vous pouvez éviter ce comportement 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 à
initializeAuth()
, le troisième paramètre de l'appel à signInWithRedirect()
.
n'aurait pas été nécessaire. En déplaçant cette dépendance vers l'appel
signInWithRedirect()
directement, l'atteinte aux performances initiales
l'initialisation est supprimée. Il y a des compromis à faire en déplaçant
la dépendance, mais l’important est que vous
êtes capable de prendre des décisions concernant
ces compromis en initialisant manuellement la bibliothèque.
Quand utiliser l'initialisation personnalisée ?
Pour résumer, l'initialisation personnalisée vous permet de contrôler beaucoup plus l'utilisation du SDK Auth par votre application. La fonction getAuth()
standard est utile pour se lancer et convient à la plupart des cas d'utilisation. Pour la plupart des applis, getAuth()
peut être votre seule personne
besoin. Il existe toutefois de nombreuses raisons pour lesquelles vous pouvez (ou avoir besoin) de passer au paiement manuel
la gestion des dépendances:
- Pour les applications dont la taille du bundle et les temps de chargement sont extrêmement importants, l'initialisation Auth personnalisée peut potentiellement réduire de nombreux kilo-octets de données. Il Vous pouvez également réduire les temps de chargement initial en déplaçant les dépendances au moment au lieu du temps d'initialisation.
- Pour le code qui s'exécute dans des contextes autres que DOM (comme les web workers et les service workers),
initializeAuth()
doit être utilisé pour éviter les erreurs.