react-firebaseui: A Thin React Wrapper for FirebaseUI Auth

A Wrapper, Not a Reimplementation

react-firebaseui provides React wrappers on top of the Firebase UI Web library, and notably Firebase UI Auth. The underlying widget is the FirebaseUI Web project, and this package is the React binding for it.

What the underlying library provides is a drop-in auth solution that handles the interface flows for signing in users with email addresses and passwords, and identity provider sign-in using Google, Facebook and others. It is built on top of Firebase Auth, so the credentials, the session handling and the provider configuration live in Firebase, and FirebaseUI contributes the user interface and the flow logic.

That division is worth holding on to, because it decides what this package can and cannot do for you. Anything about how the sign-in screen looks and behaves is the business of the firebaseui dependency, which the package declares at ^6.0.0. What this repository owns is the React component, the props, the stylesheet handling and the build.

The repository is small and shaped like a library rather than an application: src/ for the source, dist/ for the built output, types/ for the TypeScript declarations, an example/ application that demonstrates the component, and a webpack.config.js and .babelrc for the build.

Two Components, One Difference That Matters for Your Build

There are two similar components, FirebaseAuth and StyledFirebaseAuth, and the difference between them is entirely about where the CSS lives.

FirebaseAuth has a reference to the FirebaseUI CSS file, it requires the CSS. StyledFirebaseAuth is bundled with the CSS directly.

The README's advice is explicit about which to reach for. For simplicity, use StyledFirebaseAuth. For potential better performance and build sizes, use FirebaseAuth, which is meant to be used with a CSS or style loader as part of the webpack build configuration.

The reasoning is standard bundler behaviour. If the stylesheet is imported as a module, the bundler treats it as part of the JavaScript dependency graph and can extract it into a separate file, so it is cached separately and does not have to be re-parsed as JavaScript. If the CSS is inlined into the component, the bundler has nothing to extract.

The practical trap is in the packaging section. FirebaseAuth needs a global CSS to get proper styling, and the CSS is already imported within FirebaseAuth, so you do not import it yourself. With webpack you need to add CSS loaders, and the rule has to match css files:

{
  module: {
    rules: [
      {
        test: /\.css/,
        use: [ 'style-loader', 'css-loader' ]
      }
    ]
  }
}

The README adds a warning that the rule must not exclude /node_modules/, since that is where the library, and therefore the CSS, is located. That single detail is the usual cause of an unstyled sign-in form.

Four Steps From an Empty Project to a Sign-in Screen

The README gives the setup as four steps. You import the FirebaseAuth or StyledFirebaseAuth component from react-firebaseui, and import firebase. You configure Firebase as described in the Firebase docs. You write a FirebaseUI configuration as described in the firebaseui-web repository. And you use the FirebaseAuth component in your template, passing it the FirebaseUI configuration and a Firebase Auth instance.

The two npm packages are installed separately, because the Firebase SDK is a peer dependency rather than a bundled one:

npm install --save react-firebaseui

npm install --save firebase

The peer dependency design matters more than it looks. The package.json declares peerDependencies of react from 15 up to 17 and firebase at ^9.1.3, and a single dependency on firebaseui at ^6.0.0. So the React version and the Firebase SDK version in your application are the ones that end up in your bundle, and the wrapper only has to work with the range it declares.

The component itself takes two props that matter, uiConfig and firebaseAuth, and the example shows the shape of a typical configuration with a popup sign-in flow, a success URL and a list of providers:

const uiConfig = {
  signInFlow: 'popup',
  signInSuccessUrl: '/signedIn',
  signInOptions: [
    firebase.auth.GoogleAuthProvider.PROVIDER_ID,
    firebase.auth.FacebookAuthProvider.PROVIDER_ID,
  ],
};

The provider ids come from the Firebase Auth instance itself, which is why the config and the auth instance are both passed to the component.

Redirect Flow or Local State

The two worked examples differ in how the application reacts to a completed sign-in, and the choice is yours rather than the library's.

In the redirect example, the config carries signInSuccessUrl set to /signedIn, and the comment notes that you can alternatively provide a callbacks.signInSuccess function. The browser navigates, and the next page reads the session.

In the local state example, the callback signInSuccessWithAuthResult returns false to avoid redirects after sign-in, and the component tracks the signed-in state itself by registering an auth observer:

const [isSignedIn, setIsSignedIn] = useState(false);

useEffect(() => {
  const unregisterAuthObserver = firebase.auth().onAuthStateChanged(user => {
    setIsSignedIn(!!user);
  });
  return () => unregisterAuthObserver();
}, []);

The cleanup function in that effect is the part to copy. The comment in the example says to make sure the Firebase observers are unregistered when the component unmounts, and without that the observer keeps firing against a component that is gone.

The redirect approach is simpler and survives a page refresh, since the session is in Firebase rather than in React state. The local state approach keeps the user in place and lets the component render a welcome message and a sign-out link, which the example does using firebase.auth().currentUser.displayName.

uiCallback for the Options the Props Do Not Cover

The wrapper does not expose every FirebaseUI option through props. For further configuration there is a uiCallback prop, a function that receives the FirebaseUI instance before it is started, and the README shows it being used to enable the disableAutoSignIn option:

return (
  <div>
    <h1>My App</h1>
    <p>Please sign-in:</p>
    <StyledFirebaseAuth uiCallback={ui => ui.disableAutoSignIn()} uiConfig={uiConfig} firebaseAuth={firebase.auth()}/>
  </div>
);

This is the escape hatch for anything the configuration object does not cover. The FirebaseUI instance exposes a wider set of methods than the React props mirror, and disableAutoSignIn is one of them. Because the callback runs before the widget starts, an option set here still takes effect for the first render, which is the reason it is a callback rather than a prop.

For an application that needs a provider the wrapper does not mention, this is where you would look before deciding to fork the component.

A Build Pipeline From the Babel 6 Era

The package.json tells you the vintage of the tooling. The build script is webpack -p followed by babel src --out-dir dist -s, then a copy of the types, the README, the licence and the package.json into dist, then a production install inside dist before publishing from there.

The dev dependencies confirm it: babel-cli and babel-core at 6.26, babel-preset-env at 1.7, babel-loader at 7.1.5, css-loader at 0.28.11, eslint at 4.19 with the Google, React and Standard configs, and webpack with its own plugins. The .babelrc at the root and the babel plugins for class properties, object rest spread and dynamic import are part of that same generation.

None of that is a problem in itself, since a wrapper that emits plain JavaScript with a CommonJS main entry works with whatever bundler you use. The problem is the age of the peer dependency range, which is the real constraint rather than the build.

The published package is also assembled in an unusual way. The files array lists prebuilt JavaScript, source maps and TypeScript declarations at the top level of the package, and the publish script runs from the dist directory, so the dist folder is what ends up on npm. The repository also ships a friendlypix-web-react.iml file, an IntelliJ module descriptor, which is a marker of when the project was last worked on in earnest.

What the Release History Means for Adoption

The version history is the decisive fact for anyone evaluating this today. The recent releases are v6.0.0 from 2021-11-09, 5.0.2 and 5.0.1 both from 2021-04-27. The current version in the package.json is 6.0.0, and the last push to the repository was on 2026-06-21, so the tree is receiving changes while the published package is five years old.

The peer dependency on react, from 15 up to 17, is the practical blocker. React 18 and later are outside that range, so a modern application will get a peer dependency conflict on install, and a strict package manager will refuse it. The Firebase peer dependency at ^9.1.3 is looser and more current, and the examples import from firebase/compat/app and firebase/compat/auth, which is the compatibility build that keeps the older namespace API working inside the modular SDK.

For an application still on React 17 with Firebase 9, the package does what it says and the documentation is complete enough to get there in an afternoon. For a new application, the choice is between forking the wrapper, which is a small amount of code, and using the FirebaseUI Web library directly with a few lines of your own React glue, which is what most teams end up doing once they outgrow the wrapper.

The licence is Apache-2.0, and the package is published by Google under the name react-firebaseui.

Editorial conclusion

react-firebaseui fits a React application that already uses Firebase Auth and wants the FirebaseUI sign-in flows, including identity provider sign-in, without hand wiring the underlying widget. It is a poor fit for a new project, because the newest release is 6.0.0 from 2021-11-09, the peer dependencies allow React from 15 up to 17 only, and the build tooling is from the Babel 6 era, so a React 18 or 19 project would have to fork it or replace it. Before adopting it, check the React version in your application against the peer range, and read the peer dependency on firebase at ^9.1.3 against the Firebase SDK you already have, because the examples import from firebase/compat/app, which is the compatibility build.

Frequently asked questions

Official sources

1. firebase/firebaseui-web-react on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases