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

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

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