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

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

คุณเริ่มต้นใช้งานไลบรารีการตรวจสอบสิทธิ์ได้ 2 วิธี ได้แก่ ฟังก์ชัน 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,
});

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

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

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

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

ในหลายกรณี คุณต้องกำหนดการขึ้นต่อกันของ Auth ด้วยตนเองเพื่อ หลีกเลี่ยงข้อผิดพลาดในการเริ่มต้น ฟังก์ชัน getAuth() จะถือว่าแพลตฟอร์ม หนึ่งๆ สำหรับจุดแรกเข้าเริ่มต้นคือสภาพแวดล้อมของเบราว์เซอร์ และสำหรับจุดแรกเข้าของ Cordova คือสภาพแวดล้อมของ Cordova แต่บางครั้งความต้องการของแอปพลิเคชันเฉพาะของคุณอาจขัดแย้งกับสมมติฐานเหล่านี้ เช่น สำหรับสคริปต์ของ Web และ Service Worker การติดตั้งใช้งาน 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
});

โค้ดนี้จะสั่งให้ Auth เริ่มต้นด้วยการคงอยู่ของ indexedDB (ซึ่งพร้อมใช้งานในบริบทของ Worker) และละเว้นทรัพยากร Dependency ของ popupRedirectResolver ซึ่งถือว่ามีบริบท DOM อยู่

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

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

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

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