अपनी प्रामाणिक निर्भरताएँ अनुकूलित करें

फायरबेस जेएस एसडीके का मॉड्यूलर डिज़ाइन आपको इस बात पर अधिक नियंत्रण देता है कि आपका ऐप कैसे बनाया गया है। यह लचीलापन आपको अपने प्लेटफ़ॉर्म के लिए अपनी निर्भरताएँ तैयार करने और उन सुविधाओं को हटाकर अपने बंडल आकार को अनुकूलित करने की अनुमति देता है जिनकी आपको आवश्यकता नहीं है।

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

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() फ़ंक्शन एक विशिष्ट प्लेटफ़ॉर्म मानता है। डिफ़ॉल्ट प्रविष्टि बिंदु के लिए, वह एक ब्राउज़र वातावरण है और कॉर्डोवा प्रविष्टि बिंदु के लिए, वह एक कॉर्डोवा वातावरण है। लेकिन कभी-कभी आपके विशेष एप्लिकेशन की ज़रूरतें इन धारणाओं से टकराती हैं। उदाहरण के लिए, वेब और सर्विस वर्कर स्क्रिप्ट के लिए, डिफ़ॉल्ट 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 फ़ील्ड को परिभाषित करके, कुछ मामलों में लाइब्रेरी आरंभीकरण पर अतिरिक्त कार्य करेगी। मोबाइल ब्राउज़र पर, लाइब्रेरी स्वचालित रूप से आपके प्रामाणिक डोमेन के लिए एक 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() पर ले जाकर, आरंभीकरण के दौरान प्रारंभिक प्रदर्शन हिट को हटा दिया जाता है। ऐसे ट्रेडऑफ़ हैं जो निर्भरता को आगे बढ़ाने के साथ आते हैं, लेकिन महत्वपूर्ण बात यह है कि आप लाइब्रेरी को मैन्युअल रूप से प्रारंभ करके उन ट्रेडऑफ़ के बारे में निर्णय लेने में सक्षम हैं।

कस्टम इनिशियलाइज़ेशन का उपयोग कब करें

संक्षेप में, कस्टम इनिशियलाइज़ेशन आपको अपने ऐप के प्रामाणिक एसडीके के उपयोग पर कहीं अधिक नियंत्रण प्रदान करता है। मानक getAuth() फ़ंक्शन आरंभ करने के लिए अच्छा है और अधिकांश उपयोग के मामलों में कार्य करता है। अधिकांश ऐप्स के लिए, getAuth() वह सब कुछ हो सकता है जिसकी आपको आवश्यकता है। लेकिन ऐसे कई कारण हैं जिनकी वजह से आप मैन्युअल निर्भरता प्रबंधन पर स्विच करना चाहते हैं (या इसकी आवश्यकता है):

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