La struttura modulare dell'SDK Firebase JS offre un maggiore controllo sulle come è 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 Auth: 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 estrae molto codice che potenzialmente
inutilizzati dalla tua app. Potrebbe anche eseguire il pull in codice che non è semplicemente supportato
alla piattaforma scelta come target, generando errori. Per evitare questi problemi, puoi
usa initializeAuth(), che accetta una mappa delle dipendenze. 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 valore getAuth() predefinito include molti
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'indirizzo email
e localStorage sia sufficiente (poiché non stai utilizzando
script dei service worker), puoi eliminare molti sovraccarichi di codice inizializzando Auth
nel seguente 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 grandi che la tua app non riducendo significativamente la quantità di larghezza di banda utilizzata dagli utenti quando visitano il tuo sito.
Considerazioni specifiche per la piattaforma
In molti casi, devi definire manualmente le dipendenze di Auth per evitare errori all'inizializzazione. La funzione getAuth() presuppone una piattaforma specifica. Per il punto di ingresso predefinito, ovvero l'ambiente del browser e per
Il punto di accesso a Cordova è l'ambiente circostante. Ma a volte, però, le esigenze
la tua applicazione specifica
con queste ipotesi. 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 quelle
in ogni caso, è 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, ovvero
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à altre attività sull'inizializzazione. Nei browser mobile, la libreria aprirà automaticamente un iframe per il tuo dominio Auth. Ciò avviene per semplificare l'esperienza alla maggior parte
per gli utenti, ma può influire sulle prestazioni
caricando codice aggiuntivo
. 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
Per riepilogare, l'inizializzazione personalizzata ti offre un controllo molto maggiore sull'utilizzo dell'SDK Auth da parte della tua app. La funzione getAuth() standard è un buon punto di partenza e soddisfa 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 del bundle e i tempi di caricamento sono estremamente importanti, l'inizializzazione dell'autenticazione personalizzata 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 web e service worker),
initializeAuth()deve essere utilizzato per evitare errori.