DEV Community: Nick Scialli (he/him)

How the Web Works: What is a web server?

Nick Scialli (he/him) — Thu, 16 May 2024 14:29:30 +0000

This article is part of the How the Web Works series I'm running over on Substack! If you're interested in following along, check it out here:

https://howthewebworks.substack.com

In the last edition of How the Web Works, we talked about the web client. We concisely defined web clients as fancy document viewers. This week, we’ll talking about the other half of the “client-server” relationship: web servers!

The web server is where our fancy document viewer, the web client, gets its documents (and other data). Web servers are just computers that are usually physically located in a different place than web clients. While a web client might be located on a user’s laptop or cell phone, web servers will be located in a facility somewhere. Technically, this could even be a computer in a company’s closet. More often, however, web servers are found in massive data centers maintained by big tech companies (e.g., Amazon, Microsoft, and Google).

How clients and server work together

Let’s get a bit more specific about how web clients and web servers work together. One immediate question we need to answer:

How do web clients even find web servers in the first place?

This is a great question and, like pretty much everything else in web technology, is complex enough that it will receive its own newsletter edition! In short: web clients locate web servers using the Domain Name System (DNS). For now, we can think of it like this:

A user types www.example.com into their web browser’s URL bar and hits Enter
The web browser asks a service called DNS the following question: “Where can I find the web server for www.example.com“
DNS responds with the server’s IP address, which is used to route messages to the correct location.

Web clients and web servers communicate using Hypertext Transfer Protocol (HTTP), which again we’ll cover in much more detail in another edition! But in short, once a web client knows where a web server is, it can send a HTTP request. After the web server receives this request and decides what to do with it, it sends the client an HTTP response.

Putting this all together, we emerge with the following diagram:

The web client uses DNS to find the web server’s location. Then, it sends an HTTP request to the web server asking for the page.html document. Finally, the web server sends an HTTP response back to the web client with the page.html document content.

A more realistic picture

Realistically, web servers often connect to a bunch of different components like databases, file storage, and third-party services.

In this fictional scenario, the following happens:

A user types www.example.com into their web browser’s URL bar and hits Enter
The web browser asks a service called DNS the following question: “Where can I find the web server for www.example.com“
DNS responds with the server’s IP address, which is used to route messages to the correct location.
The web client sends an HTTP Request for page.html to the server
The server uses a third-party authentication service to check if the user is allowed to access page.html. The authentication service says that the user is indeed allowed access.
The server requests content from a database and a file storage service that is required to populate information in page.html.
Once all that information is assembled, the web server sends an HTTP response with the page.html content.

Whew! Now we’re getting somewhere. A couple things to note about this flow: First, we haven’t covered a bunch of the concepts in this flow, so don’t worry if it feels a bit overwhelming. Second, this flow is still a lot simpler than a lot of real-life applications. But that’s okay—we’re just on the second newsletter in our How the Web Works series after all!

Some important characteristics of web servers

While the web client is on the user’s device, you (or your company) has control over the web server. This has some really nice benefits!

More predictable hardware and software

When writing code for web clients, we generally have to stick to the technology commonly supported by users’ browsers and devices. This means we’re mostly stuck with HTML, CSS, and JavaScript code. And even then, different clients have varying levels of support for features of these languages. Furthermore, if someone is using an old or low-powered client, they may have trouble even running web application code if that code is more demanding. In short: coding for clients can be pretty tricky due to all the variability!

Web servers, on the other hand, are much more predictable. You generally know the exact hardware and software specifications of your web server. You can install and run any languages you want. Some popular options include Java, Python, Ruby, and JavaScript, but really anything is fair game.

A more secure environment

Web servers are more secure than web clients. While you should assume anyone can see information sent to their web client, it is reasonable to expect information you access on the web server will be private—unless you expose it. This means your web server can access a database that has information on all users in your system because your server code can pick which information to expose to web clients.

I should note here that securing your web servers is a big deal. The fact that web servers have access to protected information also makes them a target for bad actors. One large category of attacks is Remote Code Execution (RCE), where the attacker finds a way to run their code on your web server. If a bad actor does gain access to your web server, they could potentially gain access to user credentials, information about your users, trade secrets, etc.

Server security measures will mostly be outside the bounds of the How the Web Works material—security engineering is its own distinct profession and I wouldn’t do it justice.

You have to figure out how to accommodate varying loads of web traffic

While each user has their own web client, we do not have that luxury with web servers. This means we can run into issues with overloading our servers—imagine have 1,000, 10,000, or even 1,000,000 web clients trying to make requests to the same web server. Yikes!

While it’s out-of-scope for this edition of the newsletter, one important consideration for web servers is scaling. We’ll discuss scaling in its own edition of the newsletter, but in short you will often need to find a way to scale your web service to accommodate varying amounts of traffic. This can be done using vertical scaling (making your server more powerful) or horizontal scaling (adding more servers to handle the load).

Concluding thoughts

In the next could editions of the newsletter, we’re going to focus in on two of the technologies mentioned in this article that enable client-server communication: HTTP (the message request format) and DNS (how clients locate servers). Understanding web servers also unlocks a lot of related technologies we can look at—server-side programming, file storage, and databases, to name a few!

This article is part of the How the Web Works series I'm running over on Substack! If you're interested in following along, check it out here:

https://howthewebworks.substack.com

How the Web Works series: What is a web client?

Nick Scialli (he/him) — Mon, 13 May 2024 11:33:04 +0000

This article is part of the How the Web Works series I'm running over on Substack! If you're interested in following along, check it out here:

https://howthewebworks.substack.com

—--

If the goal of the How the Web Works newsletter is to thoroughly understand how the web works, there is no better place to start than the web client.

Web clients are the most-recognized, user-facing component of the web. You’re probably using one right now to read this newsletter article.

Common types of web clients

Common types of web clients include the following:

Web browsers (e.g., Chrome, Edge, Firefox, Safari)
Mobile applications (e.g., the LinkedIn application)
Desktop applications (e.g., the Spotify application)

Basically, any application that is used to browse the Internet or interact with web services can be thought of as a web client.

But what is a web client, really?

I just described web clients as any application used to browse the Internet or interact with web services, but I actually don’t think that definition does a good enough job at isolating the functionality of a web client well enough to gain a deep understanding of the web.

Instead, what I generally tell people is that web clients are fancy document viewers.

When you navigate to a website, there is a lot that goes on (much of which we’ll cover in subsequent editions of this newsletter!). But, at the end of the day, your browser (the web client) receives a document and displays it to you. Even though you had to browse to a website to get it, that document is now on your device!

If it seems strange that I’m focusing so much on the fact that the web client is a document viewer, I totally get it! But I promise there is a reason I’m doing so. As we get further and further into our exploration of how the web works, it is going to be critical to keep in mind the exact role the web client is playing.

Web browsers were first invented for linking documents together

In 1990, Tim Berners-Lee created the first web browser, the WorldWideWeb, while working at CERN. Berners-Lee’s browser was a graphical user interface (GUI) that allowed text documents to be linked together over a public network.

In 1994, Netscape released Netscape Navigator, the first commercial web browser, to the public. The following screenshot shows Netscape Navigator v2, which was released in 1995.

In the years to come, fierce competition between companies like Netscape, Microsoft, and Google would lead to rapid browser innovation, including Microsoft’s introduction of the first implementation of Cascading Style Sheets (CSS) in Internet Explorer and Netscape’s introduction of JavaScript.

While browsers have evolved to include a lot of additional, fancy functionality, they have always had a foundation in sharing documents.

What makes the web client a “fancy” document viewer?

These days, web clients don’t only display documents. They do quite a bit of work in order to make that happen! In the following sections, I’ll provide a list of some of this additional functionality. Note that we will spend some time on each of these topics in coming editions of the How the Web Works newsletter!

Parse and understand the languages of the web

All common browsers can parse and understand HyperText Markup Language (HTML), Cascading Style Sheets (CSS), and JavaScript. These three languages dictate the structure, display style, and interactivity of the documents you view. For example, HTML may specify what is heading text versus what is paragraph text. CSS would specify the size and color of those texts. Finally, JavaScript could make that text scroll across the page! (Note: just because we could doesn’t mean we should!).

Understand Hypertext Transfer Protocol (HTTP)

HTTP is a network protocol used to communicate between clients and servers on the web. In order to display documents (and other data) to users, web clients need to parse them from HTTP messages. Furthermore, web clients need to send HTTP messages to request or update data elsewhere on the web.

As a brief example, an HTTP message may look like this:



GET /index.html HTTP/1.1
Host: www.example.com

This message would request the contents from the index.html file from www.example.com. Don’t worry too much about trying to understand this example—we’ll get more into HTTP in a dedicated edition of the newsletter.

Keep you safe with various security measures

It’s a big, scary world out there! As you are probably aware, bad actors are constantly trying to find ways to steal peoples’ personal information. Web clients perform various security checks to try to keep you safe.

Some important safety measures that browsers perform:

Negotiate secure connections with web servers
Make sure a website’s content is truly being sent by the website owner
Prevent malicious code from being run inside your browser
Disallow websites from viewing your data associated with another website

Store pieces of information to help us interact with web services

Browsers store pieces of information on your computer to help you interact with web services. For example, you have likely heard of web cookies, which are often critical in maintaining your logged-in state on a website.

Main takeaways

We’ve spent some time talking about a familiar but critical piece of the web: the web client. If you take anything away from this edition of the newsletter, it should be the following:

A web client is a piece of software running on a user’s device. Common web clients are web browsers, mobile applications, and desktop applications.

Web clients are essentially a fancy document viewers. They do a lot more than this, but for the purposes of understanding the web, it’s helpful for us to think of them in this simple way.

In future editions of this newsletter, we’ll start building out our knowledge of the technologies that enable your web client to request documents (and other data) from web servers. Additionally, we’ll learn more about the technologies used within web clients to make modern web applications work.

Check out the newsletter

This article is part of the How the Web Works series I'm running over on Substack! If you're interested in following along, check it out here:

https://howthewebworks.substack.com

10x engineering for the rest of us

Nick Scialli (he/him) — Wed, 08 May 2024 11:00:51 +0000

The mythical 10x engineer is said to have the efficiency and output of 10 normal engineers. While their existence has been debated, I have actually worked with a couple 10xers over the course of my career.

As Santa Claus proclaimed in the undying M&Ms Christmas commercial: “They do exist!”

But before you get too exicted about their existence, I have some bad news to bear: working with this type of 10x engineer isn’t all that great. Who is going to review all the code this engineer just cranked out? All of a sudden you have an imbalance. You now either have team members spending much of their time reviewing a 10xer’s code (no fun) or you start piling up a backlog of pull requests authored by a single person.

So if this type of 10x engineer isn’t all that helpful, is there a type that is helpful? Yes! A looser definition of 10x engineering also includes engineers that are capable of technical depth and discovery very quickly. They can evaluate a complex feature for which there is no prior art in your code base and come up with an elegant solution quickly. The nuance here is about cognitive load rather than lines of code.

Now that I have described two types of 10x engineers, I have some more bad news: many of us, myself included, will never be 10x engineers by either of these definitions. But that’s okay! I think there’s actually another type of 10x engineering that’s attainable for the rest of us.

The third type of 10x engineer is one who works on the developer experience and health of the team. This engineer does their day job, but has an eye out for ways the team can run better. Here are some examples of improvements I have seen these kinds of 10x engineers make:

Tightening the development feedback loop. This includes things like speeding up automated tests and adding pre-commit hooks so failures occur locally rather than in continuous integration.
Implementing per-branch previews for design review (rather than having a limited number of preview environments).
Periodically auditing/fixing development setup instructions.
Adding caching to speed up continuous integration runs.

Think about the cumulative effects of these changes over time. That’s what makes this 10x work—it’s not that you yourself are doing 10x the work, but rather you’re improving the productivity of a bunch of engineers, resulting in a multiplying effect.

There are less technical ways to have this effect on teams as well. Consider doing glue work to keep the team running smoothly. One of my personal favorite contributions is being the engineer that sits down with product and design to make sure work is well-specified and ready to be estimated. Additionally, consider making a culture impact by approaching work with positivity, helping out junior engineers, and encouraging cross-discipline collaboration.

Maybe you find it a stretch to call this work 10x engineering—and that’s okay. It’s not important what we call it. What’s important is that focusing on improving the experience and productivity of your colleagues will make you an integral part of any team.

What are single page apps, really?

Nick Scialli (he/him) — Tue, 07 May 2024 17:42:29 +0000

🚀 If you enjoy this article, please give it a ❤️ and 🔖 to help others find it. Thank you!

Sometimes we get so immersed in learning technology that we forget to ask the basic questions. If you started learning front-end software development in the past few years, you were likely quickly introduced to single page application frameworks like React, Vue, and Angular—but their interaction with web servers and how things were in the “before times” may be a bit fuzzy to you.

Conversely, if you have been a web developer for a while in languages like Java, PHP, or Ruby, you may not have gotten into the single page application world (after all, popular server-side frameworks tend to have excellent templating features).

Regardless of your experience, it’s worth taking stock of how “conventional” web apps work and then how things are different in the single page app world.

Conventional web applications

The way web applications used to work was as follows: a user would navigate in their web browser (“the client”) to your website (let’s call it mywebsite.com). This would result in an HTTP GET request over the Internet to a computer somewhere (“the server”).

The server would look at this request and respond with an HTTP response that, among other information, includes some HTML. The client would receive that HTML and render it for the user to view and interact with.

🎓 Learn how the web works!

This article is taken from my newsletter, How the Web Works. You can sign up for free here: https://howthewebworks.substack.com. I won't spam and you can unsubscribe any time. You won't regret it!

Let’s say that HTML has a link to an “About” page located at mywebsite.com/about. If the user clicks on that link, the browser performs another HTTP GET request. Again, this request is sent over the Internet and received by your server. Your server sees that this is a GET request to the /about route. Based on that information, it sends a new reponse, this time with the HTML associated with the “About” page.

When the client receives the response to this request, the entire screen is replaced with the “About” page HTML. The user can now interact with the “About” page.

This interaction can be represented by the following diagram:

Importantly: for each page our user wants, a new HTTP request is sent over the Internet, a bunch of HTML is returned, and the user’s view is replaced with that HTML.

What is a single page application?

Our “conventional” application can be thought of as a multiple page application: for each link we click in our site, we get an entirely new HTML page back and our screen is totally refreshed.

But what if we didn’t have to contact the server every time we wanted to navigate somewhere in our website? What if the server sends all the necessary information to the client in response to the first request? Maybe we would avoid some page reload time since we wouldn’t have to keep reloading the server.

In other words, what if our client/server flow looked something more like this?

This is essentially what a single page application is. The user only really receives the html for one page (the “single page”) and then all browsing/navigation happens client-side.

Technically, this is accomplished using JavaScript. When a user performs an action or navigates someone else within the current application, some JavaScript executes an action that updates the view accordingly. This is usually faster than having to get a new page from the server since there is no network request involved.

Is it realistic to send everything to the client immediately?
In reality, we often have some data that can’t be sent to the client immediately. Perhaps we maintain a list of 500,000 books and the user is searching for one. It would be a very bad idea to send 500,000 book titles to the client on initial page load: the bandwidth and load time would be astronomical.

This doesn’t derail our single page application plans, though. It simply means our single page application sometimes needs to make HTTP requests from within the client-side JavaScript code. When our JavaScript code makes these requests, the server can just return the requested data rather than an entire HTML document. Once the JavaScript code has the result of this request, it populates the document accordingly.

Drawbacks

Single page applications have their drawbacks. If they get large enough, then you’re potentially sending way too much code to the client at one time and that can result in poor user experience. Because of this issue, features like code splitting have been developed. Code splitting separates the front-end code you develop into smaller bundles and sends them to the client only when needed.

Managing application state also gets complicated with single page applications. With multiple page applications, a request is sent the the server, the server does whatever data lookups it needs to do, and then HTML is sent to the client. In single page applications, server requests are happening in the background while users are looking at the HTML document. What do we show the user while these requests are happening? The application has to be in some state. What if there are a few different background requests going at the same time? Do we have one big “loading” indicator or a bunch of smaller indicators? What if one of the three requests fail? Do we show data for the the requests and then a failure indicator for the third?

Try it out

If you’re a programmer, one of the best ways to understand single vs. multiple page applications is to try them out. I’d recommend tinkering with the following frameworks depending on your skillset:

Front-end:

React
Angular
Vue
Svelte

Backend:

Express (Javascript)
Ruby on Rails (Ruby)
Django (Python)
Laravel (PHP)
Spring (Java)

🎓 Learn how the web works!

This article is taken from my newsletter, How the Web Works. You can sign up for free here: https://howthewebworks.substack.com. I won't spam and you can unsubscribe any time. You won't regret it!

How the web works

Nick Scialli (he/him) — Mon, 06 May 2024 16:49:52 +0000

If you like what I'm doing with How the Web Works, please give this post a ❤️ and 🔖 to help others find it! Thank you!

After my first couple installments of How the Web Works, I received a great suggestion to structure my articles to build off of each other. Based on that feedback, I created the following outline showing topics and their dependencies:

The way this diagram works is the lines represent dependencies: I generally don’t want to introduce a topic until I have covered any topic(s) pointing to it. For example, I wouldn’t write about client-side programming until I write about the web client.

Whether or not you feel like you know all of these topics, none of them, or somewhere in between, I think we’re going to learn quite a bit by going through this structured approach!

Also, I’m sure the list and structure isn’t perfect—but I think it’s a good start! Please let me know any suggestions you might have in the comments.

Note that this is cross-posted from my Substack! I would love if you wanted to subscribe there to receive updates over email:

Subscribe to the newsletter

Fresh off passing Google and Microsoft interviews, I put together an free, opinionated interview guide that I hope can help you

Nick Scialli (he/him) — Fri, 30 Sep 2022 17:08:13 +0000

If you'd like to support my efforts, please give this post a ❤️ and 🔖 to help others find it!

As many of us know, interviewing for software engineering jobs can be incredibly time-consuming and stressful. Recently, I had my own job search and was able to pass my interviews at Google and Microsoft. I decided to document my prep methodology and share it at https://interviewguide.dev.

What the guide covers

The guide aims to be opinionated and easily-digestible. It covers the following topics:

Preparing mentally

Interviewing is mentally tough. No one wants particularly enjoys being judged nor do they enjoy feeling like they failed. Furthermore, the amount of prep can be daunting.

Creating a schedule (both high and low-level)

One of the biggest mistakes you can make when prepping for interviews is to not have a schedule, including target dates for applying, interviewing, and obtaining a job.

Prep strategies for different interview types

Behavioral

Behavioral questions attempt to gauge how you would behave in stressful or otherwise adverse conditions. There are a couple common types of behavioral questions:

"Tell me about a time..." These questions are based on the idea that the best predictor of future behavior is past performance. The goal is to get you to present real examples of how you have handled things like conflict and failure in the past so the company can have some insight into how you may behave in the future.
Scenarios. Rather than looking for past examples, scenario question present you with situations and you're asked how you would handle them. Interviewers are generally looking for problem solving and empathy skills when asking these questions.

Studying for behavioral interviews is incredibly important! Almost any interview you do will have a behavioral component.

Read the behavioral section »

Values

Not to be confused with behavioral interviews, values interviews attempt to gauge how you align with a company's value system. For example, Google has its "Ten things we know to be true," which is a set of philosophies against which candidates might be assessed.

Some companies explicitly test against values while others unconsciously make this assessment. Regardless, it's very important to know a company's public values and be prepared to demonstrate how you align with them.

Read the values section »

Leetcode

Leetcode-style interviews are probably the most famous, or should I say infamous, type of interview. Leetcode is a website with algorithm and data structure programming problems. In Leetcode-style interviews, you solve algorithm and data structure challenges in front of one or more interviewers. These challenges are performed on a white board or a computer depending on the company's preference and whether the interview is being conducted in-person or remotely.

These challenges aim to test your problem solving, collaboration, and technical skill. Often, interviewers will ask for your understanding of the time and space complexity required to run the algorithm.

These types of interviews were popularized by big tech companies but are used throughout the industry. For those of us who are really uncomfortable with this type of interview, there are plenty of companies that do not use Leetcode-style interviews.

Read the leetcode section »

Practical coding

Practical coding interviews are my favorite types of technical assessments because they generally assess the kinds of things you'd actually be doing on the job. For example, if you're applying as a front-end engineer, your practical coding interview might be writing a small HTML, CSS, JavaScript application. If you already work as a front-end engineer, then you're practice for this style of interview every day at work!

Read the practical coding section »

System design

System design interviews are aimed at determining how more senior engineering candidates might go about designing a system. These interviews try to determine how the candidate thinks about systems as a whole, whether the candidate can elicit and clarify vague requirements, and depth of knowledge in the candidate's domain. System design interviews can be very fun but their open-endedness can also be very challenging.

Read the system design section »

Technical knowledge

Technical trivia interviews generally don't involve writing code, but rather ask you technical questions to determine how well you know a subject area. These types of interviews get a bad rap, but their effectiveness really depends a lot on what types of questions are asked. For example, asking about some uncommon/obscure language feature that can be googled quickly is pointless and a bad way to assess someone's domain knowledge. On the other hand, asking someone about a foundational aspect of a domain works may be useful. Technical knowledge questions are fairly common in all interviews.

Read the technical knowledge section »

Communication: before, during, and after the interview

Communication is extremely important. Before the interview, it can help you get an idea of what to expect and make sure you're prepared. During the interview, it helps you clarify problems and demonstrate your ability to problem-solve and be a good colleague.

Read the guide

You can find the guide at https://interviewguide.dev. I would love to know what you think!

Mutation isn't always bad in JavaScript

Nick Scialli (he/him) — Mon, 29 Nov 2021 13:24:52 +0000

We humans like dealing in absolutes. It's easy. Nuance is hard. Unfortunately for us, everything involves nuance. That's why we should question ourselves if we start to wonder if mutation is always bad.

Hey all, if you enjoy this article I’d love if you signed up for my free, weekly newsletter. 1,500+ other developers have already signed up and are leveling up their web dev skills with me!

The truth is mutation isn't always bad, nor is it usually bad. It just is. It's an excellent tool some languages give us to manipulate objects. Like with any tool, it's our responsibility to use it correctly.

What is object mutation?

Here's a quick refresher on object mutation. Let's say we have a person object:

const person = { name: 'Jarvis', age: 32 };

If we were to change this person's age, we will have mutated the object:

person.age = 33;

This seems innocuous, right?

Where mutation goes awry

Programming is all about communication and expectations. Mutation goes awry when the intent of an operation isn't clearly communicated and when a developer's (or machine's) expectations are violated.

Let's consider the following (bad) use of mutation:

function copyPerson(person, newName, newAge) {
  const newPerson = person;
  newPerson.name = newName;
  newPerson.age = newAge;
  return newPerson;
}

Why is this bad? Well let's look at what happens when we use this function in the wild:

const jarvis = { name: 'Jarvis', age: 32, arms: 2, legs: 2 };
const stanley = copyPerson(jarvis, 'Stanley', 27);

console.log(stanley);
// { age: 27, arms: 2, legs: 2, name: "Stanley" }

console.log(jarvis);
// { age: 27, arms: 2, legs: 2, name: "Stanley" }

Out expectations have been thoroughly violated!

In our copyPerson function, we accidentally assigned newPerson a reference to the same person object. Since they reference the same object, mutating newPerson also mutates person.

How do we fix this? We can do it entirely without mutation by copying the person object using the spread operator and simultaneously overwriting the name and age properties:

function copyPerson(person, newName, newAge) {
  const newPerson = {
    ...person,
    name: newName,
    age: newAge,
  };
  return newPerson;
}

And that will work! But we can also make it work with mutation, and this is totally fine. Some might even find it more readable!

function copyPerson(person, newName, newAge) {
  const newPerson = { ...person };
  newPerson.name = newName;
  newPerson.age = newAge;
  return newPerson;
}

So wait, if this is fine, was mutation actually the culprit? No, it wasn't. It was our lack of understanding about how references work.

Mutability and popular front-end frameworks

Popular front-end frameworks like React use references for render logic. Let's consider the following example:

function App() {
  const [person, setPerson] = useState({ name: 'Jarvis', age: 32 });

  return <PersonCard person={person} />;
}

In this example, the PersonCard component will re-render if person changes.

Actually, let's be more careful in our wording here: the PersonCard component will re-render person references a new object. Again, we can get ourselves in trouble if we mutate person rather than creating a new object.

For this reason, the following code will be buggy:

function App() {
  const [person, setPerson] = useState({ name: 'Jarvis', age: 32 });

  function incrementAge() {
    person.age++;
    setPerson(person);
  }

  return (
    <>
      <PersonCard person={person} />
      <button onClick={incrementAge}>Have a birthday</button>
    </>
  );
}

If we click the "Have a birthday" button, we increment the age property of the person object and then try to set the person state to that object. The problem is that it's not a new object, it's the same person object as the prevous render! React's diffing algorithm sees no change to the person reference and doesn't re-render the PersonCard.

How do we fix this? You guessed it: we just have to make sure we create a new object based on person. Then, we can either accomplish the task by mutating the new object or some other means:

function App() {
  const [person, setPerson] = useState({ name: 'Jarvis', age: 32 });

  function incrementAge() {
    const newPerson = { ...person };
    newPerson.age++;
    setPerson(newPerson);
  }

  return (
    <>
      <PersonCard person={person} />
      <button onClick={incrementAge}>Have a birthday</button>
    </>
  );
}

If your instinct here is that mutating newPerson is bad because we're using React, make sure to check your assumptions! There's nothing wrong here: newPerson is a variable scoped to the incrementAge function. We're not mutating something React is tracking, and therefore the fact that we're "in React" doesn't come into play here.

Again, it's very important to recognize here that mutation isn't bad. Our misunderstanding of object references and the React diffing algorithm are what caused the buggy behavior here.

When is mutation good?

Now that I have discussed some scenarios in which mutation often gets blamed for buggy behavior, let's talk about when mutation really shines.

Clarity

Often, I find mutation to be clearer. One example I like to use is if we need to create a new array with one of the elements in the array updated. When working in React, I have often seen the following:

function updateItem(index, newValue) {
  const newItems = items.map((el, i) => {
    if (i === index) {
      return newValue;
    }
    return el;
  });
  setItems(newItems);
}

And this works fine, but it's kind of confusing and probably a bit challenging to read for someone who isn't fluent in JavaScript array methods.

A more readable alternative, in my opinion, is to simply create a copy of the initial array and then mutate the appropriate index of the copied array:

function updateItem(index, newValue) {
  const newItems = [...items];
  newItems[index] = newValue;
  setItems(newItems);
}

I think that's a lot clearer.

Working with complex structures

One of my favorite examples of where mutability shines is building a tree structure. You can do this in O(n) time all thanks to references and mutation.

Consider the following array thay represents a flattened tree:

const data = [
  { id: 56, parentId: 62 },
  { id: 81, parentId: 80 },
  { id: 74, parentId: null },
  { id: 76, parentId: 80 },
  { id: 63, parentId: 62 },
  { id: 80, parentId: 86 },
  { id: 87, parentId: 86 },
  { id: 62, parentId: 74 },
  { id: 86, parentId: 74 },
];

Each node has an id and then the id of its parent node (parentId). Our code to build a tree can be as follows:

// Get array location of each ID
const idMapping = data.reduce((acc, el, i) => {
  acc[el.id] = i;
  return acc;
}, {});

let root;
data.forEach((el) => {
  // Handle the root element
  if (el.parentId === null) {
    root = el;
    return;
  }
  // Use our mapping to locate the parent element in our data array
  const parentEl = data[idMapping[el.parentId]];
  // Add our current el to its parent's `children` array
  parentEl.children = [...(parentEl.children || []), el];
});

How this works is we first loop through the data array once to create a mapping of where each element is in the array. Then, we do another pass through the data array and, for each element, we use the mapping to locate its parent in the array. Finally, we mutate the parent's children property to add the current element to it.

If we console.log(root), we end up with the full tree:

{
  id: 74,
  parentId: null,
  children: [
    {
      id: 62,
      parentId: 74,
      children: [{ id: 56, parentId: 62 }, { id: 63, parentId: 62 }],
    },
    {
      id: 86,
      parentId: 74,
      children: [
        {
          id: 80,
          parentId: 86,
          children: [{ id: 81, parentId: 80 }, { id: 76, parentId: 80 }],
        },
        { id: 87, parentId: 86 },
      ],
    },
  ],
};

That's really nifty and rather challenging to accomplish without mutation.

Key takeaways about object mutation

Over time, I have come to realize that there are a few key points to understand with respect to mutation:

Often we blame mutation for our own lack of understanding about how references work.
Popular front-end frameworks like React rely on comparing object references for render logic. Mutating older versions of state causes all sorts of headaches and hard-to-understand bugs. Instead of recognizing the nuance, developers will often avoid mutation entirely anywhere within React code.
Mutation is an excellent tool when its usage is clearly communicated.
Mutation is an excellent tool if localized (e.g., the mutated object never escapes a function).

Your First React GraphQL Frontend with the Apollo Client: A Gentle Introduction

Nick Scialli (he/him) — Tue, 23 Feb 2021 11:46:16 +0000

If you're integrating your React frontend with a GraphQL API, you may want to check out the Apollo client! I found it to be pretty straightforward to hook up.

In this post, we'll create a React project from scratch using create-react-app, add in the Apollo GraphQL client, and then use the SpaceX GraphQL API to display data in our application.

Please give this post a 💓, 🦄, and 🔖 if you want more introduction to GraphQL posts!

Creating a new React App

I'm going to use the yarn package manager to create a new React app called react-with-apollo. You can, of course, use npm if you'd like.



yarn create react-app react-with-apollo

We can cd into that directory and run yarn start to make sure our default React app is up-and-running on port 3000.



cd react-with-apollo
yarn start

If we navigate to http://localhost:3000, we'll get something like this:

Adding GraphQL the Apollo Client

To use GraphQL with the Apollo client, we need to install them both as project dependencies. Let's do that with yarn.



yarn add graphql @apollo/client

The next thing we need to do is configure out Apollo client. Normally this might require figuring out authentication with your GraphQL server but, since the SpaceX API is public, we don't need to worry about that. Instead, we just need to configure the client with our GraphQL API endpoint. We can additionally specify any caching we want to do for our queries. In this basic example, we'll just do some in-memory caching.

In this example, we'll configure our client in our index.js file and wrap our App in the Apollo provider. In practice you should probably put your Apollo provider as the lowest common ancestor for any components that will need to fetch data from the GraphQL API.

index.html



import React from 'react';
import ReactDOM from 'react-dom';
import './index.css';
import App from './App';
import reportWebVitals from './reportWebVitals';
import { ApolloClient, InMemoryCache, ApolloProvider } from '@apollo/client';

const client = new ApolloClient({
  uri: 'https://api.spacex.land/graphql/',
  cache: new InMemoryCache(),
});

ReactDOM.render(
  <React.StrictMode>
    <ApolloProvider client={client}>
      <App />
    </ApolloProvider>
  </React.StrictMode>,
  document.getElementById('root')
);

// If you want to start measuring performance in your app, pass a function
// to log results (for example: reportWebVitals(console.log))
// or send to an analytics endpoint. Learn more: https://bit.ly/CRA-vitals
reportWebVitals();

Querying the API

We're now all set up to query the API! In our App.js file, let's create a query that gets past SpaceX missions, including the date, launch site, and rocket. Of course, since this is GraphQL, it's trivial to grab all that information in one query.

We will include one variable in our query, numLaunches, just so we can see how to use variables.

App.js



import { gql } from '@apollo/client';

const PAST_LAUNCHES = gql`
  query GetPastLaunces($numLaunches: Int!) {
    launchesPast(limit: $numLaunches) {
      mission_name
      launch_date_local
      launch_site {
        site_name_long
      }
      rocket {
        rocket_name
      }
    }
  }
`;

function App() {
  // TBD
}

Now comes the part where we integrate the Apollo client. It has an incredibly handy useQuery hook that does a lot of heavy lifting for us. Basically, we pass the query we just defined, and any query options (in our case, just variables), and the hook returns a loading boolean, possibly an error object, and the returned data.



import { gql, useQuery } from '@apollo/client';

const PAST_LAUNCHES = gql`
  query GetPastLaunces($numLaunches: Int!) {
    launchesPast(limit: $numLaunches) {
      mission_name
      launch_date_local
      launch_site {
        site_name_long
      }
      rocket {
        rocket_name
      }
    }
  }
`;

function App() {
  const { loading, error, data } = useQuery(PAST_LAUNCHES, {
    variables: {
      numLaunches: 10,
    },
  });
}

Here we can see that we have provided our PAST_LAUNCHES query along with our numLaunches parameter, which we have set for 10 right now.

So—let's use the information the hook is returning to us! Since we're just learning now we'll have a very simple interaction. If loading is true, we'll show the user a "Loading..." message, if error is truthy, we'll tell the user something has gone wrong, and otherwise we'll format our query data in a readable way.



import { gql, useQuery } from '@apollo/client';

const PAST_LAUNCHES = gql`
  query GetPastLaunces($numLaunches: Int!) {
    launchesPast(limit: $numLaunches) {
      mission_name
      launch_date_local
      launch_site {
        site_name_long
      }
      rocket {
        rocket_name
      }
    }
  }
`;

function App() {
  const { loading, error, data } = useQuery(PAST_LAUNCHES, {
    variables: {
      numLaunches: 10,
    },
  });

  if (loading) {
    return <p>Loading...</p>;
  }

  if (error) {
    return <p>Oh no!</p>;
  }

  return (
    <ul>
      {data.launchesPast.map((launch) => (
        <li key={launch.mission_name}>
          <strong>{launch.mission_name}</strong>
          <ul>
            <li>
              Launch Date:{' '}
              {new Date(launch.launch_date_local).toLocaleDateString()}
            </li>
            <li>Rocket: {launch.rocket.rocket_name}</li>
            <li>Launch Site: {launch.launch_site.site_name_long}</li>
          </ul>
        </li>
      ))}
    </ul>
  );
}

export default App;

Of course, the structure of our data is exactly the same as the structure of our input query; one of the more helpful GraphQL features!

Let's check out our web app and see if things look alright.

Perfect! Looks great to me.

Updating Variables

In the last part of this post, let's explore how easy it is to re-fetch data if we update our variables. In this case, we may want a different number of past launches.

Our hope might be that we can just maintain a separate numLaunches stateful variable and, when we update that, we can cause te useQuery hook to fire again. In the following example, we just add a button to show five launches instead of 10. Trivial, but you get the idea!



import { gql, useQuery } from '@apollo/client';
import { useState } from 'react';

const PAST_LAUNCHES = gql`
  query GetPastLaunces($numLaunches: Int!) {
    launchesPast(limit: $numLaunches) {
      mission_name
      launch_date_local
      launch_site {
        site_name_long
      }
      rocket {
        rocket_name
      }
    }
  }
`;

function App() {
  const [numLaunches, setNumLaunches] = useState(10);
  const { loading, error, data } = useQuery(PAST_LAUNCHES, {
    variables: {
      numLaunches,
    },
  });

  if (loading) {
    return <p>Loading...</p>;
  }

  if (error) {
    return <p>Oh no!</p>;
  }

  return (
    <>
      <button onClick={() => setNumLaunches(5)}>Show 5</button>
      <ul>
        {data.launchesPast.map((launch) => (
          <li key={launch.mission_name}>
            <strong>{launch.mission_name}</strong>
            <ul>
              <li>
                Launch Date:{' '}
                {new Date(launch.launch_date_local).toLocaleDateString()}
              </li>
              <li>Rocket: {launch.rocket.rocket_name}</li>
              <li>Launch Site: {launch.launch_site.site_name_long}</li>
            </ul>
          </li>
        ))}
      </ul>
    </>
  );
}

export default App;

So does this work? Let's test it out.

You bet it does!

Concluding Thoughts

I'm enjoying the Apollo client with React quite a bit! It "just works" and offers the reactivity I need when executing GraphQL queries. Hopefully this post has helped you get started with GraphQL in React as well!

A Couple VSCode Themes I Made 🎨

Nick Scialli (he/him) — Mon, 15 Feb 2021 15:46:06 +0000

I made a couple of VS Code themes that I thought I'd share with you all!

1. Neon Glow

I'm a fan of neon color schemes and dark themes, so I figured I'd try my hand at making my own neon theme.

Install Neon Glow

2. Svelte Dark

I have been getting into the Svelte framework and decided it could use a dark theme.

Install Svelte Dark

Let Me Know What You Think

I'd appreciate it if you tried out these themes and let me know what you think! I'm certain they're not perfect so I'd love any suggestions.

How to Set Up a Svelte App with Rollup

Nick Scialli (he/him) — Mon, 15 Feb 2021 14:58:02 +0000

Svelte is a relatively new, blazing fast front-end UI library. Like some other front-end libraries (e.g., React), svelte code can't be immediately interpreted and executed by a browser. Instead, you have to add a build step that will take your Svelte code and turn it into the HTML, CSS, and JavaScript that browsers understand.

The post will explore the basics on how to build Svelte apps for development and production using Rollup.

Creating a Basic Svelte App

Let's create a super simple Svelte app to start with. First, we'll create our application directory, which we'll call my-svelte-app:

mkdir my-svelte-app

Next, let's navigate into that directory and initialize a new npm project. We'll use the -y flag to use default settings.

cd my-svelte-app
npm init -y

Great, we now have a basic package.json file. Of course, this is a svelte projects, so the first thing we'll want to do is actually install svelte as a development dependency.

npm i svelte

By convention, we'll write our app code in a src directory. We'll create that directory, an App.svelte file for our component code, and a main.js file, which will instantiate our app and tell it where to be inserted into the DOM.

mkdir src
touch src/App.svelte src/main.js

In our App.svelte file, we'll just have a paragraph that outputs "Hello [name]", where that name is a prop.

App.svelte

<script>
  export let name;
</script>

<p>Hello {name}</p>

Next up, we'll configure main.js. Here we create a new instance of our App, plan to load our app in the document's body (document.body), and we'll provide a name of "Daffodil" to our component.

main.js

import App from './App.svelte';

const app = new App({
  target: document.body,
  props: {
    name: 'Daffodil',
  },
});

export default app;

Perfect! We have finished setting our our Svelte app, but we have no way of running it in development mode or production; it's just a bunch of Svelte code right now.

As I stated before, we'll reach for Rollup to convert our Svelte code into browser-readable HTML, CSS, and JavaScript.

Adding Rollup

Rollup is a module bundler for JavaScript applications. It takes modular code, like our Svelte app, and bundles it into files that browsers can readily parse and display to users. This means converting things like our .svelte file and its various imports, props, etc., into HTML, CSS, and JavaScript files. Webpack is another such module bundler and can also be used for Svelte projects. Today, however, we focus on Rollup.

Getting Started with Rollup

One thing you might notice when you clone down a Svelte template (or a template from another UI library like React) is that the module bundler config files seem complex and unapproachable. The truth is that there is a lot that goes into these files, but if we create them from scratch and incrementally add features, we are able to see that it all makes sense and is very much doable.

That being said, let's get our hands dirty! The first thing we'll do is add rollup as a development dependency for our project.

npm i -D rollup

Next up, we need to add two additional rollup development dependencies:

@rollup/plugin-node-resolve, which is used to help rollup resolve third-party plugins
rollup-plugin-svelte a third-party plugin that helps rollup understand how to process Svelte apps

npm i -D @rollup/plugin-node-resolve rollup-plugin-svelte

Keep in mind that we're using the -D flag to install these as development dependencies. After all, we only use rollup in development; by the time we're in production our app has been built into HTML, CSS, and JavaScript.

Creating the Rollup Config File

Let's create a very simple rollup config file. For now, all it will do is bundle our Svelte app into JavaScript in a public/build folder.

touch rollup.config.js

In that file, our default export will be the rollup config object.

rollup.config.js

import svelte from 'rollup-plugin-svelte';
import resolve from '@rollup/plugin-node-resolve';

export default {
  // This `main.js` file we wrote
  input: 'src/main.js',
  output: {
    // The destination for our bundled JavaScript
    file: 'public/build/bundle.js',
    // Our bundle will be an Immediately-Invoked Function Expression
    format: 'iife',
    // The IIFE return value will be assigned into a variable called `app`
    name: 'app',
  },
  plugins: [
    svelte({
      // Tell the svelte plugin where our svelte files are located
      include: 'src/**/*.svelte',
    }),
    // Tell any third-party plugins that we're building for the browser
    resolve({ browser: true }),
  ],
};

Hopefully that's not too much at once! The input field tells rollup where the main entrypoint the app is, the output field specifies information about the bundled result, and the plugins filed tells rollup how to process the input application.

Adding Rollup to Our NPM scripts

The last thing we need to do before we take our app for a test drive is to make it so we can (a) run rollup with an npm script and (b) serve the content that's added to the public folder.

Running rollup with an npm script

To run rollup with an npm script, let's add a new script to our package.json file:

package.json

/* other package.json content here */
{
  "scripts": {
    "dev": "rollup -c -w"
  }
}
/* other package.json content here */

The -c flag indicates we want rollup to use a config file. Since we don't provide a file location, rollup will assume we have followed a convention, which we did when we named our config file rollup.config.js. The -w flag is super handy because it tells rollup to watch our included app files for changes. When there are any changes, rollup will helpfully rebuild our app into public/build/bundle.js.

Now if we go to the command line and run npm run dev, we should see that rollup has bundled our app into a new public/build/bunde.js file. Success!

Serving the content

We have our bundled JavaScript, but the browser isn't going to know what to do with that without an html file. Therefore, let's add an index.html file to our public folder:

touch public/index.html

Inside that index.html file, let's create an HTML file with nothing in the body. We will, however, want to make sure we add a scrpt tag that loads our bundled JavaScript from /build/bundle.js.

index.html

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>My Svelte App</title>
    <script defer src="build/bundle.js"></script>
  </head>
  <body></body>
</html>

Now, we need a simple web server to serve our index.html file. We will use a popular npm package called sirv-cli to do this. Since this is only for development, we will again only be adding sirv-cli as a dev dependency.

npm i -D sirv-cli

Now let's add an npm script to serve our app. We'll put this under the start script.

/* other package.json content here */
{
  "scripts": {
    "dev": "rollup -c -w",
    "start": "sirv public"
  }
}
/* other package.json content here */

Now we should finally be able to build and start our app! For now, we'll do so by first running the dev script and then the start script.

npm run dev && npm run start

You should now be able to navigate to http://localhost:5000 and see your Svelte app in all its glory!

Now if we change the the name prop in our src/main.js file to "Nick" (or your own name), rollup will helpfully rebuild our application. Note that our application won't refresh itself, we'll have to go ahead and refresh http://localhost:5000 to see the changes.

Those are the basics

Congrats, those are the basics to using rollup to build and serve your Svelte app! That was a good chunk of information, so it makes sense if you want to stop there. However, there are some enhancements and improvements we can make! If you still have the appetite, forge ahead with me to make our development process a bit more robust.

Enhancements and Improvements

There are quite a few improvements we can make to our project. We'll tackle two main improvements in this post: having rollup start the dev server for us and adding hot reloading to the project.

Much of the work here is derived from the Svelte starter template located here. Big thanks for the maintainers of that repo!

Having Rollup Start the Server

Running npm run dev && npm run start is a bit of a pain, we should only have to run npm run dev to get our dev server going. Therefore, let's use the flexibility of rollup plugins to create our own serve plugin.

Our custom serve plugin can be added to the top of our rollup.config.js file. It needs to export an object with a writeBundle key that is a function. We can then call our serve function in our plugins array.

rollup.config.json

import svelte from 'rollup-plugin-svelte';
import resolve from '@rollup/plugin-node-resolve';

function serve() {
  return {
    writeBundle() {},
  };
}

export default {
  input: 'src/main.js',
  output: {
    file: 'public/build/bundle.js',
    format: 'iife',
    name: 'app',
  },
  plugins: [
    svelte({
      include: 'src/**/*.svelte',
    }),
    resolve({ browser: true }),
    serve(),
  ],
};

Let's fill in the serve function. The following is a completed version of the function with some inline notes. Note that this blog post won't go into detail about spawning a child process in node as it's a bit out of scope!

function serve() {
  // Keep a reference to a spawned server process
  let server;

  function toExit() {
    // kill the server if it exists
    if (server) server.kill(0);
  }

  return {
    writeBundle() {
      if (server) return;
      // Spawn a child server process
      server = require('child_process').spawn(
        'npm',
        ['run', 'start', '--', '--dev'],
        {
          stdio: ['ignore', 'inherit', 'inherit'],
          shell: true,
        }
      );

      // Kill server on process termination or exit
      process.on('SIGTERM', toExit);
      process.on('exit', toExit);
    },
  };
}

Now we can go ahead and run npm run dev in our terminal and we'll see that our sirv server is started for us! We can navigate to http://localhost:5000 and we'll be up and running.

Adding Hot Reloading

You probably noticed earlier on that, when we made changes to our Svelte app, rollup would rebuild our bundle, but we had to refresh the browser in order to see changes. There's actually a pretty easy way to make that happen without having to manually refresh—there's a package for it called rollup-plugin-livereload!

npm i -D rollup-plugin-livereload

Then we simply add it to our rollup config plugins array. It takes a string argument specifying which folder to watch for live reloading. In this case, we wish to watch anything in public.

rollup.config.js

import svelte from 'rollup-plugin-svelte';
import resolve from '@rollup/plugin-node-resolve';
import livereload from 'rollup-plugin-livereload';

function serve() {
  // Keep a reference to a spawned server process
  let server;

  function toExit() {
    // kill the server if it exists
    if (server) server.kill(0);
  }

  return {
    writeBundle() {
      if (server) return;
      // Spawn a child server process
      server = require('child_process').spawn(
        'npm',
        ['run', 'start', '--', '--dev'],
        {
          stdio: ['ignore', 'inherit', 'inherit'],
          shell: true,
        }
      );

      // Kill server on process termination or exit
      process.on('SIGTERM', toExit);
      process.on('exit', toExit);
    },
  };
}

export default {
  input: 'src/main.js',
  output: {
    file: 'public/build/bundle.js',
    format: 'iife',
    name: 'app',
  },
  plugins: [
    svelte({
      include: 'src/**/*.svelte',
    }),
    resolve({ browser: true }),
    serve(),
    livereload('public'),
  ],
};

Now if we start our application with npm run dev, we see that our server will hot-reload the application whenever we make changes to our Svelte files. Neat!

Keep Exploring

There's so much more you can configure (CSS/preprocessor support, various config differences in production versus dev, a wide ecosystem of very cool plugins),
so hopefully this post has helped you dip your toe in and actually understand the Svelte/Rollup process enough to keep configuring it to your heart's desire!

Your First Node Express App with Typescript

Nick Scialli (he/him) — Tue, 19 Jan 2021 14:36:14 +0000

Express is the most ubiquitous framework for nodejs. In this post, we learn how to add Typescript to the mix.

The Goal

Our goal here is to be able to use Typescript to develop our application quickly, but ultimately we want our application to compile down to plain old javascript to be executed by the nodejs runtime.

Initial Setup

First and foremost, we'll want to create an application directory in which we host our app files. We'll call this directory express-typescript-app:

mkdir express-typescript-app
cd express-typescript-app

To accomplish our goal, we'll want to make a distinction between what we install as regular application dependencies versus development dependencies (i.e., dependencies that will help us develop our application but that won't be necessary after we compile our code).

Throughout this tutorial, I'll be using yarn as the package manager, but you could use npm just as easily!

Production Dependencies

In production, this will still be an express app. Therefore, we'll need to install express!

yarn add express

Note that this will create a package.json file for us!

For now, this will be our only production dependency (we'll add another later).

Development Dependencies

In development, we'll be writing Typescript. Therefore, we need to install typescript. We'll also want to install the types for both express and node. We use the -D flag to let yarn know that these are dev dependencies.

yarn add -D typescript @types/express @types/express @types/node

Great! But we're not quite done. Sure, we could stop here, but the problem is that we would need to compile our code every time we wanted to see changes in development. That's no fun! So we'll add a couple additional dependences:

ts-node—this package will let us run Typescript without having to compile it! Crucial for local development.
nodemon—this package automagically watches for changes in your application code and will restart your dev server. Coupled with ts-node, nodemon will enable us to see changes reflected in our app instantaneously!

Again, these are development dependencies because they only help us with development and won't be used after our code is compiled for production.

yarn add -D ts-node nodemon

Configuring our App to Run

Configuring Typescript

Since we're using Typescript, let's set some Typescript options. We can do this in a tsconfig.json file.

touch tsconfig.json

Now in our Typescript config file, let's set some compiler options.

module: "commonjs"—when we compile our code, our output will use commonjs modules, which we're familiar with if we've used node before.
esModuleInterop: true—this option allows us to do star (*) and default imports.
target: "es6"—unlike on the front-end, we have control of our runtime environment. We will make sure we use a version of node that understands the ES6 standard.
rootDir: "./"—the root directory for our Typescript code is the current directory.
outDir: "./build"—when we compile our Typescript to JavaScript, we'll put our JS in the ./build directory.
strict: true—enables strict type-checking!

All together, our tsconfig.json file should look like this:

{
  "compilerOptions": {
    "module": "commonjs",
    "esModuleInterop": true,
    "target": "es6",
    "rootDir": "./",
    "outDir": "./build",
    "strict": true
  }
}

Configuring package.json Scripts

Currently, we have no package.json scripts! We'll want to add a couple scripts: one script to start the app in development mode and another script to build the application for production. To start the application in development mode, we just need to run nodemon index.ts. For building the application, we've given our Typescript compiler all the information it needs in the tsconfig.json file, so all we have to do is run tsc.

The following shows what your package.json file might look like at this point. Note that your dependencies will likely be at different versions than mine since I wrote this at some point in the past (hello from the past, by the way).

{
  "dependencies": {
    "express": "^4.17.1"
  },
  "devDependencies": {
    "@types/express": "^4.17.11",
    "@types/node": "^14.14.21",
    "nodemon": "^2.0.7",
    "ts-node": "^9.1.1",
    "typescript": "^4.1.3"
  },
  "scripts": {
    "build": "tsc",
    "start": "nodemon index.ts"
  }
}

Git Config

If you're using git (I recommend it!), you'll want a .gitignore file to ignore your node_modules folder and your build folder:

touch .gitignore

And the file contents:

node_modules
build

Finished Setup!

I hope you've made it this far because we're done setup! It's not too bad, but definitely slightly more of a barrier to entry than a normal express.js application.

Creating our Express App

Let's create our express app. This is actually fairly similar to how we would do it with plain old JavaScript. The one difference is that we get to use ES6 imports!

Let's create index.ts:

touch index.ts

And in the index.ts file, we can do a basic "hello world" example:

import express from 'express';

const app = express();
const PORT = 3000;

app.get('/', (req, res) => {
  res.send('Hello world');
});

app.listen(PORT, () => {
  console.log(`Express with Typescript! http://localhost:${PORT}`);
});

Now in our terminal we can start the app by using yarn run start:

yarn run start

And you'll get an output like this:

$ nodemon index.ts
[nodemon] 2.0.7
[nodemon] to restart at any time, enter `rs`
[nodemon] watching path(s): *.*
[nodemon] watching extensions: ts,json
[nodemon] starting `ts-node index.ts`
Express with Typescript! http://localhost:3000

We can see nodemon is watching all our files for changes and launches our app using ts-node index.ts. We can now navigate to http://localhost:3000 in a web browser and see our "hello world" app in all it's glory!

Huzzah! (well, it's a start!)

Beyond "Hello World"

Our "Hello world" app is a nice achievement, but I think we can do more. Let's create some (very bad) user registration functionality to flex our express/typescript muscles a bit. Specifically, this functionality will:

Maintain a list of users and associated passwords in memory
Have a POST endpoint that allows users to register (i.e., adds an additional user to the aforementioned list)
Have a POST endpoint that allows users to attempt to sign in, issuing an appropriate response based on the correctness of provided credentials

Let's get started!

Maintaining Users

First, let's create a types.ts file in which we can declare our User type. We'll end up using this file for more types in the future.

touch types.ts

Now add the User type in types.ts and make sure to export it:

export type User = { username: string; password: string };

Okay! So rather than using a database or anything fancy like that, we're just going to maintain our users in memory. Let's create a users.ts file in a new directory, data.

mkdir data
touch data/users.ts

Now in our users.ts file, we can create an empty array of users and make sure to specify it as an array of our User type.

import { User } from "../types.ts;

const users: User[] = [];

POSTing New Users

Next, we'll want to be able to POST a new user to our application. If you're familiar with what an HTTP actually looks like, you know that variables will typically come across in the HTTP request body looking something like url encoded variables (e.g., username=foo&password=bar). Rather than parsing this ourselves, we can use the ubiquitous body-parser middleware. Let's install that now:

yarn add body-parser

And then we'll import and use it in our app:

import express from 'express';
import bodyParser from 'body-parser';

const app = express();
const PORT = 3000;

app.use(bodyParser.urlencoded({ extended: false }));

app.get('/', (req, res) => {
  res.send('Hello world');
});

app.listen(PORT, () => {
  console.log(`Express with Typescript! http://localhost:${PORT}`);
});

Finally, we can create a POST request handler on a /users endpoint. This handler will do a few things:

Check if both a username and password are defined on the request body and run some very basic validations on those fields
Return a 400 status message if there is anything wrong with the provided values
Push a new user to our users array
Return a 201 status message

Let's get to it. First, we create an addUser function in our data/users.ts file:

import { User } from '../types.ts';

const users: User[] = [];

const addUser = (newUser: User) => {
  users.push(newUser);
};

Now, we go back to our index.ts file and add the "/users" route:

import express from 'express';
import bodyParser from 'body-parser';
import { addUser } from './data/users';

const app = express();
const PORT = 3000;

app.use(bodyParser.urlencoded({ extended: false }));

app.get('/', (req, res) => {
  res.send('Hello world');
});

app.post('/users', (req, res) => {
  const { username, password } = req.body;
  if (!username?.trim() || !password?.trim()) {
    return res.status(400).send('Bad username or password');
  }
  addUser({ username, password });
  res.status(201).send('User created');
});

app.listen(PORT, () => {
  console.log(`Express with Typescript! http://localhost:${PORT}`);
});

Our logic here is simply that our username and password variables need to exist and, when using the trim() method, they need to be longer than zero characters. If those criteria fail, we return a 400 error with a custom Bad Request message. Otherwise, we push the new username and password onto our users array and send a 201 status back.

Note: You may notice that our array of users has no way of knowing if a username is added twice. Let's pretend our app doesn't have this glaring issue!

Let's take this signup logic for a test drive using curl! In your terminal, make the following POST request:

curl -d "username=foo&password=bar" -X POST http://localhost:3000/users

You should get the following response back:

User created

Success! Now, let's just verify that our request fails if we don't meet our validation criteria. We'll provide a password that's just one space character (" ".trim() is falsey so our validation will fail).

curl -d "username=foo&password= " -X POST http://localhost:3000/users

And we get the following response:

Bad username or password

Looking good to me!

Logging In

Logging in will be a very similar process. We'll grab the provided username and password from the request body, use the Array.find method to see if that username/password combination exists in our users array, and return either a 200 status to indicate the user is logged in or a 401 status to indicate that the user is not authenticated.

First, let's add a getUser function to our data/users.ts file:

import { User } from '../types';

const users: User[] = [];

export const addUser = (newUser: User) => {
  users.push(newUser);
};

export const getUser = (user: User) => {
  return users.find(
    (u) => u.username === user.username && u.password === user.password
  );
};

This getUser function will either return the matching user from the users array or it will return undefined if no users match.

Next, we use this getUser function in our index.ts file:

import express from 'express';
import bodyParser from 'body-parser';
import { addUser, getUser } from "./data/users';

const app = express();
const PORT = 3000;

app.use(bodyParser.urlencoded({ extended: false }));

app.get('/', (req, res) => {
  res.send('Hello word');
});

app.post('/users', (req, res) => {
  const { username, password } = req.body;
  if (!username?.trim() || !password?.trim()) {
    return res.status(400).send('Bad username or password');
  }
  addUser({ username, password });
  res.status(201).send('User created');
});

app.post('/login', (req, res) => {
  const { username, password } = req.body;
  const found = getUser({username, password})
  if (!found) {
    return res.status(401).send('Login failed');
  }
  res.status(200).send('Success');
});

app.listen(PORT, () => {
  console.log(`Express with Typescript! http://localhost:${PORT}`);
});

And now we can once again use curl to add a user, log in as that user, and then also fail a login attempt:

curl -d "username=joe&password=hard2guess" -X POST http://localhost:3000/users
# User created

curl -d "username=joe&password=hard2guess" -X POST http://localhost:3000/login
# Success

curl -d "username=joe&password=wrong" -X POST http://localhost:3000/login
# Login failed

Hey, we did it!

Exporing Express Types

You may have noticed that everything we have done so far, outside of our initial setup, is basic express stuff. In fact, if you have used express a bunch before, you're probably bored (sorry).

But now we'll get a bit more interesting: we're going to explore some of the types exported by express. To do so, we will define a custom structure for defining our routes, their middleware, and handler functions.

A Custom Route Type

Perhaps we want to establish a standard in our dev shop where we write all our routes like this:

const route = {
  method: 'post',
  path: '/users',
  middleware: [middleware1, middleware2],
  handler: userSignup,
};

We can do this by defining a Route type in our types.ts file. Importantly, we'll be making use of some important types exported from the express package: Request, Response, and NextFunction. The Request object represents the request coming from our client, the Response object is the response that express sends, and the NextFunction is the signature of the next() function you may be familiar with if you have used express middlware.

In our types.ts file, let's specify our Route. We'll make liberal use of the any type for our middleware array and handler function since we will want to discuss those further later.

export type User = { username: string; password: string };

type Method =
  | 'get'
  | 'head'
  | 'post'
  | 'put'
  | 'delete'
  | 'connect'
  | 'options'
  | 'trace'
  | 'patch';

export type Route = {
  method: Method;
  path: string;
  middleware: any[];
  handler: any;
};

Now, if you're familiar with express middleware, you know that the a typical middleware function looks something like this:

function middleware(request, response, next) {
  // Do some logic with the request
  if (request.body.something === 'foo') {
    // Failed criteria, send forbidden resposne
    return response.status(403).send('Forbidden');
  }
  // Succeeded, go to the next middleware
  next();
}

It turns out that express exports types for each of the three arguments that middlware take: Request, Response, and NextFunction. Therefore, we could create a Middleware type if we wanted to:

import { Request, Response, NextFunction } from 'express';

type Middleware = (req: Request, res: Response, next: NextFunction) => any;

...but it turns out express has a type for this already called RequestHandler! I don't love the name RequestHandler for this type, so we're going to go ahead and import it under the name Middleware and add it to our Route type in types.ts:

import { RequestHandler as Middleware } from 'express';

export type User = { username: string; password: string };

type Method =
  | 'get'
  | 'head'
  | 'post'
  | 'put'
  | 'delete'
  | 'connect'
  | 'options'
  | 'trace'
  | 'patch';

export type Route = {
  method: Method;
  path: string;
  middleware: Middleware[];
  handler: any;
};

Finally, we need to type our handler function. This is purely a personal preference since our handler could technically be our last middleware, but perhaps we have made a design decision that we want to single out our handler function. Importantly, we don't want our handler to take a next parameter; we want it to be the end of the line. Therefore, we will create our own Handler type. It will look very similar to RequestHandler but won't take a third argument.

import { Request, Response, RequestHandler as Middleware } from 'express';

export type User = { username: string; password: string };

type Method =
  | 'get'
  | 'head'
  | 'post'
  | 'put'
  | 'delete'
  | 'connect'
  | 'options'
  | 'trace'
  | 'patch';

type Handler = (req: Request, res: Response) => any;

export type Route = {
  method: Method;
  path: string;
  middleware: Middleware[];
  handler: Handler;
};

Adding Some Structure

Instead of having all of our middleware and handlers in our index.ts file, let's add some structure.

Handlers

First, let's move our user-related handler functions into a handlers directory:

mkdir handlers
touch handlers/user.ts

Then, within our handlers/user.ts file, we can add the follow code. This represents the one user-related route handler (signing up) that we already have in our index.ts file, we're just reorganizing. Importantly, we can be sure that the signup function meets our need because it matches the type signature of the Handler type.

import { addUser } from '../data/users';
import { Handler } from '../types';

export const signup: Handler = (req, res) => {
  const { username, password } = req.body;
  if (!username?.trim() || !password?.trim()) {
    return res.status(400).send('Bad username or password');
  }
  addUser({ username, password });
  res.status(201).send('User created');
};

Next up, let's add an auth handler that contains our login function.

touch handlers/auth.ts

Here's the code we can move to the auth.ts file:

import { getUser } from '../data/users';
import { Handler } from '../types';

export const login: Handler = (req, res) => {
  const { username, password } = req.body;
  const found = getUser({ username, password });
  if (!found) {
    return res.status(401).send('Login failed');
  }
  res.status(200).send('Success');
};

Finally, we'll add one more handler for our home route ("Hello world").

touch handlers/home.ts

And this one is pretty simple:

import { Handler } from '../types';

export const home: Handler = (req, res) => {
  res.send('Hello world');
};

Middleware

We don't have any custom middleware yet, but let's change that! First, add a directory for our middleware:

mkdir middleware

We can add a middleware that will log the path that the client hit. We can call this requestLogger.ts:

touch middleware/requestLogger.ts

And in this file, we can once again import RequestHandler from express to make sure our middleware function is the right type:

import { RequestHandler as Middleware } from 'express';

export const requestLogger: Middleware = (req, res, next) => {
  console.log(req.path);
  next();
};

Creating Routes

Now that we have our fancy new Route type and our handlers and middleware organized into their own spaces, let's write some routes! We'll create a routes.ts file at our root directory.

touch routes.ts

And here's an example of what this file could look like. Note that I added our requestLogger middleware to just one of the routes to demonstrate how it might look—it otherwise doesn't make a whole lot of sense to log the request path for only one route!

import { login } from './handlers/auth';
import { home } from './handlers/home';
import { signup } from './handlers/user';
import { requestLogger } from './middleware/requestLogger';
import { Route } from './types';

export const routes: Route[] = [
  {
    method: 'get',
    path: '/',
    middleware: [],
    handler: home,
  },
  {
    method: 'post',
    path: '/users',
    middleware: [],
    handler: signup,
  },
  {
    method: 'post',
    path: '/login',
    middleware: [requestLogger],
    handler: login,
  },
];

Revamping Our index.ts File

Now the payoff! We can greatly simplify our index.ts file. We replace all our route code with a simple forEach loop that uses everything we specified in routes.ts to register our routes with express. Importantly, the Typescript compiler is happy because our Route type fits the shape of the corresponding express types.

import express from 'express';
import bodyParser from 'body-parser';
import { routes } from './routes';

const app = express();
const PORT = 3000;

app.use(bodyParser.urlencoded({ extended: false }));

routes.forEach((route) => {
  const { method, path, middleware, handler } = route;
  app[method](path, ...middleware, handler);
});

app.listen(PORT, () => {
  console.log(`Express with Typescript! http://localhost:${PORT}`);
});

Wow this looks great! And, importantly, we have established a type-safe pattern by which we specify routes, middleware, and handlers.

The App Code

If you'd like to see the final app code, head on over to the github repository here.

Conclusion

Well, that was a fun exploration of express with Typescript! We see how, in its most basic form, it's not dissimlar to a typical express.js project. However, you can now use the awesome power of Typescript to give your project the structure you want in a very type-safe way.

How to Perfectly Fit an SVG’s ViewBox to its Contents Using JavaScript

Nick Scialli (he/him) — Tue, 19 Jan 2021 11:53:57 +0000

Using the SVG tag on websites is handy, but its interface can be different than we're used to. In this post, we're going to see how to fit the viewport of an SVG to its contents every time.

Please give this post a 💓, 🦄, and 🔖 if you want more SVG/visualization posts!

The Problem

In some cases, we might have an SVG with some arbitrary shapes or paths in it. Those shapes and paths may have specified dimentsions that don't always fit your viewport.

Let's consider the following SVG. We have two paths that I have taken from a map of the United States. One path is for the state of Maryland and the other is for the state of New York.

<svg style="height: 300px;">
  <path
    d="m 822.9,269.3 0,-1.7 h -.8 l 0,1.8 z m 11.8,-3.9 1.2,-2.2 .1,-2.5 -.6,-.6 -.7,.9 -.2,2.1 -.8,1.4 -.3,1.1 -4.6,1.6 -.7,.8 -1.3,.2 -.4,.9 -1.3,.6 -.3,-2.5 .4,-.7 -.8,-.5 .2,-1.5 -1.6,1 v -2 l 1.2,-.3 -1.9,-.4 -.7,-.8 .4,-1.3 -.8,-.6 -.7,1.6 .5,.8 -.7,.6 -1.1,.5 -2,-1 -.2,-1.2 -1,-1.1 -1.4,-1.7 1.5,-.8 -1,-.6 v -.9 l .6,-1 1.7,-.3 -1.4,-.6 -.1,-.7 -1.3,-.1 -.4,1.1 -.6,.3 .1,-3.4 1,-1 .8,.7 .1,-1.6 -1,-.9 -.9,1.1 -1,1.4 -.6,-1 .2,-2.4 .9,-1 .9,.9 1.2,-.7 -.4,-1.7 -1,1 -.9,-2.1 -.2,-1.7 1.1,-2.4 1.1,-1.4 1.4,-.2 -.5,-.8 .5,-.6 -.3,-.7 .2,-2.1 -1.5,.4 -.8,1.1 1,1.3 -2.6,3.6 -.9,-.4 -.7,.9 -.6,2.2 -1.8,.5 1.3,.6 1.3,1.3 -.2,.7 .9,1.2 -1.1,1 .5,.3 -.5,1.3 v 2.1 l -.5,1.3 .9,1.1 .7,3.4 1.3,1.4 1.6,1.4 .4,2.8 1.6,2 .4,1.4 v 1 h -.7 l -1.5,-1.2 -.4,.2 -1.2,-.2 -1.7,-1.4 -1.4,-.3 -1,.5 -1.2,-.3 -.4,.2 -1.7,-.8 -1,-1 -1,-1.3 -.6,-.2 -.8,.7 -1.6,1.3 -1.1,-.8 -.4,-2.3 .8,-2.1 -.3,-.5 .3,-.4 -.7,-1 1,-.1 1,-.9 .4,-1.8 1.7,-2.6 -2.6,-1.8 -1,1.7 -.6,-.6 h -1 l -.6,-.1 -.4,-.4 .1,-.5 -1.7,-.6 -.8,.3 -1.2,-.1 -.7,-.7 -.5,-.2 -.2,-.7 .6,-.8 v -.9 l -1.2,-.2 -1,-.9 -.9,.1 -1.6,-.3 -.9,-.4 .2,-1.6 -1,-.5 -.2,-.7 h -.7 l -.8,-1.2 .2,-1 -2.6,.4 -2.2,-1.6 -1.4,.3 -.9,1.4 h -1.3 l -1.7,2.9 -3.3,.4 -1.9,-1 -2.6,3.8 -2.2,-.3 -3.1,3.9 -.9,1.6 -1.8,1.6 -1.7,-11.4 60.5,-11.8 7.6,27.1 10.9,-2.3 0,5.3 -.1,3.1 -1,1.8 z m -13.4,-1.8 -1.3,.9 .8,1.8 1.7,.8 -.4,-1.6 z"
  ></path>
  <path
    d="m 872.9,181.6 -1.3,.1 -.5,1 z m -30.6,22.7 .7,.6 1.3,-.3 1.1,.3 .9,-1.3 h 1.9 l 2.4,-.9 5.1,-2.1 -.5,-.5 -1.9,.8 -2,.9 .2,-.8 2.6,-1.1 .8,-1 1.2,.1 4.1,-2.3 v .7 l -4.2,3 4.5,-2.8 1.7,-2.2 1.5,-.1 4.5,-3.1 3.2,-3.1 3,-2.3 1,-1.2 -1.7,-.1 -1,1.2 -.2,.7 -.9,.7 -.8,-1.1 -1.7,1 -.1,.9 -.9,-.2 .5,-.9 -1.2,-.7 -.6,.9 .9,.3 .2,.5 -.3,.5 -1.4,2.6 h -1.9 l .9,-1.8 .9,-.6 .3,-1.7 1.4,-1.6 .9,-.8 1.5,-.7 -1.2,-.2 -.7,.9 h -.7 l -1.1,.8 -.2,1 -2.2,2.1 -.4,.9 -1.4,.9 -7.7,1.9 .2,.9 -.9,.7 -2,.3 -1,-.6 -.2,1.1 -1.1,-.4 .1,1 -1.2,-.1 -1.2,.5 -.2,1.1 h -1 l .2,1 h -.7 l .2,1 -1.8,.4 -1.5,2.3 z m -.8,-.4 -1.6,.4 v 1 l -.7,1.6 .6,.7 2.4,-2.3 -.1,-.9 z m -10.1,-95.2 -.6,1.9 1.4,.9 -.4,1.5 .5,3.2 2.2,2.3 -.4,2.2 .6,2 -.4,1 -.3,3.8 3.1,6.7 -.8,1.8 .9,2.2 .9,-1.6 1.9,1.5 3,14.2 -.5,2 1.1,1 -.5,15 .7,1 2.8,16.3 1.8,1.5 -3.5,3.4 1.7,2.2 -1.3,3.3 -1.5,1.7 -1.5,2.3 -.2,-.7 .4,-5.9 -14.6,-4.9 -1.6,-1.1 -1.9,.3 -3,-2.2 -3,-5.8 h -2 l -.4,-1.5 -1.7,-1.1 -70.5,13.9 -.8,-6 4.3,-3.9 .6,-1.7 3.9,-2.5 .6,-2.4 2.3,-2 .8,-1.1 -1.7,-3.3 -1.7,-.5 -1.8,-3 -.2,-3.2 7.6,-3.9 8.2,-1.6 h 4.4 l 3.2,1.6 .9,-.1 1.8,-1.6 3.4,-.7 h 3 l 2.6,-1.3 2.5,-2.6 2.4,-3.1 1.9,-.4 1.1,-.5 .4,-3.2 -1.4,-2.7 -1.2,-.7 2,-1.3 -.1,-1.8 h -1.5 l -2.3,-1.4 -.1,-3.1 6.2,-6.1 .7,-2.4 3.7,-6.3 5.9,-6.4 2.1,-1.7 2.5,.1 20.6,-5.2 z"
  ></path>
</svg>

What we might expect to see is this:

But if we were to fire up our web browser and navigate to this page, we wouldn't see a thing. Why is that? Well, it's because these paths were taken from a full map of the U.S., so the origin (0, 0) point of the coordinate system being used is at the top-left of the entire country—next to Alaska.

This is no good as want our SVG to fit our two states perfectly.

Our Options

We have a couple reasonable options:

Transform each path such that it fits our current SVG view
Change our SVG "viewBox" to fit our paths

I personally like the second option and will go through that one in this post!

First, an Abstaction and a Tiny Bit of Math

Let's back off the states example for a moment and just use a couple arbitrary paths in an SVG:

We can see that our SVG is 100x100, but our shapes actually only start at about x = 40, y = 30 and end somewhew around x = 80, y = 90. What we'd love is for our SVG to zoom in on that area, so our view looks something like this:

How can we do this? It turns out the svg HTML element has a handy zoomBox attribute that lets us pass the desired origin's x and y values along with the desired width and height.

In the case of our shapes, we have the following:

We can see that our origin is at x=40, y=30 and then we have to do a little math for our width and height:

width = xMax - xMin = 80 - 40 = 40
height = yMax - yMin = 90 - 30 = 60

Therefore, we might specify the following viewBox for our SVG.

<svg viewBox="40 30 40 60">
  <!-- Shapes here -->
</svg>

And this works! Note that, by default, the SVG will center the objects in its viewBox rather than distorting them.

That Seems Tedious

Yes, it would be super tedious to do this math any time we want to use SVGs, and seems nearly impossible if we dynamic SVG children or many children.

Luckily, we're programmers! We enjoy automating things, so let's automate the process we just did in our heads.

Automatically Finding the Boundary

The way I like to automatically find the boundary is to iterate through all children of the svg. I use a native svg method called getBBox() that will return the x, y, width, and height of an element. Then, just some simple comparison: if the x is lower than all the other x values we have seen so far, it's the new xMin. Same with y. To get xMax and yMax, we do a similar operation, except we have to make sure we're looking at x + width and y + height for each element since x and y only give us the top-left point of the element and we want the bottom-right.

Here's how this code might look:

const svg = document.querySelector('svg');

const { xMin, xMax, yMin, yMax } = [...svg.children].reduce((acc, el) => {
  const { x, y, width, height } = el.getBBox();
  if (!acc.xMin || x < acc.xMin) acc.xMin = x;
  if (!acc.xMax || x + width > acc.xMax) acc.xMax = x + width;
  if (!acc.yMin || y < acc.yMin) acc.yMin = y;
  if (!acc.yMax || y + height > acc.yMax) acc.yMax = y + height;
  return acc;
}, {});

We use document.querySelector('svg') to grab the only SVG on our page (but make sure to use an ID or class if you need a different selector!). Next, I use [...svg.children] to (a) get all of the child elements of our svg and (b) use the spread operator (...) to convert the HTMLCollection to an array of elements. Have an array enables me to use the reduce method, which takes a callback function and an initial accumulator (an empty object {}).

Within the reduce callback, I use the getBBox() method on each element to get the x, y, width, and height. Using the aformentioned logic, we conditionally overwrite the xMin, xMax, yMin, and yMax, properties on our accumulator.

Our one final step is to set he viewBox attribute of the parent svg. Remember, the viewBox is set to x y width height, so we have to convert our xMax and yMax to width and height, respectively!

We can do this with the math we discussed in our simplified example:

width = xMax - xMin
height = yMax - yMin

Let's put it all together here:

const svg = document.querySelector('svg');

const { xMin, xMax, yMin, yMax } = [...svg.children].reduce((acc, el) => {
  const { x, y, width, height } = el.getBBox();
  if (!acc.xMin || x < acc.xMin) acc.xMin = x;
  if (!acc.xMax || x + width > acc.xMax) acc.xMax = x + width;
  if (!acc.yMin || y < acc.yMin) acc.yMin = y;
  if (!acc.yMax || y + height > acc.yMax) acc.yMax = y + height;
  return acc;
}, {});

const viewbox = `${xMin} ${yMin} ${xMax - xMin} ${yMax - yMin}`;

svg.setAttribute('viewBox', viewbox);

And we can see it in action with our state SVGs. In fact, we touted the flexibility of this solution, so it better be able to accommodate an additional state! Let's add North Carolina for good measure.

Conclusion

Thanks for playing with shapes, states, and even a little math with me today. Hopefully you learned something new today and how have a handy utility to fit items in your SVGs.