DEV Community: Doug Safreno

Firebase as a React Hook

Doug Safreno — Wed, 15 Jan 2020 12:12:51 +0000

In a prior post, "How we use Firebase instead of React with Redux," I discussed how we created a withDbData function to load data from Firebase Realtime Database (RTDB) into React conveniently.

Now that we've switched to writing most of our components as functions, I wanted a hook equivalent for loading state. In this post, I'll explain how to use and how I implemented useDbDatum / useDbData, two hooks for generically loading data from Firebase RTDB.

Note: you can get the code as a gist here.

Usage

useDbDatum is a hook that loads a single datum at a single path in Firebase RTDB.

You could, for instance, use useDbDatum as follows:

const Name = ({uid}) => {
  let name = useDbDatum(`users/${uid}/name`)
  return <div>{name}</div>
}

Note that name is null initially, but the component rerenders with the value once it loads.

useDbData loads multiple paths at the same time, returning an object where the keys are the paths and the values are the data in Firebase RTDB.

Most of the time, you'll want to use useDbDatum over useDbData - it's more convenient and direct - but I've had to switch over once or twice in our code base.

An example for useDbData:

const SortedStudentNames = ({classUid}) => {
  let students = useDbDatum(`classes/${classUid}/students`);
  let uids = Object.keys(students || {});
  let paths = studentIds.map(id => `students/${id}/name`);
  let nameValues = useDbData(paths);
  let names = Object.values(nameValues || {});
  names.sort();
  return <p>{names.join(', ')}</p>
}

Implementation

During this implementation, I learned a lot about React hooks. I found it pretty quick to get up and running with useReducer and useEffect, but the tricky key to getting useDbData working was useRef.

useRef provides an escape hatch from the other state of functional React components, which generally trigger rerenders when updated. If you're ever yearning to replace using this.something = {} in a React class component, useRef may be your solution.

Doesn't that useRef seem hacky? I thought so too, but I discovered that I wasn't the only one who used useRef this way. Dan Abramov, one of the most famous contributors to React and author of Redux / create-react-app, also uses useRef this way. Check out his blog post "Making setInterval Declarative with React Hooks" for more.

Note: you can get the code as a gist here.

import React, { useReducer, useEffect, useRef } from 'react';
import firebase from 'firebase/app';
import equal from 'deep-equal';

function filterKeys(raw, allowed) {
  if (!raw) {
    return raw;
  }
  let s = new Set(allowed);
  return Object.keys(raw)
    .filter(key => s.has(key))
    .reduce((obj, key) => {
      obj[key] = raw[key];
      return obj;
    }, {});
}

export const useDbData = (paths) => {
  let unsubscribes = useRef({})
  let [data, dispatch] = useReducer((d, action) => {
    let {type, path, payload} = action
    switch (type) {
      case 'upsert':
        if (payload) {
          return Object.assign({}, d, {[path]: payload})
        } else {
          let newData = Object.assign({}, d)
          delete newData[path]
          return newData
        }
      default:
        throw new Error('bad type to reducer', type)
    }
  }, {})
  useEffect(() => {
    for (let path of Object.keys(paths)) {
      if (unsubscribes.current.hasOwnProperty(path)) {
        continue
      }
      let ref = firebase.database().ref(path)
      let lastVal = undefined
      let f = ref.on('value', snap => {
        let val = snap.val()
        val = paths[path] ? filterKeys(val, paths[path]) : val
        if (!equal(val, lastVal)) {
          dispatch({type: 'upsert', payload: val, path})
          lastVal = val
        }
      })
      unsubscribes.current[path] = () => ref.off('value', f)
    }
    let pathSet = new Set(Object.keys(paths))
    for (let path of Object.keys(unsubscribes.current)) {
      if (!pathSet.has(path)) {
        unsubscribes.current[path]()
        delete unsubscribes.current[path]
        dispatch({type: 'upsert', path})
      }
    }
  })
  useEffect(() => {
    return () => {
      for (let unsubscribe of Object.values(unsubscribes.current)) {
        unsubscribe()
      }
    }
  }, [])
  return data
}

export const useDbDatum = (path, allowed=null) => {
  let datum = useDbData(path ? {[path]: allowed} : {})
  if (datum[path]) {
    return datum[path]
  }
  return null
}

Conclusion

Have any thoughts or questions about useDbData/Datum? Let me know at doug@pragli.com or on Twitter @dougsafreno

Learn More about Pragli

I'm the co-founder of Pragli, a virtual office for remote teams. Teams use Pragli to communicate faster and build closeness with one another. Learn more here.

Include your Remote Team with “Brady Bunch” Video Conferencing

Doug Safreno — Thu, 21 Nov 2019 17:50:24 +0000

Update: If you're interested in learning more, check out this PHD work by Banu Saatçi - she comes to similar conclusions with a scientific approach. Thanks for sharing Banu!

It’s hard to level the playing field between remote and in-office teammates.

Teams especially fail to include remote teammates during "mixed" video conferencing, when some teammates are in a conference room. Remote teammates can't participate in side conversations and have a hard time injecting their questions and thoughts at the right moment.

At Gitlab and General Catalyst's "Making Remote Work" conference, we were fortunate to see several thought leaders discuss how they make meetings more inclusive to remote teammates.

Ian Tien (CEO of Mattermost) introduced the concept of "Brady Bunch" video conferencing. Each person in the meeting room uses their own laptop's video camera, rather than relying on the room video camera. As a result, everyone can see each other's face the same way.

This helps remote workers feel more included in many ways.

Visual Equality

Everyone is visually equal - all participants see each other in the same way. This feeling of equality makes remote teammates more likely to contribute, and in-office teammates more likely to be inclusive.

Everyone is equal - even if Allison and Minnie are in the same office

Side Conversations

In traditional meetings, side conversations frequently emerge, often as things get off track. But remote employees can't engage in side conversations without it sounding off to everyone over the conference room speaker.

If people are paying attention to different speakers, you probably have a side conversation. Remote workers will only get the gist of one conversation.

Forcing Brady Bunch displays the side conversations. This helps remote employees gain context. It also helps the meeting stay on track - in-office employees feel more reluctant to engage in side conversations that are out-of-scope if everyone will partake in them.

Social Cues

One of the hardest things about talking to a conference room full of people as a remote employee is that it's hard to see everyone's faces. This makes it difficult to read social cues, making it more likely for remote teammates to accidentally say something at an awkward time. In practice, remote teammates just speak less on calls to reduce the risk of derailing the meeting.

How would the remote teammate insert themselves if this was their view of the meeting?

In practice, remote teammates just speak less on calls to reduce the risk of derailing the meeting.

With Brady Bunch, it’s easy to see everyone's faces and thereby read social cues, so that the remote teammates feel more comfortable jumping in at the right moment.

Reduce Cost

Requiring Brady Bunch conferencing can also save cost - there’s no longer a need for all of the expensive conferencing equipment!

What's Next

Pragli is a video conferencing service that is inclusive to remote teammates. Pragli not only enables Brady Bunch video conferencing, it shows your other teammates who is meeting, building closeness and trust across all members of your distributed team.

Try out Pragli today - it's free!

How we use Firebase instead of Redux (with React)

Doug Safreno — Tue, 24 Sep 2019 16:05:01 +0000

This article explains how Pragli uses Firebase Realtime Database like a Redux store for our React front-end.

Background

Vivek and I use Firebase with React to operate Pragli.

For those who aren't familiar, Firebase Realtime Database (RTDB) provides in-browser (or in-app) data reading, writing, and subscribing. One client can simply write to a JSON document, and the document immediately propagates to all other clients. This largely eliminates the need for server code.

Data is represented as one large JSON document with subdata referenced by "routes." For instance, my user in the JSON document below is at the route users/dsafreno.

{
  "teams": {
    "Pragli": { ... },
    ...
  },
  "users": {
    "dsafreno": { ... },
    "vnair611": { ... },
    ...
  }
}

For a production application, the client can't do everything, largely for security reasons. For instance, sending emails or authenticating with integrations requires tokens that should not be shared with the client. We fill in the gaps using Firebase's Cloud Functions.

Wiring Firebase RTDB and React Sucks (By Default)

The problem with Firebase RTDB is that it isn't designed for React, so wiring the two together sucks. We ended up doing the same thing over and over again:

subscribe to a bunch of data in componentDidMount
unsubscribe in componentWillUnmount
perform our "data mounted" logic in componentDidUpdate

class Example extends React.Component {
  constructor(props) {
    super(props);
    this.state = { user: null, team: null };
  }
  componentDidMount() {
    let {userId, teamId} = this.props;
    // subscribe to user data
    let userRef = firebase.database().ref(`users/${userId}`);
    let userOff = userRef.on('value', (snap) => {
      this.setState({user: snap.val()});
    }
    this.userOff = () => ref.off('value', userOff);
    // subscribe to team data
    let teamRef = firebase.database().ref(`teams/${teamId}`);
    let teamOff = teamRef.on('value', (snap) => {
      this.setState({team: snap.val()});
    }
    this.teamOff = () => ref.off('value', teamOff);
  }
  componentDidUpdate(prevProps, prevState) {
    if (!prevState.user && this.state.user) {
        // first time we got user data!
    }
    if (!prevState.team && this.state.team) {
        // first time we got team data!
    }
  }
  componentWillUnmount() {
    this.userOff();
    this.teamOff();
  }
  render() {
    let { user, team } = this.state;
    if (!user || !team) {
      return null;
    }
    // ...
  }
}

export default Example

Ugly, right? That's a ton of boilerplate for a React component to subscribe to the data at two routes in Firebase. Components that required more data were even worse.

So we brainstormed how we could do better, considering a few solutions.

Ideas

Pass more data as props from higher-level components

We considered subscribing to data in a high level component and passing it down to child components.We started implementing this in some places, but we ultimately got frustrated because it caused too many child / intermediary component re-renders, slowing down the application.

Load data from Firebase RTDB → Redux → React

Redux is a state container for JS apps commonly used alongside React.

We considered syncing our data into Redux from Firebase RTDB and then subscribing to the Redux store for data. There's even a library for making React, Redux, and Firebase RTDB play nicely together.

But isn't the whole point of Firebase RTDB to have one easy-to-use source of state? Why duplicate with Redux?

We decided we wanted to come up with a solution that didn't involve piping state through Redux.

Which led us to our final solution...

Autoload Data with Specs

Ultimately, we decided to write our own wrapper function to make accessing Firebase RTDB more convenient.

The key idea is to statically specify which data your component needs via a static template. Once the data becomes available, Firebase RTDB fetches that data and passes it directly into the component as props.

We use the following schema:

const MY_DATA_SPEC = {
  name: 'myData',
  template: 'data/{myUid}',
  await: true
};

This schema specifies that the data at route data/{myUid} is passed into the component as the myData prop (myUid is assumed to be passed in as a prop from the parent).

The await: true prevents the component from mounting until it has received some data at that path (so that componentDidMount always has data).

Wiring it together - withDbData

We wrote withDbData to conveniently load components with the data in this spec.

Here's what the above component looks like now:

class Example extends React.Component {
  componentDidMount() {
    // first time we got data!
  }
  render() {
    let {user, team} = this.props;
    // don't need to null check since we await the data!
  }
}

const USER_SPEC = {
  name: 'user',
  template: 'users/{userId}',
  await: true
};

const TEAM_SPEC = {
  name: 'team',
  template: 'teams/{teamId}',
  await: true
};

export default withDbData([USER_SPEC, TEAM_SPEC])(Example)

Here's the source code (MIT license, feel free to use it). It's also available on Github here.

import React from 'react';
import firebase from 'firebase/app';
import equal from 'deep-equal';

export function withDbData(specs) {
  let propToSpecs = {};
  for (let spec of specs) {
    let {propIds} = parseSpec(spec);
    for (let propId of propIds) {
      if (!propToSpecs[propId]) {
        propToSpecs[propId] = [];
      }
      propToSpecs[propId].push(spec);
    }
  }

  return (Child) => {
    let Wrapper = class extends React.PureComponent {
      constructor(props) {
        super(props);
        this.unmounting = false;
        this.offs = {};
        this.state = {};
      }
      subscribeToSpec(spec) {
        let { name, keys } = spec;
        let { propIds, formatPath } = parseSpec(spec);
        let path = formatPath(this.props);
        if (!path) {
          return;
        }
        let ref = firebase.database().ref(path);
        let offFunc = ref.on('value', (snap) => {
          let dat = keys ? filterKeys(snap.val(), keys) : snap.val();
          if (equal(dat, this.state[name])) {
            return;
          }
          this.setState({
            [name]: dat,
          });
        });
        let hasBeenOffed = false;
        let off = () => {
          if (hasBeenOffed) {
            return;
          }
          hasBeenOffed = true;
          if (!this.unmounting) {
            this.setState({
              [name]: null,
            });
          }
          ref.off('value', offFunc);
        };
        for (let propId of propIds) {
          if (!this.offs[propId]) {
            this.offs[propId] = [];
          }
          this.offs[propId].push(off)
        }
      }
      componentDidMount() {
        for (let spec of specs) {
          this.subscribeToSpec(spec)
        }
      }
      componentDidUpdate(prevProps) {
        let resubs = new Set();
        for (let prop of Object.keys(propToSpecs)) {
          if (prevProps[prop] !== this.props[prop]) {
            if (this.offs[prop]) {
              for (let off of this.offs[prop]) {
                off();
              }
            }
            this.offs[prop] = [];
            for (let spec of propToSpecs[prop]) {
              if (resubs.has(spec.name)) {
                continue;
              }
              resubs.add(spec.name);
              this.subscribeToSpec(spec);
            }
          }
        }
      }
      componentWillUnmount() {
        this.unmounting = true;
        for (let offList of Object.values(this.offs)) {
          for (let off of offList) {
            off();
          }
        }
        this.offs = {};
      }
      render() {
        for (let spec of specs) {
          if (spec.await && !this.state[spec.name]) {
            return null;
          }
        }
        let childProps = Object.assign({}, this.props, this.state);
        return (<Child {... childProps} />);
      }
    }
    return Wrapper;
  }
}

Conclusion

Did this help you learn how to better use Firebase with React? Do you have any follow up questions? Shoot me an email at doug@pragli.com, or follow up with me on Twitter @dougsafreno.

Live Avatars (like Animoji in the Browser) with face-api.js

Doug Safreno — Thu, 29 Aug 2019 16:41:11 +0000

In this article, I explain how we added live avatars to our app to help teammates feel more present with one another on distributed teams.

Background

Pragli is an virtual office for remote workers. In Pragli, I wanted a way for teammates to feel present together when working, without invading privacy. We started by trying "always on" video - but that was too creepy. Then, we decided to try something like streamed Animoji.

Here’s what it looks like in the end:

How it Works

Live avatars are remarkably easy to code up.

We built Pragli with React and Electron (for the desktop version). To implement live avatars, we did the following:

1) Add an avatar creation flow

We used the Avataaars library by Pablo Stanley (specifically this project by fangpenlin). We evaluated a couple other libraries for this but it had the most configurability / diversity (race, gender expression, etc).

2) Detect faces with face-api.js

I set face-api.js to detect the bounding box and expression attributes. I played with eyebrow detection but couldn't get it to feel right.

3) Transform the live avatar

Once the face has been detected, we use the bounding box to horizontally translate the avatar. We tried zooming the avatar in and out, but it felt strange to us, so we nixed it.

We use expression "happy" as a smile with teeth ("Smile"), "neutral" as a normal smile ("Twinkle"), and "sad" as a more neutral / serious expression ("Serious").

Left to right - happy, sad, neutral

Development Tip

Development was much easier when I could actually see the video and photo that face-api.js was using. Example below:

Issues

The system works better than we expected, namely because face-api.js is pretty good at what it does. There are still a few gotchas...

Performance

Face detection with face-api.js can take anywhere from 10ms to 3-4s to run, depending on how many runs it’s done and how loaded your computer is.

This means that, sometimes, your otherwise snappy app turns laggy for a moment.

I minimize this by not running face-api.js too frequently (about once per 5s seems right) and by letting it “warm up” when it first boots. The first detection always seems to take the longest - more work to be done (might just be me being a bad developer).

Responsiveness

Since face-api.js takes time and CPU, we throttled it down to not run all the time. This means it doesn't have the responsive, real face experience of Animoji. Instead, it's more passive. However, it works very well for our use case - passive presence.

Devices

If you have multiple devices connected, managing the video device the app is using can be a nightmare, especially since it turns out Chrome might decide to ignore the one you pick anyways.

This especially becomes a problem if you use the device for other things (like we do when the user is in a video conference) - we still have some open bugs around this.

What’s Next

If you’re interested in trying out live avatars, sign up for Pragli and invite your teammates - it’s free. You'll have to turn on live avatars by clicking on the avatar in the top left and then selecting "live avatar - video."