আপনার প্রমাণ নির্ভরতা কাস্টমাইজ করুন

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() অনেক অব্যবহৃত কোড অন্তর্ভুক্ত করে যা অকারণে বান্ডিলের আকার বাড়ায়। পরিবর্তে, এই অ্যাপ্লিকেশানগুলি তাদের নির্ভরতাগুলিকে উপযোগী করতে পারে৷ উদাহরণস্বরূপ, যদি আপনার অ্যাপ শুধুমাত্র ইমেল লিঙ্ক প্রমাণীকরণ ব্যবহার করে এবং স্থানীয় স্টোরেজ যথেষ্ট হয় (কারণ আপনি ওয়েব বা পরিষেবা কর্মী স্ক্রিপ্ট ব্যবহার করছেন না), তাহলে আপনি এইভাবে প্রমাণীকরণ শুরু করে অনেক কোড ব্লোট মুক্ত করতে পারেন:

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 অবজেক্ট থেকে পড়ে, যা ত্রুটির কারণ হবে। এই ক্ষেত্রে, আপনার নির্ভরতাকে টেইলার করা প্রয়োজন। নিম্নলিখিত কোড একটি পরিষেবা কর্মী প্রসঙ্গে 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 প্রসঙ্গ উপলব্ধ।

আপনি নির্দিষ্ট প্ল্যাটফর্মের উপর নির্ভরতা ম্যানুয়ালি সংজ্ঞায়িত করতে পারেন এমন অন্যান্য কারণ রয়েছে। অথ ইনিশিয়ালাইজেশনে 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() আপনার প্রয়োজন হতে পারে। কিন্তু আপনি ম্যানুয়াল নির্ভরতা ব্যবস্থাপনায় স্যুইচ করতে চান (বা প্রয়োজন) এর অনেক কারণ রয়েছে:

• অ্যাপ্লিকেশানগুলির জন্য যেখানে বান্ডেলের আকার এবং লোডের সময়গুলি অত্যন্ত গুরুত্বপূর্ণ, কাস্টম প্রমাণীকরণ প্রাথমিকভাবে অনেক কিলোবাইট ডেটা হ্রাস করতে পারে৷ এটি প্রারম্ভিক সময়ের পরিবর্তে ব্যবহারের সময় নির্ভরতাগুলি সরিয়ে প্রাথমিক লোডের সময় কমাতে পারে।
• নন-ডোম প্রেক্ষাপটে (যেমন ওয়েব এবং পরিষেবা কর্মীদের) কোড চালানোর জন্য, ত্রুটি এড়াতে initializeAuth() ব্যবহার করতে হবে।