Настройте свои зависимости аутентификации

Модульная конструкция Firebase JS SDK дает вам гораздо больший контроль над созданием вашего приложения. Эта гибкость позволяет вам адаптировать зависимости для вашей платформы и оптимизировать размер пакета, удаляя ненужные функции.

Существует два способа инициализации библиотеки Auth: функция getAuth() и функция initializeAuth() . Первый, getAuth() , предоставляет все, что нужно вашему приложению, чтобы воспользоваться всеми функциями, которые может предложить библиотека Auth. Обратной стороной является то, что он использует много кода, который потенциально не используется вашим приложением. Он также может использовать код, который просто не поддерживается на целевой платформе, что приводит к ошибкам. Чтобы избежать этих проблем, вы можете использовать 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,
});

Адаптация ваших зависимостей

Не все приложения используют семейство функций signInWithPopup или signInWithRedirect . Многим приложениям не потребуется гибкость, которую обеспечивает indexedDB , или не потребуется возможность поддерживать как indexedDB , так и localStorage , если один из них недоступен. В этих случаях метод getAuth() по умолчанию включает в себя много неиспользуемого кода, который без причины увеличивает размеры пакетов. Вместо этого эти приложения могут адаптировать свои зависимости. Например, если ваше приложение использует только аутентификацию по ссылке электронной почты и достаточно localStorage (поскольку вы не используете веб-скрипты или сценарии сервисных рабочих), вы можете избавиться от большого количества раздутого кода, инициализируя 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
});

С помощью этого кода вы удалили три большие зависимости, которые не нужны вашему приложению, что значительно сократило объем пропускной способности, используемой вашими пользователями при каждом посещении вашего сайта.

Особенности платформы

Во многих случаях вам необходимо вручную определить зависимости Auth, чтобы избежать ошибок при инициализации. Функция getAuth() предполагает определенную платформу. Для точки входа по умолчанию это среда браузера, а для точки входа Cordova — это среда Cordova. Но иногда потребности вашего конкретного приложения противоречат этим предположениям. Например, для веб-скриптов и сервисных рабочих сценариев реализация getAuth() по умолчанию извлекает код, который считывает из объекта window , что приведет к ошибкам. В таких случаях необходимо адаптировать ваши зависимости. Следующий код подходит для инициализации библиотеки Auth в контексте сервисного работника:

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 (который доступен в рабочих контекстах) и опускает зависимость popupRedirectResolver , которая предполагает доступность контекста DOM.

Есть и другие причины, по которым вы можете вручную определять зависимости на определенных платформах. Определив поле popupRedirectResolver при инициализации Auth, в некоторых случаях библиотека выполнит дополнительную работу по инициализации. В мобильных браузерах библиотека автоматически откроет iframe для вашего домена Auth. Это сделано для того, чтобы упростить работу для большинства пользователей, но это может повлиять на производительность из-за загрузки дополнительного кода сразу при запуске приложения. Такого поведения можно избежать, используя initializeAuth() и вручную передав зависимость 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() , третий параметр в вызове signInWithRedirect() не был бы нужен. Но если перенести эту зависимость непосредственно на вызов signInWithRedirect() , то первоначальный удар по производительности во время инициализации будет устранен. Существуют компромиссы, связанные с перемещением зависимости, но важно то, что вы можете принимать решения об этих компромиссах, инициализируя библиотеку вручную.

Когда использовать пользовательскую инициализацию

Напомним, что пользовательская инициализация дает вам гораздо больший контроль над использованием вашего приложения Auth SDK. Стандартная функция getAuth() хороша для начала работы и подходит для большинства случаев использования. Для большинства приложений getAuth() может быть всем, что вам нужно. Но существует множество причин, по которым вам может потребоваться (или понадобится) перейти на ручное управление зависимостями:

  • Для приложений, где размер пакета и время загрузки чрезвычайно важны, пользовательская инициализация аутентификации потенциально может сократить объем данных на многие килобайты. Это также может сократить время начальной загрузки, переместив зависимости на время использования, а не на время инициализации.
  • Для кода, который выполняется в контекстах, отличных от DOM (например, веб-работники и сервисные работники), необходимо использовать initializeAuth() , чтобы избежать ошибок.