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()
, bietet alles, was Ihre App benötigt, um alle Funktionen der Auth-Bibliothek nutzen zu können. 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, können Sie initializeAuth()
verwenden, das eine Abhängigkeitskarte verwendet. Das getAuth()
ruft einfach initializeAuth()
mit allen angegebenen Abhängigkeiten auf.
Hier ist das Äquivalent zu getAuth()
in Browserumgebungen zur Veranschaulichung:
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 Funktionen der Familie signInWithPopup
oder signInWithRedirect
. Viele Apps benötigen nicht die Flexibilität, die indexedDB
bietet, oder
brauchen nicht die Möglichkeit, sowohl indexedDB
als auch localStorage
zu unterstützen, falls eines
nicht verfügbar sein. In diesen Fällen enthält die Standard-getAuth()
viele
nicht verwendetem Code, der ohne Grund die Größe von Sets erhöht. Stattdessen können diese Apps ihre Abhängigkeiten anpassen. Wenn Ihre App beispielsweise nur E-Mail-Links verwendet
Authentifizierung und localStorage ausreichend, da Sie keine Web- oder
Service Worker-Skripts) können Sie durch Initialisieren von Auth
wie hier:
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. Aber manchmal sind die Bedürfnisse
Ihre Anwendung diese Annahmen
nicht widerspricht. 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
müssen Sie Ihre Abhängigkeiten
an Ihre Anforderungen 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
});
Dieser Code weist Auth an, mit indexedDB
-Persistenz zu initialisieren (die
in Worker-Kontexten verfügbar) und lässt die Abhängigkeit popupRedirectResolver
aus,
Dabei wird davon ausgegangen, dass ein DOM-Kontext verfügbar ist.
Es gibt noch andere Gründe, warum Sie Abhängigkeiten von bestimmten
Plattformen. Wenn du das Feld popupRedirectResolver
bei der Authentifizierung initialisierst, führt die Bibliothek in einigen Fällen zusätzliche Aufgaben 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 kann mithilfe von initializeAuth()
und
manuelle Übergabe der browserPopupRedirectResolver
-Abhängigkeit an die Funktionen
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. Aber wenn Sie diese Abhängigkeit
in den Aufruf verlagern,
signInWithRedirect()
direkt erreicht haben, erreichte die anfängliche Leistung während
Initialisierung entfernt. 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 sollte die benutzerdefinierte Initialisierung verwendet werden?
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):
- Für Apps, bei denen die Paketgröße und die Ladezeiten entscheidend sind, Durch die Auth-Initialisierung können viele Kilobyte an Daten reduziert werden. 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 (wie Web- und Service Workern) ausgeführt wird:
initializeAuth()
muss verwendet werden, um Fehler zu vermeiden.