Thiết kế mô-đun của SDK Firebase JS mang đến cho bạn khả năng kiểm soát tốt hơn nhiều đối với cách xây dựng ứng dụng của bạn. 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 hóa kích thước gói bằng cách loại bỏ các tính năng 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() . Đầ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 rất nhiều mã mà ứng dụng của bạn có thể không sử dụng. Nó cũng có thể lấy mã đơn giản là không được hỗ trợ trên nền tảng bạn đang nhắm mục tiêu, dẫn đến lỗi. Để tránh những vấn đề này, bạn có thể sử dụng initializeAuth() để lập 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 họa, đây là tương đương với getAuth() trên 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 sự phụ thuộc của bạn
Không phải tất cả các ứng dụng đều sử dụng nhóm chức năng 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ếu ứng dụng này không có sẵn. Trong những trường hợp này, getAuth() mặc định bao gồm nhiều mã không được sử dụng làm tăng kích thước gói mà không có lý do. Thay vào đó, những ứ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 xác thực liên kết email và localStorage là đủ (vì bạn không sử dụng tập lệnh web hoặc tập lệnh của nhân viên dịch vụ), bạn có thể loại bỏ nhiều mã phình to bằng cách khởi tạo Auth như thế này:
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 đã loại bỏ ba 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 trang web của bạn.
Những cân nhắc dành riêng cho nền tảng
Trong nhiều trường hợp, bạn cần xác định thủ công các phần phụ thuộc Auth để tránh lỗi khi khởi tạo. Hàm getAuth() giả định một nền tảng cụ thể. Đối với điểm vào mặc định, đó là môi trường trình duyệt và đối với điểm vào 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 của nhân viên dịch vụ và web, việc 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 đó, cần phải điều chỉnh các phần phụ thuộc của bạn. Đoạn mã sau phù hợp để khởi tạo thư viện Auth trong ngữ cảnh của nhân viên 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 với tính bền vững được lập indexedDB (có sẵn trong ngữ cảnh công nhân) và bỏ qua phần phụ thuộc popupRedirectResolver , giả sử 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 nhất định. Bằng cách xác định trường popupRedirectResolver trong quá trình khởi tạo Auth, trong một số trường hợp, thư viện sẽ thực hiện công việc bổ sung khi khởi tạo. Trên trình duyệt di động, thư viện sẽ tự động mở iframe cho miền Auth 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 nó có thể ảnh hưởng đến hiệu suất bằng cách tải mã bổ sung ngay khi ứng dụng khởi động. Có thể tránh hành vi này bằng cách sử dụng initializeAuth() và chuyển phần phụ thuộc browserPopupRedirectResolver theo cách thủ công tới 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 chúng tôi đã cung cấp browserPopupRedirectResolver trong các phần phụ thuộc cho initializeAuth() thì tham số thứ ba trong lệnh gọi signInWithRedirect() sẽ không cần thiết. Nhưng bằng cách di chuyển trực tiếp phần phụ thuộc đó sang lệnh gọi signInWithRedirect() , hiệu suất ban đầu đạt được trong quá trình khởi tạo sẽ bị loại bỏ. Có những sự cân bằng đi kèm với việc di chuyển phần phụ thuộc, nhưng phần quan trọng là bạn có thể đưa ra quyết định về những sự cân bằng đó bằng cách khởi tạo thư viện theo cách thủ công.
Khi nào nên sử dụng khởi tạo tùy chỉnh
Tóm lại, việc khởi chạy tùy chỉnh mang lại cho bạn khả năng kiểm soát tốt hơn nhiều đối với việc sử dụng SDK xác thực trong ứng dụng của bạn. Hàm getAuth() tiêu chuẩn phù hợp để bắt đầu và phục vụ 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. Nhưng 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 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 tạo xác thực tùy chỉnh có khả năng cắt giảm nhiều kilobyte dữ liệu. Nó cũng có thể 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 tạo.
- Đối với mã chạy trong ngữ cảnh không phải DOM (như web và nhân viên dịch vụ),
initializeAuth()phải được sử dụng để tránh lỗi.