Modułowa konstrukcja pakietu Firebase JS SDK zapewnia znacznie większą kontrolę nad sposobem tworzenia aplikacji. Ta elastyczność pozwala dostosowywać zależności do platformy i optymalizować rozmiar pakietu przez usuwanie funkcji, których nie potrzebujesz.
Bibliotekę uwierzytelniania można zainicjować na 2 sposoby: za pomocą funkcji getAuth() i funkcji initializeAuth(). Pierwsza z nich, getAuth(), zawiera wszystko, czego aplikacja potrzebuje, aby korzystać ze wszystkich funkcji biblioteki uwierzytelniania. Wadą jest to, że pobiera on dużo kodu, który może być nieużywany przez aplikację. Może też pobierać kod, który jest po prostu nieobsługiwany na platformie, na którą kierujesz aplikację, co prowadzi do błędów. Aby uniknąć tych problemów, możesz użyć funkcji initializeAuth(), która przyjmuje mapę zależności. Funkcja getAuth()
wywołuje po prostu funkcję initializeAuth() ze wszystkimi określonymi zależnościami.
Na przykład w środowiskach przeglądarki odpowiednikiem getAuth() jest:
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,
});
Dostosowywanie zależności
Nie wszystkie aplikacje korzystają z funkcji z rodziny signInWithPopup lub signInWithRedirect. Wiele aplikacji nie będzie potrzebować elastyczności, jaką zapewnia indexedDB, ani możliwości obsługi zarówno indexedDB, jak i localStorage, jeśli jedno z nich nie będzie dostępne. W takich przypadkach domyślny getAuth() zawiera dużo nieużywanego kodu, który bez powodu zwiększa rozmiar pakietu. Zamiast tego aplikacje te mogą dostosowywać swoje zależności. Jeśli na przykład Twoja aplikacja używa tylko uwierzytelniania za pomocą linku w e-mailu, a pamięć localStorage jest wystarczająca (ponieważ nie używasz skryptów internetowych ani skryptów service worker), możesz usunąć wiele niepotrzebnych fragmentów kodu, inicjując uwierzytelnianie w ten sposób:
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
});
Dzięki temu kodowi usuniesz 3 duże zależności, których Twoja aplikacja nie potrzebuje, co znacznie zmniejszy ilość pasma wykorzystywanego przez użytkowników podczas odwiedzania Twojej witryny.
Uwagi dotyczące poszczególnych platform
W wielu przypadkach musisz ręcznie zdefiniować zależności uwierzytelniania, aby uniknąć błędów podczas inicjowania. Funkcja getAuth() zakłada określoną platformę. W przypadku domyślnego punktu wejścia jest to środowisko przeglądarki, a w przypadku punktu wejścia Cordova – środowisko Cordova. Czasami jednak potrzeby konkretnej aplikacji są sprzeczne z tymi założeniami. W przypadku skryptów web worker i service worker domyślna implementacja getAuth() pobiera kod, który odczytuje dane z obiektu window, co spowoduje błędy. W takich przypadkach konieczne jest dostosowanie zależności. Poniższy kod jest odpowiedni do zainicjowania biblioteki Uwierzytelnianie w kontekście skryptu service worker:
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
});
Ten kod instruuje Auth, aby zainicjować indexedDB trwałość (która jest dostępna w kontekstach procesów roboczych) i pomija zależność popupRedirectResolver, która zakłada dostępność kontekstu DOM.
Istnieją też inne powody, dla których możesz ręcznie zdefiniować zależności na niektórych platformach. Jeśli zdefiniujesz pole popupRedirectResolver podczas inicjowania uwierzytelniania, w niektórych przypadkach biblioteka wykona dodatkowe działania podczas inicjowania. W przeglądarkach mobilnych biblioteka automatycznie otworzy ramkę iframe do Twojej domeny uwierzytelniania. Dzieje się tak, aby zapewnić większości użytkowników płynne działanie, ale może to mieć wpływ na wydajność, ponieważ dodatkowy kod jest wczytywany od razu po uruchomieniu aplikacji. Można tego uniknąć, korzystając z funkcji initializeAuth() i ręcznie przekazując zależność browserPopupRedirectResolver do funkcji, które jej potrzebują:
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);
Gdybyśmy podali browserPopupRedirectResolver w zależnościach od initializeAuth(), trzeci parametr w wywołaniu signInWithRedirect() nie byłby potrzebny. Przeniesienie tej zależności bezpośrednio do wywołania funkcji signInWithRedirect() eliminuje początkowy spadek wydajności podczas inicjowania. Przeniesienie zależności wiąże się z pewnymi kompromisami, ale najważniejsze jest to, że możesz podejmować decyzje dotyczące tych kompromisów, ręcznie inicjując bibliotekę.
Kiedy używać niestandardowej inicjalizacji
Podsumowując, niestandardowa inicjalizacja zapewnia znacznie większą kontrolę nad korzystaniem z pakietu SDK Auth w aplikacji. Standardowa funkcja getAuth() jest dobrym rozwiązaniem na początek i sprawdza się w większości przypadków. W przypadku większości aplikacji wystarczy getAuth(). Istnieje jednak wiele powodów, dla których możesz chcieć (lub musieć) przejść na ręczne zarządzanie zależnościami:
- W przypadku aplikacji, w których rozmiar pakietu i czas wczytywania mają ogromne znaczenie, niestandardowa inicjalizacja uwierzytelniania może zmniejszyć ilość danych o wiele kilobajtów. Może też skrócić czas początkowego wczytywania, przenosząc zależności na czas użycia zamiast na czas inicjowania.
- W przypadku kodu, który działa w kontekstach innych niż DOM (np. w przypadku skryptów web worker i service worker), należy używać
initializeAuth(), aby uniknąć błędów.