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

Модульная структура 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() , мы устранили первоначальное снижение производительности во время инициализации. Перемещение зависимости сопряжено с определенными компромиссами, но важно то, что вы можете принимать решения об этих компромиссах, инициализируя библиотеку вручную.

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

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

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