Tuỳ chỉnh phần phụ thuộc tính năng Xác thực

Thiết kế dạng mô-đun của Firebase JS SDK giúp bạn kiểm soát chặt chẽ hơn nhiều đối với cách xây dựng ứng dụng. Tính linh hoạt này cho phép bạn điều chỉnh các phần phụ thuộc cho nền tảng của mình và tối ưu hoá kích thước gói bằng cách loại bỏ những tính năng mà bạn không cần.

Có hai cách để khởi tạo thư viện Auth: hàm getAuth() và hàm initializeAuth(). Thư viện đầu tiên, getAuth(), cung cấp mọi thứ mà ứng dụng của bạn cần để tận dụng tất cả các tính năng mà thư viện Auth cung cấp. Nhược điểm là nó kéo theo nhiều mã mà ứng dụng của bạn có thể không dùng đến. Nó cũng có thể kéo theo mã không được hỗ trợ trên nền tảng mà bạn đang nhắm đến, dẫn đến lỗi. Để tránh những vấn đề này, bạn có thể sử dụng initializeAuth(), nhận một bản đồ các phần phụ thuộc. Hàm getAuth() chỉ cần gọi initializeAuth() với tất cả các phần phụ thuộc được chỉ định. Để minh hoạ, đây là nội dung tương đương với getAuth() trên các môi trường trình duyệt:

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

Điều chỉnh các phần phụ thuộc

Không phải ứng dụng nào cũng sử dụng nhóm hàm signInWithPopup hoặc signInWithRedirect. Nhiều ứng dụng sẽ không cần đến sự linh hoạt mà indexedDB mang lại, hoặc không cần khả năng hỗ trợ cả indexedDB và localStorage nếu một trong hai không có sẵn. Trong những trường hợp này, getAuth() mặc định chứa rất nhiều mã không dùng đến, làm tăng kích thước gói mà không có lý do. Thay vào đó, các ứng dụng này có thể điều chỉnh các phần phụ thuộc của chúng. Ví dụ: nếu ứng dụng của bạn chỉ sử dụng phương thức xác thực bằng đường liên kết qua email và localStorage là đủ (vì bạn không sử dụng tập lệnh web hoặc trình chạy dịch vụ), thì bạn có thể loại bỏ nhiều mã dư thừa bằng cách khởi chạy Auth như sau:

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

Với đoạn mã này, bạn đã xoá 3 phần phụ thuộc lớn mà ứng dụng của bạn không cần, giảm đáng kể lượng băng thông mà người dùng sử dụng bất cứ khi nào họ truy cập vào trang web của bạn.

Những điều cần cân nhắc theo từng nền tảng

Trong nhiều trường hợp, bạn cần xác định các phần phụ thuộc Auth theo cách thủ công để tránh lỗi khi khởi chạy. Hàm getAuth() giả định một nền tảng cụ thể. Đối với điểm truy cập mặc định, đó là môi trường trình duyệt và đối với điểm truy cập Cordova, đó là môi trường Cordova. Nhưng đôi khi nhu cầu của ứng dụng cụ thể của bạn lại xung đột với những giả định này. Ví dụ: đối với các tập lệnh web và worker dịch vụ, chế độ triển khai getAuth() mặc định sẽ kéo mã đọc từ đối tượng window, điều này sẽ gây ra lỗi. Trong những trường hợp đó, bạn cần điều chỉnh các phần phụ thuộc. Đoạn mã sau đây phù hợp để khởi chạy Thư viện Xác thực trong ngữ cảnh của trình chạy dịch vụ:

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

Mã này hướng dẫn Auth khởi tạo bằng tính năng duy trì indexedDB (có trong các ngữ cảnh worker) và bỏ qua phần phụ thuộc popupRedirectResolver, giả định rằng có sẵn ngữ cảnh DOM.

Có những lý do khác khiến bạn có thể xác định các phần phụ thuộc theo cách thủ công trên một số nền tảng. Bằng cách xác định trường popupRedirectResolver trong quá trình khởi chạy Auth, trong một số trường hợp, thư viện sẽ thực hiện thêm thao tác khi khởi chạy. Trên trình duyệt di động, thư viện sẽ tự động mở trước một iframe đến miền Auth của bạn. Việc này được thực hiện để mang lại trải nghiệm liền mạch cho hầu hết người dùng, nhưng có thể ảnh hưởng đến hiệu suất bằng cách tải thêm mã ngay khi ứng dụng khởi động. Bạn có thể tránh hành vi này bằng cách sử dụng initializeAuth() và truyền phần phụ thuộc browserPopupRedirectResolver theo cách thủ công vào các hàm cần phần phụ thuộc đó:

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

Nếu chúng ta đã cung cấp browserPopupRedirectResolver trong các phần phụ thuộc cho initializeAuth(), thì không cần tham số thứ ba trong lệnh gọi đến signInWithRedirect(). Nhưng bằng cách di chuyển phần phụ thuộc đó sang lệnh gọi đến signInWithRedirect() trực tiếp, mức giảm hiệu suất ban đầu trong quá trình khởi tạo sẽ bị loại bỏ. Việc di chuyển phần phụ thuộc sẽ có những điểm đánh đổi, nhưng điều quan trọng là bạn có thể đưa ra quyết định về những điểm đánh đổi đó bằng cách khởi động thư viện theo cách thủ công.

Trường hợp nên sử dụng chế độ khởi tạo tuỳ chỉnh

Tóm lại, quá trình khởi chạy tuỳ chỉnh giúp bạn kiểm soát tốt hơn nhiều việc sử dụng Auth SDK của ứng dụng. Hàm getAuth() tiêu chuẩn phù hợp để bắt đầu và đáp ứng hầu hết các trường hợp sử dụng. Đối với hầu hết các ứng dụng, getAuth() có thể là tất cả những gì bạn cần. Tuy nhiên, có nhiều lý do khiến bạn muốn (hoặc cần) chuyển sang chế độ quản lý phần phụ thuộc theo cách thủ công:

  • Đối với những ứng dụng mà kích thước gói và thời gian tải cực kỳ quan trọng, việc khởi chạy Auth tuỳ chỉnh có thể giúp giảm nhiều kilobyte dữ liệu. Thao tác này cũng có thể giảm thời gian tải ban đầu bằng cách di chuyển các phần phụ thuộc sang thời gian sử dụng thay vì thời gian khởi tạo.
  • Đối với mã chạy trong các bối cảnh không phải DOM (chẳng hạn như trình chạy web và trình chạy dịch vụ), bạn phải sử dụng initializeAuth() để tránh lỗi.