An implementation of Firelist using React
Branch: master
Clone or download
Chris Esplin
Latest commit 2b5b2d7 Jun 1, 2018
Type Name Latest commit message Commit time
Failed to load latest commit information.
bin Adding email to toolbar. Adding curl command to test messaging. May 22, 2018
functions Updating messaging prompts Jun 1, 2018
public Updating messaging prompts Jun 1, 2018
src Updating messaging prompts Jun 1, 2018
.firebaserc firebase init May 3, 2018
.node-version Prepare to eject Mar 31, 2018
.prettierrc Initial commit Mar 30, 2018 Moving to localhost May 21, 2018
database.rules.json Repairing a challenge prompt that should have been for Realtime DB May 28, 2018
firebase.json Preparing for deploy May 21, 2018
firestore.indexes.json firebase init May 3, 2018
firestore.rules Repairing firestore.rules May 29, 2018
package-lock.json Beginning to test onFinalize. Added recursiveDelete May 4, 2018
package.json Updating cloud functions prompts and tests May 30, 2018
storage.rules firebase init May 3, 2018
webpack.config.js Moving to localhost May 21, 2018
yarn.lock Updating for localhost May 21, 2018

Firelist React

We'll build this app together using and a git branch for each feature.

You can definitely follow along on your local machine. It will require a little more git and command-line skill, but it's all very standard stuff for Node.js development.


Simply open up the project :)

You can use CodeSandbox to work on specific branches by using the following url pattern:[BRANCH_NAME]

Just replace BRANCH_NAME with the name of the branch that you're working on.

Localhost installation

Pull the repo directly from GitHub and install dependencies with yarn or npm install

git clone
cd firelist-react

We'll use yarn instead of npm, but either will work fine.

If you need to check out a new branch, let's say firebase-authentication, you'd run the following...

git checkout firebase-authentication

And you can switch back to master whenever you need it.

git checkout master

Once you're on your branch, run yarn start to spin up the local dev server.

yarn start

Your development environment will be up and running at http://localhost:8080


Our yarn start command uses Webpack and the Webpack Dev Server. Webpack is great... but it has its limitations. If you find that Webpack is in a funny state, kill the yarn start process and run yarn start again to refresh your server. Sometimes that's all you'll need.


We're huge fans of VSCode and highly recommend it for local development.

If you're using VSCode, try the Firebase extension for Firestore security rules highlighting.

Node Versions

Cloud Functions lags in its support for Node.js. It supports one or two LTS versions back. So we'll want to run our Cloud Functions code in a very specific version of Node.js

The trick is to run yarn add node@6.14.2 --save-exact to install v6.14.2 locally. This doesn't affect global node versions, but any script in package.json will run on v6.14.2.

You can test this with a package.json script:

"scripts": {
  "v": "node --version"

The run yarn v. You should see v6.14.2 in the output.

Now our tests will ensure compatibility with Cloud Functions!

GCP (Google Cloud Platform) APIs

You'll need to create a service account that has signBlob rights in order to create thumbnail images.

You'll need to enable the Identity and Access Management API to make image thumbnails.

While developing this application I ran into a nasty error where I couldn't upload files to Firebase Storage any longer. I solved the problem by upgrading my Firebase project to the Blaze plan and explicitly granting Storage Admin rights to as described on this Stackoverflow answer.

I also ran into trouble with iam.serviceAccounts.signBlob permissions. That was resolved by adding the "Cloud Functions Service Agent" role to my as recommended on this Stackoverflow answer.

HTTPS Required

This project includes a Service Worker. And Service Workers require a valid HTTPS connection.

The HTTPS requirement makes local development a real pain, because you can't ever generate a legitimate SSL certificate for localhost. We've found two ways to get around this.

  1. Start Chrome with the --ignore-certificate-errors switch.
  2. Open Chrome flags and enable #allow-insecure-localhost

Option #1 enables serving the page from any test domain. Option #2 works for localhost only.

Option #1 (--ignore-certificate-errors) is a huge pain, because it's a Chrome startup setting, which means that you have to manually open Chrome with that settings, which is a different process for both Windows and Mac.

Option #2 (#allow-insecure-localhost) is preferred in every way to #1... unless you're developing from a domain other than localhost. If that's the case... then consider serving from a custom SSL cert with Webpack Dev Server.

We'll do our best to stick to localhost so that #allow-insecure-localhost will work seamlessly.