Diese Seite wurde von der Cloud Translation API übersetzt.

Auth-Abhängigkeiten anpassen

Das modulare Design des Firebase JS SDK gibt Ihnen viel mehr Kontrolle wie Ihre App aufgebaut ist. So können Sie Ihre Abhängigkeiten an Ihre Plattform anpassen und die Größe Ihres Bundles 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(), liefert alles, Ihre App benötigt, um alle Funktionen der Auth-Bibliothek nutzen zu können zu bieten. Der Nachteil ist, dass es viel Code abruft, der möglicherweise nicht von Ihrer App verwendet werden. Es kann auch Code übernehmen, der auf dem verwendet wird, was zu Fehlern führt. Um diese Probleme zu vermeiden, Verwenden Sie initializeAuth(), wodurch eine Map der Abhängigkeiten erstellt wird. Das getAuth() ruft einfach initializeAuth() mit allen angegebenen Abhängigkeiten auf. Zur Veranschaulichung: Das entspricht 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 nutzen die signInWithPopup- oder signInWithRedirect-Familie Funktionen. Viele Apps benötigen nicht die Flexibilität von indexedDB oder die Möglichkeit, sowohl indexedDB als auch localStorage zu unterstützen, falls eine der beiden Optionen nicht verfügbar ist. In diesen Fällen enthält das standardmäßige getAuth() viel ungenutzten Code, der die Bundle-Größe ohne Grund erhöht. Stattdessen können diese Apps ihre Abhängigkeiten anzupassen. Wenn Ihre App beispielsweise nur die E-Mail-Link-Authentifizierung verwendet und localStorage ausreicht (weil Sie keine Web- oder Service Worker-Scripts verwenden), können Sie viel Code entfernen, indem Sie die Authentifizierung 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 beim Besuch Ihrer Website verbrauchen, erheblich reduziert.

Plattformspezifische Überlegungen

In vielen Fällen müssen Sie die Authentifizierungsabhängigkeiten manuell definieren, um Fehler bei der Initialisierung zu vermeiden. Die Funktion getAuth() geht davon aus, Plattform. Für den Standardeinstiegspunkt ist das eine Browserumgebung und für den Cordova-Einstiegspunkt eine Cordova-Umgebung. Manchmal stehen die Anforderungen Ihrer spezifischen Anwendung jedoch im Widerspruch zu diesen Annahmen. Für Web und Service Worker-Skripts wie z. B. die standardmäßige getAuth()-Implementierung Code, der aus dem window-Objekt liest, was zu Fehlern führt. In diesen Fällen müssen Sie Ihre Abhängigkeiten anpassen. Mit dem folgenden Code wird die Auth-Bibliothek in einem Service Worker-Kontext initialisiert:

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

In diesem Code wird Auth angewiesen, mit indexedDB-Persistenz zu initialisieren (die in Worker-Kontexten verfügbar ist). Die Abhängigkeit von popupRedirectResolver wird weggelassen, da davon ausgegangen wird, dass ein DOM-Kontext verfügbar ist.

Es gibt noch weitere Gründe, warum Sie Abhängigkeiten für bestimmte Plattformen manuell definieren können. Durch die Definition des Felds popupRedirectResolver bei der Auth-Initialisierung in einigen Fällen führt die Bibliothek zusätzliche Schritte bei der Initialisierung aus. In mobilen Browsern öffnet die Bibliothek automatisch einen Iframe zu Ihrer Authentifizierungsdomain. Das soll die Nutzung für die meisten Nutzer reibungslos gestalten. Es kann jedoch zu Leistungseinbußen kommen, da beim Starten der App zusätzlicher Code 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 zu initializeAuth() angegeben, wäre der dritte Parameter im Aufruf von signInWithRedirect() nicht erforderlich gewesen. Wenn Sie diese Abhängigkeit jedoch direkt auf den Aufruf von signInWithRedirect() verschieben, wird der anfängliche Leistungseinbruch während der Initialisierung beseitigt. Das Verschieben der Abhängigkeit hat Vor- und Nachteile. Wichtig ist jedoch, dass Sie Entscheidungen zu diesen Vor- und Nachteilen treffen können, indem Sie die Bibliothek manuell initialisieren.

Wann die benutzerdefinierte Initialisierung verwendet werden sollte

Zusammenfassend lässt sich sagen, dass Sie mit der benutzerdefinierten Initialisierung die Verwendung des Auth SDK durch Ihre App viel besser steuern können. Mit der Standardfunktion getAuth() können Sie und ist für die meisten Anwendungsfälle geeignet. Bei den meisten Apps ist getAuth() möglicherweise nur du die Sie brauchen. Es gibt jedoch viele Gründe, warum Sie zur manuellen Abhängigkeitsverwaltung wechseln möchten (oder müssen):

Bei Apps, bei denen die Größe des Bundles und die Ladezeiten extrem wichtig sind, kann die benutzerdefinierte Authentifizierungsinitialisierung potenziell 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 statt auf den Zeitpunkt der Initialisierung verschieben.
Für Code, der in nicht DOM-Kontexten ausgeführt wird (z. B. Web- und Dienst-Worker), muss initializeAuth() verwendet werden, um Fehler zu vermeiden.