Personalizzare le dipendenze dell'autenticazione

Il design modulare dell'SDK Firebase JS ti offre un maggiore controllo su come viene creata la tua app. Questa flessibilità ti consente di personalizzare le dipendenze per la tua piattaforma e ottimizza le dimensioni dei bundle eliminando le funzionalità che non ti servono.

Esistono due modi per inizializzare la libreria di autenticazione: la funzione getAuth() e la funzione initializeAuth(). Il primo, getAuth(), fornisce tutto quanto serve alla tua app per sfruttare tutte le funzionalità della libreria Auth. Lo svantaggio è che importa molto codice potenzialmente non utilizzato dalla tua app. Potrebbe anche importare codice semplicemente non supportato sulla piattaforma di destinazione, causando errori. Per evitare questi problemi, puoi utilizzare initializeAuth(), che accetta una mappa di dipendenze. La funzione getAuth() chiama semplicemente initializeAuth() con tutte le dipendenze specificate. Per spiegarci, ecco l'equivalente di getAuth() negli ambienti browser:

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,
});

Personalizza le dipendenze

Non tutte le app utilizzano la famiglia signInWithPopup o signInWithRedirect di funzioni. Molte app non hanno bisogno della flessibilità offerta da indexedDB, oppure non avrà bisogno della possibilità di supportare sia indexedDB sia localStorage nel caso non sarà disponibile. In questi casi, il getAuth() predefinito include molto codice non utilizzato che aumenta le dimensioni del bundle senza motivo. Queste app possono invece personalizzare le proprie dipendenze. Ad esempio, se la tua app utilizza solo l'autenticazione tramite link email e localStorage è sufficiente (perché non utilizzi script web o service worker), puoi rimuovere molto codice inutilizzato inizializzando Auth come segue:

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
});

Con questo codice, hai rimosso tre dipendenze grandi che la tua app non riducendo significativamente la quantità di larghezza di banda utilizzata dagli utenti quando visitano il tuo sito.

Considerazioni specifiche della piattaforma

In molti casi, devi definire manualmente le dipendenze di Auth per evitare errori all'inizializzazione. La funzione getAuth() presuppone uno specifico completamente gestita. Per il punto di ingresso predefinito, ovvero l'ambiente del browser e per Il punto di accesso a Cordova è l'ambiente circostante. Tuttavia, a volte le esigenze della tua applicazione specifica entrano in conflitto con questi presupposti. Ad esempio, per gli script worker web e di servizio, l'implementazione predefinita di getAuth() importa codice che legge dall'oggetto window, causando errori. In questi casi, è necessario personalizzare le dipendenze. Il seguente codice è appropriato per inizializzare la libreria Auth in un contesto di 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
});

Questo codice indica ad Auth di inizializzarsi con la persistenza indexedDB (disponibile nei contesti worker) e omette la dipendenza popupRedirectResolver, che presuppone che sia disponibile un contesto DOM.

Esistono altri motivi per cui potresti definire manualmente le dipendenze piattaforme di terze parti. Se definisci il campo popupRedirectResolver nell'inizializzazione dell'autenticazione, in alcuni casi la libreria eseguirà un'operazione aggiuntiva durante l'inizializzazione. Attivato browser mobile, la libreria aprirà automaticamente un iframe per il tuo account il dominio in modo preventivo. Questo viene fatto per rendere l'esperienza fluida per la maggior parte degli utenti, ma può influire sul rendimento caricando codice aggiuntivo all'avvio dell'app. Questo comportamento può essere evitato utilizzando initializeAuth() e passando manualmente la dipendenza browserPopupRedirectResolver alle funzioni che ne hanno bisogno:

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);

Se avessimo fornito browserPopupRedirectResolver nelle dipendenze di initializeAuth(), il terzo parametro nella chiamata a signInWithRedirect() non sarebbe stato necessario. Tuttavia, spostando questa dipendenza direttamente sulla chiamata a signInWithRedirect(), l'impatto iniziale sul rendimento durante l'inizializzazione viene rimosso. Lo spostamento della dipendenza comporta dei compromessi, ma la parte importante è che puoi prendere decisioni in merito inizializzando manualmente la libreria.

Quando utilizzare l'inizializzazione personalizzata

Ricapitolando, l'inizializzazione personalizzata ti offre un controllo molto maggiore sulle l'utilizzo dell'SDK Auth. La funzione getAuth() standard è ideale per ottenere per la maggior parte dei casi d'uso. Per la maggior parte delle app, getAuth() potrebbe essere tutto ciò di cui hai bisogno. Ma ci sono molti motivi per cui potresti voler (o avere) bisogno di passare alla modalità manuale gestione delle dipendenze:

  • Per le app in cui le dimensioni dei pacchetti e i tempi di caricamento sono estremamente importanti, L'inizializzazione dell'autenticazione può potenzialmente ridurre molti kilobyte di dati. Inoltre, consente di ridurre i tempi di caricamento iniziali spostando le dipendenze al momento dell'utilizzo anziché al momento dell'inizializzazione.
  • Per il codice eseguito in contesti non DOM (come worker web e service worker), initializeAuth() deve essere utilizzato per evitare errori.