react-redux-firebase: Redux bindings for Firebase, and when reactfire is the better call

The problem react-redux-firebase solves, and who actually has that problem

Firebase clients are event driven. You attach a listener to a path or a collection, the SDK pushes snapshots at you, and your components re-render from whatever you keep in local state. Redux is the opposite shape: one store, plain reducers, selectors that derive views from that store. Bridging the two by hand means writing the same attach-on-mount, detach-on-unmount, dispatch-on-snapshot cycle for every screen.

react-redux-firebase is that bridge, packaged. It adds a firebaseReducer to your root reducer, reads data out of state.firebase, and gives you hooks and higher order components that own the listener lifecycle. The README describes it as "Redux bindings for Firebase" with an HOC for use with React, and the feature list includes authentication with automatic loading of a user profile from the database, support for Realtime Database, Firestore and Storage, and a population capability the README compares to mongoose's populate or a SQL JOIN.

The audience is narrow and specific. This is for teams that already run react-redux in an application and want Firebase included in that same store, so that a component can select Firebase-backed data the way it selects anything else. If Firebase data does not need to live in Redux, the project's own README says to look at reactfire instead. That note sits near the top of the file, above the examples, which is an unusually honest piece of placement.

How the binding works: reducer, provider, listeners

Three pieces fit together. The reducer holds state. The provider gives components access to the Firebase instance and the store's dispatch. The hooks and higher order components translate component lifecycle into listener attach and detach.

The README's setup example imports firebaseReducer from react-redux-firebase, adds it to combineReducers under the key firebase, creates the store as usual, and then builds an rrfProps object containing the firebase instance, a config object and store.dispatch. That object is spread onto ReactReduxFirebaseProvider, which wraps the app inside the ordinary react-redux Provider.

Config is where behaviour is decided. The README example sets userProfile to 'users', which is what triggers the automatic profile loading, and shows useFirestoreForProfile: true as the switch that reads the profile from Firestore instead of Realtime Database. Firestore is not included by default: the example comments out createFirestoreInstance, firestoreReducer and the firebase/firestore import, and each has to be turned on deliberately.

On the read side, useFirebaseConnect takes an array of paths and manages listeners for the lifetime of the component. Data lands in state.firebase.ordered for list-shaped queries, and the README pairs it with isLoaded and isEmpty so a component can distinguish loading from empty. The feature list notes that small data can be read with value while large datasets use child_added, child_removed and child_changed, and that query types include orderByChild, orderByKey, orderByValue, orderByPriority, limitToLast, limitToFirst, startAt, endAt and equalTo.

Installing react-redux-firebase and loading a first list

Installation is a single npm command. The README assumes npm and points readers who use something else at unpkg, a download, or their package manager of choice.

npm install --save react-redux-firebase

Wiring comes next. The reducer goes into the root reducer under the firebase key, and the provider receives the Firebase instance, the config object and dispatch. Everything below is copied from the README's setup example, with the Firestore lines left commented out as the README leaves them.

import { createStore, combineReducers } from 'redux'
import { ReactReduxFirebaseProvider, firebaseReducer } from 'react-redux-firebase'

const rrfConfig = {
  userProfile: 'users'
  // useFirestoreForProfile: true // Firestore for Profile instead of Realtime DB
}

const rootReducer = combineReducers({ firebase: firebaseReducer })
const store = createStore(rootReducer, {})

const rrfProps = { firebase, config: rrfConfig, dispatch: store.dispatch }

With the provider mounted, a list component attaches its own listener. The README's example calls useFirebaseConnect with an array containing 'todos', reads state.firebase.ordered.todos through useSelector, and guards the render with isLoaded and isEmpty.

import { useSelector } from 'react-redux'
import { useFirebaseConnect, isLoaded, isEmpty } from 'react-redux-firebase'

export default function Todos() {
  useFirebaseConnect(['todos'])
  const todos = useSelector((state) => state.firebase.ordered.todos)
  if (!isLoaded(todos)) return <div>Loading...</div>
  if (isEmpty(todos)) return <div>Todos List Is Empty</div>
  return <ul>{Object.keys(todos).map((key, id) => <TodoItem key={key} id={id} todo={todos[key]} />)}</ul>
}

What you should see is a loading state until the snapshot arrives, then either the empty message or the list. Writes go through useFirebase, which returns the instance; the README's add example calls firebase.push('todos', sampleTodo) with an object of the form { text: 'Sample', done: false }.

The v2 to v4 break, and what it costs to upgrade

The release history is lumpy rather than steady. v3.10.1 and v3.11.0 both landed on 2021-11-23, and the next release in the list is v4.0.0 on 2026-06-11. The last push to the repository was on 2026-09-25, so work is happening, but the gap between v3.11.0 and v4.0.0 is the thing an upgrading team will feel.

The README treats the version boundary as a hard one. Support for react-redux before v6 and for the pre-context API is not in the current package; the README directs those users to the v2 line, installed as [email protected]. That means an application still on an older react-redux cannot simply bump the dependency. It either moves its react-redux version first or stays on v2.

The package itself ships three build targets. package.json lists main as lib/index.js, module as es/index.js and typings as ./index.d.ts, with files limited to lib, es, src and index.d.ts. The build scripts run Babel twice, once with BABEL_ENV=commonjs into lib and once with BABEL_ENV=es into es, and prepack runs clean and build before publishing. So consuming from npm is straightforward; consuming from a git checkout means running the build yourself.

Testing is not a plain vitest run. The test script wraps vitest in firebase emulators:exec with --only database,auth,firestore and --project rrf-test. Anyone contributing has to have the emulators available, which is a real setup cost the README does not walk through.

Where react-redux-firebase is the wrong tool

The clearest limitation is stated by the project. The README's usage note says that if you are starting a new project, or are not required to have Firebase data loaded into Redux, you might want to try reactfire before react-redux-firebase, and links an article explaining why. A library whose own documentation opens by recommending a different library for a common case is telling you that the Redux store is the cost, not the benefit.

That cost is real. Every snapshot you bind goes into a single store, and every component that selects from state.firebase.ordered re-renders when that slice changes. The README's own guidance to use value for small data and child_added, child_removed and child_changed for large datasets is a hint about where this gets awkward: list-shaped data with frequent updates is the case where a global store is least comfortable. A component that only needs one document still pays for the reducer path.

There is also the Firestore split. Firestore support is not part of the base package: the README comments out the firestore import, createFirestoreInstance, firestoreReducer and the createFirestoreInstance key in rrfProps, and the installation section links to redux-firestore on unpkg rather than to react-redux-firebase. If your data lives in Firestore, you are wiring two packages, not one.

Finally, the documentation is a site plus a README, and the README does not cover failure paths. There is no guidance in it on what happens to listeners when a query errors, how to cancel an in-flight write, or how to roll back an optimistic update. Those are the questions that decide whether a binding layer is safe in production, and the README is silent on them.

reactfire and the difference in approach

The alternative the README names is reactfire, from FirebaseExtended. The difference is not cosmetic. reactfire keeps Firebase state in React rather than in a Redux store: components subscribe to the data they need and re-render from that subscription, with no reducer, no dispatch, and no global slice holding every bound path.

That changes what you give up and what you keep. With react-redux-firebase you get one place to inspect Firebase-backed state, a reducer you can combine with your other reducers, and selectors that work like every other selector in the app. You also get the population capability the README describes as similar to mongoose's populate, which resolves referenced records across paths. With reactfire you get a smaller surface and no store to keep in sync, but you lose the Redux integration that the rest of the application may depend on.

The README also mentions redux-thunk and redux-observable among the integrations it has examples for, and the repository topics include both. If your application already routes side effects through thunk or redux-observable, react-redux-firebase fits the pattern you have. If it does not, reactfire removes a layer instead of adding one. The README's own recommendation for new projects is the honest summary of which way that trade usually goes.

Licence, maintenance signals and what to check before adopting

The package is MIT licensed, and package.json carries the same identifier. MIT is permissive: it allows use, modification and redistribution with the licence and copyright notice retained. That is the extent of what the repository states, and it is not legal advice about your particular distribution or about the Firebase terms you accept separately.

Maintenance signals are mixed but readable. The repository is not archived, and the last push was on 2026-09-25. The release list shows v4.0.0 on 2026-06-11, following v3.11.0 on 2021-11-23. The tooling in package.json is current rather than frozen: Biome for linting and formatting through biome.jsonc, Vitest for tests through vitest.config.js, Husky for hooks, and a renovate.json for dependency updates. That combination suggests a repository that is being kept alive, not one that has been abandoned.

What the README does not document is the upgrade path within the v4 line, because there is only one v4 release in the list. There is a CHANGELOG.md at the top level and a docs directory, but the README itself gives no migration steps for moving from v3 to v4 beyond the react-redux version boundary. Before adopting, check the CHANGELOG for the v4.0.0 entry and confirm which react-redux version your application is on, since the README states that pre-v6 react-redux and the pre-context API are served by the v2 line rather than the current package.

Editorial conclusion

Adopt react-redux-firebase when Firebase data already belongs in a Redux store and you want listeners attached and detached by component lifecycle through useFirebaseConnect, firestoreConnect or the higher order components. Skip it for a greenfield app that does not need Firebase state in Redux: the README sends those readers to reactfire before they start, and that advice is worth taking. Before committing, verify one thing first: whether your app is on react-redux v6 or later, because the README states that support for earlier react-redux versions and the pre-context API lives in the v2 line, installed as [email protected], not in the v4 package on npm.

Frequently asked questions

Official sources

1. License: MIT
2. prescottprue/react-redux-firebase on GitHub
3. Project website
4. README
5. Releases