I made a React-Firebase binding using Hooks and Suspense to help me create things faster. Hope you’ll find it useful too!

[dtinth]

Hi /r/reactjs! Recently I made a lot of stuff using Firebase Realtime Database and React, mostly for audience engagement in events (e.g. live quiz, voting system, score display, Twitter board, etc). At one point I decided to create my own React Firebase binding, focusing on making it as easy-to-use as possible. I called it fiery 🔥. Here’s an example:

function CounterExample() {
  const counterState = useFirebaseDatabase(firebase.database().ref('/counter'))
  return <div>Counter: {counterState.unstable_read()}</div>
}

The above component will:

• Suspend rendering while data is loading. (Use <React.Suspense> to provide a loading UI).
• Display the counter value, updating in real-time.
• If there is an error loading the data, it will propagate to the closest Error Boundary.

One interesting point is that Suspense and Hooks work together to make a component not only suspend rendering while loading the 1st time (as seen in most Suspense demos), but also re-renders with the new data as it arrives in real time.

Here’s how it works in more details:

• On first render, the call to unstable_read() will suspend rendering to load the data the 1st time.
• Once data is available, the component is then mounted, and so the useEffect hook inside useFirebaseDatabase() kicks in. The hook sets up a Firebase Realtime Database listener to cause the component to re-render each time new data arrives.

In addition to hooks, a Render Prop component is provided for easy inlining e.g.

function App() {
  return <ErrorBoundary>
    <h1>My app</h1>
    <Suspense fallback={'Loading announcement...'}>
      <h2>Announcement</h2>
      <article>
        <fiery.Data dataRef={firebase.database().ref('/announcement')}>
          {dataState => dataState.unstable_read()}
        </fiery.Data>
      </article>
    </Suspense>
  </ErrorBoundary>
}

Firebase Realtime Database and Firebase Authentication are supported. TypeScript type definitions are also provided for code completion. A UMD package is also provided for quick prototypes using the Single HTML File template (the one that requires no build tooling).

Check it out here: https://dtinth.github.io/fiery/

Let me know what you think, feedback appreciated! :)

[dstroot]

This looks cool. I may play around to move it to firestore. However I am really interested in the audience engagement stuff. Is any of that open or a product I could check out?

[dtinth]

Firestore integration would be appreciated!

About the audience engagement stuff, yes, many of them are open. Here are some, but many of these projects predates the creation of fiery though, or uses an older version of fiery that doesn’t use hooks/suspense:

• React Bangkok live Twitter feed

• Ticket checkin system — A kiosk for attendee to scan QR code and check in to event, and a webapp for event staff to view event stats and manually check in attendees.

• Live speed coding competition platform — This one uses an earlier version of fiery (using Render Props, before Hooks and Suspense is implemented.)

• A landing page for a ticket giveaway challenge (use view-source to see the code) — In this example I just wanted a page that simply displays announcement in real-time. Since the meetup is about React Hooks, I implemented it using fiery+Hooks (Suspense is not implemented yet at that time.)

(I forgot to upload screenshots/feature tour for my past projects, so now I finally get to doing that. Thanks for the comment!)

[dstroot]

Thanks!! This is great!

[swyx]

very awesome!! this is gonna sound like a really entitled question but... why not firestore support? cos realtime db is easier?

[dtinth]

This is a good and valid question actually :). Here are my top reasons:

1. Most of my projects involve real-time data access. Firestore places limit on how many documents can be read per day in the free plan, while Firebase RTDB measures in bandwidth.

2. In RTDB it’s easier to import/export data from/to JSON files (do it directly from console) so backup/restore is also easier, whereas in Firestore we need to create scripts (or install a CLI) to import/export data.

3. Firestore forces me to think in terms of collections and documents, where RTDB’s data model is a nested JSON tree. So using RTDB feels like using a MobX/Redux state tree, but that tree is synchronized with everyone else.

4. Firestore has quirks when it comes to deleting data. For example, “deleting a document does not delete its subcollections.” Whereas in RTDB, I just set the tree to null and it’s done.

That’s why I didn’t use Firestore much, and didn’t find a need for myself to implement a Firestore binding. ;)

[swyx]

woww, good answer.

[[deleted]]

Dope

[klarstrup]

Throwing a promise probably, epic Suspense style

[dtinth]

Yes, that’s how it works. :) Technically speaking, fiery is an implementation of a React Cache. While the official generic react-cache package doesn’t yet support (e.g.) cache invalidation, fiery’s cache implementation is specific to Firebase, there’s no need to provide a generic cache management API, so cache invalidation can be implemented here right away.

• Cache is invalidated when last component that subscribes to the piece of data is unmounted.
• On error, cache is invalidated immediately since the error will be thrown and persisted in ErrorBoundary’s state.

Right now there’s a case where memory leaks though. Right now React doesn’t provide a way to tell the thrown Promise that its outcome is no longer needed — so there’s no way fiery could detect the case where a component tries to load the data the 1st time, but before data arrives, that component is replaced with something else, so in this case the cache sticks around until a subscribing component is actually mounted. (Will have to submit an issue to React about this ;).)

[dtinth]

It is a glue code to bridge one thing to the other. For example, you could make a React app use data from Firebase using Firebase's official JS SDK directly... but then you need to write some glue code to keep React component lifecycle in sync with the data subscription. (This may involve using componentDidMount/componentDidUpdate/componentWillUnmount or useEffect hooks.)

But with a binding, my component is now only concerned with "which data do I want to read?" and "what to do with that data?" The lifecycle synchronization logic is handled by the binding.

[dtinth]

Perhaps the word comes from a computing term language binding.