ปรับแต่งทรัพยากร Dependency ของการตรวจสอบสิทธิ์

การออกแบบโมดูลนี้ของ Firebase JS SDK ทำให้คุณควบคุมการสร้างแอปได้ดีขึ้นมาก ความยืดหยุ่นนี้ทำให้คุณปรับ���ต่งทรัพยากร Dependency สำหรับแพลตฟอร์มและเพิ่มประสิทธิภาพขนาดแพ็กเกจได้โดยการตัดฟีเจอร์ที่ไม่ต้องการออก

การเริ่มต้นไลบรารีการตรวจสอบสิทธิ์มี 2 วิธี ได้แก่ ฟังก์ชัน getAuth() และฟังก์ชัน initializeAuth() ฟีเจอร์แรกคือ getAuth() จะมีทุกอย่างที่แอปของคุณต้องการเพื่อใช้ประโยชน์จากฟีเจอร์ทั้งหมดที่มีในไลบรารีการตรวจสอบสิทธิ์ ข้อเสียคือระบบจะดึงโค้ดจำนวนมากที่แอปอาจไม่ได้ใช้ นอกจากนี้ยังอาจดึงโค้ดที่เพียงไม่รองรับในแพลตฟอร์มที่คุณกำหนดเป้าหมายอยู่และทำให้เกิดข้อผิดพลาดด้วย เพื่อหลีกเลี่ยงปัญหาเหล่านี้ คุณสามารถใช้ initializeAuth() ซึ่งจะใช้แผนที่ทรัพยากร Dependency ฟังก์ชัน getAuth() จะเรียกใช้ initializeAuth() พร้อมทรัพยากร Dependency ทั้งหมดที่ระบุ เพื่อให้เห็นภาพ นี่คือฟังก์ชันที่เทียบเท่ากับ 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,
});

การปรับแต่งทรัพยากร Dependency

แอปบางแอปไม่ได้ใช้ฟังก์ชันในตระกูล signInWithPopup หรือ signInWithRedirect แอปจำนวนมากไม่จำเป็นต้องมีความยืดหยุ่นแบบที่ indexedDB มีให้ หรือไม่จำเป็นต้องรองรับทั้ง indexedDB และ localStorage หากไม่มีให้เลือก ในกรณีเหล่านี้ getAuth() เริ่มต้นจะมีโค้ดที่ไม่มีการใช้งานจำนวนมากซึ่งจะเพิ่มขนาด Bundle โดยไม่มีเหตุผล แอปเหล่านี้จะปรับแต่ง ทรัพยากร Dependency ได้ ตัวอย่างเช่น หากแอปของคุณใช้เพียงการตรวจสอบสิท��ิ์ลิงก์อีเมลและ localStorage นั้นเพียงพอแล้ว (เนื่องจากคุณไม่ได้ใช้ส����ิปต์เว็บหรือสคริปต์ของโปรแกรมทำงานของบริการ) คุณสามารถตัดการขยายโค้ดจำนวนมากออกไปได้โดยเริ่มต้นการตรวจสอบสิทธิ์ดังนี้

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
});

โค้ดนี้ช่วยขจัดทรัพยากร Dependency ขนาดใหญ่ 3 รายการที่แอปของคุณไม่จำเป็นต้องใช้ออกไป ซึ่งช่วยลดจำนวนแบนด์วิดท์ที่ผู้ใช้ต้องใช้เมื่อเข้าชมเว็บไซต์ของคุณลงได้อย่างมาก

ข้อควรพิจารณาเฉพาะแพลตฟอร์ม

ในหลายกรณี คุณต้องระบุทรัพยากร Dependency ของการตรวจสอบสิทธิ์ด้วยตนเองเพื่อหลีกเลี่ยงข้อผิดพลาดในการเริ่มต้น ฟังก์ชัน getAuth() จะถือว่ามาจากแพลตฟอร์มที่เฉพาะเจาะจง จุดแรกเข้าเริ่มต้นเป็นสภาพแวดล้อมของเบราว์เซอร์และสำหรับจุดแรกเข้าของ Cordova นั่นก็คือสภาพแวดล้อม Cordova แต่บางครั้งความต้องการของแอปพลิเคชัน ของคุณก็ขัดแย้งกับสมมติฐานเหล่านี้ ตัวอย่างเช่น สำหรับสคริปต์เว็บและโปรแกรมทำงานของบริการ การใช้งาน getAuth() เริ่มต้นจะดึงโค้ดที่อ่านจากออบเจ็กต์ window ซึ่งจะทำให้เกิดข้อผิดพลาด ในกรณีเหล่านั้น คุณจำเป็นต้องปรับทรัพยากร Dependency เอง โค้ดต่อไปนี้มีความเหมาะสมที่จะเริ่มต้นไลบรารีการตรวจสอบสิทธิ์ในบริบทของ Service Worker

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 (ซึ่งจะพร้อมใช้งานในบริบทของผู้ปฏิบัติงาน) และละเว้นทรัพยากร Dependency ของ popupRedirectResolver ซึ่งจะถือว่าบริบท DOM พร้อมใช้งาน

มีเหตุผลอื่นๆ ที่คุณอาจกำหนดทรัพยากร Dependency ในบางแพลตฟอร์มด้วยตัวเอง การกำหนดช่อง popupRedirectResolver ในการเริ่มต้นการตรวจสอบสิทธิ์ในบางกรณี ไลบรารีจะดำเนินการเพิ่มเติมในการเริ่มต้น ในเบราว์เซอร์ในอุปกรณ์เคลื่อนที่ ไลบรารีจะเปิด iframe ไปยังโดเมน Auth ของคุณชั่วคราวโด���อัตโนมัติ การทำเช่นนี้ทำให้ผู้ใช้ส่วนใหญ่ได้รับประสบการณ์การใช้งานที่ราบรื่น แต่ก็อาจส่งผลกับประสิทธิภาพได้ด้วยการโหลดโค้ดเพิ่มเติมทันทีที่แอปเริ่มทำงาน คุณหลีกเลี่ยงลักษณะการทำงานนี้ได้โดยใช้ initializeAuth() และส่ง���รัพยากร Dependency ของ 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 ในทรัพยากร Dependency ไปยัง initializeAuth() แล้ว ก็ไม่จำเป็นต้องใช้พารามิเตอร์ที่ 3 ในการเรียกใช้ signInWithRedirect() แต่เมื่อย้ายทรัพยากร Dependency นั้นไปยังการเรียกไปยัง signInWithRedirect() โดยตรง ระบบจะนำ Hit ด้านประสิทธิภาพเริ่มต้นระหว่างการกำหนดค่าออก มีทั้งข้อดีและข้อเสีย แต่สิ่งสำคัญคือคุณสามารถตัดสินใจเกี่ยวกับข้อดีข้อเสียเหล่านั้นด้วยการเริ่มต้นใช้งานไลบรารีด้วยตนเอง

กรณีที่ควรใช้การเริ่มต้นที่กําหนดเอง

กล่าวโดยสรุปคือ การเริ่มต้นที่กำหนดเองช่วยให้คุณควบคุมการใช้ Auth SDK ของแอปได้มากขึ้น ฟังก์ชัน getAuth() มาตรฐานเหมาะกับการเริ่มต้นใช้งานและแสดง Use Case ส่วนใหญ่ สำหรับแอปส่วนใหญ่ คุณอาจ ต้องใช้ getAuth() แต่มีหลายสาเหตุที่คุณอาจต้องการ (หรือจำเป็นต้อง) เปลี่ยนไปใช้การจัดการการขึ้นต่อกันด้วยตนเอง เช่น

• สำหรับแอปที่ขนาดแพ็กเกจและเวลาในการโหลดมีความสำคัญมาก การเริ่มต้นการตรวจสอบสิทธิ์แบบกำหนดเองอาจช่วยลดข้อมูลหลายกิโลไบต์ได้ นอกจากนี้ยังช่วยลดเวลาในการโหลดเริ่มต้นด้วยการย้ายทรัพยากร Dependency ไปยังเวลาใช้งานแทนเวลาเริ่มต้น
• สำหรับโค้ดที่ทำงานในบริบทที่ไม่ใช่ DOM (เช่น Web และ Service Worker) ต้องใช้ initializeAuth() เพื่อหลีกเลี่ยงข้อผิดพลาด