In the scripts, I put local-react as the image tag. You'll soon find out trying to use the same tag on all your containers is not the greatest idea!

For my local projects, I swap out local-react with ${PWD##*/}. This says "get the folder name". This way, not all my images are tagged the same, they are tagged with the folder they are contained in. This is typically the name of the project and is a great starter tag for the image. Sweet!

So, the new commands will look like the following:

To build:

docker build . -t ${PWD##*/}

To run:

docker run \
  -it \
  --rm \
  -v ${PWD}:/app \
  -v /app/node_modules \
  -p 3000:3000 \
  ${PWD##*/}

Happy programming!!

It's interesting seeing how I code things while I "try it out", then compare it to how Kent codes things in his solutions. One difference I wanted to share was around methods to conditionally rendering within components.

Let's imagine we have a component that allows you to search for pokemon. It has the following states:

• Idle upon arrival to the page
• Pending after submitting a search
• A results view if proper data is returned
• An error view if something goes wrong

We can use conditional rendering to display different content depending on what state the page is in.

Pseudocode Example

The skeleton below shows the `state passed into the component and the four different resulting states that are expected.

export const ConditionallyRendered = ({ state }) => {
    return (
        <div>
            {/* Display idle state when first loaded (state is "idle") */}
            {/* Display pending message if waiting for response (state is "pending") */}
            {/* Display the Pokemon if successfully received (state is "resolved") */}
            {/* Display an Error Message if there's an error (state is "rejected") */}
        </div>
    );
};

Let's first take a look at rendering different JSX depending on the states.

Approach 1: JavaScript Rendering Different JSX

Here, outside of the return (<jsx/>) block, we use an if/else statement to decide what to render.

export const ConditionallyRendered = ({ state }) => {
    if (state === "idle") {
        // Display idle state when first loaded.
        return "Submit a pokemon";
    } else if (state === "pending") {
        // Display pending message if waiting for response.
        return <PokemonInfoFallback name={pokemonName} />;
    } else if (state === "resolved") {
        // Display the Pokemon if successfully received.
        return <PokemonDataView pokemon={pokemon} />;
    } else if (state === "rejected") {
        // Display an Error Message if there's an error.
        return <ErrorMessage error={error} />;
    }
    return <div></div>;
};

You could easily use a case/switch statement if you'd prefer.

The alternative I will show sounds like a similar method, but there is a nuanced difference.

Approach 2: JavaScript in JSX Rendering Different JSX

Here we jump right into JSX, then we drop into JavaScript and use some simple logic to decide what to render.

export const ConditionallyRendered = ({ state }) => {
    return (
        <>
            {/* Display idle state when first loaded. */}
            {state === states.idle && "Submit a pokemon"}
            {/* Display pending message if waiting for response. */}
            {state === states.pending && <PokemonInfoFallback pokemon={pokemon} />}
            {/* Display the Pokemon if successfully received. */}
            {state === states.resolved && <PokemonDataView pokemon={pokemon} />}
            {/* Display an Error Message if there's an error. */}
            {state === states.rejected && <ErrorMessage error={error} />}
        </>
    );
};

It's a bit weird when you first see it. We are taking advantage of the fact that cond1 && cond2 will stop evaluating at the && if cond1 is falsy. That means cond2 will never be reached. In our case, the JSX will not be rendered.

In the case that cond1 is truthy, cond2 will be evaluated. In our case, the JSX will be rendered.

Pros and Cons

While I like the cleaner look to Appoach 2, if you think about it, there's a potential buggy state we could achieve with that.

• Using an if/then statement like in Appoach 1, one and only one return (<jsx/>) block will be reached.
• Using the && login in Approach 1, depending on the logic to the left of && (called cond1), you could accidentally render two different states.

Maybe this is a pro for you though. Perhaps you want to be able to render any number of states depending on complex conditioning. In this case Approach 2 is definitely the way to go.

Another reason to go with Approach 2 is if there is content you want on the page regardless of the state (a title, the data, etc). If you want this, you'll want to extract these conditional states into separate components to use Approach 1.

However, in the example we are looking at here, we only want one state to show at a time and there is no other content displayed in the component. This makes it a good candidate for Approach 2

Conclusion

So, between Kent and I, who chose Approach 1 and who chose Approach 2 in the ` Epic React course? Hopefully, I keps an unbiased approach while writing this article and you'll just need to buy his course to find out! 😜

The promise is a prominent way to deal with asynchronous code in JavaScript. Many APIs return asyncronousely and use the promise as a return value. The promise is to return data once it's ready.

You can either await on the promise to be fulfilled or chain a .then() to tell JavaScript what to do once the promise is fulfilled. Let's consider a method fetchPokemon() that returns a promise that fulfills with pokemonData.

Handling Promises

Here are two general examples of handling promises in javascript.

1. Using async/await

   const pokemonData = await fetchPokemon(pokemonName)
   setPokemon(pokemonData)
   

2. Using .then() chain notation

   fetchPokemon(pokemonName)
    .then(pokemonData => setPokemon(pokemonData))
   

Note: To use async/await you will need this code to run in an asynchronous function.

Error Handling

We can't forget about error handling! Here is how to error handle with both approaches.

1. Using async/await

   try {
    const pokemonData = await fetchPokemon(pokemonName)
    setPokemon(pokemonData)
   }
   catch (error) {
    setError(error)
   }
   console.log('completed')
   

2. Using .then() chain notation

   fetchPokemon(pokemonName)
    .then(pokemonData => setPokemon(pokemonData))
    .catch(error => setError(error))
    .finally(() => console.log('completed'))
   

Depending on the circumstance, folks prefer one versus the other. With async/await the flow of code is more similar to synchronous code flow.

However, some prefer the chaining syntax for simple circumstances - especially in the useEffect hook in react.

Alternative to then/catch

Did you know that the .then() can take two parameters? If you supply the second parameter, it will specify what the code should do when there is an error. This way, you no longer need to provide a .catch() chain.

Here's the .then() example from above update:

fetchPokemon(pokemonName)
    .then(
        pokemonData => setPokemon(pokemonData),
        error => setError(error),
    )
    .finally(() => console.log('completed'))

This is especially nice for simple one-line arrow functions like the ones shown here. Try it out and let me know what you think!

What is Cypress?

Cypress is "fast, easy and reliable testing for anything that runs in a browser". It is batteries included so it comes fully baked-in tons of features and perks. It is also open-source, has a strong user community, and great documentation.

Cypress accesses the application via the browser, therefore it is most suitable for end-to-end (E2E) acceptance tests or user interface (UI) tests. Cypress can be used to unit test your components with some home-brewing. Cypress also allows for full-on traffic control of API calls, so it can also be used for API testing.

Levels of Our Application that Cypress Tests

Our team uses Angular, which comes with Jasmine/Karma for unit testing and Protractor for E2E tests. We chose to replace the former with Jest since our team had more experience with it. We chose not to use Protractor because of past experiences with Selenium testing.

TestBed is the Angular testing way to set up the modules, providers, and child components necessary to shallow mount a component. It is necessary in order to do any UI testing on a unit test level. We did not enjoy the developer experience that TestBed provides for UI testing. It was difficult to set up (see code block below) and cumbersome to interact with the document object model (DOM - the term used for the outline of HTML elements on a webpage).

We use Jest to unit test our components. Instead of doing these tests with TestBed, we reserved Jest unit testing for TypeScript logic only. This means any logic around function calls and flags were tested, but their connection to the template or DOM was not at this level. This is where we leveraged Cypress tests

Our Team Workflow

The tech ecosystem regarding QA requirements and dynamics is complex. Every team or project will vary in their approach as they all have unique needs. QA can be embedded on a team or separated as a different group. Developers can write automated tests or QA automation engineers can. Below is the workflow that our team uses.

A quality assurance (QA) team member writes test cases and manually tests, while our developers write automated tests. We’ve found that writing E2E tests have bolstered communication on our team, particularly tightening our dev-to-QA feedback loop.

At the beginning of each story, developers and testing come together to whiteboard a story around acceptance criteria. If needed, developers will have a separate technical implementation whiteboarding session to further refine their approach.

When the developers are wrapping up feature work, they meet again with QA to discuss what was implemented. At this point, test cases have been written, are refined, and the developers and QA can decide which E2E test cases should be automated via Cypress.

Even if test cases are automated, at feature implementation QA still rigorously manually tests them. They also check the effectiveness of the Cypress tests against their manual testing for a given case. From that point, the tests are marked as “automated” and Cypress can act as our regression test suite. This allows us to focus on smoke and exploratory testing, rather than redoing tedious and manual regression testing.

Integration with Build and Deploys (working towards CI/CD)

Let’s get some definitions set out around builds and deploys, as it can be a bit technical and confusing! First, for those that don’t know, CI/CD continuous integration/continuous deployment. This refers to the practice of getting code into master and deployed to your environments faster and in smaller chunks.

I will refer to a build or build artifact as the code that is going to be released to an environment. The release process involves deploying code, therefore another term for a release is a deploy. Both a build and a release have the possibility to fail (red) or pass (green). Failing means that the next step will not be performed.

The deploy process releases a build to an environment. An environment consists of a group of resources that are required to run an instance of our digital application (distinct URL, database, API server, UI server, functions, etc). The five environments we deploy to builds are DEV, TEST, AUTO, STAGE, and PROD. DEV is for developers to check their work, TEST is for QA, AUTO is for our E2E tests, STAGE is for our business users, and PROD is for our customers to use.

Our deploy process as it pertains to Cypress is that we run Cypress tests on deploy to AUTO. The tests are required to pass in AUTO (green) in order to go to STAGE. You can see the details of this in the figure below and in the text that follows:

When we create a pull request (PR) to master, we are requesting new code to be merged and deployed. At this point, a build happens. As part of our build process, before any releases happen, we run integration tests. These include unit tests in Jest on the frontend, unit tests in MSTest on the back end, and SpecFlow acceptance tests on our API. If these fail, the build does not release to any of our environments.

After building, we deploy to DEV and AUTO environments concurrently. If the DEV release passes (green), the build also goes to TEST. These releases stand up resources and deploy our new code — nothing special.

The AUTO release does the same release as DEV and AUTO with an additional step. Once the new code has been deployed to the environment, we trigger an additional build that runs all of our Cypress E2E tests against the AUTO environment. If the tests fail, the release fails (red) and rolls back to the previous build. If the tests pass, the release passes (green).

For tests that fail, we capture screen-shots. Regardless of tests passing or failing, videos are captured of each test. Both of these are saved to the build artifact after Cypress tests are run.

In order for a build to go to STAGE, we require two things: Cypress tests passing in auto (green) and QA signing off on all features merged. Once a release is in STAGE, it can go to PROD if it has been signed off by our business counterparts.

Working with Feature Flags

We use Launch Darkly for feature flags to help remove barriers to releasing partial features. Given our deployment and QA workflows, we needed to figure out how to integrate feature flags into our Cypress testing flow. While it is possible to toggle feature flags for certain Cypress tests, we decided to create a workflow that was suitable for us. What we ended up agreeing on as a dev team is:

1. Start with a feature flag on in DEV/Local for initial feature
2. We submit a PR to merge the feature with the flag off in
3. We update Cypress tests locally with the feature flag
4. When the Cypress PR merges we turn the feature flag on in
5. The Cypress tests pass in AUTO with the new feature 🎉

Conclusion

Cypress has brought a lot to our team and our process. It has encouraged our team to communicate feature expectations. It has provided us with a tool to catch defects as they are being generated. Possibly the biggest value, Cypress serves as a regression test suite. This helps us feel assured that we have not negatively affected any previous features when implementing new ones.

Cypress also offers a breadth of helpful features allowing developers to dive into E2E testing without having to create a Page Object Model or write wait helpers. Also, the value of the interactive test runner, screen-shot, and video output makes this tool highly valuable to non-developer members of our team.

Since then, I've worked with AWS Lambda Functions, Azure Functions, Firebase (Google Cloud) Functions, and Netlify Functions for various work tasks and side projects.

I've discovered the utility of these functions by using them where they are needed. For example:

• Lambdas are easy to edit data between a Firehose and S3
• Firebase functions can be triggered off of changes from RTD or Firestore databases
• Netlify functions are a simple and elegant way to run backend API calls without having to spin up a backend

I need to be honest, I love using Netlify to deploy my frontend apps. It's amazing to have functions bundled in with my frontend repo, deployed on the same TLD so that there are no CORS issues to deal with.

Case Study

To get up and running quickly, we will be hitting the Github API. This is partly due to the widespread familiarity with Github. Also, Github API allows calls to be made without authentication so that headache can be saved for another blog!

The basic flow will look like this:

We will:

• Set up local repo
• Create Netlify function to call Github API
• Deploy function to Netlify

Prerequisites

To follow along, you will want the following:

• Netlify for deploying our site and using functions
• Github to integrate our site with netlify
• A text editor like VS Code
• Node installed (go with the LTS version)
• Netlify CLI installed

Create Repository

We are going to create a clean repository, hooked up to Github. We can do this in several ways. Instructions are given on Github when you create a fresh repository:

The second option of create a new repository on the command line is my typical go-to. That is because I usually forget to create my repo before I start my project locally 😅

Once you have your repo set up, cd into the project. For example, my repo is: netlify-function-blog so I will go:

cd netlify-function-blog

Initiation Netlify

To initiate this as netlify project, we will run:

netlify init

If you get an error here, make sure you have the Netlify CLI installed.

If you have the CLI and have not logged in before, you will get a request to log in.

After you are logged in, you should get a message like:

? What would you like to do? 
  ⇄  Connect this directory to an existing Netlify site 
❯ +  Create & configure a new site

Since we have not created our netlify site yet (you can do so from their GUI at netlify.com), chose the second option.

You can choose all of the default options while setting things up. What's important is the site name and the location for functions. I like the default of functions folder. The name makes sense, right?

Commit and push. You can check out your site by running

netlify open

Nothing really there. This is because we're going to focus on creating cloud functions.

Creating functions

We told netlify to look in the folder functions folder, so let's create this folder with mkdir functions and create a new file in it called helloWorld.js.

Let's create a new function here:

exports.handler = async function(event, context) {
    return {
        statusCode: 200,
        body: JSON.stringify({message: "Hello World"})
    };
}

This is a simple function that returns a "Hello World" message. We can locally test our function by running the command:

netlify dev

The server should automatically open up at localhost:8888. You can access your function by navigating to the subroute .netlify/functions/helloWorld.

You should get the response:

{
"message": "Hello World"
}

You can also commit and push your changes and check out the same subroute on your netlify app. For example, with my app, the url is https://netlify-function-blog.netlify.app/.netlify/functions/helloWorld.

Nice! 🎉

Now let's do something a bit more interesting. Let's use a function to make a call to Github to get our repositories and return them.

To make our API calls, we'll want fetch installed. Install this with npm like this:

npm install node-fetch

Then, create a new file in the functions folder called getRepos.js.Your code should look something like this:

const fetch = require('node-fetch');

exports.handler = async function (event, context) {
  const url = 'https://api.github.com/users/micleners/repos';
  const response = await fetch(url);
  const json = await response.json();

  return {
    statusCode: 200,
    body: JSON.stringify(json),
  };
};

Of course, you should fill in your username for micleners in the code above! And when you run it locally, you should get a list of repos you own!

To get this to run on Netlify, you'll need to do two things.

1. Create a package.json by running this command:

npm init

1. Go into netlify.toml and change the build command to npm install. Your netlify.toml should start like this:

[build]
  command = "npm install"
  functions = "functions"

With these changes, you should be able to merge and push your changes. Then you can hit your deployed function on Netlify.

Next Steps

This is just a tickle of what Netlify functions can do. You can imagine filtering and processing results in a function. You can also use Netlify environment variables to store and access secrets within functions. Check out Netlify docs on environment variables for more info!

• Make complex local environments quick and easy to spin up
• Allow for specific versioning of languages and packages to coexist locally
• Provide an easy tool to ship code for pipeline integration and deployment
• Help create a consistent work environment across developers

Docker has taken the spotlight for creating development containers. This tutorial will show you how to dockerize a project created with Create React App.

Prerequisites

In order to go through this tutorial, you should have node (LTS version if you're uncertain) and docker installed. The links just listed should work for you, but feel free to use Homebrew or installer you prefer.

Project Startup

If you don't have a CRA project yet, use npm to create a new one using the npx command:

npx create-react-app my-project

Move into your project:

cd my-project

Start up and check out your app:

yarn start

It soon should be running at http://localhost:3000. When you've had your fun exploring, turn off the server when with ctrl+c and get ready to start dockerizing 🤓

Dockerize!

New docker images are built on a base image and ours will be no different. Docker hub contains a multitude of images. It is probably no surprise that we will be using a node docker image as our base (we'll use 14.15.1 which is LTS at the time of writing).

To specify this docker image and other configuration, create the file Dockerfile in the root of your project and add the following:

# pull official base image
FROM node:lts-alpine

# set working directory
WORKDIR /app

# add `/app/node_modules/.bin` to $PATH
ENV PATH /app/node_modules/.bin:$PATH

# copies package.json and package-lock.json
COPY package*.json ./

# installs app dependencies
RUN npm install
RUN npm install react-scripts -g

# add app contents to the container
COPY . ./

# start app
CMD ["npm", "start"]

Let's break this down line by line

1. FROM node:lts-alpine This line tells docker what base image to use. We want to use the latest stable (LTS stands for long term stable) version of node. Alpine is a distribution of linux that is designed for security, simplicity, and resource efficiency. It is a common choice for docker images because of this.
2. WORKDIR /app It's good practice to chose a working directory to enter into. If you don't, docker will copy all the contents into the root of the image. If there is namespace clashes, there may be

Also, create a .dockerignore file in the root of your project with the following content:

node_modules
build
.dockerignore
Dockerfile
Dockerfile.prod

This makes sure not to copy any unnecessary files to our docker image.

Start Up Docker

First, we need to build the docker image:

docker build . -t local-react

The -t local-react is a tag to easily reference our docker container later. You can change local-react to whatever name you want, just make sure you change the next script as well!

You should see the steps from the above Dockerfile run. Then we can start up our docker server with this command:

docker run \
  -it \
  --rm \
  -v ${PWD}:/app \
  -v /app/node_modules \
  -p 3000:3000 \
  local-react

Let's go through what's happening here line by line

1. docker run starts up the docker container
2. -it runs the docker container in interactive mode so that the container remains open after it starts. As of react-scripts v3.4.1 this is now required).
3. -v ${PWD}:/app creates a volume of your current working directory into the app directory. This way, when changes are made locally, they will be reflected in docker
4. -v /app/node_modules is a workaround to ensure that we use the node_modules in the docker container rather than the node_modules locally
5. -p 3000:3000 exposes the docker port 3000 on your localhost so you can view the app running
6. local-react is the tag of the container we built

Boom 🎉 With any luck you should be up and running!