Modułowa konstrukcja pakietu SDK Firebase JS zapewnia znacznie większą kontrolę nad sposobem tworzenia aplikacji. Ta elastyczność pozwala dostosować zależności do platformy i zoptymalizować rozmiar pakietu, usuwając niepotrzebne funkcje.
Istnieją dwa sposoby inicjalizacji biblioteki Auth: funkcja getAuth() i funkcja initializeAuth() . Pierwsza, getAuth() , zapewnia wszystko, czego potrzebuje Twoja aplikacja, aby móc korzystać ze wszystkich funkcji, jakie ma do zaoferowania biblioteka Auth. Wadą jest to, że pobiera dużo kodu, który jest potencjalnie niewykorzystany przez aplikację. Może także pobierać kod, który po prostu nie jest obsługiwany na docelowej platformie, co prowadzi do błędów. Aby uniknąć tych problemów, możesz użyć initializeAuth() , która pobiera mapę zależności. Funkcja getAuth() po prostu wywołuje initializeAuth() ze wszystkimi określonymi zależnościami. Aby to zilustrować, oto odpowiednik metody 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 rodziny funkcji signInWithPopup lub signInWithRedirect . Wiele aplikacji nie będzie potrzebować elastyczności, jaką zapewnia indexedDB , lub nie będzie potrzebować możliwości obsługi zarówno indexedDB , jak i localStorage , jeśli taka nie będzie dostępna. W takich przypadkach domyślna funkcja getAuth() zawiera dużo nieużywanego kodu, co zwiększa rozmiar pakietu bez powodu. Zamiast tego aplikacje te mogą dostosowywać swoje zależności. Na przykład, jeśli Twoja aplikacja korzysta tylko z uwierzytelniania poprzez łącze e-mail i wystarczy localStorage (ponieważ nie używasz skryptów WWW ani Service Workera), możesz pozbyć się nadmiaru kodu, inicjując Auth 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
});
Za pomocą tego kodu usunięto trzy duże zależności, których aplikacja nie potrzebuje, znacznie zmniejszając przepustowość wykorzystywaną przez użytkowników podczas odwiedzania Twojej witryny.
Uwagi dotyczące konkretnej platformy
W wielu przypadkach konieczne jest ręczne zdefiniowanie zależności uwierzytelniania, aby uniknąć błędów podczas inicjalizacji. Funkcja getAuth() zakłada konkretną platformę. W przypadku domyślnego punktu wejścia jest to środowisko przeglądarki, a w przypadku punktu wejścia Cordova jest to środowisko Cordova. Czasami jednak potrzeby konkretnej aplikacji kolidują z tymi założeniami. Na przykład w przypadku skryptów WWW i procesów roboczych domyślna implementacja getAuth() pobiera kod odczytujący z obiektu window , co spowoduje błędy. W takich przypadkach konieczne jest dostosowanie zależności. Poniższy kod jest odpowiedni do inicjowania biblioteki Auth w kontekście Service Workera:
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ł z trwałością indexedDB (która jest dostępna w kontekstach roboczych) i pomija zależność popupRedirectResolver , która zakłada, że kontekst DOM jest dostępny.
Istnieją inne powody, dla których możesz ręcznie zdefiniować zależności na niektórych platformach. Definiując pole popupRedirectResolver podczas inicjalizacji Auth, w niektórych przypadkach biblioteka wykona dodatkową pracę przy inicjalizacji. W przeglądarkach mobilnych biblioteka automatycznie i zapobiegawczo otworzy ramkę iframe w Twojej domenie Auth. Ma to na celu zapewnienie bezproblemowego działania większości użytkowników, ale może mieć wpływ na wydajność, ładując dodatkowy kod zaraz po uruchomieniu aplikacji. Tego zachowania można uniknąć, korzystając z initializeAuth() i ręcznie przekazując zależność browserPopupRedirectResolver do funkcji, które tego 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 w zależnościach do initializeAuth() podali browserPopupRedirectResolver , trzeci parametr w wywołaniu metodysignInWithRedirect signInWithRedirect() nie byłby potrzebny. Jednak poprzez bezpośrednie przeniesienie tej zależności do wywołania signInWithRedirect() usuwany jest początkowy spadek wydajności podczas inicjalizacji. 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, inicjalizacja niestandardowa zapewnia znacznie większą kontrolę nad wykorzystaniem przez aplikację pakietu Auth SDK. Standardowa funkcja getAuth() jest dobra na początek i sprawdza się w większości przypadków użycia. W przypadku większości aplikacji wystarczy getAuth() . Istnieje jednak wiele powodów, dla których możesz chcieć (lub potrzebować) przejść na ręczne zarządzanie zależnościami:
- W przypadku aplikacji, w których rozmiar pakietu i czas ładowania są niezwykle ważne, niestandardowa inicjalizacja uwierzytelniania może potencjalnie zmniejszyć wiele kilobajtów danych. Może również skrócić czas początkowego ładowania, przenosząc zależności na czas użycia zamiast na czas inicjalizacji.
- W przypadku kodu działającego w kontekstach innych niż DOM (takich jak procesy robocze sieci i usług) należy użyć
initializeAuth(), aby uniknąć błędów.