Trang này được dịch bởi Cloud Translation API.

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

Thiết kế mô-đun của Firebase JS SDK cho phép bạn kiểm soát tốt hơn nhiều cách thức 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 phù hợp với 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 chạy thư viện Xác thực: hàm getAuth() và hàm initializeAuth(). Thứ nhất, 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 Xác thực có cung cấp. Nhược điểm là tính năng này lấy nhiều mã mà ứng dụng của bạn có thể không sử dụng được. Ngoài ra, mã này cũng có thể lấy những đoạn mã đơn giản là 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() để lấy bản đồ các phần phụ thuộc. Hàm getAuth() chỉ gọi initializeAuth() với tất cả các phần phụ thuộc đã chỉ định. Để minh hoạ, sau đây là mã 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 bộ hàm signInWithPopup hoặc signInWithRedirect. Nhiều ứng dụng sẽ không cần tính linh hoạt mà indexedDB cung cấp hoặc sẽ không cần khả năng hỗ trợ cả indexedDB và localStorage nên không có sẵn. Trong những trường hợp như vậy, getAuth() mặc định sẽ chứa nhiều mã không sử dụng làm tăng kích thước gói mà không vì lý do gì. Thay vào đó, các ứng dụng này có thể điều chỉnh các phần phụ thuộc. Ví dụ: nếu ứng dụng của bạn chỉ sử dụng phương thức xác thực đường liên kết email và localStorage là đủ (vì bạn không sử dụng tập lệnh trình chạy dịch vụ hoặc web), thì bạn có thể loại bỏ nhiều mã bị rò rỉ bằng cách khởi chạy Xác thực 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 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úp giảm đáng kể lượng băng thông mà người d��ng sử dụng mỗi khi họ truy cập vào trang web.

Những điểm cần cân nhắc theo nền tảng cụ thể

Trong nhiều trường hợp, bạn cần xác định các phần phụ thuộc Xác thực 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ậpCordova thì đó là môi trường Cordova. Nhưng đôi khi nhu cầu của ứng dụng cụ thể xung đột với những giả định này. Ví dụ: đối với các tập lệnh trình làm việc web và dịch vụ, quy trình triển khai getAuth() mặc định sẽ lấy 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 phải điều chỉnh các phần phụ thuộc. Mã sau đây phù hợp để khởi chạy thư viện Xác thực trong ngữ cảnh 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 tính năng Xác thực khởi chạy với tính năng cố định indexedDB (có sẵn trong ngữ cảnh trình thực thi) 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 Xác thực, trong một số trường hợp, thư viện sẽ thực hiện thêm tác vụ khởi chạy. Trên trình duyệt dành cho thiết bị di động, thư viện sẽ tự động mở iframe tới miền Xác thực của bạn trước. Điều 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 do 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 đến các hàm cần đến:

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 đã cung cấp browserPopupRedirectResolver trong các phần phụ thuộc cho initializeAuth(), thì tham số thứ ba trong lệnh gọi đến signInWithRedirect() có thể là không cần thiết. Tuy nhiên, bằng cách chuyển phần phụ thuộc đó sang lệnh gọi trực tiếp đến signInWithRedirect(), lượt truy cập hiệu suất ban đầu trong quá trình khởi chạy sẽ bị xoá. Việc di chuyển phần phụ thuộc sẽ có cả những đánh đổi, nhưng điều quan trọng là bạn có thể đưa ra quyết định về những sự đánh đổi đó bằng cách khởi chạy thư viện theo cách thủ công.

Trường hợp sử dụng quy trình khởi chạy tuỳ chỉnh

Tóm lại, tính năng khởi chạy tuỳ chỉnh cho phép bạn kiểm soát tốt hơn nhiều đối với mức sử dụng SDK Xác thực của ứng dụng. Hàm getAuth() chuẩn phù hợp để bắt đầu và dùng trong hầu hết các trường hợp sử dụng. Đối với hầu hết ứ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 quản lý phần phụ thuộc theo cách thủ công:

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