Authentifizierungsabhä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(), 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.