התאם אישית את תלות ההסמכה שלך

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

ישנן שתי דרכים לאתחל את ספריית Auth: הפונקציה getAuth() והפונקציה initializeAuth() . הראשון, getAuth() , מספק את כל מה שהאפליקציה שלך צריכה כדי לנצל את כל התכונות שיש לספריית Auth להציע. החיסרון הוא שהוא מושך הרבה קוד שעלול לא להשתמש באפליקציה שלך. זה גם עשוי למשוך קוד שפשוט לא נתמך בפלטפורמה שאליה אתה ממקד, מה שיוביל לשגיאות. כדי להימנע מבעיות אלה, אתה יכול להשתמש 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 מספיק (מכיוון שאינך משתמש בסקריפטים של אינטרנט או 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. אבל לפעמים הצרכים של האפליקציה הספציפית שלך מתנגשים עם הנחות אלו. עבור סקריפטים של Web ו-Service Worker, למשל, יישום ברירת המחדל getAuth() מושך קוד שקורא מאובייקט window , מה שיגרום לשגיאות. במקרים אלה, יש צורך להתאים את התלות שלך. הקוד הבא מתאים לאתחול ספריית Auth בהקשר של 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 (הזמינה בהקשרי עובד) ומשמיטה את התלות popupRedirectResolver , אשר מניחה שהקשר DOM זמין.

ישנן סיבות אחרות שאתה עשוי להגדיר ידנית תלות בפלטפורמות מסוימות. על ידי הגדרת השדה popupRedirectResolver באתחול Auth, במקרים מסוימים הספרייה תבצע עבודה נוספת באתחול. בדפדפנים ניידים, הספרייה תפתח אוטומטית iframe לדומיין ה-Auth שלך באופן מנע. זה נעשה כדי להפוך את החוויה לחלקה עבור רוב המשתמשים, אבל זה יכול להשפיע על הביצועים על ידי טעינת קוד נוסף מיד עם הפעלת האפליקציה. ניתן להימנע מהתנהגות זו על ידי שימוש ב- 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() עשוי להיות כל מה שאתה צריך. אבל ישנן סיבות רבות מדוע ייתכן שתרצה (או תצטרך) לעבור לניהול תלות ידני:

• עבור אפליקציות שבהן גודל החבילה וזמני הטעינה חשובים ביותר, אתחול אימות מותאם אישית עשוי להפחית קילובייט רבים של נתונים. זה יכול גם לצמצם את זמני הטעינה הראשוניים על ידי העברת התלות לזמן השימוש במקום לזמן האתחול.
• עבור קוד שפועל בהקשרים שאינם DOM (כמו Web ו-Service Workers), יש להשתמש initializeAuth() כדי למנוע שגיאות.