تخصيص العناصر التابعة للمصادقة

يمنحك التصميم القائم على وحدات حزمة تطوير البرامج (SDK) لـ Firebase JS تحكّمًا أكبر في كيفية إنشاء تطبيقك. تسمح لك هذه المرونة بتخصيص تبعياتك لنظامك الأساسي وتحسين حجم الحزمة من خلال إزالة الميزات التي لا تحتاج إليها.

هناك طريقتان لإعداد مكتبة المصادقة: دالة 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
});

يوجِّه هذا الرمز ميزة "المصادقة" لإجراء الإعداد باستخدام ثبات 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);

إذا قدّمنا browserPopupRedirectResolver في التبعيات initializeAuth()، المعلمة الثالثة في استدعاء الدالة signInWithRedirect() لم تكن هناك حاجة إليه. ولكن من خلال نقل هذه التبعية إلى طلب signInWithRedirect() مباشرةً، نتيجة الأداء الأولي خلال عند إزالة التهيئة. هناك مفاضلات تأتي مع تحريك التبعية، ولكن الجزء المهم هو أنك قادر على اتخاذ قرارات بشأن هذه المفاضلات من خلال تهيئة المكتبة يدويًا.

حالات استخدام الإعداد المخصص

باختصار، تمنحك التهيئة المخصصة تحكمًا أكبر في إدارة استخدام حزمة Auth SDK. تعد الدالة getAuth() القياسية جيدة للحصول على تبدأ وتخدم معظم حالات الاستخدام. بالنسبة إلى معظم التطبيقات، قد يكون getAuth() هو ما يناسبك المحتاجين. ولكن هناك العديد من الأسباب التي قد تدفعك إلى استخدام الطريقة اليدوية (أو تحتاج إليها) إدارة التبعية:

• بالنسبة إلى التطبيقات التي يكون فيها حجم الحزمة وأوقات التحميل مهمَّين للغاية، يجب تخصيص من المحتمل أن يؤدي إعداد المصادقة إلى خفض العديد من الكيلوبايت من البيانات. أُنشأها جون هنتر، الذي كان متخصصًا أيضًا تقليل أوقات التحميل الأولي من خلال نقل التبعيات إلى وقت ستستخدمه بدلاً من وقت التهيئة.
• بالنسبة إلى الرموز البرمجية التي يتم تشغيلها في سياقات غير نموذج العناصر في المستند (DOM) (مثل مشغّلي الويب والخدمات): يجب استخدام initializeAuth() لتجنُّب الأخطاء.