Durch den modularen Aufbau des Firebase JS SDK haben Sie viel mehr Kontrolle darüber, wie Ihre App erstellt wird. Diese Flexibilität ermöglicht es Ihnen, Ihre Abhängigkeiten an Ihre Plattform anzupassen und Ihre Paketgröße zu 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() , stellt alles bereit, was Ihre App benötigt, um alle Funktionen der Auth-Bibliothek nutzen zu können. Der Nachteil besteht darin, dass eine Menge Code eingezogen wird, der möglicherweise von Ihrer App nicht verwendet wird. Es kann auch passieren, dass Code einfließt, der auf der Plattform, auf die Sie abzielen, einfach nicht unterstützt wird, was zu Fehlern führt. Um diese Probleme zu vermeiden, können Sie initializeAuth() verwenden, das eine Abhängigkeitskarte erstellt. Die Funktion getAuth() ruft einfach initializeAuth() mit allen angegebenen Abhängigkeiten auf. Zur Veranschaulichung ist hier 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,
});
Passen Sie Ihre Abhängigkeiten an
Nicht alle Apps verwenden die Funktionsfamilie signInWithPopup oder signInWithRedirect . Viele Apps benötigen nicht die Flexibilität, die indexedDB bietet, oder benötigen nicht die Fähigkeit, sowohl indexedDB als auch localStorage zu unterstützen, falls eines davon nicht verfügbar ist. In diesen Fällen enthält die Standardeinstellung getAuth() eine Menge ungenutzten Codes, der die Paketgröße ohne Grund erhöht. Stattdessen können diese Apps ihre Abhängigkeiten anpassen. Wenn Ihre App beispielsweise nur die E-Mail-Link-Authentifizierung verwendet und localStorage ausreicht (weil Sie keine Web- oder Service-Worker-Skripts verwenden), können Sie eine Menge aufgeblähten Codes entfernen, indem Sie Auth wie folgt 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, wodurch die Menge an Bandbreite, die Ihre Benutzer beim Besuch Ihrer Website verbrauchen, erheblich reduziert wird.
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 ist das eine Cordova-Umgebung. Aber manchmal kollidieren die Anforderungen Ihrer speziellen Anwendung mit diesen Annahmen. Bei Web- und Service-Worker-Skripten beispielsweise ruft die standardmäßige getAuth() Implementierung Code ab, der aus dem window liest, was zu Fehlern führt. In diesen Fällen ist es notwendig, Ihre Abhängigkeiten anzupassen. 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 indexedDB Persistenz zu initialisieren (die in Worker-Kontexten verfügbar ist) und lässt die Abhängigkeit popupRedirectResolver weg, die davon ausgeht, dass ein DOM-Kontext verfügbar ist.
Es gibt andere Gründe, warum Sie Abhängigkeiten auf bestimmten Plattformen möglicherweise manuell definieren. Durch die Definition des Felds popupRedirectResolver bei der Auth-Initialisierung führt die Bibliothek in einigen Fällen zusätzliche Arbeit bei der Initialisierung aus. In mobilen Browsern öffnet die Bibliothek automatisch präventiv einen Iframe zu Ihrer Auth-Domain. Dies geschieht, um den meisten Benutzern ein nahtloses Erlebnis zu bieten. Es kann sich jedoch auf die Leistung auswirken, da direkt beim Start der App zusätzlicher Code geladen wird. Dieses Verhalten kann vermieden werden, indem initializeAuth() verwendet und die browserPopupRedirectResolver Abhängigkeit manuell an die Funktionen übergeben wird, 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() bereitgestellt, wäre der dritte Parameter im Aufruf von signInWithRedirect() nicht erforderlich gewesen. Durch die direkte Verlagerung dieser Abhängigkeit auf den Aufruf von signInWithRedirect() wird jedoch der anfängliche Leistungseinbruch während der Initialisierung beseitigt. Mit dem Verschieben der Abhängigkeit gehen Kompromisse einher. Der wichtige Teil besteht jedoch darin, dass Sie Entscheidungen über diese Kompromisse treffen können, indem Sie die Bibliothek manuell initialisieren.
Wann sollte eine benutzerdefinierte Initialisierung verwendet werden?
Um es noch einmal zusammenzufassen: Durch die benutzerdefinierte Initialisierung erhalten Sie weitaus mehr Kontrolle über die Nutzung des Auth SDK durch Ihre App. Die Standardfunktion getAuth() eignet sich gut für den Einstieg und deckt die meisten Anwendungsfälle ab. Für die meisten Apps ist getAuth() möglicherweise alles, was Sie benötigen. Es gibt jedoch viele Gründe, warum Sie möglicherweise auf manuelles Abhängigkeitsmanagement umsteigen möchten (oder müssen):
- Bei Apps, bei denen Paketgröße und Ladezeiten äußerst wichtig sind, kann die benutzerdefinierte Auth-Initialisierung möglicherweise viele Kilobyte an Daten einsparen. Es kann auch die anfänglichen Ladezeiten verkürzen, indem Abhängigkeiten in die Nutzungszeit statt in die Zeit der Initialisierung verschoben werden.
- Für Code, der in Nicht-DOM-Kontexten ausgeführt wird (z. B. Web- und Service-Worker), muss
initializeAuth()verwendet werden, um Fehler zu vermeiden.