התאמה אישית של יחסי התלות של אימות

העיצוב המודולרי של Firebase JS SDK מאפשר לכם לשלוט טוב יותר באופן שבו האפליקציה בנויה. הגמישות הזו מאפשרת לכם להתאים את התלות שלכם לפלטפורמה ולבצע אופטימיזציה של גודל החבילה על ידי הסרת תכונות שאתם לא צריכים.

יש שתי דרכים לאתחל את ספריית האימות: הפונקציה getAuth() והפונקציה initializeAuth(). הספרייה הראשונה, getAuth(), מספקת את כל מה שהאפליקציה צריכה כדי לנצל את כל התכונות של ספריית האימות. החיסרון הוא שהיא מושכת הרבה קוד שאולי לא נמצא בשימוש באפליקציה. היא גם עשויה למשוך קוד שלא נתמך בפלטפורמה שמטרגטים, מה שמוביל לשגיאות. כדי למנוע את הבעיות האלה, אפשר להשתמש ב-initializeAuth(), שמקבל מיפוי של יחסי תלות. הפונקציה getAuth() פשוט קוראת לפונקציה initializeAuth() עם כל יחסי התלות שצוינו. לדוגמה, הנה המקבילה ל-getAuth() בסביבות דפדפן:

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

התאמה אישית של התלויות

לא כל האפליקציות משתמשות בפונקציות של signInWithPopup או signInWithRedirect. באפליקציות רבות לא נדרשת הגמישות ש-indexedDB מספק, או שלא נדרשת היכולת לתמוך גם ב-indexedDB וגם ב-localStorage אם אחד מהם לא זמין. במקרים כאלה, getAuth() שמוגדר כברירת מחדל כולל הרבה קוד שלא בשימוש, שמגדיל את גודל החבילה ללא סיבה. במקום זאת, האפליקציות האלה יכולות להתאים את התלות שלהן. לדוגמה, אם האפליקציה שלכם משתמשת רק באימות באמצעות קישור באימייל, ו-localStorage מספיק (כי אתם לא משתמשים בסקריפטים של web או service worker), אתם יכולים להסיר הרבה קוד מיותר על ידי הפעלה של Auth באופן הבא:

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

בעזרת הקוד הזה, הסרתם שלוש תלויות גדולות שהאפליקציה לא צריכה, וכך צמצמתם באופן משמעותי את כמות רוחב הפס שהמשתמשים צורכים בכל פעם שהם מבקרים באתר.

שיקולים ספציפיים לפלטפורמה

במקרים רבים, צריך להגדיר ידנית את יחסי התלות של אימות כדי למנוע שגיאות במהלך האתחול. הפונקציה getAuth() מניחה פלטפורמה ספציפית. נקודת הכניסה שמוגדרת כברירת מחדל היא סביבת דפדפן, ונקודת הכניסה של Cordova היא סביבת Cordova. אבל לפעמים הצרכים של האפליקציה הספציפית שלכם לא תואמים להנחות האלה. לדוגמה, בהטמעה של getAuth() שמוגדרת כברירת מחדל בסקריפטים של web worker ו-service worker, הקוד קורא מהאובייקט window, ולכן יופיעו שגיאות. במקרים כאלה, צריך להתאים את יחסי התלות. הקוד הבא מתאים לאתחול ספריית האימות בהקשר של 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
});

הקוד הזה מורה לספריית Auth לבצע אתחול עם indexedDB persistence (שזמין בהקשרים של worker) ומשמיט את התלות popupRedirectResolver, שמניחה שהקשר DOM זמין.

יש סיבות נוספות שבגללן כדאי להגדיר באופן ידני תלות בפלטפורמות מסוימות. אם מגדירים את השדה popupRedirectResolver באתחול של Auth, במקרים מסוימים הספרייה תבצע עבודה נוספת באתחול. בדפדפנים בנייד, הספרייה תפתח באופן אוטומטי iframe לדומיין האימות שלכם מראש. הפעולה הזו מתבצעת כדי להבטיח חוויה חלקה לרוב המשתמשים, אבל היא עלולה להשפיע על הביצועים כי קוד נוסף נטען ברגע שהאפליקציה מתחילה לפעול. כדי להימנע מההתנהגות הזו, אפשר להשתמש ב-initializeAuth() ולהעביר באופן ידני את התלות browserPopupRedirectResolver לפונקציות שזקוקות לה:

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

אם היינו מציינים את browserPopupRedirectResolver כתלות ב-initializeAuth(), לא היה צורך בפרמטר השלישי בקריאה ל-signInWithRedirect(). אבל אם מעבירים את התלות הזו לקריאה ישירה אל signInWithRedirect(), פגיעה בביצועים הראשוניים במהלך האתחול מוסרת. יש חסרונות למעבר התלות, אבל מה שחשוב הוא שתוכלו לקבל החלטות לגבי החסרונות האלה על ידי הפעלה ידנית של הספרייה.

מתי כדאי להשתמש בהגדרה בהתאמה אישית

לסיכום, אתחול בהתאמה אישית מאפשר לכם שליטה רבה יותר בשימוש באפליקציה שלכם ב-Auth SDK. הפונקציה הרגילה getAuth() מתאימה להתחלה ולרוב תרחישי השימוש. ברוב האפליקציות, יכול להיות שכל מה שתצטרכו הוא getAuth(). אבל יש הרבה סיבות שבגללן כדאי (או צריך) לעבור לניהול תלויות ידני:

• באפליקציות שבהן גודל החבילה וזמני הטעינה חשובים במיוחד, אתחול מותאם אישית של Auth יכול לצמצם את כמות הנתונים בכמה קילובייט. הוא גם יכול לקצר את זמני הטעינה הראשוניים על ידי העברת התלויות לזמן השימוש במקום לזמן האתחול.
• כדי למנוע שגיאות בקוד שפועל בהקשרים שאינם DOM (כמו web workers ו-service workers), צריך להשתמש ב-initializeAuth().