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

يمنحك التصميم المعياري لحزمة تطوير البرامج (SDK) من Firebase بلغة JavaScript إمكانية تحكّم أكبر بكثير في طريقة إنشاء تطبيقك. تتيح لك هذه المرونة تخصيص التبعيات للنظام الأساسي وتحسين حجم الحِزمة من خلال إزالة الميزات التي لا تحتاج إليها.

تتوفّر طريقتان لتهيئة مكتبة 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. ولكن في بعض الأحيان، تتعارض احتياجات تطبيقك مع هذه الافتراضات. بالنسبة إلى نصوص الويب وService Worker البرمجية، على سبيل المثال، يؤدي التنفيذ التلقائي 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
});

يطلب هذا الرمز من المصادقة بدء عملية الإعداد باستخدام 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() مباشرةً، تتم إزالة التأثير السلبي الأوّلي في الأداء أثناء عملية التهيئة. هناك بعض التنازلات التي يجب تقديمها عند نقل التبعية، ولكن الأهم هو أن تتمكّن من اتّخاذ قرارات بشأن هذه التنازلات من خلال تهيئة المكتبة يدويًا.

حالات استخدام عملية الإعداد المخصّصة

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

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