העיצוב המודולרי של ה-SDK של Firebase ל-JavaScript מאפשר לכם לשלוט בצורה רבה יותר בתהליך פיתוח האפליקציה. הגמישות הזו מאפשרת להתאים אישית את יחסי התלות לפלטפורמה שלכם ולבצע אופטימיזציה של גודל החבילה על ידי הסרת תכונות שאתם לא צריכים.
יש שתי דרכים לאתחל את ספריית האימות: הפונקציה 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 (משום שלא משתמשים באינטרנט
סקריפטים של 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
});
בעזרת הקוד הזה, הסרתם שלוש יחסי תלות גדולים שהאפליקציה לא זקוקה להם, וכך הפחתתם באופן משמעותי את כמות רוחב הפס שהמשתמשים משתמשים בו בכל פעם שהם מבקרים באתר.
שיקולים ספציפיים לפלטפורמה
במקרים רבים, צריך להגדיר באופן ידני את יחסי התלות של Auth כדי למנוע שגיאות במהלך האימות. הפונקציה getAuth()
מניחה
הפלטפורמה. בנקודת הכניסה שמוגדרת כברירת מחדל, זוהי סביבה של דפדפן, ובנקודת הכניסה של Cordova, זוהי סביבה של Cordova. אבל לפעמים הצרכים של האפליקציה הספציפית שלכם לא תואמים להנחות האלה. לאינטרנט ולשירות
סקריפטים של worker, לדוגמה, הטמעת ברירת המחדל של getAuth()
שולפת
שקורא מהאובייקט 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
(שזמינה בהקשרים של עובדים) ומחסיר את התלות ב-popupRedirectResolver
, שמניחה שיש הקשר DOM זמין.
יש סיבות אחרות לכך שתרצו להגדיר ידנית יחסי תלות בפלטפורמות מסוימות. על ידי הגדרת השדה popupRedirectResolver
באתחול האימות,
במקרים מסוימים הספרייה תבצע עבודה נוספת על האתחול. בדפדפנים לנייד, הספרייה תפתח באופן אוטומטי 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()
הוא כל מה שאפשר
צריכים. אבל יש הרבה סיבות אפשריות לכך שתרצו (או תצטרכו) לעבור לדף ידני.
ניהול יחסי תלות:
- באפליקציות שבהן גודל החבילה וזמני הטעינה חשובים במיוחד, מומלץ להוסיף התאמה אישית אתחול אימות עלול לקצר קילובייט (KB) רבים של נתונים. הוא הוא יכול גם לקצר את זמני הטעינה המתחילים על ידי העברת יחסי התלות בזמן במקום זמן האתחול.
- בקוד שפועל בהקשרים שאינם DOM (כמו Web Workers ו-Service Workers), צריך להשתמש ב-
initializeAuth()
כדי למנוע שגיאות.