Personnaliser vos dépendances d'authentification

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.