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

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

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

باستخدام هذا الرمز، قمت بإزالة ثلاث تبعيات كبيرة لا يحتاجها تطبيقك، مما يقلل بشكل كبير من مقدار النطاق الترددي الذي يستخدمه المستخدمون عند زيارتهم لموقعك.

اعتبارات خاصة بالمنصة

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