Modułowa konstrukcja pakietu SDK Firebase JS daje dużo większą kontrolę nad sposobem tworzenia aplikacji. Dzięki tej elastyczności możesz dostosować zależności do platformy i zoptymalizować rozmiar pakietu, usuwając funkcje, których nie potrzebujesz.
Bibliotekę uwierzytelniania można zainicjować na 2 sposoby: za pomocą funkcji getAuth() i initializeAuth(). Pierwsza (getAuth()) zawiera wszystko, czego potrzebuje aplikacja, aby korzystać ze wszystkich funkcji biblioteki Auth. Wadą tej metody jest to, że pobiera ona dużo kodu, który może nie być używany przez aplikację. Może też pobierać kod, który nie jest obsługiwany na platformie, na którą kierujesz reklamy, i powodować błędy. Aby uniknąć tych problemów, możesz użyć narzędzia initializeAuth(), które tworzy mapę zależności. Funkcja getAuth() wywołuje po prostu initializeAuth() ze wszystkimi określonymi zależnościami.
Aby to zilustrować, poniżej przedstawiamy odpowiednik interfejsu getAuth() w środowiskach przeglądarki:
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 signInWithPopup lub signInWithRedirect. Wiele aplikacji nie będzie potrzebować elastyczności zapewnianej przez indexedDB lub nie będzie potrzebować możliwości obsługi zarówno indexedDB, jak i localStorage, jeśli któraś z nich będzie niedostępna. W takich przypadkach domyślny getAuth() zawiera dużo nieużywanego kodu, który bez powodu zwiększa rozmiar pakietów. Aplikacje te mogą
dopasowywać swoje zależności. Jeśli na przykład Twoja aplikacja używa tylko uwierzytelniania linków w e-mailach, a wystarczy zasób localStorage (ponieważ nie używasz skryptów Web ani Service Worker), możesz usunąć znaczną ilość zbędnych kodu przez inicjowanie uwierzytelniania 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
});
Ten kod pozwolił Ci usunąć 3 duże zależności, których aplikacja nie potrzebuje, co znacznie zmniejsza przepustowość wykorzystywaną przez użytkowników przy każdych odwiedzinach Twojej witryny.
Uwagi dotyczące poszczególnych platform
Aby uniknąć błędów przy inicjowaniu, w wielu przypadkach trzeba ręcznie zdefiniować zależności uwierzytelniania. Funkcja getAuth() zakłada konkretną platformę. Domyślnym punktem wejścia jest środowisko przeglądarki, a punktem wejścia Cordova – środowisko Cordova. Czasem jednak potrzeby konkretnej aplikacji
są niezgodne z tymi założeniami. Na przykład w przypadku skryptów internetowych i skryptów skryptu service worker domyślna getAuth() pobiera kod, który odczytuje dane z obiektu window, co powoduje błędy. W takich przypadkach musisz dostosować zależności. Do inicjowania biblioteki uwierzytelniania w kontekście skryptu service worker odpowiedni jest ten kod:
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 inicjował się z trwałością indexedDB (która jest dostępna w kontekście instancji roboczych) i pomija zależność popupRedirectResolver, która zakłada, że dostępny jest kontekst DOM.
Istnieją też inne powody, dla których warto ręcznie zdefiniować zależności od określonych platform. Gdy zdefiniujesz pole popupRedirectResolver w trakcie inicjowania uwierzytelniania, w niektórych przypadkach biblioteka wykona dodatkowe czynności przy inicjowaniu. W przeglądarkach mobilnych biblioteka z wyprzedzeniem automatycznie otworzy element iframe w domenie uwierzytelniania. Ma to na celu zapewnienie bezproblemowej obsługi większości użytkowników, ale może to wpłynąć na wydajność przez ładowanie dodatkowego kodu już przy uruchomieniu aplikacji. Takiego zachowania można uniknąć, używając metody 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 w zależnościachinitializeAuth() określilibyśmy browserPopupRedirectResolver, trzeci parametr w wywołaniu funkcji signInWithRedirect() nie byłby potrzebny. Jeśli jednak przeniesiesz tę zależność bezpośrednio do wywołania signInWithRedirect(), początkowe działanie związane z wydajnością podczas inicjowania zostanie usunięte. Przeniesienie zależności wiąże się z pewnymi kompromisami, ale ważna jest możliwość podejmowania decyzji o tych kompromisach przez ręczne zainicjowanie biblioteki.
Kiedy należy używać inicjowania niestandardowego
Podsumowując, niestandardowe inicjowanie daje znacznie większą kontrolę nad wykorzystaniem pakietu Auth SDK w aplikacji. Standardowa funkcja getAuth() jest odpowiednia na początek i działa w większości przypadków. W przypadku większości aplikacji wystarczy getAuth(). Istnieje jednak wiele powodów, dla których możesz (lub potrzebować) przejść na ręczne zarządzanie zależnościami:
- W przypadku aplikacji, w których rozmiar i czas wczytywania pakietu są niezwykle ważne, niestandardowe inicjowanie uwierzytelniania może potencjalnie zmniejszyć ilość kilobajtów danych. Może też skrócić początkowe czasy wczytywania, przenosząc zależności do czasu użycia, a nie do czasu inicjowania.
- W przypadku kodu, który działa w kontekście innym niż DOM (np. instancji sieciowych i instancji service worker), należy używać
initializeAuth(), aby uniknąć błędów.