Dostosuj zależności uwierzytelniania

Modułowa konstrukcja pakietu SDK Firebase JS zapewnia dużo większą kontrolę sposób tworzenia aplikacji. Dzięki temu możesz dostosować do własnych potrzeb zależności dla swojej 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 funkcji initializeAuth(). Pierwsza (getAuth()) zawiera wszystkie informacje by Twoja aplikacja mogła korzystać ze wszystkich funkcji biblioteki Auth co oferuje Twoja firma. Jego wadą jest to, że pobiera on dużo kodu, który potencjalnie nieużywane przez aplikację. Może też pobierać kod, który nie jest obsługiwany na na wybraną platformę, co może powodować błędy. Aby uniknąć tych problemów, możesz: użyj metody initializeAuth(), która tworzy mapę zależności. getAuth() funkcja po prostu wywołuje 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 rodziny signInWithPopup lub signInWithRedirect funkcji. Wiele aplikacji nie będzie potrzebować elastyczności, jaką zapewnia indexedDB. nie będą potrzebować możliwości obsługi zarówno indexedDB, jak i localStorage, jeśli nie są dostępne. W takich przypadkach domyślna wartość getAuth() zawiera wiele elementów nieużywany kod, który bez powodu zwiększa rozmiary pakietów. Zamiast tego mogą dostosować swoje zależności. Na przykład: jeśli aplikacja korzysta tylko z linku w e-mailu i uwierzytelnianie lokalne jest wystarczające (ponieważ nie korzystasz z skrypty service worker), możesz pozbyć się nadmiaru kodu, inicjując uwierzytelnianie. podobny do tego:

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 udało Ci się usunąć 3 duże zależności, z których Twoja aplikacja nie korzysta znacznie zmniejsza przepustowość wykorzystywaną przez użytkowników odwiedzają Twoją witrynę.

Uwagi dotyczące poszczególnych platform

W wielu przypadkach trzeba ręcznie zdefiniować zależności uwierzytelniania, aby uniknąć błędów przy inicjowaniu. Funkcja getAuth() zakłada platformy. Domyślnym punktem wejścia jest środowisko przeglądarki, a dla interfejsu Punkt wejścia Kordowy to środowisko Cordova. Czasami jednak potrzeba koliduje z tymi założeniami. Do sieci i usług skryptów roboczych, np. domyślna implementacja getAuth() pobiera który odczytuje z obiektu window, co powoduje błędy. W tych konieczne jest dopasowanie zależności. Ten kod jest odpowiednie do zainicjowania biblioteki Auth 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 inicjował się z trwałością indexedDB (która jest dostępne w kontekstach instancji roboczych) i pomija zależność popupRedirectResolver, który zakłada, że dostępny jest kontekst DOM.

Istnieją też inne powody, dla których możesz ręcznie definiować zależności od określonych platform. Dzięki zdefiniowaniu pola popupRedirectResolver w inicjowaniu uwierzytelniania w niektórych przypadkach biblioteka wykonuje dodatkowe czynności przy inicjowaniu. Wł. mobilnych, biblioteka automatycznie otworzy element iframe na stronie Auth z wyprzedzeniem. W ten sposób chcemy ułatwić korzystanie z tych usług użytkowników, ale może wpływać na wydajność przez wczytywanie dodatkowego kodu w momencie, gdy po uruchomieniu aplikacji. Takiego zachowania można uniknąć, używając funkcji initializeAuth() i ręcznie przekazując zależność browserPopupRedirectResolver do funkcji którzy 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 w zależnościach przekazali element browserPopupRedirectResolver initializeAuth(), trzeci parametr w wywołaniu funkcji signInWithRedirect() nie byłoby potrzebne. Przeniesienie tej zależności do wywołania signInWithRedirect(), początkowy wzrost skuteczności w okresie zostanie usunięte. Przeniesienie danych osobowych wiążą się z pewnymi kompromisami ale ważna jest jeszcze możliwość podejmowania decyzji te kompromisy, ręcznie inicjując bibliotekę.

Kiedy należy używać inicjowania niestandardowego

Podsumujmy. Niestandardowe inicjowanie daje znacznie większą kontrolę nad pakietu Auth SDK. Standardowa funkcja getAuth() jest odpowiednia do uzyskania i działa w większości przypadków użycia. W większości aplikacji możesz używać getAuth() potrzeby. Jest jednak wiele powodów, dla których możesz (lub potrzebować) przejść na płatności ręczne zarządzanie zależnościami:

  • W przypadku aplikacji, w których rozmiar i czas wczytywania są niezwykle istotne, ustaw niestandardowy Inicjowanie uwierzytelniania może potencjalnie zmniejszyć ilość kilobajtów danych. it może też skrócić początkowe czasy wczytywania, przenosząc zależności na czas zamiast czasu inicjowania.
  • W przypadku kodu, który działa w kontekście innym niż DOM (np. Web i service worker): Aby uniknąć błędów, należy użyć właściwości initializeAuth().