طراحی واحدی کیت توسعه نرم‌افزار Firebase JS کنترل بسیار بیشتری بر نحوه ساخت برنامه شما به شما می‌دهد. این انعطاف‌پذیری به شما امکان می‌دهد وابستگی‌هایتان را برای پلاتفرم خودتان سفارشی‌سازی کنید و با حذف ویژگی‌هایی که نیاز ندارید، اندازه دسته‌تان را بهینه کنید.
دو راه برای مقداردهی اولیه کتابخانه 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() پیش‌فرض شامل مقدار زیادی
کد استفاده‌نشده است که اندازه دسته‌ها را بدون دلیل افزایش می‌دهد. درعوض، این برنامه‌ها می‌توانند
وابستگی‌هایشان را سفارشی‌سازی کنند. برای مثال، اگر برنامه شما فقط از
اصالت‌سنجی پیوند ایمیل استفاده می‌کند و «فضای ذخیره‌سازی محلی» کافی است (چون از
برنامه‌های وب یا کارگر سرویس استفاده نمی‌کنید)، می‌توانید با مقداردهی اولیه 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 می‌خواند که باعث بروز خطا می‌شود. در این موارد، لازم است وابستگی‌های خود را سفارشی‌سازی کنید. کد زیر برای مقداردهی اولیه کتابخانه «اصالت‌سنجی» در بافت عامل خدماتی مناسب است:
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 را به دامنه 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» به شما می‌دهد. تابع استاندارد getAuth() برای شروع خوب است و برای اکثر موارد استفاده مناسب است. برای اکثر برنامه‌ها، getAuth() ممکن است تمام چیزی باشد که نیاز دارید. اما دلایل زیادی وجود دارد که ممکن است بخواهید (یا نیاز داشته باشید) به مدیریت وابستگی دستی تغییر دهید:
- برای برنامه‌هایی که اندازه دسته‌ها و زمان‌های بار کردن در آن‌ها بسیار مهم است، مقداردهی اولیه سفارشی Auth می‌تواند به‌طور بالقوه چندین کیلوبایت از داده‌ها را کاهش دهد. با انتقال وابستگی‌ها به زمان استفاده به‌جای زمان مقداردهی اولیه، می‌تواند زمان‌های بار کردن اولیه را نیز کاهش دهد.
- برای کدی که در زمینه‌های غیر DOM (مانند کارگران وب و سرویس) اجرا می‌شود،
initializeAuth()باید برای جلوگیری از خطاها استفاده شود.