Personnaliser vos dépendances d'authentification

La conception modulaire du SDK JS Firebase vous offre un contrôle beaucoup plus important sur la façon dont votre application est conçue. 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 tout ce dont votre application a besoin pour profiter de toutes les fonctionnalités de la bibliothèque Auth. L'inconvénient est qu'il extrait beaucoup de code potentiellement inutilisé par votre application. Il peut également extraire du code qui n'est tout simplement pas compatible avec 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 cela, 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 fonctions signInWithPopup ou signInWithRedirect. De nombreuses applications n'ont pas besoin de la flexibilité offerte par indexedDB ni de la possibilité de prendre en charge à la fois indexedDB et localStorage si l'un d'eux n'est pas disponible. Dans ce cas, le getAuth() par défaut inclut beaucoup de code inutilisé qui augmente la taille des bundles sans raison. À la place, ces applications peuvent adapter leurs dépendances. Par exemple, si votre application n'utilise que l'authentification par lien e-mail et que localStorage est suffisant (car vous n'utilisez pas de scripts Web ni de service worker), vous pouvez supprimer beaucoup de code inutile en initialisant Auth comme suit :

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 bande passante utilisée par vos utilisateurs chaque fois qu'ils visitent votre site.

Considérations spécifiques à la plate-forme

Dans de nombreux cas, vous devez définir manuellement les dépendances d'authentification 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 de votre application spécifique entrent en conflit avec ces hypothèses. Par exemple, pour les scripts de service worker et Web, l'implémentation getAuth() par défaut extrait le code qui lit à partir de l'objet window, ce qui entraînera des erreurs. Dans ce cas, il est nécessaire d'adapter vos dépendances. Le code suivant permet d'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 (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 pouvez définir manuellement des dépendances sur certaines plates-formes. En définissant le champ popupRedirectResolver lors de l'initialisation de l'authentification, la bibliothèque effectue parfois des tâches supplémentaires lors de l'initialisation. Sur les navigateurs mobiles, la bibliothèque ouvre automatiquement un iframe vers votre domaine Auth de manière préventive. Cette opération est effectuée pour offrir une expérience fluide à la plupart des utilisateurs, mais elle peut avoir un impact sur les performances en chargeant du code supplémentaire dès le démarrage de l'application. Pour éviter ce comportement, utilisez initializeAuth() et transmettez 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. Toutefois, en déplaçant cette dépendance directement vers l'appel à signInWithRedirect(), l'impact initial sur les performances lors de l'initialisation est supprimé. Le déplacement de la dépendance présente des inconvénients, mais l'important est que vous puissiez prendre des décisions concernant ces inconvénients en initialisant manuellement la bibliothèque.

Quand utiliser l'initialisation personnalisée ?

Pour récapituler, l'initialisation personnalisée vous offre un contrôle beaucoup plus important sur l'utilisation du SDK Auth par votre application. La fonction getAuth() standard est un bon point de départ et convient à la plupart des cas d'utilisation. Pour la plupart des applications, getAuth() peut suffire. Toutefois, il existe de nombreuses raisons pour lesquelles vous pouvez souhaiter (ou avoir besoin) de passer à la gestion manuelle des dépendances :

  • Pour les applications où 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 peut également réduire les temps de chargement initiaux en déplaçant les dépendances au moment de l'utilisation au lieu du moment de l'initialisation.
  • Pour le code qui s'exécute dans des contextes non DOM (comme les workers Web et de service), initializeAuth() doit être utilisé pour éviter les erreurs.