Personalizzare le dipendenze dell'autenticazione

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

Esistono due modi per inizializzare la libreria Auth: la funzione getAuth() e la funzione initializeAuth(). Il primo, getAuth(), fornisce tutto ciò di cui la tua app ha bisogno per sfruttare tutte le funzionalità offerte dalla libreria Auth. Lo svantaggio è che estrae molto codice potenzialmente inutilizzato dalla tua app. Potrebbe anche estrarre codice semplicemente non supportato sulla piattaforma di destinazione, causando errori. Per evitare questi problemi, puoi utilizzare initializeAuth(), che accetta una mappa delle dipendenze. La funzione getAuth() chiama semplicemente initializeAuth() con tutte le dipendenze specificate. Per illustrare, 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,
});

Personalizzare le dipendenze

Non tutte le app utilizzano la famiglia di funzioni signInWithPopup o signInWithRedirect. Molte app non avranno bisogno della flessibilità offerta da indexedDB o della possibilità di supportare sia indexedDB che localStorage nel caso in cui uno dei due non sia disponibile. In questi casi, il getAuth() predefinito include molto codice inutilizzato che aumenta le dimensioni dei 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 di service worker o web worker), puoi eliminare gran parte del codice ridondante inizializzando Auth in questo modo:

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 di grandi dimensioni che la tua app non necessita, riducendo significativamente la quantità di larghezza di banda utilizzata dagli utenti ogni volta che visitano il tuo sito.

Considerazioni specifiche della piattaforma

In molti casi, devi definire manualmente le dipendenze di autenticazione per evitare errori durante l'inizializzazione. La funzione getAuth() presuppone una piattaforma specifica. Per l'entry point predefinito, si tratta di un ambiente browser e per l'entry point Cordova, si tratta di un ambiente Cordova. Tuttavia, a volte le esigenze della tua applicazione specifica sono in conflitto con questi presupposti. Per gli script dei service worker e web worker, ad esempio, l'implementazione getAuth() predefinita recupera il codice che legge dall'oggetto window, il che causerà 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 dei worker) e omette la dipendenza popupRedirectResolver, che presuppone la disponibilità di un contesto DOM.

Esistono altri motivi per cui potresti definire manualmente le dipendenze su determinate piattaforme. Se definisci il campo popupRedirectResolver nell'inizializzazione dell'autenticazione, in alcuni casi la libreria eseguirà ulteriori operazioni di inizializzazione. Sui browser mobile, la libreria aprirà automaticamente un iframe al tuo dominio di autenticazione in modo preventivo. Questa operazione viene eseguita per rendere l'esperienza fluida per la maggior parte degli utenti, ma può influire sulle prestazioni 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 nella chiamata a signInWithRedirect() direttamente, l'impatto iniziale sulle prestazioni durante l'inizializzazione viene rimosso. Lo spostamento della dipendenza comporta dei compromessi, ma la cosa importante è che tu possa prendere decisioni in merito inizializzando manualmente la libreria.

Quando utilizzare l'inizializzazione personalizzata

Ricapitolando, l'inizializzazione personalizzata ti offre un controllo molto maggiore sull'utilizzo dell'SDK Auth da parte della tua app. La funzione standard getAuth() è un buon punto di partenza e copre la maggior parte dei casi d'uso. Per la maggior parte delle app, getAuth() potrebbe essere tutto ciò di cui hai bisogno. Tuttavia, ci sono molti motivi per cui potresti voler (o dover) passare alla gestione manuale delle dipendenze:

  • Per le app in cui le dimensioni del bundle e i tempi di caricamento sono estremamente importanti, l'inizializzazione personalizzata di Auth può potenzialmente ridurre molti kilobyte di dati. Può anche 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 i service worker e i web worker), initializeAuth() deve essere utilizzato per evitare errori.