ऑथ डिपेंडेंसी को पसंद के मुताबिक बनाना

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 काफ़ी है (क्योंकि वेब या सर्विस वर्कर स्क्रिप्ट का इस्तेमाल नहीं किया जा रहा है), तो 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 ऑब्जेक्ट से डेटा पढ़ता है. इससे गड़बड़ियां होंगी. ऐसे मामलों में, आपको अपनी डिपेंडेंसी को ज़रूरत के हिसाब से बनाना होगा. नीचे दिया गया कोड, सर्विस वर्कर के कॉन्टेक्स्ट में Auth लाइब्रेरी को शुरू करने के लिए सही है:

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 कॉन्टेक्स्ट उपलब्ध है.

कुछ प्लैटफ़ॉर्म पर डिपेंडेंसी को मैन्युअल तरीके से तय करने की अन्य वजहें भी हो सकती हैं. Auth शुरू करने के दौरान 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);

अगर हमने initializeAuth() की डिपेंडेंसी में browserPopupRedirectResolver दिया होता, तो signInWithRedirect() को कॉल करने के लिए तीसरे पैरामीटर की ज़रूरत नहीं होती. हालांकि, इस डिपेंडेंसी को सीधे तौर पर signInWithRedirect() को कॉल करने पर ले जाने से, शुरुआत में परफ़ॉर्मेंस पर पड़ने वाला असर कम हो जाता है. डिपेंडेंसी को ट्रांसफ़र करने से कुछ समस्याएं आ सकती हैं. हालांकि, सबसे अहम बात यह है कि लाइब्रेरी को मैन्युअल तरीके से शुरू करके, उन समस्याओं के बारे में फ़ैसले लिए जा सकते हैं.

कस्टम इनिशियलाइज़ेशन का इस्तेमाल कब करना चाहिए

संक्षेप में कहें, तो कस्टम इनिशियलाइज़ेशन से आपको Auth SDK के इस्तेमाल पर ज़्यादा कंट्रोल मिलता है. स्टैंडर्ड getAuth() फ़ंक्शन, शुरू करने के लिए अच्छा है. साथ ही, यह ज़्यादातर इस्तेमाल के उदाहरणों के लिए काम करता है. ज़्यादातर ऐप्लिकेशन के लिए, getAuth() ही काफ़ी होता है. हालांकि, मैन्युअल डिपेंडेंसी मैनेजमेंट पर स्विच करने की कई वजहें हो सकती हैं:

• जिन ऐप्लिकेशन के लिए बंडल का साइज़ और लोड होने में लगने वाला समय बहुत ज़रूरी होता है उनके लिए, कस्टम ऑथराइज़ेशन की सुविधा को चालू करने से कई किलोबाइट डेटा कम किया जा सकता है. यह शुरुआती लोड होने के समय को भी कम कर सकता है. इसके लिए, यह डिपेंडेंसी को शुरू होने के समय के बजाय इस्तेमाल के समय पर ले जाता है.
• नॉन-डॉम कॉन्टेक्स्ट (जैसे, वेब और सर्विस वर्कर) में चलने वाले कोड के लिए, गड़बड़ियों से बचने के लिए initializeAuth() का इस्तेमाल करना ज़रूरी है.