Personnaliser vos dépendances d'authentification

La conception modulaire du SDK Firebase JS vous permet de mieux contrôler la création de votre application. Cette flexibilité vous permet d'adapter vos dépendances à votre plate-forme et d'optimiser la taille de votre 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 utiliser initializeAuth(), qui utilise une carte des dépendances. getAuth() appelle simplement initializeAuth() avec toutes les dépendances spécifiées. Pour illustrer, 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é qu'offre indexedDB. n'aura pas besoin de pouvoir prendre en charge à la fois indexedDB et localStorage ne seront pas disponibles. 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 spécifiques à la plate-forme

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 une plate-forme 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, d'un environnement Cordova. 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 indique à Auth de s'initialiser avec la persistance indexedDB (qui est disponible dans les contextes de worker) 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 dans l'initialisation de l'authentification, Dans certains cas, la bibliothèque effectuera un travail supplémentaire sur 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. 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 à initializeAuth(), le troisième paramètre de l'appel à signInWithRedirect(). n'aurait pas été nécessaire. Toutefois, en déplaçant cette dépendance directement vers l'appel de signInWithRedirect(), l'impact initial sur les performances lors de l'initialisation est supprimé. 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 ?

En résumé, l'initialisation personnalisée vous offre beaucoup plus de contrôle du SDK Auth. La fonction getAuth() standard permet d'obtenir et sert la plupart des cas d'utilisation. Pour la plupart des applications, getAuth() peut suffire. 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 nœuds de calcul Web et les service workers), Vous devez utiliser initializeAuth() pour éviter les erreurs.