The tech stack chosen for this guide was selected for its capabilities, efficiency, and robustness. This tech stack is both minimal/compact and extremely powerful. It will enable you to build your web application quickly and to iterate on it as the needs of your application change.

This guide is intended to get you up and running quickly and to set up your project for fast iteration. With that said, it is a wise idea to do some amount of planning before you actually start coding. This will ultimately improve your development efficiency over the course of your project.

Take a moment to write out some bullet points about what your application is required to do in order to be complete. Jot down some of the data that you’ll need to save and think about how you might structure it. Maybe even sketch out a few screens for how users will interact with your application.

This doesn’t have to be anything formal. Just spend a little time to make a few notes that you can refer back to as you develop your project.

To get started, let’s first install React with TypeScript. You can find the instructions for this on the React documentation, but the command should be something like this:

yarn create react-app my-app --template typescript

Whenever I create a new React application, I always run the default project just to make sure everything is working properly and give myself a good baseline to work with. Once you’ve verified that your React app is working, add Firebase to your project.

yarn add firebase

Finally, we are going to add react-router-dom to help us with managing the screen navigation.

yarn add react-router-dom

Run the application again to ensure that everything is still working as expected.

Next, go to the Firebase website and set up a new project for your application. You should be given a JSON object with your API Key and some other information. Make a note of this because we will be saving this to a file soon.

The following structure is how I like to organize my code files for most projects. This is simply a suggestion, and you are free to make whatever adjustments you think will work best for you. Please note that some files have been omitted from this diagram for simplicity. In reality, you will have additional files like package.json and folders like /node_modules.

You’ll notice that I added a TestScreen.ts in the project structure. This TestScreen won’t make it to the final production build of your application, but when first starting out, this is a great way to experiment with code. Think of it as a canvas that you can use to try out whatever you want.

I typically use it to design new components. I will build out my component on the TestScreen to get it close to how I want it to look, then store it away in my /components directory to use later.

Another advantage of this screen is that we can easily configure it to be the first screen that appears when we launch our application or refresh it. That way, if we make a change and end up needing to refresh, we don’t have to click through multiple pages to get to the screen we want.

Your application will very likely need to save some information about the user. You’ll likely want to store their email address in case you need to send emails to certain users at some point. Go ahead and create a new interface called IUser to store some data you think you’re going to need for each user.

You will probably need additional data types depending on what your application does, so go ahead and add some additional interfaces in your models.ts file to cover whatever data you think you’re going to need. Remember, this is just an initial attempt and you will come back and make adjustments to this as you build out your application.

For efficiency, you may want to "flatten" your data structure. This means rather than nesting things under one node, you spread it out (or "flatten") it across several nodes.

For example, if you are building a note-taking app, rather than having a structure like this:

Consider putting the note contents in a separate node and only referencing the IDs from your /users node. This way, if you need to pull data about a user, you aren’t forced to download the contents of every single note. This can make loading data faster.

Now, when you grab a user’s node, you get the IDs of all the notes belonging to that user and can perform another query specifically for that node within /notes. If a user creates a new note, you add the data to /notes and the ID to /users/notes/{id}. If a user deletes a note, you do something similar.

In this chapter we will define a pattern for creating React components using TypeScript. Our component will provide standard TypeScript type-checking. We will create two components: One to view an instance of a TypeScript class and one to edit an instance of that class.

To demonstrate, suppose we have the following TypeScript interface:

Let’s start with the View component and create the following skeleton component:

Here we have a simple ReactJS component. We import the IUser interface from the /models folder and we also import the styles for this component. For this component, we’d like to pass in an IUser object in the following way:

To arrange this in our component, let’s define a new type: 

We can now template our component so that it expects a property named user of type IUser. This allows us to get compile-time type checking on our component. We’ll also display some of the IUser data. Our updated component looks like this:

We can also include a CSS file, which is optional if you’d like to use CSS to manage your styles:

For the edit component, we will start with the UserView as a template, but add a few things to make it editable.

We want users of the component to receive an event whenever the user’s email changes and provide them with the updated email address. Users will pass their event handler via a property so we will update our Props interface to include this event handler:

Next, we will swap out the <p> element that we used to display the email with an <input> element that we can use to edit the property. Our UserEdit component looks like this:

We can then update our user object like this:

Now, test your components. Open your Test Screen and import the IUser interface as well as the two components you’ve created:

Create an IUser object and assign it to your application’s state (here, we have created a concrete User class that implements IUser:

Add the two components to your UI:

The first component should show you the values in your User object. The second component will allow you to update them in real-time. You should notice that as you change the email in UserEdit, that UserView will also update, confirming that your components are working properly.

When you start a new project, you have an idea of what functionality it needs because that functionality is what defines your project. It’s useful to try to break down all of the functional pieces into methods and try to define the inputs and the outputs (also known as the interface). We can define these in "stub functions", which are just empty functions that simply define the interface of the functionality we need.

Suppose we’re developing an application that tracks the gas mileage for vehicles. At a minimum, we’ll need something to calculate the gas mileage, so let’s start with that. As our application becomes more defined, we can continue adding functions to this module. For example, as we add additional pages, we might discover functionality needed by those pages and we can add that here.

We can imagine that elsewhere in our application, we will receive data about how many miles were driven and how many gallons of gas were used (perhaps from a database), and rather than performing these calculations from within our screens or components, we can call this API and keep that logic seperate from our UI.

We use the marker TODO: to mark that the functionality is incomplete. Many IDEs have a way to search for this marker, but if not, it’s easy and unique enough to search for yourself.

In the example above, we exported functions. Consuming code can then import those functions and use them as needed. Another option would be to export a class containing static functions. For example:

Although it’s very likely we will end up with a Vehicle class in our code, and we may wish to call something like vehicle.getAverageGasMileage(), I recommend sticking to these kind of non-object-based functions because in many cases, we will be loading objects from our database and when loaded, they will contain only the data and not the associated functions.

For instance, our code may end up looking something like this:

When we load the vehicle from our database, all we have is a JSON object contianing data, not an actual instance of a Vehicle class.

Firebase allows us to easily and conveniently interact with the database from the client. Although Firebase has a great API, I find it useful to add an additional layer on top of that. This additional layer allows us to add typings to our inputs and outputs, and can help to abstract the data model a bit and prevent us from having to remember its exact structure.

For example, suppose our data structure consists of an array of times that the user has filled up the gas in their vehicle. Let’s say it stores the date, the number of gallons they put into the vehicle, how much it cost, and what their vehicle’s current mileage is.

Using the default Firebase API, we can grab the gasFillups data by calling:

Every screen that needs to get gas mileage can simply call that chain of functions to get the data. The problem is that this is extremely difficult to remember. It’s also really long, at risk of having typos, and would require each screen to import firebase.

Instead, let’s wrap this in a more compact function that our screens can import. This will give us the benefit of type-checking.

Now our screens can simply import the getGasFillups method. Think of the benefits we are getting from this:

I personally like to store functions like the ones in the previous section in a Firebase folder. I also like to separate functions that read data from functions that write data. I find this helps me to organize my code a little better, but you can stick with whatever style works for you. I would probably put this in a file called /model/Firebase/Read.ts.

In my /model/Firebase folder, I will also have a file called index.ts that will handle exporting all the modules in that folder:

And I would do something similar in the /models folder:

In the end, your folder structure would look something like this, with each index.ts file exporting whatever folders or files are in the same directory as itself:

The reason I like this organization is because then in my client modules (screens, components, etc.), I can use it like this:

I personally like accessing the functions in this way, but like I said, feel free to organize the code in whatever style is best for you.

There’s a good chance that you’ll want to share some of this functionality with your server. For example, maybe you want to do some computations on a nightly schedule and you need to load the data from the database. If you keep your UI sufficiently separate from your logical functionality, you should be able to easily copy these functions into your server repository and reuse them.

There are other ways of sharing the functionality between your frontend and backend. For example, you could create an NPM package in a separate repository and install it in both your frontend and backend. Personally, I just stick to copy-and-pasting the code between the two. It’s not ideal, but it’s easy and it works.

If your application requires users to login and to save data specific to each user, then you will need some type of user authentication functionality. Fortunately, Firebase has excellent support for user authentication, so we won’t need to spend a lot of time building out this kind of thing and we can spend more time on our actual application.

Below is a list of some of the basic features that any user-authenticated application should have:

Firebase supports several types of user authentication, including Google, Twitter, and Github. However, for the purposes of this guide, we will focus on simple email/password authentication.

The Firebase library has great functions for managing user authentication workflows. I personally prefer to create my own simple wrapper for these APIs. The reasons for this are:

To begin, let’s create a file for all the basic functionality that was listed above. Since these actions will require going to the Firebase server, we want them all to return Promises so we can wait until they have completed.

We now have a class that we can import into our screens and access the set of functions to assist with our user authentication workflows. We will return to this module in later sections and make adjustments and additions to it.

You’ll see that the functions pretty much mirror the Firebase API. In fact, some of the functions are a single line of code and simply call a Firebase API of the same name, so you may be wondering why we need this module at all. If you have this feeling, let me give you a few reasons why you might want to use this.

Simplicity and Code Reuse To start off with, maybe you have a Create Account page where users will create their accounts. You’ll probably have a button that creates an account whenever the user clicks it. So maybe in that button’s onClick event, you can call firebase.auth().createUserWithEmailAndPassword(…​). After all, it’s only a few lines of code.

Although it’s not much code, you still need to handle other tasks, such as cases where the user couldn’t be created, sending a verification email, etc. So wouldn’t it be much simpler to just call Auth.signInWithEmailAndPassword(email, password)? Then you don’t need to clutter up your nice Create Account page with all the minutiae of creating an account.

Additionally, what if you allow a user to create an account from another page at some point in the future? You wouldn’t want to have to copy all that stuff (null checks, verification emails) into multiple places and then change that code in multiple places if you need to adjust the functionality in the future.

Additional Functionality Suppose you want to add functionality on top of the basic stuff that we’ve implemented above. For example, suppose whenever a user creates an account, you want to store off some meta-data about that user (a task that we will cover in later sections). Having your logic contained within this module will make that easier to manage and will ensure that all places where a user gets created are handled the same way.

Portability If you want to use the same functionality in a new application that you’re developing, it’s easier to just copy over a single file (Auth.ts) rather than extracting all of that functionality from various pages/components that you’ve created.

Now that we’ve created a module (Auth.ts) for managing the basic user authentication tasks, let’s utilize that to create a basic login page.

Notes on this screen:

The Signup page will be very similar to the Login page, only we will be calling createUserWithEmailAndPassword instead. You may also want to implement some password strength requirements, or require the user to type their password twice to avoid typos.

The Forgot Password page is also very simple and you can copy the LoginScreen to get started and make adjustments. In this page, we will be calling sendPasswordResetEmail.

Now that we have our navigation routers, we need to switch them based on the user’s authentication state. Firebase will provide us with an event that fires whenever the user’s authentication state changes and we can use that to switch our navigation router.

In our App.tsx file, we will update it to look like this:

Now, whenver the user’s authentication state changes (if they log in or log out), we re-render and show the corresponding navigator.

To link to other pages, we can use props.history such as in this link to the Login page:

Our Firebase backend will be a separate project, so all of the code will be stored in the /server directory that we created earlier (no longer in the /website directory).

Follow the instructions on the Firebase website to install and configure a new project.

You’ll first need to install the CLI using npm install -g firebase-tools.

Then, navigate to your /server directory, use firebase login to login, and then initialize the project using firebase init and selecting the features that you want.

A Firebase Function might look something like this

We can then call this function from our client code like this

We can pass data into these functions and return data back from them. And just like that, we have a backend API that we can call from our client code!

When users are created or deleted, you may want to perform certain tasks, such as initializing or clearing out nodes in the database.

For example, when a user is deleted, we’d like to clear out all the information about that user from the database. We can accomplish this using Firebase Authentication Triggers.

Suppose we have a /users/[uid] node in our database that stores information about each of our users. When a user’s account has been deleted, we want to clear out this entire node.

In your Firebase Functions file, create a function for the onDelete event:

If you have user data stored in other locations (for example, in the image above, maybe userRecords points to other nodes in the database), then you’ll want to update your function to clear out everything.

Note: You can also create a trigger for the creation of a user. This could be useful if you want to initialize the user node with default values. However, I typically do my initialization from the client because when users are signing up to create a new account, I like to ask them for additional information (such as their first and last name) and that information would not be available to an authentication trigger.

Sometimes, you may want to run code on a specified schedule.

For example, you may want to perform cleanup tasks each night at midnight. Or, maybe you want to grab data from an external source on a periodic interval. This is sometimes referred to as a Scheduled Task or a Cron Job.

Suppose we want to update the myData node in our database every night at midnight. We also want to store the time at which it was updated, just in case there was a failure.

In your Firebase Functions file, create a function for the pubsub.schedule.onRun event:

Note: The 0 0 * * * portion is Unix Crontab syntax used to specify what time the function should run. You can read more about this yourself, but in the above example, the first two 0`s refer to which minute and hour on which to run the function. The next three `*`s specify the `day of month, month, and day of week on which to run the function, however because we have a *, that means it should run on all possible days.

Often, you’ll need to get data from external domains. Perhaps you need to scrape some data from a public website. This is not usually possible on the client, but on the server, we can do it using the cors library.

First, you’ll have to install cors and then import it into your functions module:

Then wrap your request inside of a cors call.

Sometimes you don’t want to deploy your Firebase Functions just to test them. It’s time consuming to wait for them to be deployed only to find out that you made an error.

Testing them "locally" (meaning on localhost) involves these steps:

After making a change to a Firebase Function,

In Firebase, database security is setup via a JSON object that defines the database rules. You configure the rules by setting properties of nodes in your database to true or false depending on what kind of access they should have (read access, write access, or no access). By default, all nodes will be given no access.

Suppose our database looks like the following.

We have a users node where each child is the UID of the user. Within that node, we have all of the user’s data (name, email, user-generated content). We want to make sure that each user has access to read and modify their own node, but not the nodes of other users.

We can accomplish this by setting up our database rules like so:

This sets the .read and .write access to true only for the users node corresponding to the authenticated user’s UID (auth.uid).

Firebase provides an extension (Trigger Email) that makes it really easy to send emails from a Firebase Function.

The way it works is that you add a document containing the email contents to a collection in the Firestore and then Firebase will trigger a 3rd-Party email provider to send our your email.

You can use this feature to send users emails when specific events occur, or you can combine it with the pubsub scheduler to send emails on a periodic schedule.

In this article, we will use SendGrid as our 3rd-Party email provider.

Stripe is a payment provider that makes it really easy to integrate payments into your application. A quick summary will be provided here, but you should consult the most up-to-date documentation on the Stripe website.

The first step to deploying your website is to build it. The build process will minify all of your code and prepare it to be placed on a web server for hosting.

Building is as simple as running a build script: yarn build.

Once you have built the website, the files will be generated in a /build directory. All you need to do is copy them into your web server and you’re good to go!

INFO: Firebase does provide a hosting service, so you can also host your website directly from Firebase.

The first thing we’re going to do is go to Github and create a new repository for the project. This is quick and easy to do and we’re going to do it now so that we will always have it ready whenever we’re ready to save our code. We’ll use the default README.md to take notes of things as we’re doing development.

Check out this branch locally on your computer by running git clone <url>.

Now head over to the Firebase website and create a new project.

Click the "Web" button and follow the steps and you should be given a JSON object with your Firebase configuration. Make a note of that, as we will be using it soon.

Let’s take a moment to think about what our application requirements are. These don’t need to be final, but they will give us a concrete starting point to work towards on our first iteration. We’ve already got an idea in our heads, but let’s transcribe it to bullet points now.

Our app must…​

Go into your project folder and setup the folders as demonstrated in the Project Structure chapter in the guide.

You’ll see there are a few additional files that were added by the create react-app script that we ran. You can ignore these for now.

Paste the JSON object from the Firebase website into the ApiKeys.js file. Your file should be formatted like the following, but the data should be set to the values from your Firebase project.

Create a TestScreen.tsx file that we will use as a sort of scratch pad to test things out during development.

Even though TestScreen.tsx is meant to be a screen, we can treat it like a component. Let’s display it in our App.tsx page so that it shows up as soon as we launch our app. This will make development a little faster because we’re going to add to that Test Screen as we build components and see how they look.

To add TestScreen, first import it and then display it like you would any component. Let’s also delete all the other stuff in App.tsx since we won’t need it. While we’re at it, let’s go ahead and delete all the styles out of App.css as well.

Save and your application should automatically refresh and if your app looks like this, then it worked!

Now that you have a basic application setup with a Test Screen that you can use to try things out, it seems like a good idea to commit your code to Github to take a "snapshot" that you can always revert back to if needed.

We will start by building a view component for our GasFillup data, which is the simpler of the two. In our /components directory, let’s create a GasFillupView.tsx file.

We add the "GasFIllupView-container" class so we can add styles to our component, and in App.css, let’s add some basic styling.

We can try out our component by displaying it in our TestScreen.tsx. There are a few things we’ll need to do to get this working.

TestScreen.tsx should now look something like this

And when we look at the output in our browser, it should look like this:

It’s not the most beautiful component in the world, but it gets the job done (displays the data in our object), so we can use it and clean it up later. Since we’ve already created a component for it, it will be really easy for us to find the component (since it’s in our /components folder) and update the styling for it, which should apply across our entire application as long as we use this component any time we want to display a GasFillup object.

Remember: We are aiming for a balance between quick iteration and organized structure.

Now we’ll build a component that will allow us to edit a GasFillup object. This will be slightly more complex than creating GasFillupView.tsx, but we will follow the same procedure.

Let’s create the GasFillupEdit.tsx component inside our /components directory. To make your development even faster, you could just copy GasFillupView.tsx and rename everything to GasFillupEdit.

This is quite a bit more code! But if you read through it, you’ll see that much of it is just boilerplate code for listening to onChange events on <input> elements.

A few notes on this component:

Let’s add some styles to our App.css file to make the component look a little bit better.

Finally, we’ll display it in our TestScreen by importing it and then rendering it. For the events, we will just update our state object according to which propery was changed.

And our TestScreen should now look similar to the image below. Note that as we make changes to the data in our edit component, the view component is updated to reflect those changes since they are both using the same state instance of GasFillup.

Within our /model directory, let’s create a new directory called /GasMileageTracker and then inside of that, we will make a file called Util.ts that will hold our utility functions. These are the functions that will do some calculations that we determined during our initial planning would be needed by our application.

In our case, we want to provide our current GasFillup and our previous GasFillup and calculate the gas mileage we got on our most recent tank of gas. We need the previous GasFillup so we can determine what the mileage was at that time, and with the current GasFillup, we can see how many miles we’ve driven since then as well as how much gas we put into the tank, which will tell us how much gas we’ve used since the last fillup (assuming we always fully fill the tank).

If the logic of these functions (in our case, just one function for now) is too complicated, it is acceptable to simply create the stub functions and come back and actually implement them later. This is similar to how we created really bare components and will come back and clean them up later. The point is to setup our infrastructure early so our application is easy to work with as it becomes more complex. The gas mileage calculation isn’t particularly complex, so we will go ahead and implement it now so we don’t need to jump around to different files in this guide.

Now we will add some functions that allow us to read and write to the database. We will stick with the basic CRUD functionality, which stands for Create, Read, Update, Delete. Those will all be useful functions that users will likely need to do.

Let’s start by adding a directory in /model/GasMileageTracker called /Firebase. Within that directory, let’s add two files called Read.ts and Write.ts. I personally like to separate my read and write modules so it’s more clear to me when I read my code if I am actually manipulating the database (writing to it), but once again: feel free to organize the code however you’d like.

We will add the stub functionality for now and then go back and update our code later.

Let’s also add index.ts files in our directories to make importing the functionality from our components and screens more easy.

The way that we’d like to use the functionality from a screen, for example, is something like this:

We can accomplish this by exporting our modules in the index.ts files as shown below. Whenever we add a new file, we’ll have to remember to update the index.ts files.

Note that Util is actually a file and Firebase is a directory. That’s ok. The syntax will remain the same. When you specify a directory, the system will search for the index.ts file in that directory.

We will see soon in practice how this will make importing and using these modules much easier.

To summarize, you should now have a folder structure that looks something like this:

We will add a new file, Auth.ts in our /model/Firebase directory and we can just copy the code directly from the guide. This API will allow us to perform the basic functionality of signing users in, signing them out, and creating new accounts, among other things. By putting this in a dedicated module, it makes it easier for us to add more functionality on top of those actions. For example, after a user creates an account, we may want to perform additional tasks.

And don’t forget to update the index.ts file to export Auth.

In our /screens directory, let’s create an additional directory called /auth to store all of our auth screens (Login, Signup, etc.).

For the login screen, we can just copy the LoginScreen from the guide with minimal changes.

The SignupScreen will be very similar to the LoginScreen.

The ForgotPasswordScreen will be very similar to the LoginScreen.

For convenience, we can export all of these screens from the /screens/index.ts file.

Back in App.tsx, we will listen for authentication state changes and switch our router accordingly. The onAuthStateChanged event will fire when a user creates an account, signs in, signs out, etc.

Now that everything is setup, we just need to add links to the various pages so we can navigate to them. A menu bar would be great, but until then, we can just add simple links in our TestScreen. We can link to a page like this.