Authentifizierungsabhängigkeiten anpassen

Das modulare Design des Firebase JS SDK bietet Ihnen viel mehr Kontrolle darüber, wie Ihre App erstellt wird. So können Sie Ihre Abhängigkeiten für Ihre Plattform anpassen und die Bundle-Größe optimieren, indem Sie nicht benötigte Funktionen entfernen.

Es gibt zwei Möglichkeiten, die Auth-Bibliothek zu initialisieren: die Funktion getAuth() und die Funktion initializeAuth(). Die erste, getAuth(), bietet alles, was Ihre App benötigt, um alle Funktionen der Auth-Bibliothek nutzen zu können. Der Nachteil ist, dass viel Code abgerufen wird, der möglicherweise von Ihrer App nicht verwendet wird. Es kann auch Code abgerufen werden, der auf der Zielplattform nicht unterstützt wird, was zu Fehlern führt. Um diese Probleme zu vermeiden, können Sie initializeAuth() verwenden, das eine Zuordnung von Abhängigkeiten akzeptiert. Die Funktion getAuth() ruft einfach initializeAuth() mit allen angegebenen Abhängigkeiten auf. Hier ist das Äquivalent zu getAuth() in Browserumgebungen:

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,
});

Abhängigkeiten anpassen

Nicht alle Apps verwenden die Funktionsfamilie signInWithPopup oder signInWithRedirect. Viele Apps benötigen nicht die Flexibilität, die indexedDB bietet, oder die Möglichkeit, sowohl indexedDB als auch localStorage zu unterstützen, falls eine der beiden nicht verfügbar ist. In diesen Fällen enthält das Standard-getAuth() viel ungenutzten Code, der die Bundle-Größen unnötig erhöht. Stattdessen können diese Apps ihre Abhängigkeiten anpassen. Wenn Ihre App beispielsweise nur die Authentifizierung über E-Mail-Links verwendet und localStorage ausreicht (weil Sie keine Web- oder Service Worker-Skripts verwenden), können Sie viel Code entfernen, indem Sie Auth so initialisieren:

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
});

Mit diesem Code haben Sie drei große Abhängigkeiten entfernt, die Ihre App nicht benötigt. Dadurch wird die Bandbreite, die Ihre Nutzer bei jedem Besuch Ihrer Website verwenden, erheblich reduziert.

Plattformspezifische Überlegungen

In vielen Fällen müssen Sie die Auth-Abhängigkeiten manuell definieren, um Fehler bei der Initialisierung zu vermeiden. Die Funktion getAuth() setzt eine bestimmte Plattform voraus. Für den Standardeinstiegspunkt ist das eine Browserumgebung und für den Cordova-Einstiegspunkt eine Cordova-Umgebung. Manchmal stehen die Anforderungen Ihrer Anwendung jedoch im Widerspruch zu diesen Annahmen. Bei Web- und Service-Worker-Scripts wird beispielsweise durch die Standardimplementierung von getAuth() Code abgerufen, der aus dem window-Objekt gelesen wird. Das führt zu Fehlern. In diesen Fällen müssen Sie Ihre Abhängigkeiten anpassen. Der folgende Code eignet sich zum Initialisieren der Auth-Bibliothek in einem Service Worker-Kontext:

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
});

Dieser Code weist Auth an, mit der indexedDB-Persistenz zu initialisieren (die in Worker-Kontexten verfügbar ist), und lässt die popupRedirectResolver-Abhängigkeit aus, die davon ausgeht, dass ein DOM-Kontext verfügbar ist.

Es gibt auch andere Gründe, aus denen Sie möglicherweise Abhängigkeiten von bestimmten Plattformen manuell definieren. Wenn Sie das Feld popupRedirectResolver bei der Auth-Initialisierung definieren, führt die Bibliothek in einigen Fällen zusätzliche Initialisierungsarbeiten aus. In mobilen Browsern öffnet die Bibliothek automatisch vorab einen iFrame zu Ihrer Auth-Domain. Dies geschieht, um die Nutzung für die meisten Nutzer nahtlos zu gestalten. Es kann sich jedoch auf die Leistung auswirken, da zusätzlicher Code direkt beim Start der App geladen wird. Dieses Verhalten lässt sich vermeiden, indem Sie initializeAuth() verwenden und die browserPopupRedirectResolver-Abhängigkeit manuell an die Funktionen übergeben, die sie benötigen:

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);

Hätten wir browserPopupRedirectResolver in den Abhängigkeiten von initializeAuth() angegeben, wäre der dritte Parameter im Aufruf von signInWithRedirect() nicht erforderlich gewesen. Wenn Sie diese Abhängigkeit jedoch direkt in den Aufruf von signInWithRedirect() verschieben, wird die anfängliche Leistungseinbuße bei der Initialisierung vermieden. Das Verschieben der Abhängigkeit ist mit Kompromissen verbunden. Wichtig ist jedoch, dass Sie Entscheidungen zu diesen Kompromissen treffen können, indem Sie die Bibliothek manuell initialisieren.

Wann sollte die benutzerdefinierte Initialisierung verwendet werden?

Zusammenfassend lässt sich sagen, dass Sie mit der benutzerdefinierten Initialisierung viel mehr Kontrolle über die Verwendung des Auth SDK durch Ihre App haben. Die Standardfunktion getAuth() ist ein guter Ausgangspunkt und deckt die meisten Anwendungsfälle ab. Für die meisten Apps ist getAuth() ausreichend. Es gibt jedoch viele Gründe, warum Sie möglicherweise zu einer manuellen Abhängigkeitsverwaltung wechseln möchten oder müssen:

  • Bei Apps, bei denen die Bundle-Größe und die Ladezeiten extrem wichtig sind, kann die benutzerdefinierte Auth-Initialisierung möglicherweise viele Kilobyte an Daten einsparen. Außerdem können Sie die anfänglichen Ladezeiten verkürzen, indem Sie Abhängigkeiten auf den Zeitpunkt der Verwendung anstatt auf den Zeitpunkt der Initialisierung verschieben.
  • Für Code, der in Nicht-DOM-Kontexten (z. B. Web- und Service-Worker) ausgeführt wird, muss initializeAuth() verwendet werden, um Fehler zu vermeiden.