Customising the Firestore Quickstart

Customising the Firestore Quickstart for 2026

Adapting the FriendlyEats quickstart and connecting it to the Firebase Local Emulator Suite

In this walkthrough, we take the Firestore quickstart — part of the actively maintained quickstart-js repository on GitHub — and reshape it into a working web admin app for a FlutterFlow-based mobile app backed by Firebase. As of 2026, the quickstart-js repository has been migrated to TypeScript and continues to receive regular updates, so some of what you find there will look a little different from older tutorials.

TL:DR – This article focuses on the practical modifications needed to turn the FriendlyEats quickstart into a custom admin app for a Firestore database. It also covers connecting that app to the Firebase Local Emulator Suite so you can experiment safely without touching production data. In the end I didn't pursue this particular approach beyond the prototype stage — but the process taught me a great deal, and the steps here are still valid and useful in 2026.

What's changed in 2026

If you followed a version of this guide written a few years ago, there are a few things worth flagging before you dive in.

• quickstart-js is now TypeScript. The repository — which has over 5,300 stars on GitHub — has been substantially updated and the primary language across samples is now TypeScript rather than plain JavaScript. If you're working from a fresh clone today, expect .ts files and a build step rather than the loose JS files described in older guides.
• FriendlyEats-web is a separate repository. The friendlyeats-web project now lives in its own dedicated repository (597 stars, last updated May 2026) rather than being a subdirectory of quickstart-js. Clone from there if you want the most current version of the sample.
• The Firebase Local Emulator Suite UI has matured significantly. The Emulator UI is now a first-class part of the Firebase developer workflow, with improved Firestore data visualisation, import/export tooling, and cleaner auth management compared to earlier versions.
• Firebase SDK initialisation has changed. The /__/firebase/init.js?useEmulator=true pattern still works for Hosting-deployed apps, but the modern recommended approach uses the modular SDK with explicit connectFirestoreEmulator(), connectAuthEmulator(), and connectStorageEmulator() calls in your initialisation code. This gives you finer control and works outside of Firebase Hosting too.

With those updates in mind, the rest of this guide follows the same overall approach as the original — renaming and reshaping the quickstart — but with notes where the 2026 reality differs.

Customising the quickstart into a new project

FriendlyEats is written in JavaScript (or TypeScript in the current repo), using Material Design Components and the Firebase SDK. It can feel daunting if you're new to any of these, but it has much of the functionality a Firestore admin app needs — which makes it a far better starting point than a blank canvas. Modifying it is also a practical way to understand how it fits together.

You probably don't need to rename every single FriendlyEats reference, but doing so forces you to read the code carefully and understand what each piece does. That's worth the time early in a project.

License

quickstart-js is licensed under the Apache License 2.0. You can modify it and use the result in commercial work, provided you comply with the licence terms noted in the GitHub repository.

Project files

In the current TypeScript version of the quickstart, you'll find TypeScript source files rather than the loose .js files from earlier versions. The structure includes compiled output, a package.json, an index.html, some CSS, and configuration files. The renaming steps below apply regardless of whether you're working from an older JS clone or the current TS version — just adjust the file extensions accordingly.

package.json

package.json records important metadata about the project. Update the name, version, and description to reflect your new project:

"name": "yellowgreen",
"version": "0.0.1",
"description": "YellowGreen Firebase Web Admin",

package-lock.json

package-lock.json is automatically generated whenever npm modifies the node_modules tree or package.json. According to the npm documentation, it describes the exact dependency tree that was generated so that subsequent installs produce identical results regardless of intermediate dependency updates. Update the name and version to match your package.json:

"name": "yellowgreen",
"version": "0.0.1",

manifest.json

The web app manifest provides the metadata a browser needs to present your app as an installable PWA — name, icons, theme colour, display mode, and so on. Update it to reflect your project:

{
  "name": "YellowGreen",
  "short_name": "YellowGreen",
  "start_url": "/",
  "display": "standalone",
  "orientation": "portrait",
  "icons": [{
    "src": "images/icons/yellowgreen-192x192.png",
    "sizes": "192x192",
    "type": "image/png"
  }],
  "theme_color": "#567f17"
}

index.html

Update the <title>, swap out the restaurant-specific imagery, change colour references to your brand colour (#567f17 in this case), and hunt down every reference to FriendlyEats and replace it with your project name. The four scripts — now renamed YellowGreen.Data.js, YellowGreen.View.js, YellowGreen.Mock.js, and YellowGreen.js — need updating here too.

There are two references to "restaurants" in the original: one is an element id, the other is display text. Neither is relevant to a territories-based admin app, so both become "territories". The corresponding id="no-territories" reference lives in YellowGreen.View.js and needs updating there.

The original quickstart includes a div with id="guy-container" holding a placeholder image. Replace the image with something appropriate for your project and rename the container to something generic — image-container works well — updating all references in both main.css and index.html.

Connecting to the Firebase Local Emulator Suite

Up to this point the app runs locally against the live Firestore database. Before experimenting with data structures or security rules, it makes sense to switch to the Firebase Local Emulator Suite. This lets you read, write, and break things freely without any risk to production data.

Initialise the emulators for your project

From your project directory, run firebase init emulators and select Authentication, Firestore, and Hosting when prompted:

% firebase init emulators

     ######## #### ########  ######## ########     ###     ######  ########
     ##        ##  ##     ## ##       ##     ##  ##   ##  ##       ##
     ######    ##  ########  ######   ########  #########  ######  ######
     ##        ##  ##    ##  ##       ##     ## ##     ##       ## ##
     ##       #### ##     ## ######## ########  ##     ##  ######  ########

You're about to initialize a Firebase project in this directory:

  /Users/.../.../.../firestore-admin

=== Emulators Setup
? Which Firebase emulators do you want to set up? Authentication Emulator, Firestore Emulator, Hosting Emulator
? Which port do you want to use for the auth emulator? 9099
? Which port do you want to use for the firestore emulator? 8080
? Which port do you want to use for the hosting emulator? 5000
? Would you like to enable the Emulator UI? Yes
? Which port do you want to use for the Emulator UI (leave empty to use any available port)?
? Would you like to download the emulators now? Yes

i  Writing configuration info to firebase.json...
i  Writing project information to .firebaserc...

✔  Firebase initialization complete!
%

Connecting your app to the emulators

The older approach — appending ?useEmulator=true to the hosted init script — still works when your app is served via Firebase Hosting. However, the current recommended approach uses the modular Firebase SDK with explicit emulator connection calls. This works in any environment, not just Firebase Hosting, and makes it much clearer in your code exactly what is and isn't emulated.

In your Firebase initialisation file, add the following after initialising each service:

import { getFirestore, connectFirestoreEmulator } from 'firebase/firestore';
import { getAuth, connectAuthEmulator } from 'firebase/auth';

const db = getFirestore(app);
const auth = getAuth(app);

if (location.hostname === 'localhost') {
  connectFirestoreEmulator(db, 'localhost', 8080);
  connectAuthEmulator(auth, 'http://localhost:9099');
}

The location.hostname === 'localhost' guard ensures the emulator connections are only made during local development — your production build will talk to the real Firebase services as normal.

If you prefer to keep the older hosted init script approach for a quick prototype, it remains valid:

<script src="/__/firebase/init.js?useEmulator=true"></script>

Starting the emulators

Start everything with firebase emulators:start. Your app will connect to the local auth, Firestore, and hosting emulators. Open the Emulator UI (by default at http://localhost:4000) to confirm the services are running and to inspect data, manage users, and review security rule evaluations in real time.

Reflections

The FriendlyEats quickstart — now living in the actively maintained friendlyeats-web repository — remains a solid foundation for a Firestore-backed web app in 2026. The shift to TypeScript in the broader quickstart-js project adds a small amount of tooling overhead, but also brings better IDE support and clearer type contracts as your data model grows.

In the end I didn't continue down this path for the admin app — the requirements evolved in a direction that made a different approach more practical. But working through these modifications gave me a clear mental model of how the Firebase SDK, the emulator suite, and a modular web app fit together, and that understanding has been useful ever since.