This is the seventh post in a series of posts which will illuminate my journey to becoming a Full-Stack JavaScript Developer. Read the first one here.

Recap

My plan is to progressively enhance the app into a fully complete app, allowing me to step-by-step learn important principles of development without overwhelming myself while at the same time practice my learning by applying them to a real app.

JavaScript the Dynamic Language

JavaScript is considered to be a weakly-typed, dynamic language. A dynamic language refers to the way variables and functions are initialized while a weakly-typed language has “looser typing rules and may produce unpredictable results or may perform implicit type conversion at runtime”.

When you declare a variable in JavaScript, you don’t need to state the variable type, it’s implicitly determined by the programming language. What’s more, the variable type can change based on reassignment.

An Example

Let’s say I have built a shopping cart app in JS and the app has a variable named price to record the cost of a single product. I need to not only be able to record and display this price but perform math operations with it(sum up the prices to make a Shopping Cart total, for instance).

When I first initialize the price variable I set it to a floating point number value of 9.99. I did not specify that it was a floating point number; JavaScript figured that out for me.

Later on, I need to display this price on the front-end and I hastily enter the price as a string of text. The JavaScript engine says, Cool, I guess this is a string now.

Why would I do this? Perhaps I need to prepend the currency symbol($) to the price and I can’t do that with a number.

var price = 9.99
console.log(typeof(price))  // number
price = "$9.99"
console.log(typeof(price))  // string

The Problem

Now if I try to perform math operations on the price it’s going to fail as it’s now a string.

This super simple example should hopefully illustrate one of the pitfalls of a dynamic language and this type of implicit type conversion is one of the biggest causes of bugs in dynamic language applications.

Sure, it’s easy enough to notice the bug in our example but imagine the application has dozens of files and thousands of lines of code. Keeping track of all of the variables and their types in your head becomes impossible so it would be nice to have a tool that helped avoid the aforementioned pitfall.

A Possible Solution

Typescript is a superset of the JavaScript language which offers things like static checking and code refactoring when developing JavaScript applications. When you write Typescript it is later compiled into clean JavaScript code.

Basically, it makes your JavaScript look like more like a strongly-typed and static language resembling something more like Java or C#.

New Projects

There isn’t a single initialization command for adding Typescript to your React Native app, however, specific instructions can be found here. I won’t bother going through them in this post. I can say that it was relatively easy and took just a few minutes.

The Plan

The nice thing about Typescript is that we don’t have to convert the entire project immediately to Typescript in order for our app to run. We can convert one file at a time into Typescript and slowly clean up our app in a measured fashion.

What’s more, Typescript files can be just plain JavaScript, meaning that we could simply rename our .JS(or .JSX) files into .TS(or .TSX) and they would compile fine without actually adding any Typescript.

With that in mind, we can convert our app piece by piece(or atleast, the major components) to Typescript at our own pace. We’ll start with the main entry path to the app, App.js.

App.js

The first thing to do is to rename the file to App.tsx. Technically, Typescript uses .ts as the file extension but we’re using some type hinting here to indicate that we’re not writing pure JS but JSX. It’s the same reason that we would previously have our file named App.jsx.

Interfaces

If you do nothing else other than apply interfaces to your React components you would still be improving your React code quite a bit.

An interface is like a predefined shape for a structure which says, this is how this thing should look. We determine beforehand the logical shape of this structure so that it is stable. If we fail to build our structure to match the shape of the interface we will get an error. If we try to change the shape of the structure later we will get an error.

The two things you absolutely need to apply interfaces to are a component’s state and props. Here’s a super easy example from the main App.tsx file:

interface State {
  isLoadingComplete: boolean
}

interface Props {}

export default class App extends React.Component<Props, State> {
  state = {
    isLoadingComplete: false,
  }
}

My main App file has just a single piece of state which tracks whether or not loading is complete. If it’s not finished loading a loading spinner component is rendered; if it’s finished loading the rest of the app is rendered.

It doesn’t have any props.

What we’ve done in the example above is set the shape of our props and state for our App component. The following will cause an error in our IDE if we fail to maintain that shape:

• If we pass any props to this component(because none are declared in the interface).
• If we declare any new props on the state object other than isLoadingComplete.
• If we change isLoadingComplete to anything other than boolean.
• Leaving out any piece of the interface object when passing props to the component(if the Props object was not empty).
• If any piece of the Props interface did not match the declared variable type(again, if the Props object was not empty).

It’s Just a Tool

One thing to keep in mind with Typescript is that it will still compile your code into JavaScript if it catches errors. If there are no actual JavaScript errors the code will still run; TypeScript doesn’t prevent compiling your app if you leave out a prop or mutate a piece of state. It’s meant to warn you of potential issues with your code.

Typescript is really a helper tool for development teams to write better code by providing warnings when our code is not taking the shape we initially agreed it would or when we return a different variable type from a function than we initially said we would. It helps us understand our code better and know what our variables should be and how our functions should act.

There are too many files that need to be converted in this app to go over here but the idea is generally the same for all of the files:

• Create interfaces for our Props and State.
• Assign a type to our variables.
• Specify the return type for our functions.

Next

In order to speed up this app as well as add some offline compatibility we’ll be adding some sort of caching to the app in the next blog post.

In the previous post we built a database sanitization function but how do we know it works other than testing directly in the app and looking at the database? We can actually do this with Unit Tests.

In computer programming, unit testing is a software testing method by which individual units of source code, sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures, are tested to determine whether they are fit for use.

https://en.wikipedia.org/wiki/Unit_testing

The important bit about Unit Tests is that they should test functionality independent of external systems. This means that this app’s unit tests should only test the self-contained functions within it and not test any functions that interact with my database or with the Auth system(anything to do with Firebase, really).

Testing functionality which integrates with external systems does have its purpose, however, that would fall under integration testing.

Jest

I’m going to be using Jest for unit testing here. Jest is an open-source testing framework created by Facebook with the help of many other contributors. It’s widely used by a number of giant tech companies to quickly and easily set up JavaScript unit tests.

Since I will be performing unit tests while developing, I’ll want to make sure to only install it as a devDependency:

npm install --save-dev jest

In other words, we don’t want Jest to be a dependency in the production environment.

A Gotcha

It’s important to remember that you should be exporting the functions you are testing in your app as modules and then importing them into your tests. I have caught myself simply copying and pasting the functions from my production code into my tests, which is wrong. Not only is it not DRY but if I change those functions in my production code the tests will not reflect those changes.

In my /functions/src/index.js file I have a function which strips HTML from each of the values of the properties of an object. I export it to make it available outside of this file.

exports.stripHtmlFromObj = ( data ) => {
    for (const prop in data) {
        data[prop] = sanitizeData(data[prop])
    }
    return data
}

Importing this function into my test.js file is as simple as this:

const { stripHtmlFromObj } = require('../functions/src/index.js')

The reason we import it between a set of curly braces is because importing the file by itself imports one big object with all of the available functions and variables that were exported from that file. We are using object destructuring to only grab the stripHtmlFromObj() function.

An Example

We created a function that would sanitize input data before it is sent to the server. It works by stripping out HTML from raw text. The main inputs we have in our app are the inputs used when adding a new contact to the app. Sounds like a good thing to test.

First, let’s try to describe what a test would do in plain English.

• Import our own sanitization function so we can use it in our test.
• Create an example data object that would represent a contact.
• Add some HTML to the data object string values.
• Write tests to check if the HTML is stripped when passed through our own sanitization function.
• We expect that when we pass a string with HTML through the sanitization function that we return a string minus the HTML.

If I pass the following for Last Name:

"lastName": "<script>alert('you are screwed');</script>Shellberg"

It should strip out HTML tags from the contact.

I expect the resulting lastName property to equal “Shellberg”.

The bold portions of that last sentence are not a random style choice; we effectively just wrote a Jest unit test expectation. 🙂

The Code

Here’s an excerpt of the contacts.test.js file which tests functions that manipulate/read contact data:

const { stripHtmlFromObj } = require('../functions/src/')

describe( 'sanitize HTML inputs', () => {

    const data = {
        "id": 1,
        "firstName": "<strong>Thomas</strong>",
        "lastName": "<script>alert('you are screwed');</script>Shellberg",
        "birthday": "Sat May 25 2019 12:34:33 GMT+0200 (Central European Summer Time)",
        "phone": "(480)555-5555",
        "email": "greg@gregerson.com",
        "address": "21 Main St., Phoenix, 85224, Arizona"
    }

    it('should strip out HTML tags from contact', () => {
        const strippedData = stripHtmlFromObj(data)
        expect(strippedData.firstName).toEqual('Thomas')
    })

    it('should strip out HTML script tags from contact', () => {
        const strippedData = stripHtmlFromObj(data)
        expect(strippedData.lastName).toEqual('Shellberg')
    })

    it('should leave birthday string intact', () => {
        const strippedData = stripHtmlFromObj(data)
        expect(strippedData.birthday).toEqual("Sat May 25 2019 12:34:33 GMT+0200 (Central European Summer Time)")
    })

    it( 'should leave phone number intact', () => {
        const strippedData = stripHtmlFromObj(data)
        expect(strippedData.phone).toEqual("(480)555-5555")
    } )
})

Test Result

Parting Thoughts

We want to remember that unit tests should test functionality independent of external systems. This means that this app’s unit tests should only test the self-contained functions within it and not test any functions that interact with Firebase.

When writing a unit test, a best practice is to write a test for every possible code route. Let’s say you have a function with an if{} else{} statement which diverts the function into two directions of flow. You should write a test for each of those routes.

In this case we don’t have that sort of code diversion but we do have multiple ways that data could be entered. Since we know that we want to test HTML being sanitized from our data string, it’s easy to only write tests in which all of the data is dirty. We have to remember to also test clean(no HTML) data.

Therefore, since our data object contains 6 properties, we should probably write at least 12 unit tests here(6 properties that are dirty, 6 that are already clean).

I’ll be refactoring this code to actually put it into two different suites; one for “dirty” inputs and another for “clean” inputs.

Unit testing React Native apps is not easy as the separation between pure functions and interactivity can be a gray area, however, we should do our best to unit test our pure functions with Jest and use additional testing libraries for integration testing or end-to-end testing.

Next

The next post of this series will be one of the easiest; we’ll be adding Typescript to the project and slowly converting some of our code to Typescript.

Is Validation Enough?

Since my app is a serverless app, the validation performed on Step 2 is only client-side validation. While this does improve the user experience and helps prevent incorrect information from being entered into the app database, it does not protect against malicious attacks against my database.

Client side security is not security.

– some random person on Reddit

The Conundrum

We know that we need to do some validation/sanitization on the server side, but we don’t have a server. How is this possible?

Enter Firebase Cloud Functions. From the Firebase docs:

Cloud Functions for Firebase lets you automatically run backend code in response to events triggered by Firebase features and HTTPS requests. Your code is stored in Google’s cloud and runs in a managed environment. There’s no need to manage and scale your own servers.

When I first read about Cloud Functions I actually imagined that you would write all of your code using a browser-based GUI or something; I was having a tough time determining how exactly you would write this server-side code. As it turns out, you write all of the code within your own app and then deploy it to Google’s servers.

Let’s dive into it and figure it out.

Add the NPM Module

Importing the Cloud Functions module is pretty simple, it’s basically three terminal commands in your project folder:

npm install -g firebase-tools
firebase login
firebase init functions

After performing these steps, there will be a /functions/ folder in the root of the app. Within that folder’s /src/ folder will be an index.js file. This is where the Cloud Functions code will exist.

The Code

import * as functions from 'firebase-functions';
const sanitizeHtml = require('sanitize-html');

const sanitizeData = ( data:any ) => {
    return sanitizeHtml(data, {
        allowedTags: [],
        allowedAttributes: {}
    })
  }

exports.onContactWrite = functions.database.ref(`users/{uid}/contacts/{id}`).onWrite( (change, context) => {
    const data = change.after.val()
    for (const prop in data) {
        data[prop] = sanitizeData(data[prop])
    }
    return change.after.ref.update(data)
  })

  exports.onMeWrite = functions.database.ref(`users/{uid}/me`).onWrite( (change, context) => {
    const data = change.after.val()
    for (const prop in data) {
        data[prop] = sanitizeData(data[prop])
    }
    return change.after.ref.update(data)
  })

That’s pretty much it for that part. I may beef this up later as I learn more but this gets the job done. Data that is sent with HTML tags will get stripped out. Some examples:

What About SQL Injections?

Fair question. I have a database which means I need to protect against SQL Injection attacks, right? What are those, anyway?

SQL injection is a code injection technique, used to attack data-driven applications, in which malicious SQL statements are inserted into an entry field for execution (e.g. to dump the database contents to the attacker).

https://en.wikipedia.org/wiki/SQL_injection

Actually, I don’t.

The Firebase Realtime Database is a NoSQL database environment, meaning that as the developer you are not preparing SQL queries yourself and sending them to the server. Instead, you interact with functions provided by the Firebase codebase which then make writes/reads to the database.

So, the short answer is nah.

Database Permissions

There is, however, a second layer to protecting data within your database, namely, authorization. Put simply, you need to set rules for how users can access and write the data in your database. If you don’t do this, anyone interacting with your app can modify any of the data in your database.

We definitely don’t want that, so, let’s set up some rules. Thankfully, Firebase Realtime Database makes it easy to set some basic rules.

Here’s pretty much as simple as it can get:

{
  "rules": {
    "users": {
      "$uid": {
        ".read": "$uid === auth.uid",
        ".write": "$uid === auth.uid"
      }
    }  
  }
}

This means that within the data contained for a specific user(think back to the hierarchy of our data in the database), that user is only allowed to read and write their own data. Basically, when you are logged into your user account within my app(remember that Auth is powered by Firebase), you can only view and modify the data at or below your user account level.

Larger, more complex apps will for sure need more stringent controls but in my case I think this is sufficient. Technically a user could change anything assigned to their user account which could pose a problem if you stored things like their user privileges, plan data, or renewal dates. If that’s the case, you don’t want people upping their privileges to Admin(if you have user roles) and you definitely don’t want someone changing their renewal date to 50 years from now and getting a free ride to use your app forever.

For the purposes of this simple app, those very simple rules should work, though. As far as I can tell, the worst they could do is spam their own contact data with emojis so I’m fine with that.

Do You Even Test Bro?

You mean, have I written a unit test for this? Why yes, in fact I did, however, Unit Tests are part of Step 4. 🙂

Until next time.

This is the fourth post in a series of posts which will illuminate my journey to becoming a Full-Stack JavaScript Developer. Read the first one here.

Recap

My plan is to progressively enhance the app into a fully complete app, allowing me to step-by-step learn important principles of development without overwhelming myself while at the same time practice my learning by applying them to a real app.

Validation

…data validation is the process of ensuring data have undergone data cleansing to ensure they have data quality, that is, that they are both correct and useful. It uses routines, often called “validation rules” “validation constraints” or “check routines”, that check for correctness, meaningfulness, and security of data that are input to the system.

https://en.wikipedia.org/wiki/Data_validation

Purpose

Our app has a lot of fields that the user needs to interact with – not only do they need to login with an email and password, they need to register, reset their password, and add/modify contact information(name, birthday, email, etc).

We can make the process of interacting with and submitting these fields more friendly and intuitive using validation. For the purposes of this post we’re talking about client-side validation. This encompasses checks that we add into the client-side(the app itself) which provide visual clues as to whether or not data is accurately entered.

Library

I previously used the Joi npm module for data validation in standard React web apps but for this one I decided to give yup a try. Yup is very similar to Joi but it claims to be smaller and a bit easier to use in projects.

How it works

Validation through yup works by creating schemas for your data which define rules for what your data should look like. Let’s take an example for the First Name field in my app.

Schema

const firstNameSchema = yup.string().required().min(2).max(15)

This means that the “First Name” field should be:

• A string(not an object, array, etc).
• Required when submitting the form.
• A minimum of two characters.
• A maximum of fifteen characters.

Validation

The simplest form of validation is just calling the isValid() method on the schema object you defined and pass in the data you want to validate.

firstNameSchema.isValid(text)

In my app, whenever the text input changed for a field(when you started typing or deleting characters) the following would happen:

1. A method named handleTextUpdate() would be called with the value of the text field(the text in the input field) and the prop passed.
2. That method would update the corresponding piece of state with the new value of the text field.
3. It would then call a method to validate that input field, passing in the prop name and the text.

Full Code

This is the JSX responsible for generating the First Name field:

<TextInput 
  error={!this.state.isValidfirstName}
  prop="firstName"
  label="First Name" 
  placeholder={this.state.firstName}
  value={this.state.firstName}
  handleTextUpdate={this.handleTextUpdate}
/>

When text is changed, this.handleTextUpdate is called.

Gotcha: make sure to only write a reference to a function here, don’t include parentheses! Otherwise, the method will be called immediately upon load.

  handleTextUpdate = (text, prop) => {
    this.setState({[prop]: text})
    this.validateField(prop, text) 
  }

This clever bit of code is responsible for handling all of the fields on the screen. The prop name is passed as a string. The text is implicitly passed. The reason [prop] is in brackets is because we want to pass the name of the prop. Read about how that works here.

ValidateField method in full

  validateField = debounce ((prop, text) => {
      switch(prop) {
        case 'firstName':
            firstNameSchema.isValid(text)
            .then( (valid) => this.setState({ isValidfirstName: valid }))
            break
        case 'lastName':
            lastNameSchema.isValid(text)
            .then( (valid) => this.setState({ isValidlastName: valid }))
            break
        case 'address':
            addressSchema.isValid(text)
            .then( (valid) => this.setState({ isValidaddress: valid }))
            break
        case 'phone':
            phoneSchema.isValid(text)
            .then( (valid) => this.setState({ isValidphone: valid }))
            break
        case 'email':
            emailSchema.isValid(text)
            .then( (valid) => this.setState({ isValidemail: valid }))
            break
        default:
            break
      }
  }, 500)

The debounce() before the method parameters is a lodash library function. What this does is prevents the method from being called immediately for every single text input change; it will wait 500 ms after the last call to the function before it actually invokes it.

That might sound confusing at first so I’ll try to explain. When you type into a text field you want React to update state immediately without any delay. This is because the value of that field will be linked to state. You want that value to be “the truth” in the app and thus updated immediately and not prone to bugs or weird laggy behavior.

I do not want validation performed immediately for every single keystroke, though; that would be taxing and annoying. So, instead, the app waits a half second after the user is done typing before the app validates the field.

The debounce() function is great for search fields which automatically perform a search after you stop typing rather than requiring you to hit a submit button.

Result

My custom <TextInput> React component has a prop named error which is responsible for showing and hiding a small icon which is a visual indicator of pass/fail for validation.

If validation fails, a red X icon appears next to the field; if validation passes, a green check-mark icon appears next to the field.

That’s the gist of how I did validation throughout the app. I applied this same validation to the login form, registration form, and password reset form.

UX Improvements

Beyond validation, it’s a good idea when developing a mobile app to try to make entering data as easy as possible. You should dynamically change the keyboard type when possible to make it easier and enjoyable to enter data.

Luckily, this is easily done without any extra libraries or validation; the core TextInput component that ships with React Native has tons of properties that can add hints as to how the field should be interacted with.

The Phone Field

<TextInput    
  textContentType="telephoneNumber"
/>

The textContentType prop hints to the mobile device which type of keyboard to use.

The Email Field

<TextInput 
  autoCorrect={false}
  keyboardType="email-address"
  autoCapitalize='none'
  textContentType="emailAddress"
/>

Here we have some hints that we should not allow autocorrect nor should we automatically capitalize the first letter of the text data. Note that we also have a slightly different keyboard than the standard keyboard(the @ symbol and the .com button).

It can be tedious to go through documentation to find small little tweaks like this but it’s absolutely worth it to help make your app enjoyable to use as well as fast.

Caveat

I said earlier that this was all client-side validation. This does not make the app more secure. It only makes it less likely that users will make mistakes when inputting data as well as provides visual indication of the pass/fail condition of your validation functions.

In the next blog post we’ll talk about server-side validation which improves the security of your app by preventing garbage and malicious input from being sent to your servers.

This is the third post in a series of posts which will illuminate my journey to becoming a Full-Stack JavaScript Developer. Read the first one here.

Recap

My plan is to progressively enhance the app into a fully complete app, allowing me to step-by-step learn important principles of development without overwhelming myself while at the same time practice my learning by applying them to a real app.

App Structure

I mentioned in the previous post that I’m using React Native to build the app itself along with Firebase as the “backend”. I’ll be following as many best practices as I know for organizing my code and assets:

/__tests__/ - contains all of my Jest test suites.
/.expo/ - standard Expo folder.
/assets/ - static files(images mostly).
/components/ - the reusable React components that make up the app.
/constants/ - used for referencing screen dimensions and colors.
/functions/ - houses Firebase Cloud Functions.
/navigation/ - the React Navigation components.
/node_modules/ - all the dependencies of the project.
/screens/ - the screens which React Navigation uses for navigation.

App.tsx is the main entry point of the app. If the file extension confuses you, I’ll explain what it means in a later post. All you need to know is that it will compile to App.js and will be the “root” file of my app.

Database Data

This app will have two major data objects – users and contacts.

A User represents the person that registers and uses the app. This User will have a number of Contacts assigned to their user profile.

A Contact represents a single person which contains their contact information.

The Realtime Database module in Firebase makes this really easy to visualize:

Remember, it’s NoSQL

In contrast to an SQL database’s data being arranged via tables and rows, the app’s database is a NoSQL database(presumably MongoDB). This means that data is not saved as rows but rather documents. To access documents we’ll use Firebase database functions rather than SQL queries which is easier, safer, and lets us write JavaScript instead of SQL.

What I like as well is that you can visualize your data in a hierarchical way.

The root of the database has /users/ as the container for the users of the app. Each user has their own uniquely generated ID which Firebase takes care of. Each user has their own /contacts/ and /me/ containers.

The /contacts/ container holds all of the individual contacts created by a single logged-in user. Each contact also has their own uniquely generated ID created by Firebase. In the screenshot you can see the information saved for each user:

• Address
• Birthday
• Email
• First Name
• Last Name
• Phone Number

The /me/ container holds the information for the logged-in user. It holds all of the same type of data as a single contact would. This allows for the logged-in user to “share” their own contact data with others(we’ll see this in action later).

Viewing Contacts

When a user logs into the app they are first directed to the Contacts tab, which outputs a list of their contacts. Clicking on a contact brings you to a screen which shows all of the contact details and allows you to edit or share the contact.

The Data Flow

The gist of how this works is this:

• I log into the app and get redirected to the Main TabNavigator using a React Navigation function. The default tab is Contacts which will display a list of the contacts assigned to my user account.
• When this screen is about to load(using the componentWillMount() lifecycle method) the app calls a Firebase database function to ask for the contacts associated with my Firebase user ID.
• We await the response(because this is not instantaneous) and then use this.setState() to save the contacts into React State.
• We have a FlatList React Native component which generates a list based on the contacts data contained in state. Anytime the contacts within state changes, the list is re-rendered automatically.
• Each contact is represented by a list item within the FlatList component. Each list item has a key which links the list item to a contact.
• When you tap on a list item a React Navigation function is called to switch to a new screen to show the contact details. The contact details are carried over to the new screen as a prop using the key mentioned above.
• To reference the contact details in the new screen you can just use this.props.

That’s the basics of how contacts are loaded and displayed throughout the app:

• A Firebase user ID is grabbed once logged in.
• The contacts for that user ID is loaded via a database call.
• The contacts are stored in state
• A list is generated and automatically updated based on state.
• To update the list we just update state.

In Part Two I’ll discuss how validation and input “hinting” can make the app more enjoyable to use as well as limit mistakes made by users.

This is the second post in a series of posts which will illuminate my journey to becoming a Full-Stack JavaScript Developer. Read the first one here.

Recap

My plan is to progressively enhance the app into a fully complete app, allowing me to step-by-step learn important principles of development without overwhelming myself while at the same time practice my learning by applying them to a real app.

Planning

I mentioned in the previous post that I’ll be using React Native to build the app itself along with Firebase as the “backend”. This type of app is often referred to as a serverless app because it doesn’t require building out a separate server-side app. For example, a common modern app is built with the MERN stack:

• MongoDB
• Express.js
• React/React Native
• Node.js

We’ll be cutting out the MEN from this equation and replacing them with an integration with the Firebase platform.

Development Tools

I decided to use the Expo CLI library to create this app. When I was first learning React Native I was using the standard react-native-cli library along with Android Studio for phone emulation but Android Studio was quite buggy for me and I had an awful time with debugging.

Expo logs console messages right in the terminal(doesn’t require a browser window) so that was fine for me for this project. Additionally, I really liked testing my app on a real device. It feels so much more rewarding and “real” as you progress.

Navigation

I decided to use React Navigation for navigating through the various screens and tabs of the app. React Navigation was a bit tough for me to grasp at first but the example project that ships with Expo helped a lot.

The navigation setup is a basic Switch Navigator which contains two other main pieces of navigation: Main and Auth. Each of these are also their own StackNavigators which contain multiple screens.

Think of a Switch Navigator as just a way to navigate linearly between screens; you view one screen at a time and can switch to another one.

The Main portion of the app is the area which a logged-in user sees and gets to interact with. This is done with a React Navigation TabNavigator component which contains three different tabs to navigate through the main area of the app.

The Auth portion of the app is the area which a logged-out user sees. It is the default path when entering the app.

I don’t have a great eye for design or UI but this will do for an MVP.

Next Steps

Rather than drone on forever I’ll try to keep posts on the shorter side in order to make them more digestible and less boring.

The next post will discuss the layout and functionality of the app as well as the data it works with. Cheers!