Forem: Adam Goth

Why I’m Not Worried About AI Taking My Software Job

Adam Goth — Fri, 04 Apr 2025 07:51:46 +0000

If you had told me in 2022 that less than three years later, the founder of Replit would be tweeting "I no longer think you should learn to code," I would have been utterly confused.

If you'd gone on to say that by then, I'd be using AI to write the majority of my own code, I would’ve laughed out loud, wondering where this jokester came from.

And if you'd added, "Don't worry — you're going to love it," I probably would’ve said, "Alright buddy, lay off the edibles."

The reality is, LLMs are amazing at writing code. I now use them to write the vast majority of my code. Not only is it faster, but given enough context, LLMs often make better decisions than I do.

Are they perfect? No. Do they make mistakes? Plenty. Do they still require supervision? Absolutely. But we can all see the direction things are headed. If you're a software developer who still believes your career won't be impacted by this, you're in denial.

So why am I not anxious about this? After letting this thought percolate in my mind for the past couple of years, I've realized the answer is simple: I got into coding because I love building things.

I've always loved browsing the internet or playing around with my phone and thinking, "Hey, wouldn't it be cool if there was an app that did this?" So I set out to learn how to turn these ideas into reality.

My first attempt at building an app with Ruby on Rails was a complete disaster. I took an online course covering UI and CRUD basics and confidently set out to build my first real app.

Things started off well, but as soon as the complexity increased slightly beyond the basics, I found myself totally lost. I read Stack Overflow threads and posted questions, but by the time I got answers, my momentum was usually gone, and I'd already moved on to the next idea.

Slowly but surely, I kept trying out new app ideas, and with each attempt, I learned a bit more. Eventually, I decided to focus more on the UI, as I found the visible and tangible parts of the app (frontend) a bit more exciting than the invisible data-handling parts (backend).

Eventually, I landed my first gig as a junior frontend developer, and the rest is history. Fast forward to today, and I can now iterate on an idea and spin up a full-stack MVP in just an hour or two. Only two years ago, that same MVP would’ve taken me weeks, maybe even months.

Think about that for a moment. It's incredible. And that’s exactly why I’m not worried about AI replacing me as a developer. I got into this profession because I wanted to build apps, and now I can build them ten times faster.

So, will I still have a job two years from now? I don’t know for sure, but I think so. Will it look different? Almost certainly. But will I still be building apps? Absolutely.

Understanding package dependencies within a pnpm monorepo

Adam Goth — Wed, 05 Apr 2023 12:35:27 +0000

When you're working on a large project with multiple packages, a monorepo structure can help simplify your development workflow. With a monorepo, you can manage multiple packages as a single entity, which can make it easier to share code and manage dependencies. In this post, we'll take a look at how to structure dependencies in a pnpm monorepo, with examples to help illustrate the concepts.

What is pnpm?

Before we dive into how to structure dependencies in a pnpm monorepo, let's first define what pnpm is. pnpm is a package manager for Node.js that optimizes the installation and sharing of packages across multiple projects. Unlike other package managers like npm and Yarn, pnpm uses a single global cache for all packages, which reduces disk usage and speeds up package installation.

What is a monorepo?

A monorepo is a codebase that contains multiple packages or applications. Rather than storing each package or application in its own repository, a monorepo stores all packages or applications in a single repository. This can make it easier to manage dependencies, share code, and coordinate changes across packages.

In a monorepo, packages are often organized into a packages directory, with each package stored in its own subdirectory. Each package typically has its own package.json file, which lists its dependencies, devDependencies, and scripts.

Structuring dependencies in a pnpm monorepo

When you're working with a pnpm monorepo, there are three types of dependencies that you need to be aware of: dependencies, peerDependencies, and devDependencies.

// package.json
{
  "dependencies": {
    ...
  },
  "peerDependencies": {
    ...
  },
  "devDependencies": {
    ...
  }

Let's take a look at each one.

dependencies

dependencies are packages that your package depends on to function properly. When you install a package's dependencies, pnpm will install them in the package's node_modules directory.

If a dependency is used in multiple packages in the monorepo, it should be listed as a regular dependencies in the package.json files of those packages. However, if a dependency is only used by a single package in the monorepo, it should be listed in that package's package.json file and should not be listed in the root directory's package.json file.

For example, let's say we have a monorepo with the following packages:

my-monorepo/
  packages/
    app/
      package.json
    ui-library/
      package.json

If both the app and ui-library packages are using the same version of lodash, it makes sense to list lodash as a regular dependency in the package.json files of both packages:

// app/package.json
{
  "name": "app",
  "version": "1.0.0",
  "dependencies": {
    "lodash": "^4.17.21"
  }
}

// ui-library/package.json
{
  "name": "ui-library",
  "version": "1.0.0",
  "dependencies": {
    "lodash": "^4.17.21"
  }
}

On the other hand, if the app package is the only package that uses react-router-dom, we would only list react-router-dom as a dependency in the app package's package.json file:

// app/package.json
{
  "name": "app",
  "version": "1.0.0",
  "dependencies": {
    "react-router-dom": "^5.3.0"
  }
}

peerDependencies

peerDependencies are packages that your package depends on but that will be provided by the consumer of your package. They are typically used when your package provides functionality that depends on a specific version of another package, but you don't want to include that package as a regular dependency because it will be provided by the consumer of your package.

When you specify a package as a peerDependency in your package.json file, you are essentially saying that "this package requires that the consumer of my package provides this package". The consumer of your package must then ensure that the required package is installed and available to your package when it is used.

For example, let's say we have a monorepo with the following packages:

my-monorepo/
  packages/
    app/
      package.json
    ui-library/
      package.json

Let's say the app package depends on react as a regular dependency, but the ui-library package provides a component that depends on a specific version of react. In this case, we would list react as a regular dependency in the app package's package.json file, and as a peerDependency in the ui-library package's package.json file:

// my-monorepo/packages/app/package.json
{
  "dependencies": {
    "react": "^17.0.2"
  }
}

// my-monorepo/packages/ui-library/package.json
{
  "peerDependencies": {
    "react": "^17.0.0"
  }
}

This ensures that react is installed in the app package's node_modules directory as a regular dependency, and is also listed as a required peerDependency for the ui-library package. When a consumer installs the ui-library package, they will need to ensure that they have installed a compatible version of react in their own project, which will be used by the ui-library package's component that requires it.

devDependencies

devDependencies are packages that are only used during development and testing, and are not required for the package to run in production. They are typically used for tools like testing frameworks, build tools, and code quality tools.

When you list a package as a devDependency in your package.json file, pnpm will install it in the package's node_modules directory, but it will not be included in the production build of the package.

For example, if you are using Jest as your testing framework, you would list it as a devDependency in your package.json file:

{
  "name": "my-package",
  "version": "1.0.0",
  "devDependencies": {
    "jest": "^27.2.1"
  }
}

In a pnpm monorepo, if a devDependency is used in multiple packages in the monorepo, it should be listed as a regular devDependencies in the package.json files of those packages. However, if a devDependency is only used by a single package in the monorepo, it should be listed in that package's package.json file and should not be listed in the root directory's package.json file.

Conclusion

When you're working with a pnpm monorepo, it's important to understand how to structure your dependencies to ensure that your packages can share code and manage dependencies effectively. By using dependencies, peerDependencies, and devDependencies appropriately, you can create a clean and efficient monorepo structure that is easy to manage and maintain.

Note: The logic regarding dependency structure described in this post applies to most monorepos in general, not just pnpm, however, different package managers may have different ways of managing dependencies and version ranges, so make sure to check the documentation.

Analyzing reddit comments using Python

Adam Goth — Wed, 20 Jan 2021 15:34:16 +0000

In this post, we'll take a look at how to build a simple Python script for word analysis. We will then apply it to the comment section of any given reddit post.

Overview

Between my job and side projects, I typically spend most of my time building web applications using React and Node. That means writing almost exclusively JavaScript. To keep my perspective on programming fresh and not strictly confined to a single language, I wanted to take a little time to step out of the world of JavaScript and explore the world of another programming language. I decided to come up with a little project idea and to build it with Python. Python is a powerful yet friendly programming language that is popular with beginners and experienced programmers alike. It was created in 1991 by Guido van Rossum, but continues to rise in popularity almost 30 years later. In 2020, Python was at or near the top of the list for in-demand languages for programming jobs. It was also deemed by Wired magazine to be more popular than ever before. After spending just a short time writing code with Python, it's not hard to see why it's a popular choice. Let's jump in.

Setting up

This post will assume you have basic programming knowledge and that you have Python 3 installed. For more detailed information on installing Python, start here. The repo for this project can be found here. You will notice a .py file containing the full script, as well as a .ipynb file containing a Jupyter Notebook for the script. The Jupyter Notebook is an open-source web application that allows you to create and share documents that contain live code, equations, visualizations, and narrative text, which can make it easier to follow along and learn how a python script works.

The script

The script in its entirety can be found here.

The first thing we need to do is import the requests library. This is what we will use to make the HTTP request to reddit to get the comment data from the reddit post. After that, we will initialize a few global variables. We will use these global variables to keep track of data as we parse through comments. comment_count is an integer and will track the number of comments we parse, comment_array is an array and will hold the actual comment strings, and more_comment_ids is another array that will hold ID strings that we will need in order to fetch additional comments that are not returned in the initial payload (commonly found in posts with many comments).

# imports
import requests  # The requests library for HTTP requests in Python

# globals
comment_count = 0
comment_array = []
more_comment_ids = []

Next, we need to fetch the data for the reddit post. To do that, we can append .json to the end of any reddit post URL.

An example would be: https://www.reddit.com/r/redditdev/comments/krolrb/multicomments.json.

What we get back is JSON that will have a basic format that looks like this:

{
    "kind": "Listing",
    "data": {
        "children": [
            "kind": "t1",
            "data": {
                "body": "",
                "replies": ""
            }
        ]
    }
}

A reddit post is referred to as a "Listing". Listings can contain many kinds of children. A child with a kind of t1 indicates that the child represents a comment. Within the comments data property, among many other properties, the text of the comment can be found on the body property, along with any possible replies which are located on the replies property. Replies are structured the same way as comments. They contain children and the children has kind and data properties. Within every reply to a comment, we may see another reply to that reply comment. Each of these contains their own identically formatted children. So in order to analyze all comments within a thread, we'll have to recursively sift through all comments and replies.

If having to follow each individual comment tree recursively to its end wasn't tricky enough, there's another issue we have to worry about. Since comment threads can become quite long, not every comment is always displayed on the initial thread load. When this happens, reddit shows "load more replies" buttons within threads. So how do we get these as well? To handle these instances, the API will deliver a child with a kind property value of more.

{
    "kind": "more",
    "data": {
        "count": 2,
        "name": "t1_ghp1m6v",
        "id": "ghp1m6v",
        "parent_id": "t1_ghozojl",
        "depth": 2,
        "children": [
            "ghp1m6v"
        ]
    }
}

The array of children within the more object will contain a list of thread IDs that can be used to fetch additional comments. In the code example above, there is just one child ID, ghp1m6v. So in addition to parsing all comment trees recursively, we will also have to collect any additional comment thread IDs and then do the same thing for those.

Hopefully, you are still with me at this point. Talking about all of this without writing any code can be confusing, so let's try to break it down with some functions that will help us achieve this goal.

The first function we'll write is parse_children_for_comments.

def parse_children_for_comments(children):
    global comment_count
    global comment_array
    for child in children:
        if child['kind'] == "more":
            children = child['data']['children']
            for id in children:
                more_comment_ids.append(id)
        if child['kind'] == "t1":
            comment_count += 1
            comment_array.append(child['data']['body'])
            get_replies(child['data'])

It will take an array of children objects that are sent back in the response data and will pull out the comment text which is found in the body property. For each child in the array argument of children, we will check its kind. If the kind is more, we will loop through and add each id to the global array we created, more_comment_ids. We will eventually come back to this array of ids and parse through it.

Next, if the kind is t1, that means we have a comment and we want to read its text. In order to do that, we simply get the text with child['data']['body'] and append it to our global comment_array variable.

After appending the comment to the comment_array, we need to check if there are any replies to that comment. Since we will be doing this check many times, it's best that we write a helper function for it. We'll call it get_replies:

def get_replies(comment):
    global comment_count
    if comment['replies'] != "":
        children = comment['replies']['data']['children']
        parse_children_for_comments(children)

First, we check if there are any replies. When there are no replies, the replies property will be an empty string. If the string is not empty, we know we have a reply. As I mentioned above, replies take the same format as the original comment it is replying to. So in order to parse the reply text, we can reuse the same parse_children_for_comments function we already wrote. Since parse_children_for_comments will again call get_replies, and get_replies will again call parse_children_for_comments until there are no comments left, this will recursively continue until we reach a child comment with an empty replies property. Pretty neat.

With those helper functions defined, we're ready to fetch our data. In order to do this, we will use a built-in Python function called input which will allow the user to enter a URL to a reddit post.

# get url from user
print('enter the reddit post url (e.g. https://www.reddit.com/r/redditdev/comments/krolrb/multicomments/):')
thread_url = input()

We can expect the user to paste in a URL for a reddit post. For example, it may look something like this: https://www.reddit.com/r/redditdev/comments/krolrb/multicomments/

To get the post data, we need to turn https://www.reddit.com/r/redditdev/comments/krolrb/multicomments/ into https://www.reddit.com/r/redditdev/comments/krolrb/multicomments.json.

To do that, we can write a small helper function.

def sanitize_input(url):
    last_char = url[-1]
    if last_char == '/':
        url = url[:-1]
    url = f'{url}.json'
    return url

We pass the URL as an argument into the function. The function checks if the last character of url is a / and removes it if it is. Then the function appends .json to the end of url. After we pass the user's inputted URL to this function, we're ready to fetch the post data.

# pass user's url to sanitize helper
sanitized_thread_url = sanitize_input(thread_url)

# make network call
req_data = requests.get(sanitized_thread_url, headers={'User-agent': 'adamgoth.com'})

if req_data.status_code != 200:
    print('request failed')
    print(req_data.json())

if req_data.status_code == 200:
    json_data = req_data.json()
    for item in json_data:
        children = item['data']['children']
        parse_children_for_comments(children)

We call requests.get(), passing our URL as the first parameter, as well as a headers value for a second parameter. The reason we need to specify a User-agent property in the header is so that we have a unique identity to reddit. This will ensure we appear entirely anonymous and run into rate-limiting issues.

Once we have our data back in our req_data variable, the first thing we'll check is if we did not get a 200 response for any reason. If the response is not 200, we will print out the error.

Assuming we get a 200, we can then start parsing the data. We can use the requests library built-in JSON decoder and called .json() on the response. We then write a simple for statement that takes each child in the response data and passes it to the parse_children_for_comments we previously discussed.

After the for loop from line 13 completes, we should have a number of comments stored in our global comment_array. Additionally, depending on the number of comments from the post, we may have found some additional comment IDs and stored them in our global more_comment_ids array. As a reminder, these are IDs we can use to fetch more comments that did not appear in the initial load. In the reddit UI, these represent the links within comment threads that appear as "load more replies", and in our data response, these IDs come from the children that have a kind property value of more.

The URL for fetching the additional comment data looks similar to the URL we used for fetching the initial post data. The only difference is the comment ID is appended to the end. So https://www.reddit.com/r/redditdev/comments/krolrb/multicomments.json becomes https://www.reddit.com/r/redditdev/comments/krolrb/multicomments/{comment_id}.json. We can write a simple helper function to do this for us.

def create_thread_url(comment_id):
    return sanitized_thread_url.replace('.json', f'/{comment_id}.json')

We simply pass the comment_id as an argument and then do a string replace on .json with /{comment_id}.json.

We're then ready to make the requests for the additional comments.

# handle extra comment ids
for id in more_comment_ids:
    req_data = requests.get(create_thread_url(
        id), headers={'User-agent': 'adamgoth.com'})
    if req_data.status_code != 200:
        print('request failed')
        print(req_data.json())

    if req_data.status_code == 200:
        json_data = req_data.json()
        for item in json_data:
            children = item['data']['children']
            parse_children_for_comments(children)

To fetch the additional comments, we'll use another for loop to loop through each ID in the more_comment_ids array. For each one, we again use requests.get(), passing the comment ID to the create_thread_url function we just wrote, along with the same User-agent header as our previous request. Once we have our response, we again check the status code, and if it's successful, we'll parse the data the same way we did before, passing each child in the data to parse_children_for_comments. As a word of caution, for posts with thousands of comment replies, this can result in a large number of additional comment IDs. It's possible to have hundreds of IDs to fetch. Each one of these will require a synchronous network call, so it can take quite a while if this is the case.

Once all the additional comment IDs have been fetched, we have all the data we need to run our word analysis. To do this, we will combine all of the comments in our global comment_array variable into a single string. We will then write a function which will parse that string and keep track of how many times each word appears. The function to do that looks like this:

def analyze_words(words):
    analysis_string = words.split(' ')
    word_dict = {}
    for word in analysis_string:
        cleaned_word = word.replace('.', '').replace("'", '').replace(
            '\n', '').replace(',', '').replace("’", '').lower()
        if cleaned_word not in word_dict:
            word_dict[cleaned_word] = 1
        else:
            word_dict[cleaned_word] += 1

    return word_dict

The function takes a single string as an argument called words. It then breaks the string into an array of words called analysis_string by splitting the string on each space character found in the string. We create an empty dictionary called word_dict that we will use to keep track of each word's appearance. Then we loop through each word in our analysis_string array. For each word, we use string replaces to strip out various common special characters (commas, periods, etc.) and then call .lower() on it to convert all uppercase characters to lowercase characters. This ensures that The and the are not tracked as two different words. As we go through each word in the array, if the word does not exist in our word_dict dictionary yet, we will add it and give it a count value of 1. If it already exists in word_dict, then we will just increment the count value up by 1. When we are finished looping through each word, we will return the word_dict we created.

The end of the script looks as follows:

comment_string = ' '.join(comment_array)
results = analyze_words(comment_string)

sorted = sorted(results.items(), key=lambda x: x[1], reverse=True)

print(f'{comment_count} comments analyzed')

for key in sorted:
    print(key)

After combining all the comments into a single string and passing that string through analyze_words, we can sort all the results by the number of appearances counted by calling sorted = sorted(results.items(), key=lambda x: x[1], reverse=True). We can then print the total number of comments we parsed and then each word and the number of times it appeared.

Wrapping up

The script in its entirety can be found here. To run the script, simply run python reddit-comment-analysis.py from the directory containing the script file.

If you have Jupyter Notebooks installed, a more interactive version of this post can be found here.

This script serves as a basic starting point for fetching and analyzing data from the web. There is room for many improvements and enhancements to this script. Ideas for additional features include:

Input validation
Options for handling upper and lower casing
Options for removing special characters
Options for removing common words (the, and, I, etc.)

If you enjoyed this post or found it useful, please consider sharing it on Twitter.

If you want to stay updated on new posts, follow me on Twitter.

If you have any questions, comments, or just want to say hello, send me a message.

Thanks for reading!

Running a serverless API using Netlify Functions

Adam Goth — Thu, 14 Jan 2021 16:36:30 +0000

Over the last few years, serverless applications have been growing in popularity. There are many use cases in which a serverless solution is more practical and more convenient than the traditional server solution. In this post, we'll look at setting up a serverless Express.js API using Netlify functions.

Overview

Before we dive into the code for this demo application, let's talk about a few concepts at a high-level.

Serverless

"Serverless" is a term that is used for what can generally be thought of as a method of providing backend services on an as-used basis. Rather than setting up specific infrastructure, or a server, to provide the backend services, you can utilize a "serverless" provider to handle this functionality instead. This was first popularized by AWS Lambda but is now a service offered by many other companies as well, including the one we'll be looking at today, Netlify.

AWS Lambda

As mentioned above, AWS Lambda is the most popular provider of serverless computing. Here's how AWS Lamba describes itself in its own words:

AWS Lambda lets you run code without provisioning or managing servers. You pay only for the compute time you consume.

With Lambda, you can run code for virtually any type of application or backend service - all with zero administration. Just upload your code and Lambda takes care of everything required to run and scale your code with high availability. You can set up your code to automatically trigger from other AWS services or call it directly from any web or mobile app.

As great as this sounds (and it really is great), setting up an AWS lambda function can be a tedious process, requiring quite a bit of configuration that can be easily confusing to someone is who new to serverless functions. If you're curious to see for yourself, here's an example tutorial directly from the AWS docs. But not to worry, that's why we're here to talk about Netlify Functions.

Netlify Functions

Netlify Functions greatly simplifies the process for running serverless functions. Using Netlify Functions, we can simply write our lambda function and drop it into the functions folder of our Netlify-hosted application. Behind the scenes, Netlify handles the interaction with AWS for us. We don't even need an AWS account. Every Netlify account is set up for this feature out of the box. There's no setup, servers, or ops required.

Let's see what this looks like in code.

The application

The code for this demo can be found here. Since the purpose of this post is to show how to set up a serverless API, rather than do anything specific with the API, this particular demo application will serve up an extremely basic API with two endpoints that don't do much. I will assume the reader has some basic familiarity with Express.js and Node as we will be using these to build the API.

If we take a look at our package dependencies, we have just five packages:

nodemon is used to automatically restart our server while we're working on it in development

express gives us our API framework

body-parser is middleware that allows us the parse our request bodies

serverless-http allows us to wrap our API for serverless use

netlify-lambda is a tool that helps us build our application code so that it can be consumed correctly by Netlify using Netlify Functions

The other thing to note in the package.json file are the two scripts. We have "start": "nodemon server-local.js" which is used for development, and "build": "netlify-lambda build express" which is used to build and deploy.

  "scripts": {
    "build": "netlify-lambda build express",
    "start": "nodemon server-local.js"
  }

The start script is fairly straight forward, it will just execute our server-local.js file which in turn is calling express/server.js. This works for local development, but we need to do additional work in our build script for the application to work as a serverless function once deployed to Netlify. In the build script, we call netlify-lambda build which takes a source folder as an argument (express in our case) and outputs it to a built folder. The built folder is where Netlify will look for our serverless functions. We have a couple of options for how we specify this. We could specify the designated folder within Netlify's application settings using Netlify's web app, or within our application code, we can specify the designated folder with a netlify.toml configuration file. In our case, we'll use a configuration file that lives in our root directory that looks like this:

// netlify.toml

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

With our scripts and build configuration accounted for, let's take a look at the core of the application.

The core of the application lives in the express/server.js file, and in our case, is just 29 lines.

"use strict"
const express = require("express")
const serverless = require("serverless-http")
const app = express()
const bodyParser = require("body-parser")
const router = express.Router()

app.use(bodyParser.json())
app.use("/.netlify/functions/server", router) // path must route to lambda
app.use("/", router)

router.get("/", (req, res) => {
  res.writeHead(200, { "Content-Type": "text/html" })
  res.write("<h1>Up and running</h1>")
  res.end()
})

router.post("/doSomething", async (req, res) => {
  try {
    // maybe do some database interaction or third-party API call here!
    res.status(200).send({ data: "success" })
  } catch (err) {
    console.log(err)
    res.status(400).send({ error: "bad request" })
  }
})

module.exports = app
module.exports.handler = serverless(app)

If you've ever worked with Express.js, this should look pretty familiar to you. We have two endpoints, one GET endpoint at / and one POST endpoint at /doSomething.

These endpoints don't do much, but you could do just about anything you would normally do with GET or POST endpoints here. Hit a third-party API, connect to a database, fire off some sort of transaction, etc.

The two lines in the application that are specific to using Netlify's serverless functions are line 9 and line 29.

As we specified in our netlify.toml configuration file, our function code is going to live at ./netlify/functions/server. So we will tell our express app on line 9 to use our router object anytime a request is sent to this server.

app.use("/.netlify/functions/server", router)

Lastly, on line 29, we will utilize the serverless-http package to wrap our application up for serverless use. This means our application can work as expected without any HTTP server, ports, or sockets.

module.exports.handler = serverless(app)

With that, the application is all set to deploy to Netlify. If you've never deployed on Netlify before, you'll be amazed at how simple it is. This post won't go into details but it isn't much more than authenticating your GitHub account and selecting the repo and branch to deploy. Once the application is deployed, you can start accessing the endpoints we created at <your site URL>/.netlify/functions/server/<your endpoint>. We now have a basic yet fully-functioning API, without having to run or provision a dedicated and separate server!

Wrapping up

Hopefully you were able to follow along in creating this Netlify serverless function. Serverless computing is still a developing and evolving technology but its popularity continues to grow as more developers find it more suitable to their needs than traditional server applications.

The particular use case that led me to using Netlify functions is that I needed to make a third-party API call from my client application that required a private API key in the header. With just client-side code, there is no good way to keep your private API key private. I decided I needed a server to proxy the request through, but I didn't want to create and dedicate an entire server just to pass one small API request through. So this ended up being a perfect solution. Now that I know how convenient and simple this can be, I will be looking for more opportunities to utilize Netlify Functions.

For more technical information regarding the usage and implementation of Netlify Functions, be sure to visit the docs.

If you enjoyed this post or found it useful, please consider sharing it on Twitter.

If you want to stay updated on new posts, follow me on Twitter.

If you have any questions, comments, or just want to say hello, send me a message.

Thanks for reading!

Tips and Tricks: Chrome Dev Tools

Adam Goth — Tue, 12 Jan 2021 15:44:35 +0000

I recently spent some time diving into all that Chrome's developer tools have to offer. It's quite impressive what the Chrome team has built to make the lives of web developers easier. In this post, I will share a handful of the nifty things I learned.

Let's jump in.

Toggle the console drawer

Most people are probably familiar with the Console tab. But you can open a console drawer from almost any other tab as well. This can easily be toggled by simply hitting the esc key.

Toggle all nested elements

Clicking an element within the Elements tab will expand that particular element and show you any children elements belonging to it. Sometimes, elements can be nested several layers deep. By holding the option key while clicking an element, you can expand all children nested within that element.

Scroll element into view

Sometimes you may see an element with your Elements tab and wonder where exactly that element lives on the page. Usually, you can see the element get highlighted on the page as you hover it in the Elements tab, but sometimes the element is not within the page view. If you right-click the element, you can choose the "Scroll into view" option and Chrome will do just that.

Toggle an element's visibility

For whatever reason, you may want to toggle whether an element on your page can be seen or not. This can easily be done by simply hitting the h key while the element is selected in the Elements tab.

Converting color formats

When viewing an element's CSS color property in dev tools, you can toggle between RGB, HSL, and hex color formats by holding the shift key and clicking the color square. This can be convenient in various situations where you may find a color in one format, but need it in another.

Access recently selected elements in console

Sometimes we need access to DOM elements in the console so that we can inspect various properties or behavior. Chrome provides a quick shortcut to access these elements within the console. If you type $0 into the console, you will get the element you most recently interacted with in the Elements tab. If you type in $1, you will get the second most recent element you interacted with, and so forth...

Run commands

By pressing command + shift + p, you can search dev tools for nearly anything and quickly run various commands. This gives you extremely quick access to many features of the dev tools. Give this one a try, you may find something you didn't know existed.

Blackbox scripts

Ever get stuck debugging in some random runtime file that you never wanted to be in? Blackboxing scripts is your new friend. If there is a script that you do not want your debugger to go into, you can right-click it and select "Blackbox script". Easy enough.

Conditional breakpoints

If you have used the debugger in the dev tools before, you are likely aware that you can set breakpoints to pause your code execution. In addition to your standard breakpoint, Chrome allows you to also set conditional breakpoints. This allows you to specify that a variable must have a certain value in order for the breakpoint to hit. This can be very convenient when you are trying to debug an issue where a particular value must be present. To set a conditional breakpoint, right-click the line you want to set it at and click "Add conditional breakpoint..."

Networking calls: Who called what?

Sometimes we see network calls in the Network tab and we're not sure where they came from. Chrome has a neat trick that shows you if one network call was initiated by another call and if that network call in turn has dependencies of its own. To take a look, simply hold shift while hovering a network call. Initiators are colored green and dependencies are colored red.

Select multiple networking request types

If you are familiar with the Network tab, you are likely aware that you can select a certain type of network request to filter your results, e.g. XHR. But maybe you are interested in both XHR and JS requests. By holding command and clicking different request types, you can select multiple types of requests at once.

Wrapping up

The Chrome Dev Tools are seriously impressive. These tips are just the tip of the iceberg. The deeper you dive into what features are available to you, the more amazed you will be. The documentation is a great reference. If you are more of a visual learner, I would recommend the Mastering Chrome Dev Tools on Frontend Masters by Jon Kuperman.

Thanks for reading, I hope you learned something!

If you enjoyed this post or found it useful, please consider sharing it on Twitter.

If you want to stay updated on new posts, follow me on Twitter

If you have any questions, comments, or just want to say hello, send me a message.

Thanks for reading!

Comparing Enzyme with React Testing Library

Adam Goth — Mon, 04 Jan 2021 08:59:08 +0000

Enzyme has long been a popular library for testing React applications. More recently, React Testing Library has been gaining traction in Enzyme's place. In this post, we'll take a look at how the two compare.

Overview

Enzyme is a JavaScript Testing utility for React that makes it easier to assert, manipulate, and traverse your React Components’ output. It was created by AirBnB and released in 2015. When using Enzyme, it is common to render the React component that you are testing and then test the component based on certain props or state that are passed in, or by calling functions contained within the component.

While Enzyme tests typically focus on components working correctly internally, React Testing Library is more focused on testing the React application as it is experienced by the user. Tests tend to be more focused on the state of the DOM after imitating user behavior rather than the state of a particular component or implementation.

To get a better understanding of this, let's look at some code.

Setting up

In order to compare these two testing libraries, I've created two separate repos. Both projects contain the same exact application (a to-do list, of course). The only difference is that one test file is written using Enzyme and the other is written using React Testing Library. You can easily follow along in this post without running the application, but if you are interested, both repos are available on GitHub.

Repo for testing with Enzyme

Repo for testing with React Testing Library

The file we're going to focus on in both repos is src/components/ToDo.test.js.

Below is our testing file, written in the typical style of Enzyme.

// testing-with-enzyme/src/components/ToDo.test.js

import React from "react"
import { mount } from "enzyme"
import ToDo from "./ToDo"

const setup = () => mount(<ToDo />)

describe("<ToDo/>", () => {
  describe("The default UI", () => {
    it("Renders two default todo items", () => {
      const app = setup()
      expect(app.find(".ToDoItem").length).toBe(2)
    })

    it("Has an input field", () => {
      const app = setup()
      expect(app.find(".ToDoInput").length).toEqual(1)
    })

    it("Has an add button", () => {
      const app = setup()
      expect(app.find(".ToDo-Add").length).toEqual(1)
    })
  })

  describe("Adding items", () => {
    window.alert = jest.fn()
    it("When the add button is pressed, if the input field is empty, prevent item from being added", () => {
      const app = setup()
      app.find(".ToDo-Add").simulate("click")
      expect(app.find(".ToDoItem").length).toBe(2)
    })

    it("When the add button is pressed, if the input field is empty, prevent item from being added", () => {
      const app = setup()
      app.find(".ToDo-Add").simulate("click")
      expect(window.alert).toHaveBeenCalled()
    })

    it("When the add button is pressed, if the input field has text, it creates a new todo item", () => {
      const app = setup()
      const event = { target: { value: "Create more tests" } }
      app.find("input").simulate("change", event)
      app.find(".ToDo-Add").simulate("click")
      expect(
        app
          .find(".ToDoItem-Text")
          .at(2)
          .text()
      ).toEqual("Create more tests")
    })
  })

  describe("Deleting items", () => {
    it("When the delete button is pressed for the first todo item, it removes the entire item", () => {
      const app = setup()
      app
        .find(".ToDoItem-Delete")
        .first()
        .simulate("click")
      expect(app.find(".ToDoItem").length).toBe(1)
    })
  })
})

And then, the same tests, written with React Testing Library.

// testing-with-react-testing-library/src/components/ToDo.test.js

import React from "react"
import { render } from "@testing-library/react"
import userEvent from "@testing-library/user-event"
import ToDo from "./ToDo"

const setup = () => render(<ToDo />)

describe("<ToDo/>", () => {
  describe("The default UI", () => {
    it("Renders two default todo items", () => {
      const { getAllByRole } = setup()
      expect(getAllByRole("listitem").length).toBe(2)
    })

    it("Has an input field", () => {
      const { getByRole } = setup()
      expect(getByRole("textbox")).toBeInTheDocument()
    })

    it("Has an add button", () => {
      const { getByLabelText } = setup()
      expect(getByLabelText("add")).toBeInTheDocument()
    })
  })

  describe("Adding items", () => {
    it("When the add button is pressed, if the input field is empty, prevent item from being added", () => {
      const { getByLabelText } = setup()
      window.alert = jest.fn()
      userEvent.click(getByLabelText("add"))
      expect(window.alert).toHaveBeenCalled()
    })

    it("When the add button is pressed, if the input field has text, it creates a new todo item", async () => {
      const { getByRole, getByLabelText, getByText } = setup()
      const toDoItem = "fake item"
      userEvent.type(getByRole("textbox"), toDoItem)
      userEvent.click(getByLabelText("add"))
      const item = await getByText(toDoItem)
      expect(item).toBeInTheDocument()
    })
  })

  describe("Deleting items", () => {
    it("When the delete button is pressed for the first todo item, it removes the entire item", async () => {
      const { getAllByRole, getByLabelText, queryByText } = setup()
      // default item
      const toDoItem = "clean the house"
      userEvent.click(getByLabelText(`delete ${toDoItem}`))
      const item = await queryByText(toDoItem)
      expect(item).toBeNull()
      // should only be 1 item left
      expect(getAllByRole("listitem").length).toBe(1)
    })
  })
})

Both files test for the following:

Renders two default todo items
Has an input field
Has an add button
When the add button is pressed, if the input field is empty, prevent item from being added
When the add button is pressed, if the input field has text, it creates a new todo item
When the delete button is pressed for the first todo item, it removes the entire item

Because we are using Enzyme's mount function, the components in both tests are rendered similarly, with an instance of the component being created and then attached to the actual DOM. This would not be true if we had used another popular Enzyme function, shallow to render our component. This post does not focus on that difference, but you can read more about the difference here.

The first significant way in that the tests start to differ is when we go to search for a particular element in the DOM to assert its existence or its state. Typically in an Enzyme test, you'll see elements searched for by their classname, as follows:

it("Renders two default todo items", () => {
  const app = setup()
  expect(app.find(".ToDoItem").length).toBe(2)
})

When writing the same test using React Testing Library, you'll notice that we instead use a method called getAllByRole, and pass it an ARIA role of listitem.

it("Renders two default todo items", () => {
  const { getAllByRole } = setup()
  expect(getAllByRole("listitem").length).toBe(2)
})

So why is one better than the other? While classnames are rather arbitrary, ARIA roles are not. ARIA roles provide additional context to elements for accessibility purposes. In the future, as developers, we may go and update our classname. We may tweak the name, we may change the style, we may entirely change how we wrote our CSS. If that happens, all of the sudden our test breaks. But the application has not broken. By querying by an element's role rather than its classname, we can ensure that we are testing the application by looking for elements in the same manner that a user with assistive technology may be looking at the application. We look for elements based on the purpose they convey to our users.

This concept is discussed in the React Testing Library docs, Which query should I use?, which provides recommendations for the order of priority in which you should query for elements. For example, if we can't find an element by its role, our next best bet is to look for a label. Why? Well, that's most likely what our users would do to find a certain part of the application. This highlights React Testing Library's guiding principles.

The more your tests resemble the way your software is used, the more confidence they can give you.

The library is written to provide methods and utilities that encourage you to write tests that closely resemble how your web pages are used. It purposely drives the user towards accessibility and away from testing implementation details.

Let's move on to another example and take a look at the difference in how we test that our application successfully creates a new item in the to-do list.

With Enzyme, it's common to manually create DOM events and then pass them to Enzyme's simulate function, telling it to simulate the change event with this event data that we've created. Below is an example of this.

// testing-with-enzyme/src/components/ToDo.test.js

it("When the add button is pressed, if the input field has text, it creates a new todo item", () => {
  const app = setup()
  const event = { target: { value: "Create more tests" } }
  app.find("input").simulate("change", event)
  app.find(".ToDo-Add").simulate("click")
  expect(
    app
      .find(".ToDoItem-Text")
      .at(2)
      .text()
  ).toEqual("Create more tests")
})

While this does what we'd expect to, it doesn't test the application in the same manner the user would use it. There is a lot of API and implementation information we need to know in order for the test to work. We need to know what the event should look like. We need to know which event API to simulate. We need to know the classname of the element we want to click. We need to know the classname of the new list item to look for is. And lastly, we need to know what order the element should be in so we can compare the text. None of these things are things the user actually knows or cares about. All they know is that when they type in the box and then click the add button, a new item is added to the list.

To get away from testing our code implementation and get closer to testing how the application is actually used, we turn once again to React Testing Library. Instead of creating fake DOM event objects and simulating various change events, we have the ability to mimic how users would actually interact with the application using userEvent's, which are provided by the user-event library.

user-event tries to simulate the real events that would happen in the browser as the user interacts with it. For example userEvent.click(checkbox) would change the state of the checkbox.

Using this, the same test written in React Testing Library looks as follows:

// testing-with-react-testing-library/src/components/ToDo.test.js

it("When the add button is pressed, if the input field has text, it creates a new todo item", async () => {
  const { getByRole, getByLabelText, getByText } = setup()
  const toDoItem = "fake item"
  userEvent.type(getByRole("textbox"), toDoItem)
  userEvent.click(getByLabelText("add"))
  const item = await getByText(toDoItem)
  expect(item).toBeInTheDocument()
})

In contrast to the Enzyme test, to write the React Testing Library test, we don't need to know much more than what the user would now. We first look for an element with the role of textbox, we then simulate the user typing by using userEvent.type, we simulate the user clicking with userEvent.click on the element with the accessibility label of add. We then assert that the text we typed in is appearing in the document.

In addition to being a much closer representation of the user's experience with the application, writing this test this way also makes for a much less brittle test. We could update classnames or change the number of items in the list and the test would still pass because the application would still be working. The same can not be said for the first test written in Enzyme.

Wrapping up

These examples are shown to attempt to highlight some of the benefits that React Testing Library offers and how it differs from the more traditional testing library of Enzyme. Everything React Testing Library offers always comes back to its guiding principle.

The more your tests resemble the way your software is used, the more confidence they can give you.

We've all been there before when a little tiny change to a component causes a test to break without actually breaking any functionality. React Testing Library, used properly, guides us away from writing these types of implementation tests and towards writing more accessible code and more robust tests that more closely resemble how the application is used.

While this post is intended to serve as a high-level introduction to React Testing Library and it's baked-in philosophy, it only scratches the surface of all the library has to offer. To learn more, visit the project's site at testing-library.com.

If you enjoyed this post or found it useful, please consider sharing it on Twitter.

If you want to stay updated on new posts, follow me on Twitter.

If you have any questions, comments, or just want to say hello, send me a message.

Thanks for reading!

Building a blog with Gatsby and MDX

Adam Goth — Tue, 29 Dec 2020 11:56:31 +0000

I've long considered trying out blogging. Now, I'm finally giving it a go.

This first post is all about how I built this blog feature into my site using Gatsby and MDX. For background context, I built this site about two years ago using Gatsby. Given that it is essentially a single landing page with various social links, using Gatsby wasn't entirely necessary, but I had been looking for an excuse to try it out. Fast forward two years, I've decided to make further use of Gatsby and leverage it to add a blog to the site. Here's how I went about it.

Overview

The basic idea behind this project is to use Gatsby plugins and APIs to dynamically generate blog pages from MDX files within our project. After our project is configured, adding a new blog post will be as easy as creating a new MDX file. The plugins we'll use include the gatsby-source-filesystem plugin and gatsby-plugin-mdx along with the createPages Gatsby Node API. After setting those up, we'll then take a brief look at how to template our posts and style our MDX elements. So how does all this work? Let's jump in.

Note: This blog post assumes basic Gatsby and React knowledge. If you are unfamiliar with Gatsby, there is a great tutorial series available on Gatsby's site to get you up to speed. Additionally, I will not be setting the project up step by step, but will provide enough information that you could easily integrate a similar blog feature into any existing Gatsby project.

Setting up

Our first requirement is the gatsby-source-filesystem plugin. What this plugin allows us to do is to use our project's filesystem as a source for data in our application. We will create a posts directory that will store our MDX files. We will then use gatsby-source-filesystem to query for those files and convert the content into blog posts.

Our second requirement is going to be the gatsby-plugin-mdx plugin. This is the official integration for using MDX within Gatsby. If you are unfamiliar with MDX, it is essentially a file format that allows you to combine standard Markdown with JSX. I won't go into much detail but it is pretty neat, especially if you are a React developer and are used to writing JSX. You can read more about MDX here. This is the file format we'll use to write our posts.

After installing both plugins, we can configure them in our gatsby-config.js file as follows.

module.exports = {
  ...,
  plugins: [
    {
      resolve: `gatsby-source-filesystem`,
      options: {
        name: `posts`,
        path: `${__dirname}/src/posts/`,
      },
    },
    `gatsby-plugin-mdx`,
  ],
}

The path value here is src/posts/ which is where I will store my MDX files. This configuration tells Gatsby to query this particular directory for data.

Now that we have our plugins configured, our project is ready to query for MDX files and turn them into blog pages. But just how do we tell it to do that?

The answer is Gatsby's createPages API. If you are familiar with Gatsby, you know that by default, Gatsby core creates pages for any React files that it finds in the src/pages/ directory. Similarly, this API allows us to instruct Gatsby to create additional pages based on the criteria we specify. When all is said and done, our gatsby-node.js file (located in the project's root directory) will look as follows:

const path = require("path")

exports.createPages = async ({ graphql, actions, reporter }) => {
  // destructure the createPage function from the actions object
  const { createPage } = actions

  const result = await graphql(`
    query {
      allMdx {
        edges {
          node {
            id
            frontmatter {
              slug
            }
          }
        }
      }
    }
  `)

  if (result.errors) {
    reporter.panicOnBuild('🚨  ERROR: Loading "createPages" query')
  }

  // create blog post pages
  const posts = result.data.allMdx.edges

  // call `createPage` for each result
  posts.forEach(({ node }, index) => {
    createPage({
      path: node.frontmatter.slug,
      component: path.resolve(`./src/components/posts-page-layout.js`),
      // you can use the values in this context in
      // our page layout component
      context: { id: node.id },
    })
  })
}

In the code above, we first query our filesystem for MDX files starting on line 7. These will be located in the directory we specified in our earlier configuration. Each node in our query results is an MDX file that was found.

Then starting on line 30, for each MDX file (or "post"), we call createPage, passing it a path value which will serve as our post's URL, a component value which will be used as our page template, and a context object which can hold additional data to be made available to us within our template component.

You may have noticed that on line 13, within each file result, we expect something called frontmatter. Frontmatter is a set of key-value pairs that can be used to provide additional data about the file. In our case, we're going to use frontmatter for storing information about the blog, including details such as our posts title, slug, date, author, and more. Frontmatter is denoted in a Markdown file by three dashes at the start and end of a block.

Creating posts from MDX files

Now that the project is configured to dynamically create pages from MDX files, we need to create our MDX file within the directory we specified our gatsby-source-filesystem configuration (src/posts/). If you are using a slug frontmatter key-value pair for your path value as we are, the name of the file is not so important, as long as it is an MDX file. For consistency, I will give it the same name as the slug (src/posts/building-a-blog-with-gatsby-and-mdx.mdx). Make special note of the frontmatter at the top of the file, located between the --- lines. The slug value is what will make your post available at http://<yourdomain>/<slug>. We will make use of the rest of the frontmatter data in our page template.

---
title: Building a blog with Gatsby and MDX
slug: building-a-blog-with-gatsby-and-mdx
author: Adam Goth
---

Blog content here...

The last missing piece that our createPages function expects is the template component that we specified as the component value in our createPage call. The value we passed is ./src/components/posts-page-layout.js, so let's go ahead and create that file.

import React from "react"
import { graphql } from "gatsby"
import { MDXProvider } from "@mdx-js/react"
import { MDXRenderer } from "gatsby-plugin-mdx"
import Layout from "../components/layout"
import components from "./mdxComponents"

export default function PageTemplate({ data: { mdx } }) {
  return (
    <Layout>
      <div style={{ padding: "0 1rem", marginBottom: "10rem" }}>
        <h1>{mdx.frontmatter.title}</h1>
        <h4
          style={{
            color: "gray",
            fontWeight: "normal",
          }}
        >{`${mdx.frontmatter.date} by ${mdx.frontmatter.author}`}</h4>
        <MDXProvider components={components}>
          <MDXRenderer>{mdx.body}</MDXRenderer>
        </MDXProvider>
      </div>
    </Layout>
  )
}

export const pageQuery = graphql`
  query BlogPostQuery($id: String) {
    mdx(id: { eq: $id }) {
      id
      body
      frontmatter {
        title
        date
        author
      }
    }
  }
`

There are a few things to make note of here. If you are familiar with Gatsby and React, nothing should look too out of the ordinary here. Starting on line 27, we are using a graphQL query called BlogPostQuery to query our filesystem for an MDX file with the matching id. The id is generated in our createPages function and is passed via the context parameter to our page template component. From the results, we get our body and frontmatter data for the blog post from our MDX file. We can then access the query data in our component via our component's props (see line 8 above).

Styling MDX content

If we wanted to render the body and frontmatter data as plain HTML elements within our JSX, we could go ahead and do that within our PageTemplate component above. In fact, that is how the title is being rendered on line 12. But @mdx-js/react and gatsby-plugin-mdx provide us with <MDXProvider /> and <MDXRenderer /> components. These components allow us to customize the style of our MDX content. Let's take a look at how.

In the above code block, we're importing components from './mdxComponents' and passing it to <MDXProvider />. This components prop on <MDXProvider /> allows us to pass customized components for each type of Markdown element we may expect to render.

For example, in Markdown and MDX, a standard line of text gets rendered as a paragraph (<p>) element. But for my posts, I want my paragraph elements to contain a certain line height different from the default. I also want to provide my own margin and width properties. The way this can be accomplished is by creating a custom paragraph MDX component and passing it into the components prop to MDXProvider />.

In my src/components/mdxComponents directory, I have a paragraph.js file that looks as follows:

import React from "react"

export default ({ children }) => <p style={{ lineHeight: "1.7", maxWidth: "750px", margin: "30px auto" }}>{children}</p>

In the same src/components/mdxComponents directory, I also have an index.js file which exports the component from paragraph.js as well as all the other elements I have created customized MDX components for. I then import that as an object named components and pass it to <MDXProvider />. The body of our MDX file data is then passed as the children prop to <MDXRenderer /> on line 20, which then makes use of these components when it renders the MDX content. In addition to the paragraph element, a full list of other elements that can be customized in MDX can be found here.

Wrapping up

That concludes the process for how I've built out a blog feature, as well as the very blog post you are reading. Using Gatsby plugins gatsby-source-filesystem and gatsby-plugin-mdx, along with Gatsby's createPages API, we are able to use MDX files to dynamically generate pages for blog posts. Going forward, for my next post, all I will need to do is write the new MDX file and add it to src/posts/. I eventually plan on adding additional features such as tags, categories, search, and who knows what else. So if you are interested in that as well, stay tuned!

If you are interested in viewing the source code for the project, the repository for my site is publicly available on Github.

If you enjoyed this post or found it useful, please consider sharing it on Twitter.

If you want to stay updated on new posts, follow me on Twitter

If you have any questions, comments, or just want to say hello, send me a message.

Thanks for reading!