DEV Community: Pragli

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.

How to authenticate with Google Oauth in Electron

Vivek Nair — Fri, 10 Jan 2020 16:45:50 +0000

Last month, we started to get concerning bug reports from our users that they couldn’t authenticate with Google directly inside of the Pragli desktop application. Here’s the error message that they were seeing:

You are trying to sign in from a browser or app that doesn’t allow us to keep your account secure. Try using a different browser.

We knew that Google had deprecated Oauth authentication for non-standard browsers a year ago, but we had no idea that Electron (based on Chromium) was on the chopping block as well.

This means that our desktop application could no longer authenticate with Google directly inside of the application. We now needed to navigate the user to a supported browser to properly authenticate. I couldn't find a resource to help me solve this problem, so I ended up experimenting with different authentication architectures until I resolved the issue.

In this post, I show how to implement Google authentication for your Electron application without running into any browser restrictions. I use Firebase, React and Google Cloud Functions, but other technologies should have similar implementations.

General idea

Here’s a rough outline of how to authenticate your desktop application:

Generate a one-time random code within the Electron application when a user initiates a sign in
Listen for an authentication code in a publicly accessible database, using that one-time random code (more on this later)
Open the user’s default browser, passing along the one-time code
Once in the user’s browser, redirect to Google Oauth
Once you’re redirected back from Google Oauth with the session information, generate an authentication token for arbitrary clients to sign in as the user
Associate the authentication token with your one-time code in your datastore
The Electron application receives the authentication token via its listener in Step #2 and signs the user in

Step 1: Generating a random token

There’s no easy way to directly pass data from a browser to an Electron application.

Therefore, we need to use a datastore (Firebase in our case) that is accessible by both the browser and the Electron application to pass the authentication information from the browser, which is handling the authentication, to the Electron application, which needs to sign in.

Architecture for desktop authentication

To uniquely identify a sign in attempt, we also need to generate a random code that the supported browser can use to send the Electron application the user session information/authentication code to sign in. Within the Electron application, generate this one-time code with the uuid() module.



const signIn = () => {
  const id = uuid()

  // Rest of implementation
})

Step 2 : Listen for the authentication code

Listen for any authentication information that is passed through Firebase with the .on() function.

Note: The to-auth-codes/${id} route needs to be readable/writeable by any unauthenticated client. For Pragli, we judged that the security concerns for this approach were minimal.



const signIn = () => {
  const id = uuid()

  const oneTimeCodeRef = firebase.database().ref(`ot-auth-codes/${id}`)

  oneTimeCodeRef.on(‘value’, async snapshot => {
    const authToken = snapshot.val()

    // Rest of implementation
  })
})

Step 3: Redirect the user to the browser

Navigate the user to the browser to complete the Google authentication. We created a simple route /desktop-sign-in to initiate the authentication. Make sure that you pass along your one-time use code, so the browser can pass the authentication details back to Electron once the authentication finishes.



const signIn = () => {
  const id = uuid()

  const oneTimeCodeRef = firebase.database().ref(`ot-auth-codes/${id}`)

  oneTimeCodeRef.on(‘value’, async snapshot => {
    const authToken = snapshot.val()

    // Rest of implementation
  })

  const googleLink = `/desktop-sign-in?ot-auth-code=${id}`
  window.open(googleLink, ‘_blank’)
})

Step 4: Google authentication

At the /desktop-sign-in page, redirect to Google for authentication. In our case, Firebase made this dead simple with the signInWithRedirect() function. The service transparently handles setting the Oauth redirect URL and creating a fully populated User object.



componentDidMount() {
  const provider = new firebase.auth.GoogleAuthProvider()
  firebase.auth().signInWithRedirect(provider)
}

Step 5: Generate the authentication token

Once Google redirects back to your application, recover the Firebase user object with the getRedirectResult() function.

To generate an authentication token that Electron can use to sign in as the user, you need to use the admin Firebase library. Unfortunately, you can’t use the regular client-side Firebase library to generate a token - even if you’re already authenticated as the user.

To use the admin Firebase library, you need a secure server environment. I prefer to use Google Cloud Functions to keep our infrastructure simple. But regardless of the server that you select, you also need to send the backend the following information;

The one-time use code
A user ID token for the server to validate that the sending request comes from the correct, authenticated user

Browser Client



async componentDidMount() {
  const result = await firebase.auth().getRedirectResult()
  if (!result) {
    firebase.auth().signInWithRedirect(provider)
  } else {
    console.log(“Grabbed the user”, result.user)

    if (!result.user) {
      return
    }

    const params = new URLSearchParams(window.location.search)

    const token = await result.user.getIdToken()
    const code = params.get(“ot-auth-code”)

    const response = await fetch(`${getFirebaseDomain()}/create-auth-token?ot-auth-code=${code}&id-token=${token}`)
    await response.json()
  }
}

Server (Google Cloud Function)

Since you’re executing a cross-origin request from client to a server in Google Cloud Functions, make sure that you wrap the request with the CORS node module to ensure that the correct Access-Control-Cross-Origin headers are set.



const admin = require(‘firebase-admin’)
const cors = require(‘cors’)({
  origin: true
})

admin.initializeApp()

exports.createAuthToken = functions.https.onRequest((request, response) => {
  cors(request, response, async () => {
    const query = request.query

    const oneTimeCode = query[“ot-auth-code”]
    const idToken = query[“id-token”]

    const decodedToken = await admin.auth().verifyIdToken(idToken)

    const uid = decodedToken.uid

    const authToken = await admin.auth().createCustomToken(uid)

    console.log(“Authentication token”, authToken)

    await admin.database().ref(`ot-auth-codes/${oneTimeCode}`).set(authToken)

    return response.status(200).send({
      token: authToken
    })
  })
})

Step 6: Associate the auth token with the one-time code

Once you’ve generated the auth token, you can easily associate the token with your one-time code with the .set() function using the Firebase admin library.



exports.createAuthToken = functions.https.onRequest((request, response) => {
  // Other implementation
  const authToken = await admin.auth().createCustomToken(uid)

  await admin.database().ref(`ot-auth-codes/${oneTimeCode}`).set(authToken)

  return response.status(200).send({
    token: authToken
  })
})

Step 7: Use the auth token to sign in as a user in Electron

In Step #2, you set your Electron application to listen for updates to the the one-time use token route in Firebase. Once the server sets the auth token at that Firebase route, simply grab the auth token and use it to sign in.



const signIn = () => {
  const id = uuid()

  const oneTimeCodeRef = firebase.database().ref(`ot-auth-codes/${id}`)

  oneTimeCodeRef.on(‘value’, async snapshot => {
    const authToken = snapshot.val()

    const credential = await firebase.auth().signInWithCustomToken(authToken)
  })

  const googleLink = `/desktop-sign-in?ot-auth-code=${id}`
  window.open(googleLink, ‘_blank’)
})

Another authentication strategy

We used a publicly accessible datastore with Firebase to communicate from the browser to the Electron application.

You can also facilitate the communication between the browser and the desktop app by spinning up a local server upon boot of the Electron app. Then, the local server simply writes to a known filesystem location, and the Electron app can poll for changes at that location to get the authentication token.

Concluding thoughts

The recent Google authentication restrictions have been a huge pain for desktop developers. The trickiest part is managing the communication channel from the browser back to the Electron application. Hopefully this tutorial helped in planning your migration to browser-based authentication.

What’s Pragli?

I built a virtual office for remote teams to frictionlessly chat and feel present with each other. If you’re interested in using the product with your team, learn more here or reach out to me on Twitter.

How to manage macOS windows using JavaScript for Automation (JXA)

Vivek Nair — Wed, 04 Dec 2019 14:53:22 +0000

Pragli is a communication product that is designed to work with Slack. But until a few days ago, managing two applications on the same display was an awkward experience.

We noticed that users were frustrated managing the applications for two reasons:

They have no idea where to position the applications in a way that fits their workflow
They have to reorganize their screens into the same visual structure every time they reopen the applications

As a result, we failed to convert many signups because people had too much friction using Pragli alongside Slack.

Even though there are dozens of third party tools like Better Touch Tool and Divvy that automate window management, most people don’t use them for two reasons (again).

Non-power users don’t know that these tools exist
These tools require fairly advanced configuration to ensure that applications are placed in certain locations. That's time most users don't want to invest.

To make Pragli feel more natural alongside Slack, we implemented a basic window management feature for macOS that automatically places Slack and Pragli next to each other with a simple hotkey. The feature has been super valuable for our users to set up their communication stack instantly.

In this article, I'll cover how developers can manage windows in macOS with only a few lines of code.

How to manage windows in macOS

This tutorial covers managing windows in macOS. In a future blog post, I'll discuss the implementation of window management in Windows. Stay tuned for that.

Script Editor

This tutorial uses macOS's JavaScript for Automation (JXA) to manage windows. To get started, open the Script Editor utility and switch to the JXA editor. Try loading an application instance.

const slackApp = Application("Slack")

If Slack doesn't exist on your system, the command will throw an exception. Catching these exceptions is an excellent way to verify that your target application exists on the client machine before attempting to manage windows.

If the application exists but is not currently running, start the application with activate(). The application should boot up and foreground. If the application is already running, the application will only foreground.

slackApp.activate()

To set the bounds for an application, specify the first window for that application windows[0] and set its dimensions and position. The below example statically sets the dimensions to 500 by 500 pixels. But in practice, you will likely set the position and dimensions dynamically from the characteristics of your display.

slackApp.windows[0].bounds = {
  "x": 0,
  "y": 0,
  "width": 500,
  "height": 500
}

Integrating JXA into your desktop application

We use Electron for the Pragli desktop client, so I'll discuss how to integrate JXA with Electron. Although this won't be applicable to non-Electron products, the implementation will likely look similar.

As a prerequisite to manipulating other application windows (e.g. Slack from within Pragli), macOS requires accessibility permissions. You can prompt your users to give you permissions with a single line of code.

// Main process of the Electron application
const { systemPreferences } = require('electron')

// Prompt to access System Preferences by setting the prompt "true"
const isTrusted = systemPreferences.isTrustedAccessibilityClient(true)

console.log("Does the client have accessibility permissions?", isTrusted)

As an example, here's the flow that we use to prompt our users to accept accessibility permissions. Since the built-in macOS accessibility prompt does not clearly specify how users can add the permission, I recommend that you include a loop video or GIF showing how users can add your application.

Then, install the run-jxa npm module by Sindre Sorhus, which provides a simple interface for interacting with JXA. Run the runJxa() function within the Electron main process as a response to pressing a keyboard shortcut.

npm install run-jxa

// Main process of the Electron application
const electron = require('electron')
const {globalShortcut} = electron

// ... Other Electron setup

const runJxa = require('run-jxa')

globalShortcut.register('Shift+CmdOrCtrl+U', async () => {
  await runJxa(`
    const slackApp = Application("Slack")
    slackApp.activate()
    slackApp.windows[0].bounds = {
      "x": 0, 
      "y": 0, 
      "width": 500, 
      "height": 500
    }
  `)
})

Alternatively, if you want to set the window dimensions as a function of your primary display, you can use this next example as inspiration instead. This sets Slack to 100% of the height and width of your primary display.

// Main process of the Electron application
const electron = require('electron')
const {globalShortcut, screen} = electron

// ... Other Electron setup

const runJxa = require('run-jxa')

globalShortcut.register('Shift+CmdOrCtrl+U', async () => {
  const {getPrimaryDisplay} = screen

  const display = getPrimaryDisplay()
  const {width, height} = display.size

  await runJxa(`
    const slackApp = Application("Slack")
    slackApp.activate()
    slackApp.windows[0].bounds = {
      "x": ${display.bounds.x}, 
      "y": ${display.bounds.y}, 
      "width": ${width}, 
      "height": ${height}
    }
  `)
})

If you want to get extra fancy, you can adjust the width as a function of user preferences. Here's what that looks like in Pragli.

Conclusion

If you have any questions about our window management implementation, reach out on Twitter. I'd love to elaborate on my thoughts and strategies for implementing window management for desktop applications.

What's Pragli?

I built Pragli as a virtual office for remote workers to communicate quickly and feel more present with their teammates. By using JXA and native integrations, Pragli works great with Slack.

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!

Remote Work Trends According to US Census Data

Vivek Nair — Fri, 01 Nov 2019 01:36:46 +0000

Remote work has been top of mind for many companies recently, and technology managers are increasingly looking for analytical ways to motivate hiring remote team members.

The remote community is responding in force.

Hiten Shah recently published an enormous volume of 250 remote work statistics to help remote advocates make the case for hiring remote.
Buffer, Doist and We Work Remotely created a 2019 State of Remote Work report to reveal the biggest challenges and benefits with remote work amongst 2,500 survey respondents.

Yet, I noticed that there were no available tools to view remote work trends for US cities using official US Census Bureau data. Over the last two weeks, I spent hours formatting and displaying the data in a digestible way. You can test out my "U.S. Remote Work Trends" tool here.

Preview of my U.S. Remote Work Trends tool

In this article, I share 4 insights that I learned from using the application. But before I dive in, let's define some terminology from the application:

Remote Trend Score (RTS): a normalized score between 0 and 100 that quantifies the positive growth of the remote community in a city

Income Trend Score (ITS): a normalized score between 0 and 100 that quantifies the positive growth of median income levels for a city

If you're interested in knowing how ITS and RTS are computed, check out the "Data collection methods" section at the bottom of this article. With these terms in mind, here are a few insights about US cities that I learned from this data.

High income levels correlate with high remote populations

Cities with high income levels generally have higher remote work compositions. This intuitively makes sense. Remote work positions tend to be knowledge work that pays higher salaries, such as software engineering and accounting.

Over half of the 10 most remote cities in the United States have over $100K median income

Relatedly, cities with higher Income Trend Scores (ITS) have correspondingly higher Remote Trend Scores (RTS). Put another way - the income level and the remote community of a city correlate strongly together.

Despite the discourse around remote work empowering the economies of rural, low-income communities in the US, remote work is still a privilege largely enjoyed by affluent areas.

Southern California beach cities have the highest remote populations

Southern California beach cities dominated 4 of the top 10 remote work locations. Encinitas, Carlsbad, Santa Monica and San Clemente have above a 7.5% remote working population, and all the cities are spread amongst San Diego, Los Angeles, and Orange counties. Unsurprisingly, these cities also have more than $86,000 in median household income.

Given the highly educated populations in these areas and the lifestyle benefits associated with temperate beach cities, I'm not surprised that these remote concentrations are so high. Given the positive upward trend of remote work in these cities (89.75 average RTS score), they will likely maintain their dominance amongst the top 10 remote cities for many years to come.

Cities with smaller remote populations tend to have industries with physical constraints

Cities with the lowest remote working populations tend to have industries with physical work constraints, such as agriculture and manufacturing.

Agriculture: Madera, CA (0.81% remote) and Porterville, CA (0.74%), both located in California's Central Valley, have significant populations of agricultural laborers.

Manufacturing: New Brunswick, NJ (0.44%) and Owensboro, KY (0.47%) employ most of their citizens in manufacturing roles that require in-person fabrication.

A common thread amongst the bottom 20 remote work cities is that blue collar labor is pervasive amongst the workforce.

Cities with low remote populations are still losing their remote workers

While cities with the highest remote work percentages are increasing their share of remote workers (high RTS), the cities with the lowest remote work percentages are rapidly losing their remote workers (low RTS).

Counterintuitively, the majority of cities with declining remote populations (e.g. Sunrise Manor, Nevada and Hammond, Indiana) have increasing income levels (high ITS). I figured that higher income levels, often considered a sign of a tightening labor market, would give workers more leverage to negotiate working remotely.

Frankly, I was stumped by this trend. At the risk of provoking criticism for reading too much into correlation, I have two (potentially inaccurate) conjectures to explain this phenomenon:

Cities with low remote populations are blue collar, and blue collar cities are simply becoming even more blue collar as time passes.
Remote workers feel less comfortable in cities with social centers (e.g. coffee shops or libraries) that feel less lively during the work day. That is a strong incentive to move or work onsite. Eventually, this becomes a feedback loop that contributes further to remote work declines.

Did you find any other interesting remote work trends using my tool? Share your findings with us on Twitter and we’ll add them to this list and mention you.

Data collection methods

I used data from the US Census Bureau’s American Community Survey (ACS) to create this interactive application.

The official census survey attempts to record every American household but is only conducted once every 10 years. To fill in the gaps, the bureau created the ACS to collect survey information from a representative group of 3.5 million Americans. ACS annual data is freely available online, dating from 2007 to 2017 for the 5-year estimate samples. To simplify the analysis, we removed cities with less than 40,o00 residents.

I consulted the official ACS documentation to find the necessary information and used the citysdk npm library provided by the Census Bureau development team to easily retrieve and process the data. These are the variables that I used as the basis for the application.

B08301_021E: Means of transportation to work (working from home)

B01003_001E: Total population

B09001_001E: Population under 18 years of age

B19013_001E: Median household income in the past 12 months

I then computed several properties from these base values.

Adult Population: populations of adults (18+) in the city

Remote Percentage: percentage of remote workers in the adult population.

Remote Trend Score (RTS): normalized score between 0 and 100 to quantify the trend of remote work adoption between 2013 to 2017.

To determine this score, I compute the linear regression of the remote percentages of a city from 2013 to 2017. Then, I take the linear coefficients of each city and normalize them between 0 and 100 using the least growing remote city (Columbia, SC) and most growing remote city (Encinitas, CA) as baselines.

Income Trend Score (ITS): normalized score between 0 and 100 to quantify the trend of income levels between 2013 to 2017.

I use the same methodology as RTS to compute ITS. I compute the linear regression and normalize the linear coefficients of each city relative to low and high income growth baselines (Corona, CA and Palo Alto, CA respectively).

Big shout out to Zhi Keng He and Logan Powell in the Census Bureau development team for helping me navigate the Census APIs. 🎊

Subscribe to our newsletter here! I'll continue to push interesting statistics and visualizations in future blog posts based on this census data. Let me know if you have any ideas for future posts or visualizations that I can create.

Are you a remote worker?

My biggest challenge with working remotely was communication and social isolation. I built Pragli as a virtual office for remote workers to communicate quickly and feel more present with their teammates. Sign up for Pragli and invite your teammates - 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.

Why you should host virtual office hours for your remote team

Vivek Nair — Fri, 06 Sep 2019 17:25:30 +0000

Communication always tops the list as the biggest challenge that remote teams experience. Working asynchronously and across time zones often results in workers not getting clarity on their questions quickly enough. Junior employees especially struggle since they often have the highest volume of questions as they onboard, but also feel the least comfortable reaching out for help.

In this article, I will explain how implementing virtual office hours for your team can help mitigate issues related to communication by providing a structured outlet for workers to ask any questions they have.

What are virtual office hours?

Virtual office hours are dedicated times when you are available to your team for conversation, work-related or otherwise. These dedicated times create a structured environment for users to bond and ask questions, distributing knowledge and building closeness.

Virtual office hours provide structured time for new employees

Most companies onboard junior engineers at physical offices in roughly the same way:

Assign them a mentor
Have them work closely with that mentor for the first few weeks, asking any questions that arise about company logistics, engineering best practices, and their development environment
Wrap up onboarding after a few weeks and switch to weekly check-ins

Due to geography and time zones, remote mentors can’t answer questions with the same level of availability and responsiveness as organizations with colocated teams.

By hosting virtual office hours, remote teams can create structured time for junior engineers to answer any burning questions they have about engineering processes or the product roadmap. As a result, engineers ramp faster and gain a deeper base of knowledge.

Virtual office hours distribute knowledge across more teammates

Most employees work closely with only 1 or 2 other people and knowledge is often siloed within their own project management systems. Virtual office hours are great for distributing this knowledge and work especially well for remote teams.

In physical offices, this information sharing often happens at common office choke points, such as cafeterias, coffee machines, and water coolers. But, organic events like these rarely happen in remote teams. Many remote organizations often try to recreate these interactions by scheduling company events to “get to know each other”, but unsurprisingly these rarely provide a sense of sustained community. Asking a teammate, who you don’t know very well, to grab lunch together is very different from your boss organizing a lunch event for everyone at the company. Both events are fun, but during the latter event, everyone is far less likely to authentically share information that they've learned.

By providing scheduled office hours to your teammates and broader organization, you can develop far more organic conversations. Knowledge that was previously siloed in a team’s project management system is often discovered naturally. Moreover, your remote teammates, who you do not regularly work with, can feel more comfortable diving into conversations to chat about the feasibility of moonshot feature ideas that could 10X user retention. These are the types of conversations that founders and managers at remote companies should want to facilitate.

Bonding sessions (like offices hours) promote closeness with teammates

From our interviews with over 50 teams, we found that most remote workers average less than 1 impromptu audio/video conversation with their teammates per week. This is especially shocking, given that impromptu conversations happen virtually every hour in physical offices.

Virtual office hours provide a more transparent space for remote workers to develop bonds with teammates. Since these times are unrelated to performance, you can create a more comfortable environment for teammates to bond and more freely ask questions. This inevitably leads to higher employee happiness and productivity.

Also, by providing a transparent environment where people can easily participate in group conversations, teammates can feel as though they have more social capital to get to know anyone on a team better if they so choose. That is a psychologically powerful effect for remote team members.

Get started hosting virtual office hours

Teams use Pragli everyday to host their virtual office hours. Get started with our detailed guide to hosting office hours in Pragli.

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."

Why we are frustrated with asynchronous communication for remote teams

Vivek Nair — Fri, 23 Aug 2019 03:06:00 +0000

We have become more frustrated with asynchronous communication.

For the last few years, asynchronous communication has been championed as the cornerstone of remote team communication. Companies like Basecamp have evangelized asynchronous communication as the most ideal way for teams to collaborate and persist a team’s collective knowledge.

The argument generally goes: if a team documents every process and uses structured, timezone-agnostic platforms for discussion, the team will naturally reduce knowledge gaps by making sure that everyone (often across time zones) is involved in the decision making process.

We don’t disagree! In the life cycle of every remote team, some form of asynchronous communication is critical to scaling conversations. But, there are serious consequences to ignoring impromptu, synchronous communication.

Our interviews with over 50 remote teams reveal 3 reasons why too much asynchronous communication could lead to greater frustration within your remote team.

Reason 1: Too much asynchronous communication can hurt company culture

According to Hiten Shah’s Remote Work Report, loneliness frequently tops the list as the most challenging problem that remote workers face. The socially isolating nature of remote work can easily draw out feelings of apathy and resentment. Part of the problem is inherently with the primary medium where most asynchronous communication happens, text.

Of course, remote companies also realize that audio/video (AV) communication is excellent for combating social isolation. The higher fidelity medium promotes quicker time to resolution and promotes more empathy. Many remote companies even require that all meeting participants turn on their video.

But in a remote setting, workers simply do not have enough conversations throughout the week. In our recent remote survey, we discovered that

Around 50% of workers have only 1 scheduled AV meeting per day
Most remote workers have at most 1 unscheduled (work or “water cooler”) AV conversation per week

These statistics are especially stunning given the frequency of impromptu conversations in physical offices, where workers take breaks by grabbing lunch or coffee with colleagues. The psychological consequences of micro-isolation during breaks throughout the workday cannot be understated.

Asynchronous communication unfortunately magnifies these effects by emphasizing text as the de facto standard for communication, which often dehumanizes decision making. Although synchronous communication is difficult to scale, many remote teams have overcompensated by over communicating with text than is really necessary.

Providing outlets for impromptu, synchronous communication pays serious dividends by providing a much-needed dose of humanity to remote communication.

Reason 2: New hires onboard best synchronously

When joining either a distributed or local company, new hires absorb tons of information about company culture, engineering best practices, and employee benefits. The list of basic onboarding tasks can easily consume your first week on the job.

Even still, new hire onboarding doesn’t stop at the end of the week. Ramp periods for most roles are measured in months, not weeks.

As a marketer: understanding your company’s unique process for content creation and familiarizing yourself with their specific marketing toolkit takes time.
As a salesperson: understanding the product feature set, its technical limitations, and the competitive landscape takes time.
As an engineer: understanding the system architecture, unique motivations for the technology stack, and existing technical debt takes time.

For all roles during the onboarding period, new hires will inevitably have a ton of clarifying questions about their job. The speed with which the company can unblock new hires during this time translates directly into productivity wins.

In an asynchronous world, remote managers often “answer” new hire questions by pointing to FAQ documents in Confluence or Google Docs that may answer their questions only half of the time. And once new hires are blocked, they are often forced to twiddle their thumbs, resulting in disillusionment or insecurity in their ability to complete their work successfully.

That is not a great first experience for any new hire and can leave them looking for an escape hatch.

Impromptu, synchronous availability from remote managers and mentors can provide remote hires the quick answers that they need during the most critical time of their employment - when they step through the door.

Reason 3: Engineers work slower when they are frequently blocked and have to context switch

Engineers need concentrated focus time without distractions to build great products. Most engineering organizations (including ours) would agree.

Since asynchronous communication provides engineers with a structured process for triaging communication to a later point, the communication style seems like the perfect match for an engineer looking to optimize their deep work.

The primary issue with this line of thinking is again an issue of question resolution time. If you can create a technical spec within a single meeting that holistically captures every possible edge case, then I would agree that asynchronous communication would be strictly better.

The reality is far different. Engineering is an iterative and collaborative process , where unexpected details can quickly upend your original design and necessitate another collaboration session. Oftentimes for remote engineers, this means that they are immediately blocked and likely will have to wait anywhere between a few hours to an entire work day to properly resolve issues. To combat this, asynchronous philosophy generally endorses keeping multiple threads of operation to make global forward progress. But, the mental shift to other tasks can often have a severe effect on productivity and morale as teammates too often find themselves in limbo.

We have found that if you introduce a dose of impromptu synchronous communication into your team culture (perhaps with virtual office hours throughout the day), you can create tighter collaboration loops to resolve issues faster and get back to your focus time.

Concluding thoughts

Don’t get me wrong! Asynchronous communication is critical for remote teams at scale. Certain high level decisions are best discussed using structured communication that is inclusive to people across time zones.

But, the recurring theme across these 3 points is that the remote community has not thought through how impromptu, synchronous communication can improve immediate productivity and foster mental health. We need more frequent audio and video conversations in remote teams and over communicating with asynchronous communication is holding us back!

What’s Pragli?

We created Pragli as a virtual office to help remote workers dive into rich audio/video conversations frictionlessly. We use Pragli every day and believe that most remote teams could benefit from doing the same.

Try Pragli today and take your team's synchronous communication to the next level. The product is free to use.