
When we started [Craftwork](https://craftwork.com), I had never used TypeScript before. I spent years building with good old fashioned JavaScript, and really loved it.

I could build prototypes quickly, change my strategy on the fly, and make new features fly together without much thought.

But... it was also a bit of a mess. Because JavaScript has _many_ weird quirks and "features", writing robust javascript code requires lots of discipline and experience. I certainly had some of both, but I knew from the onset that Craftwork would be a big project, and I wanted to make sure that I could build it in a way that would be maintainable and scalable.

I would be building an engineering team, and I wanted to make sure that they could hit the ground running. Using TypeScript as the de facto language for Craftwork was a no-brainer.

## JavaScript is weird.

When I say "JavaScript has many weird quirks and features", this is what I mean:

```javascript
'b' + 'a' + + 'a' + 'a' // 'baNaNa'
```

If you're not a developer, you might be thinking "what the hell is that?"

Me too, friend.

<small className="text-xs">
  There's [plenty more adorable gotchas](https://github.com/denysdovhan/wtfjs?tab=readme-ov-file#table-of-contents), and they're all fun and games until you're debugging a production issue at 3am.
</small>

Building a product is hard enough without having to worry about whether `NaN === NaN` (it doesn't) or why `[] + []` is an empty string.

<Image
  publicId="newsletters/typescript-and-learning-hard-things/duckhunt-dog"
  alt="Duck Hunt Dog laughing"
  caption="Math? Check."
/>


## Time to TypeScript

So, it was time to dive in to TypeScript. TypeScript is a superset of JavaScript that adds static types to the language. This means that you can catch _many_ bugs before they happen, and you can write more robust code.

Even still, when I started learning TypeScript, I did not have a great time.

There's a real learning curve to TypeScript - it is notoriously picky, and it can be hard to get started. I spent hours trying to figure out how to make TypeScript happy, and I spent even more hours trying to figure out why TypeScript was unhappy.

The truth is, I spent a _ton_ of time fighting the type system. I spent hours trying to figure out how to make TypeScript happy, and I spent even more hours trying to figure out why TypeScript was unhappy.

Eventually (after a few months, in my case), everything started to click. I got used to the error messages, and I was making my way through features more and more quickly.

## Learning to learn is the whole thing

I won't bore you with how-good-I-am-at-TypeScript - that's not important. What _is_ important is that I learned how to learn TypeScript. I learned how to research, how to ask questions, and how to find the answers I needed.

In my case, it was a mix of things: YouTube tutorials, blog posts, TypeScript documentation, and a network of mega-smart dev pals who I could ask for help when I was really stuck.

The best thing about being a person-on-the-internet is the ability to research and learn new things. If you can do that, you can do anything.

...which is a damn good thing, because like 3 weeks after I got comfortable with TypeScript, we started building Craftwork's core operating system with Ruby On Rails. 😅

## Keep learning

One of my biggest fears is becoming out of touch and irrelevant. I feel pretty strongly that when you _stop_ learning things, _everything_ starts to decline.

Keep learning, my friends. Keep pushing yourself to learn new things, and keep pushing yourself to learn _hard_ things.


---

## Great resources for learning TypeScript

It's Matt Pocock. He is _the_ educator for TypeScript. His [YouTube Channel @mattpocockuk](https://www.youtube.com/@mattpocockuk) is absolutely loaded with TypeScript tutorials, and he's a great teacher.

This dispatch of Tiny Improvements is inspired by (and _not_ sponsored by) Matt's work - I owe a lot of my TypeScript knowledge to him, and if you're looking to learn TypeScript, I can't recommend his channel enough.

This week, Matt Launched:
- A _huge_ new course called [TypeScript Pro Essentials](https://www.totaltypescript.com/workshops/typescript-pro-essentials)
- A massive, free, interactive book called [Total TypeScript Essentials](https://www.totaltypescript.com/books/total-typescript-essentials)

There's a [video on his channel describing the whole launch](https://www.youtube.com/watch?v=wgcfq51twe0), and it's worth a watch.

I love Matt's work - it's world-class stuff, and they the extra mile to offer Purchasing Power Parity - the price of his paid content scales to your local currency, which is a really nice touch.

---

## What are you learning?

I'd love to hear what you're learning these days, whether it's technical, non-technical, or somewhere in between. Hit reply and drop me a line via email, or shout at me on Threads [@irreverentmike](https://threads.net/@irreverentmike).



Struggling with TypeScript: why not?


Last year, I wrote a reflection on [the first 90 days as a technical cofounder](https://mikebifulco.com/newsletter/building-a-startup-in-2023-90-day-report) about the first three months of building Craftwork. That article was largely a reflection on the differences between building a company from scratch in 2023 versus the last time I did it, around 2016. Plenty has changed since then, and I think that article is still worth a read.

Today, I want to reflect on the first year of building [Craftwork](https://craftwork.com/). We've written many chapters of our story in the last year, and I think it's worth taking a moment to reflect on what we've accomplished and what we've learned.

<SponsoredSection
  CTAtext="Subscribe Today"
  href="https://codestory.co/"
  imagePublicId="sponsors/code-story/hero"
>

### Their tech, Their products.... Their Stories.


Code Story is a podcast featuring founders, tech leaders, CTOs, CEOs, and software architects, reflecting on their human stories in creating world changing, disruptive digital products.


</SponsoredSection>

## You won't know some things until you try

I've spent a good deal of my career working in UX. I've gotten to work with some incredibly talented designers and UX researchers, and I do believe that good design is a competitive advantage. Even still, when building real features for real people, you can't always predict what will work and what won't.

Designing great software needs to be both proactive and reactive - you need to have a vision for what you want to build, but you also need to actively respond to feedback and data.

For example: the very first version of Craftwork's estimate builder was designed to be _extremely_ self-serve - we built a tool that would let customers scope out their entire project without needing to talk to us. We thought this would be a great way to let people get a feel for what we could do for them, and to be extremely transparent about what their project would cost.

In practice, we found that people were often overwhelmed by the number of choices they had to make. Over and over we saw people getting stuck playing with our estimate builder, weighing the cost of one little change against another. Many people got stuck on this process, and never actually submitted a request for painting.

On a hunch, we ran a quick A/B test to see if it would be more productive to have a conversation with one of our team members first, and the results were clear: our customers have lots of interesting questions, and a price calculator wasn't answering all of them.

We've since reworked the estimate process to be more of a guided conversation, and we've found that using it to create a human connection with our customers has been a great way to build trust and to get the ball rolling on a project.

## You can't do it alone

While building my last company, I was convinced that we could do everything with an exceptionally small team - we were just 3 people, from inception to acquisition. I'm proud to say we did the damn thing, but it was _really_ difficult. You'll often hear founding employees at startups talk about how they're "wearing many hats" - that's definitely true, and it makes work a lot of fun. It's also true that you can't wear _all_ the hats. It's _also also_ true that there exciting, beautiful new hats out there that you don't know you need to wear.

From my first day as a working professional, I've always wanted to be surrounded by people who are smarter than me. Building Craftwork has been no exception - my cofounders are dedicated, talented, and damn good at what they do. We have also hired some _truly_ amazing people to build our team.

### A few things I've learned about building the right team:

Engineers tend to undervalue the importance of understanding the mechanics of the business. Our growth team at Craftwork has been instrumental in helping us understand how to reach new customers, and how to build a _profitable_ product that people want.

Building a brand is like nurturing a garden. It takes time, patience, and a lot of care. Craftwork's brand has really grown into something special, and it's been a joy to watch it happen. Give our [Instagram](https://www.instagram.com/craftworkpaint/) a peek if you want to see what I mean.

At this stage in the startup journey, hiring engineers is really challenging. The perfect engineer for a startup is someone who is comfortable with a lot of ambiguity, who can work independently, and who can communicate well... in addition to being technically competent. It's a tall order, and it can be a challenge to find the right people.

When I have roles open on my team, hiring is the most important thing I do day to day. It is also a full-time job in itself. It requires a fair deal of patience to assemble the right team, as well as a drive to actively and creatively seek out the right people.


## Just enough (and nothing more)

I recently came across the Japanese Phrase ほどほど (hodohodo), which means "just enough." I've been trying to use it as a reminder to keep things simple, and to avoid overcomplicating things. My team is tasked with building the features we need most _today,_ with eyes on what we'll need in 6 months and a year... and that can be overwhelming.  It's easy to spiral out of control with feature creep and over-engineering, and finding ways to help each other _just-enough-for-now_ is a team remit.

_Just enough_ spills over into many areas:
- **Build vs buy:** almost every feature our team needs can be bought from a SaaS vendor, or coach built by our product team. Making this decision can be nuanced and difficult, and it's something we revisit regularly.
- **Adopting tooling:** Engineers love to play with new tools - there's always a new framework, language, database, or library to poke around with. We've been very deliberate about what we adopt, and we've been very careful to avoid adopting things just because they're new and shiny. We have also adopted tools with good intentions, and found ourselves jettisoning them when they don't work out for one reason or another.
- **Shipping new features:** Adding new functionality for our customers and teammates is always tempting, but it's important to be mindful of the complexity that comes with each new feature. Our engineering team is small-and-mighty, and ever new feature we build means we have less time to support the features we've already built.

I used to say _Just enough (and nothing more)_ - there's a funny irony in that phrase. A year into this thing, this feels more accurate: Just enough <s>(and nothing more)</s>.

---

## More on building startups

If you're inerested in a more detailed look at the past year, here's a few more links you might find interesting:

- 🎙️ [My interview on the podcast CodeStory](https://codestory.co/podcast/e14-mike-bifulco-craftwork/) was released today. Codestory's creator, Noah, was kind enough to reach out about sponsoring this newsletter as well. Telling Craftwork's origin story is a good reminder of how far we've come in a year.
- 🥽 [Learning is an infinite game](https://mikebifulco.com/newsletter/learning-is-an-infinite-game) tells a little bit about how we used 3D printing tech to produce tooling for large-scale paint projects, and what it was like to dive in to CAD modeling after years away.
- 📋 Hiring is hard. There have also been a ton of layoffs in the past year-and-change. I wrote [Your Resume Sucks. Here's how to fix it](https://mikebifulco.com/newsletter/your-resume-sucks) in an effort to help engineers represent themselves better when looking for a job.

---

## Thanks for reading

I'm grateful for the opportunity to reflect on the past year, and I'm grateful for the opportunity to share it with you. If you have any questions about what it's like to build a startup, I'd love to hear from you. Reply to this email and let me know what's on your mind.


The first year of being a technical startup cofounder

Their tech, Their products.... Their Stories.

A few things I've learned about building the right team:


Reddit has been an incredible tool for me as a writer and a learner. I've benefitted from many subreddits over the years, by immersing myself special interest topics for fun, like Strava or Watchmaking or Woodworking. I've also used reddit to share articles I've written, and to research niches for product ideas.

One thing I really love about reddit is that it is a fairly even playing field - posts that get upvotes ones which are interesting to real people, and the discussions that result are often candid and helpful.

It's not a popularity contest, it's a meritocracy.

_Many_ of the technical subreddits I frequent have fairly strict rules about what can be posted. Moderators are quick to remove low-content or spammy posts, and the community is quick to downvote posts that don't add value. When it works, this results in a fairly high signal-to-noise ratio, making places like [/r/javascript](https://reddit.com/r/javascript) a great place to learn.

Reddit's community code of conduct also encourages participation - reddit's famous 10% rule states that you should spend 10% of your time posting and 90% of your time commenting. This helps to keep the community active and engaged, and it also helps to keep the community from being overrun by spam.

This is a good thing, because it means that the content that _does_ get posted is generally high quality, and the discussions that result are often helpful and interesting.

Since the beginning of 2023, I've tried to spend some time browsing subreddits for [JavaScript](https://reddit.com/r/javascript), [Next.js](https://reddit.com/r/nextjs), and [Computer science](https://reddit.com/r/computerscience). It's an interesting way to keep up with what's going on in the industry, and is a good way to keep my own skills sharp.

I used to dismiss reddit as something that I didn't understand - though I've had an account for years, I didn't use reddit regularly until about 2018. If you find yourself in the same boat, consider giving it a try - rather than spending your time doomscrolling on instagram and TikTok, create a reddit account and subscribe to subreddits that will help you _learn_ something. Whether it's directly applicable to your professional life or not, having a steady drip of discussion from topics that interest you can be a fantastic way to stay sharp, and to keep an eye out for new opportunities.

Once you've done that, consider adding to the community by participating in discussions and posting content of your own. You'll be surprised at how much you can learn by teaching others, and you'll be surprised at how much you can learn by asking questions.

---

## Some super subreddits that suprised me

- [r/firebase](https://reddit.com/r/firebase) is the home on reddit for people building products with Firebase. My last startup was built using Firebase, and this subreddit was a great resource for me. It is moderated by a team of Firebase employees, and full of experienced devs with great advice.
- [r/buyitforlife](https://www.reddit.com/r/BuyItForLife/) is a subreddit where people ask about and recommend products that are built to last.
- [r/nextjs](https://reddit.com/r/nextjs) is just what it sounds like: discussions about building with Next.js. For me, it serves as a helpful ear-to-the-ground for tooling and best practices.
- [r/nocode](https://www.reddit.com/r/nocode/) might be one of the most inspiring subreddits I've found. No code tooling has come _so far_ in the past few years. There are solo founders building entire companies on no code tools. It's incredible.

## It's been a little quiet...

...on the Mike-publishes-content front lately. I've got a few things to share soon which I'm excited to share with you, buuut not for another week or two. If you're jonesing for some fun reading, the APIs You Won't Hate community has produced some great stuff lately:

- 🎙️ [My interview with Constantin Schreiber from Fastgen](https://apisyouwonthate.com/podcast/no-code-apis-and-automation-with-constantin-schreiber-from-fastgen/) dives into the low-code tooling for API devs that Fastgen is building.
- 📝 My cofounder and pal Phil Sturgeon produced a great review tooling review - [APIMatic Review: Developer Experience-as-a-service](https://apisyouwonthate.com/blog/apimatic-review-dx-as-a-service/)


Reddit as a tool for learning


## Introduction

When working with Supabase, you may need to seed your database with initial data. This is a common task when setting up a new develper environment, or when you need to populate your database with predictable sample data for testing purposes. In this post, I'll show you a simple pattern for seeding your Supabase database using TypeScript.

## Prerequisites

This post assumes you have a [Supabase](https://supabase.com) project set up and a basic understanding of TypeScript. If you're new to Supabase, you can follow the [official documentation](https://supabase.io/docs/guides) to get started.

Although my site is built with [tRPC](https://trpc.io/), [Drizzle ORM](https://orm.drizzle.team/) and [Next.js]https://nextjs.org/, this pattern can be adapted for other frameworks, libraries, and databases.

### Seeding the database with sample data using Faker

This example uses a library called [Faker](https://fakerjs.dev/) to generate fake data. Faker is a popular library for generating random data such as names, addresses, and phone numbers. You can install it using your package manager of choice:

```bash
# note that faker is installed as a dev dependency
pnpm install faker -D
```

## Setting up the seed data

For this example, we will use a simplified Drizzle ORM Database schema with two tables - `chefs` and `recipeTypes`. Here's what the schema might look like:

```ts
// schema.ts

// ...other tables and imports above
export const chefs = createTable("chefs", {
  id: serial("id").primaryKey(),
  name: varchar("name", { length: 256 }).notNull(),
  email: varchar("email", { length: 256 }).notNull(),
  phone: varchar("phone", { length: 256 }),
  address: text("address"),
});

export const recipeTypes = createTable("project_type", {
  id: serial("id").primaryKey(),
  name: varchar("name", { length: 256 }).notNull(),
  description: text("description"),
});

export const recipes = createTable("recipes", {
  id: serial("id").primaryKey(),
  name: varchar("name", { length: 256 }).notNull(),
  description: text("description"),
  recipeTypeId: integer("recipeTypeId").references(recipeTypes.id),
  recipeChefId: integer("recipeChefId").references(chefs.id),
});
```

I try to keep my seed data organized in a `src/db/seed` directory. Each file in this directory contains seed data for a specific table in the database. For example, if you have a `chefs` table and a `recipeTypes` table, you would create two files: `chefs.ts` and `recipeTypes.ts`.

Here's an example of what the directory structure might look like:

```bash
src
└── db
    ├── seed
    │   ├── chefs.ts
    │   ├── recipes.ts
    │   ├── recipeTypes.ts
    │   └── seed.ts   // this is where we collate all seed data and insert into db
    ├── db.ts          // exports the db instance from Drizzle
    └── schema.ts      // database schema de  ition
```

## Creating seed data

This script will stick data into the `chefs`, `recipes`, and `recipeTypes` tables. To keep things neatly organized, each table is represented by its own file. Each of these files exports a function that seeds the data for that table, which is of the type:

```tsx
type SeedFunction = () => Promise<string>;
```

The string returned by each `SeedFunction`'s promise is a message that will be logged to the console when the seeding is complete. I use this to keep track of how many rows were inserted into the database.

### For tables with predefined data

The simplest option is tables with predefined or hand-written data. For these, I more-or-less hand-write objects to stick into the database. Here's an example of how to the `recipeTypes` table:

```tsx
import type { SeedFunction } from "../seed";
import { recipeTypes } from "../schema";
import db from "../db";

type RecipeTypeRow = {
  name: string;
  description: string;
};

// note the export: we will use this later
export const RecipeTypes: SeedFunction = {
  "Breakfast": { id: 1,  name: "Breakfast", description: "Breakfast recipes" },
  "Lunch": { id: 2, name: "Lunch", description: "Lunch recipes" },
  "Dinner": { id: 3, name: "Dinner", description: "Dinner recipes" },
} as const;

const seedRecipeTypes = async () => {
  // convert the object to an array of values
  const data = Object.values(RecipeTypes);

  await db.from(recipeTypes).insert(data);

  return `${data.length} Recipe types seeded successfully`;
};
```

Some things to note in the above code:

- We're creating an array of objects with predefined data for the `recipeTypes` table.
- We're inserting the predefined data into the `recipeTypes` table using the `db.from(recipeTypes).insert(data)` method.
- The `return` statement at the end of the function is a string, which will be logged to the console when seeding this table is complete.
- the `RecipeTypes` object is exported so we can use it in other seeding functions.

### Generating data with Faker

For tables that can use randomized data, a slightly different approach is used with the [Faker.js](https://fakerjs.dev/guide/) library, which can generate many different types of randomized data.

Here's how to populate the `Chefs` table with a list of fake chefs:

```tsx
import faker from "faker";
import { chefs } from "../schema";
import db from "../db";
import type { SeedFunction } from "../seed";

type ChefRow = {
  name: string;
  email: string;
  phone: string;
  address: string;
};

const seedChefs: SeedFunction = async () => {
  // generate random data for 10 people to stick into the chefs table
  const data: ChefRow[] = Array.from({ length: 10 }, () => ({
    name: faker.name.findName(),
    email: faker.internet.email(),
    phone: faker.phone.phoneNumber(),
    address: faker.address.streetAddress(),
  }));

  await db.from(chefs).insert(data);

  return `${data.length} Chefs seeded successfully`;
};
```

### Seeding related data

If you have tables with relationships, you can seed related data by using the `id` of the parent table. For example, if you have a `recipes` table that has a foreign key to the `recipeTypes` table, you can seed the `recipes` table with the `id` of the `recipeTypes` table.

Here's an example of how you might seed the `recipes` table with related data:

```tsx
import { recipes } from "../schema";
import db from "../db";
import { RecipeTypes } from "./recipeTypes";
import type { SeedFunction } from "../seed";

type RecipeRow = {
  name: string;
  description: string;
  recipeTypeId: number;
};

const seedRecipes: SeedFunction = async () => {
  const data: RecipeRow[] = [
    {
      name: "Pancakes",
      description: "Delicious pancakes",
      // use the id from the RecipeTypes object we exported earlier
      recipeTypeId: RecipeTypes.Breakfast.id,
      // since it can be any chef, we'll just use the first one
      recipeChefId: 1,
    },
    { name: "Spaghetti", description: "Classic spaghetti", recipeTypeId: RecipeTypes.Dinner.id, recipeChefId: 2 },
    { name: "Roast chicken", description: "Juicy roast chicken", recipeTypeId: RecipeTypes.Dinner.id, recipeChefId: 3 },
    { name: "Sandwich", description: "Good ol' ham & swiss", recipeTypeId: RecipeTypes.Lunch.id, recipeChefId: 4 },
  ];

  await db.from(recipes).insert(data);

  return `${data.length} Recipes seeded successfully`;
};
```

## Seed the database

Now that we have a script written for each table in the database, we we need to run them each in a specific order, as some tables may depend on others. I keep a file called `seed.ts` which to run each of the seeding functions in the correct order.

```tsx
import seedChefs from "./chefs";
import seedRecipes from "./recipes";
import seedRecipeTypes from "./recipeTypes";

const seedDb = async () => {
  // note: this function assumes we're starting with an empty database

  console.log("Seeding database...");

  console.log("Adding independent data...");
  const res = await Promise.allSettled([
    seedRecipeTypes(),
    seedChefs(),
    // add more independent seeding functions here
    // these will run in parallel
  ]);

  res.forEach((result) => {
    if (result.status === "rejected") {
      console.log("Error seeding database:", result.reason);
    } else {
      console.log(result.value);
    }
  });

  console.log("Adding related data...");
  const dependentTasks = [
    seedRecipes,
    // add more dependent tasks here, they will run in this order
  ];
  for (const task of dependentTasks) {
    try {
    const result = await task();
    console.log(result);
    } catch e {
      console.log("Error seeding database:", e);
    }
  }

  console.log("Seeding complete!");
};

seedDb()
  .then(() => {
    console.log("Seeding complete!");
    process.exit(0);
  })
  .catch((err) => {
    console.error("Error seeding database:", err);
    process.exit(1);
  });
```

You can run this script using your package manager of choice, by adding an entry to `package.json`:

```json
{
  "scripts": {
    // ...etc
    "seed": "tsx --env-file=.env src/db/seed/seed.ts"
    // ...etc
  }
}
```

Then, run the script using:

```bash
pnpm run seed
```

This will seed your database with the sample data you've defined. Note that we're using `Promise.allSettled` to ensure that all the seeding functions run in parallel. This can be useful if you have a large amount of data to seed. It will also catch any errors that occur during seeding and log them to the console.

`Promise.allSettled` returns an array of promises that are settled (either fulfilled or rejected). This allows you to handle each promise individually and log any errors that occur. It is different from `Promise.all`, which will reject the entire promise chain if any of the promises are rejected - you may want to use `Promise.all` if you want to stop seeding if any of the promises fail.

When run, your script should output something like this:

```bash
Seeding Database...
Adding independent data...
3 Recipe types seeded successfully
10 Chefs seeded successfully

Adding related data...
10 Recipes seeded successfully
Seeding complete!
```

## Adapt this pattern to your needs

This is a simplification of the pattern I use in my projects to seed my Supabase database. You can adapt this pattern to suit your needs by adding more tables, more data, or more complex relationships between tables. The key is to keep your seed data organized and to use a consistent pattern for seeding your database.

I use this to reset my database to a known state when I'm working on new features, and to set up my test environment with fresh, predictable data. It's a simple pattern, but it's been incredibly useful for me in my projects.


Seed your Supabase database with this simple pattern

Seeding the database with sample data using Faker


<small>

_note: This post is inspired by an article that my pal Josh Finnie wrote, showing [how he added JSON-LD to his Astro.js site](https://www.joshfinnie.com/blog/adding-json-ld-to-my-blog/): If you're an Astro-naut - give that a read. It's great!_

</small>

## SEO is the growth hack you're overlooking

Many devs overlook the value of SEO for their work.

I've long contended that learning a little bit about SEO can go a long way. It's in your best interest to configure your site so that Google, Duck Duck Go, and Bing know what your site is about, and what you're expert on.

In this brief tutorial, I'll share some information about Structured Data and JSON-LD, and how you can add it to your Next.js site to improve your site's SERP (Search Engine Results Page) presentation, with just a little bit of code and configuration.

## What is JSON-LD?

**JSON-LD (JSON Lightweight Linked Data format) is a metadata format** which can be added to your site to tell Google and other search engines what type of content is on each page. This can help search engines understand your content better, and can lead to better search results for your site. In reality, JSON-LD is _just_ a specific format for JSON which is human readable, and is meant to describe the content on a page in a way that search engines can understand. You can read more about it here: [https://json-ld.org/](https://json-ld.org/)

JSON-LD looks like this:

```json
{
  "@context": "https://json-ld.org/contexts/person.jsonld",
  "@id": "http://dbpedia.org/resource/John_Lennon",
  "name": "John Lennon",
  "born": "1940-10-09",
  "spouse": "http://dbpedia.org/resource/Cynthia_Lennon"
}
```

### What is Structured Data?

**Structured Data is a set of search-engine specific JSON-LD templates** that search crawlers look for to understand more about the information you're sharing online. It is _optional_ for your site, but can help bring more traffic to your site by increasing the chances that your site will show up in search results.

Adding the _right_ type of Structured data to your site means that when your pages come up in someone's search results, the search engine can display more information about your site, like reviews, ratings, and other rich snippets. Ever seen a recipe or a product review in a search result? That's because of structured data.

<Image
  publicId="posts/structured-data-json-ld-for-next-js-sites/apple-cobbler"
  alt="A search result featuring apple cobbler recipes, with a star rating, time to complete, a short ingredients list, and a photo"
  caption="Structured Data can help your site show up in search results with rich snippets like this one"
/>
<br />

### Types of Structured Data

There are many types of Structured Data you can embed on your site - [Google Search Central has a list of structured data features](https://developers.google.com/search/docs/appearance/structured-data/search-gallery) which that is worth a good look. Some examples of Structured Data include:

- **Article**: For news, blog, and other article pages
- **Events**: Showcases events like concerts, festivals, and other happenings
- **FAQ**: Make your FAQ page more discoverable
- **Product**: Details and information about a product you're selling
- **Recipe**: Ingredients, cook time, and other details about a recipe
- **Review Snippet**: A review of a product, service, or other item
- **Video**: For pages that showcase video content

Each of these formats are slightly different in content, but they use JSON-LD to describe the content in a way that search engines can understand. By way of example, this is the Structured Data for a post on my site about a livestream I did demonstrating [how to build a site with Astro, TypeScript, and React](https://mikebifulco.com/posts/live-astro-content-driven-website-rebuild):

```html
<script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@type": "VideoObject",
    "name": "Rebuilding an open source content-rich site with Astro, TypeScript, and React",
    "description": "A YouTube live coding stream, learning to build content-driven sites with the Astro Web Framework.",
    "thumbnailUrl": "https://i.ytimg.com/vi/wyJYInvZya8/hqdefault.jpg",
    "uploadDate": "2024-03-23T00:00:00.000Z",
    "contentUrl": "https://www.youtube.com/watch?v=wyJYInvZya8",
    "embedUrl": "https://www.youtube.com/embed/wyJYInvZya8",
    "duration": "PT1M33S"
  }
</script>
```

Not too bad, right? This JSON-LD tells Google that this page is a video, and gives Google some information about the video, like the title, description, and thumbnail. In theory, if someone searches for the title of the video, Google might show this video in the search results, with a thumbnail and a link to the video.

Once you've got Structured Data embedded on your site, you can verify that it's working using [Schema.org's Structured Data Testing Tool](https://validator.schema.org/):

<Image
  publicId="posts/structured-data-json-ld-for-next-js-sites/schema-org-validator"
  alt="Schema.org's Structured Data Testing Tool showing that my video structured data is valid"
/>

Similarly, you can use [Google's Rich Results Test](https://search.google.com/test/rich-results):

<Image
  publicId="posts/structured-data-json-ld-for-next-js-sites/rich-results-test"
  alt="Google's Rich Results Test showing that my video structured data is valid"
/>

If you want to poke around yourself, check out the [results for the video example above](https://search.google.com/test/rich-results/result?id=K92cqPpaYa6TcdmYuVrIzQ).

Pretty cool! So - now let's talk about how it's done.

## Adding Structured data to your Next.js site with JSON-LD

My site is built with Next.js - the articles you read here are written in an extension of Markdown called [MDX](https://nextjs.org/docs/pages/building-your-application/configuring/mdx), and the site is statically generated.

When I publish an article that features a YouTube video, I add frontmatter to the MDX file for the article that contains the ID of the video, and then I use that ID to generate the JSON-LD for the video.

Again, for the page above, that looks like this:

```mdx
---
title: 'Rebuilding an open source content-rich site with Astro, TypeScript, and React'
excerpt: A YouTube live coding stream, learning to build content-driven sites with the Astro Web Framework.
date: 2024-03-23
tags: [video, nextjs, typescript, astro]
coverImagePublicId: posts/live-astro-content-driven-website-rebuild/cover
path: live-astro-content-driven-website-rebuild
youTubeId: wyJYInvZya8
---

OpenApi.tools is an Open Source yada yada yada
```

Google provides an npm package called [schema-dts](https://www.npmjs.com/package/schema-dts) which contains types and helpers for generating JSON-LD. Start by installing this package:

```sh
npm install schema-dts
# or with pnpm
pnpm install schema-dts
# or with yarn
yarn add schema-dts
# or with bun
bun add schema-dts
```

Then, import the package and use it to generate a typed variable to contain a VideoObject's schema:

```tsx
import type { VideoObject, WithContext } from 'schema-dts';

let videoStructuredData: WithContext<VideoObject> | undefined = undefined;
```

<small className="text-xs">

**Shout out** to redditor [/u/AdrnF](https://www.reddit.com/r/nextjs/comments/1ccr79j/comment/l172n31/) for the tip. I didn't know this npm package existed!

</small>

Next, we'll need to populate this variable with the appropriate data for the schema. In my case, I'm using the `youTubeId` from the frontmatter to generate the JSON-LD for the video, like this:

```tsx
  let videoStructuredData: VideoStructuredData | undefined = undefined;

  if (youTubeId) {
    videoStructuredData = {
      '@context': 'https://schema.org',
      '@type': 'VideoObject',
      name: title,
      description: excerpt,
      thumbnailUrl: `https://i.ytimg.com/vi/${youTubeId}/hqdefault.jpg`, // this is the thumbnail for the video straight from youtube
      uploadDate: new Date(date).toISOString(),
      contentUrl: `https://www.youtube.com/watch?v=${youTubeId}`, // this is the URL for the video on youtube
      embedUrl: `https://www.youtube.com/embed/${youTubeId}`, // this is the URL for the video embed on youtube
      duration: 'PT1M33S', // this is the duration of the video

      /*
        note that I'm not using the entire VideoObject schema here, but
        you could add more fields if you wanted to, like interactionStatistic
        and regionsAllowed:
      */

      // interactionStatistic: {
      //   '@type': 'InteractionCounter',
      //   interactionType: { '@type': 'http://schema.org/WatchAction' },
      //   userInteractionCount: 0,
      // },
      // regionsAllowed: ['US'],
    };
  }
```

Once this object is created, I serialize it to a string and add it to a `<script>` tag on the page - depending on when and where you generate it, you can stick this in the `<head>` of your page, or right in the body of the document, like I do:

```tsx

 // snip -

  return (
    <>
      {videoStructuredData && (
        <script
          type="application/ld+json"
          dangerouslySetInnerHTML={{
            __html: JSON.stringify(videoStructuredData),
          }}
        />
      )}
      <article>
        {/* page content goes here */}
      </article>
    </>
  );

```

When the page is generated, you can inspect the source and see the JSON-LD embedded in the page - as in the example above.

You can double-check that your Structured data is valid using one the [Schema.org Structured Data Testing Tool](https://validator.schema.org/) before publishing by copy/pasting the generated HTML for your pages into the "code snippet" tab. Once you're happy with it, you can publish your article and you're good to go!

Job done. Google's crawler will see this JSON-LD and use it to understand the content on your page better, and you'll be on your way to better search results.

## Embed your Structured data server-side for best results

Embedding this information on in your articles in Next.js only takes a few steps, but it's critical that you do this _server-side_ to give google the best chances of seeing it. I'm using the Next.js `/pages` directory for my site -- articles are generated statically using `getStaticPaths` and `getStaticProps`, which means that the JSON-LD is generated at build time.

If you use the _App Router,_ you'll want to make sure that you embed your JSON-LD using a React Server Component (RSC), not using a client-side script.

If you're using a CMS, you'll want to make sure that the JSON-LD is generated when the page is statically rendered, and not when the page is loaded in the browser.

## Challenges with structured data

It's worth mentioning here that even if the schema validators can read your JSON-LD, it doesn't guarantee that Google will use it in search results. Google's search algorithms are complex, and they use many signals to determine what to show in search results.

I've been tweaking the implementation of Video structured data on posts like the one above, because the Google Search Console has been showing me that the structured data is valid, but it's not showing up in search results as a video:

<Image
  publicId="posts/structured-data-json-ld-for-next-js-sites/search-console-hates-me"
  alt="Google Search Console showing that my video structured data is valid, but not showing up in search results"
  caption="Google's crawler thinks my video isn't the main content of the page."
/>

There's still some work to do here, but I'm confident that with some more tweaking, I'll be able to get this working. If you know more about this, I'd love to hear from you! Drop me a line on [Threads @irreverentmike](https://threads.net/@irreverentmike) or email me <a href="mailto:hello@mikebifulco.com">hello@mikebifulco.com</a>.

These rules are always changing, and keeping up with them is a fulltime job in itself. Nonetheless, adding structured data to your site is a good practice, and can help your site show up in more search results -- even if you can't control exactly how it shows up.

## Keep adding Structured Data to your site

Now's your turn - go give it a shot. You may want to start with something like the [Profile Page](https://developers.google.com/search/docs/appearance/structured-data/profile-page) structured data format, or by adding one for [Articles](https://developers.google.com/search/docs/appearance/structured-data/article) to your posts.

For the amount of effort required, the payoff is worth it. Every little SEO boost you build into your site pays off in the long run. Think of it as an investment in the passive value of your content - the more you can do to make your content discoverable, the more likely it is to be found.

## Resources on SEO and Structured Data

As I mentioned above, this tutorial was inspired by [Josh Finnie's article on adding JSON-LD to his Astro.js site](https://www.joshfinnie.com/blog/adding-json-ld-to-my-blog/). Josh is a great developer and a good friend, and I recommend you check out his work.

I've written a few articles on SEO that you may find helpful:

- [3 Tiny tips for better SEO](https://mikebifulco.com/newsletter/tiny-tips-for-better-seo)
- [How to set up self-healing URLs in Next.js for better SEO](https://mikebifulco.com/posts/self-healing-urls-nextjs-seo)
- [SEO tools I used to grow my sites to 20k+ visitors/month](https://mikebifulco.com/posts/seo-tools-for-new-web-projects)
- [How to reset your Open Graph embed on LinkedIn, Twitter, and Facebook](https://mikebifulco.com/posts/reset-your-open-graph-embeds-on-linkedin-twitter-facebook)

And here are some tools that can help you get started with Structured Data:

- [Google's Structured Data Testing Tool](https://search.google.com/structured-data/testing-tool)
- [Google's Rich Results Test](https://search.google.com/test/rich-results)
- [Schema.org's Structured Data Testing Tool](https://validator.schema.org/)

If you found this helpful I'd love it if you shared the article with a friend.

I'm also keen to hear from you. Drop me a line on [Threads @irreverentmike](https://threads.net/@irreverentmike) or email me <a href="mailto:hello@mikebifulco.com">hello@mikebifulco.com</a> if you think I missed anything, or if you have any questions!


Add Structured Data to your Next.js site with JSON-LD for better SEO

SEO is the growth hack you're overlooking

Adding Structured data to your Next.js site with JSON-LD

Embed your Structured data server-side for best results


OpenApi.tools is an Open Source and community-driven list of high-quality, modern tools for OpenAPI that we've been maintaining over at APIs You Won't Hate for the past few years, and it's overdue for a rebuild.

🔧 In this session, I'll be using Astro.build to recreate the openapi.tools site, with a focus on building a highly performant, maintainable, and SEO-driven experience for the next version. If i'm lucky, we'll even get into building some fun new features to help our community find the right tools for their use case with OpenAPI

I'll be building with:

- Astro: https://astro.build
- Hosting through @VercelHQ
- Visual Studio Code
- TypeScript
- React.js
- Markdown
- Fathom analytics @FathomAnalytics
- PostHog @PostHog
- Tailwind CSS @TailwindLabs

📅 Mark your calendars and join me at 10am EST for an insightful journey through the intersection of design and development. If you dig SEO and markdown, or you're a React developer, JavaScript enthusiast or TypeScript pro, or you've been curious about what Atsro brings to the table, you'll enjoy this one!

Don't miss out on this opportunity to learn, create, and connect. Be sure to subscribe and click the notification bell to stay updated on this and more exciting content from Craftwork.

For additional resources like my newsletter for founders and product builders, 💌Tiny Improvements, visit my website at https://mikebifulco.com/newsletter


Rebuilding an open source content-rich site with Astro, TypeScript, and React


Join me for an exciting live stream where we dive into the world of design and development at Craftwork! 🎨💻

🔧 In this session, we'll explore how we use a variety of image templates to elevate our software's appearance. From stylized portraits of our talented team members to vibrant paint swatches and eye-catching Open Graph (OG) preview images for our website, we'll unveil the secrets behind our visual magic.

🖌️ We'll kick things off by using the power of Figma, our design tool of choice, to craft stunning templates. Then, we'll dive deep into the development side, where we'll transform these designs into dynamically generated images. How? With the incredible Satori library and the magic of Edge Functions on Next.js, brought to you by the team at @VercelHQ .

I'll be building with:

- Satori & Next.js from @VercelHQ
- Figma
- Visual Studio Code
- TypeScript
- Tailwind CSS @TailwindLabs

📅 Mark your calendars and join us on Jan 27th at noon EST for an insightful journey through the intersection of design and development. Whether you're a React developer, JavaScript enthusiast, TypeScript pro, designer, or simply curious about UX and tech, this livestream is for you!

Don't miss out on this opportunity to learn, create, and connect. Be sure to subscribe and click the notification bell to stay updated on this and more exciting content from Craftwork.

See you there! 🚀🎉


Using Satori and Next.js to generate dynamic images


## Notes about today's Livecoding stream
This is a YouTube Livestream, where I'll be working on integrating Resend Broadcasts into my next.js site to use for sending newsletters. Resend released a new set of features this week that makes it easier to send mail to large audiences.

I'll be building with:

- Resend
- Next.js
- TypeScript
- Vercel
- Tailwind CSS

With Substack recently catching headlines for their boneheaded content moderation policies, lots of creators and developers have been looking at other tools for managing their mailing lists. Between Beehiiv, ConvertKit, Ghost, Mailchimp, and some of the other usual suspects, there are many options to choose from.

Let's take a look at Resend's new API to see how it works, and if it's a good fit for my workflow!

## Don't forget to subscribe

If you're interested in more content like this, please subscribe to my **[YouTube channel - @mikebifulco](https://www.youtube.com/@mikebifulco?sub_confirmation=1)!**


Configuring Resend Broadcasts for newsletters on my Next.js website



<small>

_note: This post is inspired by a great video from YouTuber Aaron Francis: [Make self-healing URLs with Laravel](https://www.youtube.com/watch?v=a6lnfyES-LA). For all my PHP homies - go check that video out. It's great!_

</small>

<Image
  publicId="posts/self-healing-urls-nextjs-seo/demo"
  alt="A demo of a self-healing URL made in Next.js"
  caption="Ever wonder how Amazon and Medium create self-healing URLs?"
/>

Building sites with human-readable URLs is helpful for a few reasons: it gives users a better understanding of what they're getting when they click on a link to your site, it's better for SEO, and it's more accessible (screen readers can read out the URL to the user and they can understand where they are on the site). It's also just a nice thing to do for your users... by way of example, these two URLs _feel_ dramatically different:

`https://example.com/posts/c61sca0`

vs

`https://example.com/posts/how-to-set-up-self-healing-urls-in-nextjs-for-better-seo`

The first one is a bit of a mystery box. You have no idea what you're going to get when you click on it. The second one is much more descriptive, and _hopefully_ the contents of the page match the URL.

...but, what happens if you change the title of the post? The human-readable URL is now misleading. If you're using a static site generator like Next.js, you can use the file system to create self-healing URLs that will always point to the correct page, even if the title changes.

Or, what if you're managing a larger site, where it's possible that two posts may have the same title?

These are both issues that self-healing URLs are attempting to solve.

## What are self-healing URLs?

**Self-healing URLs are URLs that allow for human-readable text, but also include a unique identifier that will always point to the correct page**, even if the human-readable text changes, or gets removed entirely.

In this post, we'll learn **how to set up self-healing URLs in Next.js.** This is something used on sites like Amazon and Medium to make sharing links a little more robust. These are URLs that allow for human-readable text, but also include a unique identifier that will always point to the correct page, even if the human-readable text changes, or gets removed entirely.

Here's the URL-pattern we're to build: `https://example.com/posts/${POST_TITLE}-${POST_ID}`.

Ultimately, we'll use the `id` of a post to identify which content to render on a page, and we'll use the `title` of the post to create a human-readable portion in the URL. As long as the URL ends with a hyphen followed by the `id`, we will redirect to the correct page, with a nicely formatted, human-readable URL.

## Self-healing URLs in Next.js with the App router

To create self-healing URLs for blog posts with the [Next.js App router](https://nextjs.org/docs/api-reference/next/router), we'll start with a fresh react app from the cli:

```bash
# with npm
npx create-next-app

# or, with yarn
yarn create next-app

# or, with pnpm
pnpm create next-app
```

Give your project a name, and select the options you want to use. I used all the defaults for this example:

```
✔ What is your project named? … next-self-healing-urls-app-router
✔ Would you like to use TypeScript? Yes
✔ Would you like to use ESLint? Yes
✔ Would you like to use Tailwind CSS? Yes
✔ Would you like to use `src/` directory? Yes
✔ Would you like to use App Router? (recommended) Yes
✔ Would you like to customize the default import alias (@/*)? No
```

You'll also need to install the `slugify` package, which we'll use to create a URL-safe slug from the post's title:

```bash
npm install slugify

# or, with yarn
yarn add slugify

# or, with pnpm
pnpm add slugify
```

### Set up dynamic routing

We'll need to add a few files to the default setup. Using the App directory, create the following directories and files:

```
app
├── posts
│   └── [slug]         // note that this is a _folder_ called [slug]. This is how dynamic routes are set up in the app router
│        └── page.tsx  // render one post
├── not-found.tsx      // this will render if someone tries to visit a post page with an id that doesn't exist in the url
├── sitemap.ts         // generate a dynamic sitemap with the _correct_ canonical URL for each post
└── utils
    └── post.ts        // types and helper functions to load posts and format URLs
```

Let's start with `post.ts`. This file contains a type definition and helper functions to load posts and format URLs.

```ts
import slugify from 'slugify';

export type Post = {
  userId: number;
  id: number;
  title: string;
  content: string;
};

export const getAllPosts = async () => {
  // fetch all posts from an example API.
  // this is just a placeholder, replace with your own data
  // shout out to https://jsonplaceholder.typicode.com/ - what a great service!
  const postsResponse = await fetch(
    'https://jsonplaceholder.typicode.com/posts',
  );
  const posts = (await postsResponse.json()) as Post[];

  return posts;
};

export const getPostById = async (id?: string | number) => {
  if (!id) {
    throw new Error('No ID provided');
  }

  if (typeof id === 'string') {
    id = parseInt(id);
  }

  const allPosts = await getAllPosts();

  const post = allPosts.find((post) => post.id === id);

  if (!post) {
    // we'll use a try/catch block around this function later
    // to redirect if a post doesn't exist with this id,
    // so make sure to throw an error here.
    throw new Error('Post not found');
  }

  return post;
};

/**
 * Converts input to a URL-safe slug
 * @param {string} title - the title of the post
 * @returns {string} a URL-safe slug based on the post's title
 */
const titleToSlug = (title: string) => {
  const uriSlug = slugify(title, {
    lower: true, // convert everything to lower case
    trim: true, // remove leading and trailing spaces
  });

  // encode special characters like spaces and quotes to be URL-safe
  return encodeURI(uriSlug);
};

// given a post, return its slug
export const getPostSlug = (post: Post) => {
  return `${titleToSlug(post.title)}-${post.id}`;
};

// given any slug, try to extract an id from it
export const getIdFromSlug = (slug: string) => slug.split('-').pop();

```

### Generate a sitemap with the correct canonical URL for each post

Let's talk SEO for a moment: Google (and other search engines) use your site's sitemap file to understand the structure of your site. This helps them index your site more accurately, and it helps them understand which pages are the most important. Next.js supports static and dynamic sitemap generation, which you can read about in their [docs on sitemap.xml](https://nextjs.org/docs/app/api-reference/file-conventions/metadata/sitemap). Your sitemap should contain the canonical URL for every page in your site.

When Google and other search engines crawl your site, they use the Sitemap as an address book, and then visit each page found in the sitemap to analyze the content on the page, and deciding how to rank it in search results. If the URL in the address bar doesn't match the URL that Google has indexed for that page, it can cause problems with SEO. For example, if you have a page with the URL `https://example.com/foo/bar/some-url-here`, but Google has indexed the page as `https://example.com/foo/bar/some-other-url-here`, Google will think that you have two pages with the same content, and it will penalize you for duplicate content.

This is where the **canonical tag** comes in. The [canonical tag](https://ahrefs.com/blog/canonical-tags/) is a special bit of metadata that you can add to your page's `<head>` tag, which is used to tell search engines which URL is the _original URL for the content onthat page_. Ideally, the canonical URL for our blog posts should _exactly_ match the pattern we've set up for our self-healing URLs: `https://example.com/posts/${POST_TITLE}-${POST_ID}`. This is the URL that we want Google to index for each post. We'll do that by making sure we use this URL in our sitemap, and by adding a canonical tag to each post page.

A canonical tag looks like this:

```html
<link rel="canonical" href="https://example.com/foo/bar" />
```


So, this is what sitemap.ts looks like:

```ts
import { getAllPosts, getPostSlug } from '@/utils/posts';
import { MetadataRoute } from 'next';

export default async function sitemap(): MetadataRoute.Sitemap {
  const allPosts = await getAllPosts();

  let urlPrefix = 'http://localhost:3000';
  if (process.env.NODE_ENV !== 'production') {
    urlPrefix = 'https://example.com';
  }

  return allPosts.map((post) => ({
    url: `${urlPrefix}/posts/${getPostSlug(post)}`, // https://example.com/posts/this-is-a-post-1
    lastModified: new Date(), // ideally, this is the last modified date of the post
    changeFrequency: 'daily', // this will be used to determine how often pages are re-crawled
    priority: 0.7, // the priority of this URL relative to other URLs on your site
  }));
}
```

Now, if you run your app and visit `https://localhost:3000/sitemap.xml`, you should see a sitemap that includes an entry for each post, with the correct canonical URL specified.


### Setting up page.tsx: where the magic happens

In the file `app/posts/[slug]/page.tsx`, we use the [Next.js App Router's `generateStaticParams` function](https://nextjs.org/docs/app/building-your-application/routing/dynamic-routes#generating-static-params) to generate URLs for all posts. This function is called at build time, and it returns an array of objects that contain the `slug` for each post. The `slug` is used to generate the URL for each post page.

Then, in the server function which renders the post page, we check whether the current URL's readable portion matches the post's actual slug. If not, we redirect to the correct URL.

We also use the [Next.js App Router's `generateMetadata` function](https://nextjs.org/docs/app/next-script#generating-metadata) to generate metadata for each post. This function is called at build time, and it returns an object that contains the `title` and `alternates` for each post. The `alternates` object contains the `canonical` URL for each post, which is used to tell search engines which URL is the correct one for each post. **This is critical for SEO purposes** - it helps Google verify that when your page loads, the URL in the address bar matches the URL that Google has indexed for that page.


```tsx
import { Metadata, ResolvingMetadata } from 'next';
import { RedirectType, notFound, redirect } from 'next/navigation';
import { isRedirectError } from 'next/dist/client/components/redirect';

import { Post, getAllPosts, getPostById, getPostSlug } from '@/utils/posts';
import { getIdFromSlug } from '@/utils/posts';

// generate URLs for all posts
export async function generateStaticParams() {
  const posts = await getAllPosts();

  return posts.map((post) => {
    const slug = getPostSlug(post);

    return {
      slug,
    };
  });
}

type PostPageParams = {
  params: {
    slug: string;
  };
};

export default async function Post({ params }: PostPageParams) {
  const id = getIdFromSlug(params.slug);

  let post: Post;
  try {
    post = await getPostById(id);
    const correctSlug = getPostSlug(post);

    // check whether the current URL's readable portion matches the post's actual slug
    if (correctSlug !== params.slug) {
      // if not, redirect to the correct URL
      const redirectUrl = `/posts/${correctSlug}`;
      await redirect(redirectUrl, RedirectType.replace);
    }
  } catch (e) {
    // this is a hack to make redirects work from within a try/catch block
    // shout out to @jeengbe on github for the tip
    // https://github.com/vercel/next.js/issues/49298#issuecomment-1537433377
    if (isRedirectError(e)) {
      throw e;
    }

    // if the post doesn't exist, return the "not found" 404 page
    notFound();
  }

  // make your post look nice IRL
  return <div>My Post: {params.slug}</div>;
}

export async function generateMetadata(
  { params }: PostPageParams,
  parent: ResolvingMetadata,
): Promise<Metadata> {
  // read route params
  const id = getIdFromSlug(params.slug);
  // fetch data
  const post = await getPostById(id);

  return {
    title: post.title,
    alternates: {
      canonical: `https://example.com/posts/${params.slug}`,
    },
  };
}
```

Another important note - _entire_ component is rendered server-side - visitors to this page won't see any content flash on screen if they enter an incorrect URL. This is huge for page performance and SEO purposes, and has traditionally been challenging while using Static Site Generation.

Instead of a screen flash, your users get a great experience: they can try to load an incorrect URL, and as long as the URL ends with a hyphen followed by the `id`, they'll be redirected to the correct URL seamlessly, like magic. If the URL doesn't match the pattern, they'll be redirected to the 404 page.



### Not Found: a 404 page for posts that don't exist

In `app/not-found.tsx`, create a 404 page that will render if someone tries to visit a post page with an id that doesn't exist in the url. [Next provides a `notFound` function](https://nextjs.org/docs/app/api-reference/functions/not-found) that will return a 404 page. We used this in page.tsx to return a 404 page if the post doesn't exist. You'll want to make this page look nice and include some helpful text, but for the sake of this example, we'll keep it simple:

```tsx
/*
  redirect to this page by calling the `notFound` function from the App Router in a page's server function:
  import { notFound } from 'next/navigation';
*/

export default function NotFound() {
  return <div>Not Found</div>;
}
```

## Try it out!

That should do it! run `yarn dev` to start the server, and navigate to `http://localhost:3000/posts/1` - you'll see it _automatically_ redirect to a better URL.

<Image
  publicId="posts/self-healing-urls-nextjs-seo/demo"
  alt="A demo of a self-healing URL made in Next.js"
/>

Nice!

Head over to `http://localhost:3000/sitemap.xml` and check out the nicely formatted sitemap, with the correct canonical URL for each post. Now your web app, your readers, _and_ Google are all on the same page. 🔥

## To do: update your redirects when a post's title changes

To be completely thorough there's one more thing we should probably do: if a post's title changes, you should add an entry to your redirects file to redirect the old URL to the new one. Even though this is a self-healing URL, it's still a good idea to add a redirect for the old URL, just in case someone has bookmarked it, or if someone has shared it on social media. This will also help Google understand that the old URL is no longer the correct one, and that it should index the new URL instead.

This is a bit more challenging, but it's worth it.

Because making this work is dependent on your specific setup, I'm not going to include a code example here, but I'll give you a few pointers:

- In your CMS, when a post is saved, check whether the title has changed. If it has, add an entry to your redirects file to redirect the old URL to the new one.
- It's a good to make sure that you don't accidentally create a redirect loop. If the new URL for a given path is the same as any of the prior URLs, don't add a new redirect, and remove any existing redirects for that path.
- You may need to kick off a rebuild of your site to make sure that the new redirect is picked up by your app. If you're using Vercel, you can use their [API to trigger a rebuild](https://vercel.com/docs/api#endpoints/deployments/redeploy-all-deployments) when a post is saved.


## Summary: self-healing URLs in Next.js

In this post, we learned how to set up self-healing URLs in Next.js. We used the App Router to generate URLs for all posts, and we used the App Router's `generateMetadata` function to generate metadata for each post. This function is called at build time, and it returns an object that contains the `title` and `alternates` for each post. The `alternates` object contains the `canonical` URL for each post, which is used to tell search engines which URL is the correct one for each post. **This is great for SEO purposes** - it helps Google verify that when your page loads, the URL in the address bar matches the URL that Google has indexed for that page. It also has usability benefits: if your post's title ever changes, the URL will magically update itself to match the new title. Additionally, people who visit your page while using a screen reader will have a better experience, because the URL will always match the content on the page.

Not too shabby!

## Get the code

You can find the code for this tutorial on [GitHub at mbifulco/next-self-healing-urls-app-router](https://github.com/mbifulco/next-self-healing-urls-app-router). If you enjoyed this post, please consider giving it a star ⭐️ on GitHub!


## PS: What about using the Next.js Pages router?

This post _started_ as a tutorial for using the Next.js Pages router to create self-healing URLs, but I ran into a few issues that would make it really challenging to recommend going down this path if you're using the pages router (which is actually what [mikebifulco.com uses](https://github.com/mbifulco/blog)!). For that reason, I think **this is a feature you should only add if you're using the App Router**. I'm including the draft of my original post here [in a gist](https://gist.github.com/mbifulco/daf23aed0d827ec6317962691cb9cd0d) in case anyone wants to take a stab at it. If you figure it out, please let me know!




How to set up self-healing URLs in Next.js for better SEO

Self-healing URLs in Next.js with the App router

Generate a sitemap with the correct canonical URL for each post

Setting up page.tsx: where the magic happens

Not Found: a 404 page for posts that don't exist

To do: update your redirects when a post's title changes

PS: What about using the Next.js Pages router?


## Adding custom fonts to your website is a typical requirement for most web projects

By default, Next.js sites will add small set of fonts that you can use for your sites (in addition to the default fonts for a given browser). That can be useful to get started quickly, but for most custom site designs, you'll need to add custom fonts and typefaces that fit your site's brand and design guidelines.

In this tutorial, you'll learn how to **add custom fonts to your Next.js site using the `next/font` package and Tailwind CSS**. There's a few configuration steps needed to load fonts from Google Fonts using `next/font`, generate CSS variables for each font, and then use those variables to create custom font families in your Tailwind config.

With this setup, you'll be able to easily use your custom fonts throughout your Next.js app using Tailwind's utility classes.

### SEO Benefits of using custom fonts correctly on your Next.js site

In addition to improving the user experience, implementing custom fonts on your website can also have a [positive impact on your Lighthouse scores](https://web.dev/patterns/web-vitals-patterns/fonts/) and SEO. However, it's important to implement custom fonts carefully to avoid performance issues. Using too many or too large font files can slow down your site's loading time and hurt your Lighthouse performance score. Additionally, using custom fonts in a way that affects the visual stability of the page can result in lower scores for Core Web Vitals, which can impact your SEO. So, it's important to strike a balance between using custom fonts to enhance the design and ensuring that they don't negatively impact performance or user experience.

### About next/font

[`next/font` is an npm package](https://nextjs.org/docs/api-reference/next/font) developed by Vercel, which provides an easy way to load fonts in your Next.js app, while maintaing performance, and minimizing [Cumulative Layout Shift (CLS)](https://web.dev/optimize-cls/). It uses the Font Loading API to asynchronously load local font files stored in your repo, or from popular font providers such as Google Fonts, Typekit, and Fonts.com. The package also generates optimized font subsets to reduce the amount of data transferred over the network, and it provides a convenient way to generate CSS variables for each font, which can be used to create custom font families in your [Tailwind config](https://tailwindcss.com/docs/configuration). This makes it easy to use custom fonts throughout your Next.js app with minimal configuration.

## How to: Add multiple custom fonts to your Next.js site with Tailwind CSS

There are several ways to load custom fonts into your next.js app. If you're using a Google Fonts as your custom font provider, you can use the `next/font/google` package to load fonts from Google Fonts. The process is slightly different for loading font files that are stored locally in your repo, but the basic steps are the same:

### Load custom fonts from Google Fonts

In `_app.jsx/tsx`, load your the fonts you need from `next/font/google`, but use the `variable` configuration prop, which you will use to generate a definition for a CSS `--var` for each font:

```tsx
import { Barlow_Condensed, Inter } from 'next/font/google';
const barlowCondensed = Barlow_Condensed({
  weight: '700',
  subsets: ['latin'],
  variable: '--font-barlow-condensed',
});
const inter = Inter({
  subsets: ['latin'],
  variable: '--font-inter',
});
```

### Load custom fonts from a local file

This next example shows how you would load a font from a local file. It also showcases another feature of the `next/fonts` library - you can map font weights to different files as needed. This also applies for font _styles_ (italic, bold, etc).

In `_app.jsx/tsx`, load your the fonts you need from `next/font/local` using the syntax below. Note that in this case, font files in my repo are also being hosted in `/public/fonts` directory. Again, make sure to use the `variable` configuration prop, which you will use to generate a definition for a CSS `--var` for each font:

```tsx
import localFont from 'next/font/local';

const grosa = localFont({
  src: [
    {
      path: '../../public/fonts/Grosa/Grosa-Regular.woff2',
      weight: '500',
      style: 'normal',
    },
    {
      path: '../../public/fonts/Grosa/Grosa-Medium.woff2',
      weight: '600',
      style: 'normal',
    },
    {
      path: '../../public/fonts/Grosa/Grosa-Bold.woff2',
      weight: '700',
      style: 'normal',
    },
  ],
  variable: '--font-grosa',
});
```

### After loading custom fonts, generate CSS variables for each font

Then, in that same `_app.tsx` component - pass the generated variables into the wrapper class. This will make that variable available to any child of that element in the DOM (in other words, your whole app):

```tsx
export default function MyApp({ Component, pageProps }) {
  return (
    <main
      className={`${inter.variable} ${barlowCondensed.variable} ${grosa.variable}`}
    >
      <Component {...pageProps} />
    </main>
  );
}
```

Behind the scenes, next is generates unique css classes for each font permutation. These classes do one thing: they define a [css custom property](https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_custom_properties) (sometimes called a css variable) for each font.

By adding the resulting CSS classes to the root of your Next.js app, these variables are made available to any child of the `App` component - essentially all pages and components on your site.

<Image
  publicId="posts/custom-fonts-with-next-font-and-tailwind/classes"
  caption="is a screenshot from Chrome Browser tools for Craftwork.com, which is built using this setup"
  alt="screenshot of chrome browser tools showing the resulting CSS classes"
/>

### Use these variables your Tailwind config to create font families

Up to this point, we've loaded our custom fonts into our Next.js app, and we've made those fonts available to our entire app using CSS variables. Now, we need to tell Tailwind how to use these variables, by assigning them to specific font-family classes.

In your Tailwind config, add an entry to your `theme.extend`, to create a new font family that uses the google fonts you just imported - that will look something like this:

```tsx
// tailwind.config.js
export default {
  theme: {
    extend: {
      fontFamily: {
        "barlow-condensed": "var(--font-barlow-condensed)", // note: you can call the left side of this whatever you want - barlow-bold or title-font or foo-bar, this is what you'll use in your Tailwind css classes to use this font
        "inter-medium": "var(--font-inter)", // note: the bit that goes inside the var() function is the same variable name we defined in app.tsx
      }
    }
  }
```

Then, whenever you want to use the fonts you've added, ask for that font-family in your tailwind classnames by prefixing the font-family with "font-", like this:

```tsx
const myComponent: React.FC = () => (
  <p className="font-barlow-condensed">
    This should be rendered with the Barlow font family
  </p>
);

export default myComponent;
```

That should do the trick!

If you're wondering where these steps came from, it is essentially a combination of the instructions provided in [Next's docs for Font Optimization](https://nextjs.org/docs/basic-features/font-optimization). My team is using this very configuration setup for our Next.js site on [Craftwork.com](https://craftwork.com) to load custom fonts both locally and from Google Fonts, and it's been working great.


Add custom fonts to Next.js sites with Tailwind using next/font

Adding custom fonts to your website is a typical requirement for most web projects

SEO Benefits of using custom fonts correctly on your Next.js site

How to: Add multiple custom fonts to your Next.js site with Tailwind CSS

After loading custom fonts, generate CSS variables for each font

Use these variables your Tailwind config to create font families


## I'm new to TypeScript.

I've been using TypeScript to build software for my new company, [Craftwork](https://craftwork.com). I've been pretty open about the fact that I'm new to TypeScript, and have been blissfully writing non-type-safe javascript code since somewhere around 2005.

Of course, that's all changing.

This new project is built with [create-t3-app](https://create.t3.gg), a framework for building TypeSafe apps with Next.js and TRPC. Out of the box, t3 is configured with some sensible (and fairly strict) settings for both eslint and TypeScript's tsconfig.

If you're familiar with TypeScript, Eslint, and tsconfig you may want to skip ahead to [My last resort to fix TypeScript errors in VS Code](#my-last-resort-to-fix-typescript-errors-in-vs-code).

### ESLint in a nutshell

If you're not familiar, _eslint is a **linter**_ - a tool that will help you identify and fix code quality and formatting issues in your code.

ESLint is a popular linter for JavaScript, and it can also be used with TypeScript. It provides a wide range of configurable rules that you can use to enforce consistent code style and identify potential bugs. ESLint is highly extensible, which means you can customize it to fit your specific needs. For example, you can use it to enforce your team's coding standards, or to catch common mistakes that TypeScript can't detect on its own.

### tsconfig in a nutshell

When you're working on a TypeScript project, `tsconfig.json` is a configuration file that allows you to specify how the TypeScript compiler should behave when it compiles your code.

The purpose of `tsconfig.json` is to provide a single source of truth for your TypeScript project's configuration. It allows you to specify options such as the target version of JavaScript you want to generate, the module system you want to use, the paths to your project's source files, and many other settings.

One of the main benefits of using `tsconfig.json` is that it allows you to enforce a consistent set of rules across your project. You can use it to enforce specific compiler options, which helps to ensure that your code is consistent and that everyone on your team is using the same settings. `tsconfig.json` also allows you to configure your project's build pipeline, so you can easily automate the process of compiling and bundling your TypeScript code.

Additionally, `tsconfig.json` allows you to take advantage of features like incremental compilation, which can significantly improve the speed of your builds by only compiling the parts of your project that have changed since the last build.

## How TypeScript works in VS Code

There are a few steps required to set up TypeScript to work with VS Code. If you haven't done this yet, you should follow the instructions on VisualStudio.com to get started: [TypeScript in Visual Studio Code](https://code.visualstudio.com/Docs/languages/typescript).

When you open a TypeScript file in VS Code, the TypeScript language server will start in the background. The language server is a separate process that provides language features like IntelliSense, code navigation, and code refactoring. It also provides the ability to run TypeScript code in the editor. Because TypeScript has _many_ options and plugins, the language server uses the `tsconfig.json` file in your project to determine the rules it should use to compile your code.

VS Code needs to determine which version of TypeScript to use, so it will look for a `package.json` file in your project. If it finds one, it will use the version of TypeScript specified in the `devDependencies` section. If it doesn't find a `package.json` file, it will use the version of TypeScript that is bundled with VS Code.

---

## My last resort to fix TypeScript errors in VS Code

Sometimes, when I'm working on a TypeScript project, I'll get an error in VS Code that I can't figure out. I'll check and double-check against articles and tutorials online, or ask my hyper-smart TypeScript friends ([Sean Rogers, everyone](https://seanrogers.dev/)), and despite doing everything I can think of to address the problem, sometimes I just can't get the error to go away.

Here's what I do when I find myself in this situation:

### Make sure VS Code is using the correct version of TypeScript

Sometimes VS Code's TypeScript process doesn't use the right version of TypeScript for the project I'm working on. For me, this seems to happen after updating TypeScript versions, or when switching between projects that use different versions of TypeScript.

To check which version of TypeScript VS Code is using, open the Command Palette (Ctrl+Shift+P on Windows, or &#8984; on a Mac) and type `TypeScript: Select TypeScript Version`.

<Image
  publicId="posts/typescript-vscode-error-fix-last-resort/select-typescript-version"
  alt="Select TypeScript Version in the command palette in VS Code"
/>

If the version of TypeScript that is selected is not the one you expect, select the correct version from the list. Generally speaking, you'll want to select the version of TypeScript that is specified in your project's `package.json` file, by selecting `Use Workspace Version` option.

### Restart the TS server process

If that doesn't fix the problem, or VS Code was already running my workspace's version of TypeScript, the next thing I'll do is restart the TS server process. This is the background process being run by VS Code to actually analyze and compile your TypeScript code into JavaScript. Sometimes this process malfunctions, and restarting it can fix the problem.

To restart the TS server process, open the Command Palette (Ctrl+Shift+P on Windows, or &#8984; on a Mac) and type `TypeScript: Restart TS Server`.

<Image
  publicId="posts/typescript-vscode-error-fix-last-resort/select-typescript-version"
  alt="Select TypeScript Version in the command palette in VS Code"
/>

### Restart the ESLint server process

On occasion I'll also need to restart the ESLint server process. Just like it sounds, this is the process that analyzes your code for linting errors, according to the rules specified in your project's `.eslintrc` file and the version of ESLint that is specified in your project's `package.json` file.

<Image
  publicId="posts/typescript-vscode-error-fix-last-resort/restart-eslint-server"
  alt="Restart ESLint Server in the command palette in VS Code"
/>

## If that doesn't work, I'm out of ideas

..and by that, I mean I'm still learning. There's loads to learn about TypeScript, and I've found quite a few great resources online from devs like me who have shared their experiences and knowledge. I hope this article helps you - and if you're looking for more, check these out:

- Kent C. Dodds has a great article called [Using fetch with TypeScript](https://kentcdodds.com/blog/using-fetch-with-type-script) which I nearly have memorized at this point. This is the problem I was trying work through when I discovered that I needed to restart the TS server process in VS Code.
- [James Q. Quick](https://www.youtube.com/@JamesQQuick) has a great YouTube channel where he shares tips and tutorials for building web apps with a wide variety of frameworks and technologies.
- I've got some more articles on working with TypeScript in VS Code, including [Refactoring TypeScript React components in VS Code](https://mikebifulco.com/posts/refactoring-typescript-react-components-vscode#resources-for-learning-typescript)


Steps I take to fix stubborn TypeScript errors in VS Code

My last resort to fix TypeScript errors in VS Code

Make sure VS Code is using the correct version of TypeScript


## Extracting types from a JavaScript object

I am brand new to TypeScript, and far from an expert. So far, I really enjoy using it to build React apps with Next.js. As I'm growing the skills I'll need to be a better TypeScript developer, I'm finding that a fairly typical chore for me is to refactor my code to extract types from a JavaScript object. For example, I often find myself writing code in react components that looks a lot like this:

```tsx
import Footer from '@components/Footer';
import Header from '@components/Header';

const PageLayout = ({ children }) => {
  return (
    <>
      <section className="min-h-[100vh] pb-8 sm:pb-12 lg:pb-12">
        <Header />
        <div className="lg:relative">{children}</div>
      </section>
      <Footer />
    </>
  );
};

export default PageLayout;
```

There is no type-checking going on in this code as it is written. I've been writing react with good ol' plain JavaScript for so long that creating components like this is reflexive for me. I'm not even thinking about it.

Eventually during implementation I get to the point where adding some complexity to the component requires me to add some type-checking. At that point, I usually refactor the component to lambda syntax, and add a type annotation to the component:

```tsx
import Footer from '@components/Footer';
import Header from '@components/Header';

const PageLayout = ({ children }) => {
  return (
    <>
      <section className="min-h-[100vh] pb-8 sm:pb-12 lg:pb-12">
        <Header />
        <div className="lg:relative">{children}</div>
      </section>
      <Footer />
    </>
  );
};

export default PageLayout;
```

Next, I'll add a type annotation to the `children` prop:

```tsx
import Footer from '@components/Footer';
import Header from '@components/Header';

const PageLayout = ({ children }: { children: React.ReactNode }) => {
  return (
    <>
      <section className="min-h-[100vh] pb-8 sm:pb-12 lg:pb-12">
        <Header />
        <div className="lg:relative">{children}</div>
      </section>
      <Footer />
    </>
  );
};
```

Taking it a step further, I'll give the function a return type signature, using `React.FC` and generics to define the props:

```tsx
import Footer from '@components/Footer';
import Header from '@components/Header';

const PageLayout: React.FC<{ children: React.ReactNode }> = ({ children }) => {
  return (
    <>
      <section className="min-h-[100vh] pb-8 sm:pb-12 lg:pb-12">
        <Header />
        <div className="lg:relative">{children}</div>
      </section>
      <Footer />
    </>
  );
};
```

Up to this point, I don't really mind the way this component was written in any of the previous refactors. It's clearly getting more complex, but I can still understand what's going on. But what if I wanted to add a `variant` prop to the component? I'd have to add another type annotation to the function signature:

```tsx
import Footer from '@components/Footer';
import Header from '@components/Header';

const PageLayout: React.FC<{
  children: React.ReactNode;
  variant: 'dark' | 'light' | 'black' | 'tan';
}> = ({ children, variant }) => {
  return (
    <>
      <section className="min-h-[100vh] pb-8 sm:pb-12 lg:pb-12">
        <Header variant={variant} />
        <div className="lg:relative">{children}</div>
      </section>
      <Footer />
    </>
  );
};
```

Even with a little prettier formatting, this is getting a little hard to read. This is where I usually extract the props into a type, and then use that type in the function signature:

```tsx
import Footer from '@components/Footer';
import Header from '@components/Header';

type PageLayoutProps = {
  children: React.ReactNode;
  variant: 'dark' | 'light' | 'black' | 'tan';
};

type PageLayout = React.FC<PageLayoutProps>;

const PageLayout: PageLayout = ({ children, variant }) => {
  return (
    <>
      <section className="min-h-[100vh] pb-8 sm:pb-12 lg:pb-12">
        <Header variant={variant} />
        <div className="lg:relative">{children}</div>
      </section>
      <Footer />
    </>
  );
};
```

Now _this_ I like! The props for this page are defined in a single place, and the function signature is much easier to read.

## Using VS Code's refactor menu to extract types

As it works out, VS Code has loads of functionality to make this sort of work quicker. The refactor menu can be accessed by highlighting some code, right clicking on it, and selecting `Refactor...`. There are a number of TypeScript-specific functions provided which can help you refactor your code.

In this case, we can extract types from our component's signature in a few steps:

<Image
  publicId="posts/refactoring-typescript-react-components-vscode/refactor-1"
  alt="VS Code Screenshot: Select the entire `React.FC<` return type and right clicking on it"
  caption='Select the entire `React.FC<` return type and right click on it, and Choose "Refactor..." from the context menu.'
/>

<Image
  publicId="posts/refactoring-typescript-react-components-vscode/refactor-2"
  alt="VS Code Screenshot: Choose 'extract type to type alias' from the refactor menu"
  caption='Select "Extract type to type alias" to extract the type into a type alias'
/>

<Image
  publicId="posts/refactoring-typescript-react-components-vscode/refactor-3"
  alt="VS Code Screenshot: Give the extracted type a name, and hit enter."
  caption="Give the extracted type a name, and hit enter."
/>

## Bonus: Add JSDoc comments to your types for better intellisense

If you want to take it further, you can add a JSDoc comment to the type definition to add some documentation. This is a good way to document your code, and it's also a good way to get better intellisense for your code if it's supported in your editor:

```tsx
import Footer from "@components/Footer";
import Header from "@components/Header";

type PageLayoutProps = {
  children: React.ReactNode;
  variant: "dark" | "light" | "black" | "tan";
};

/**
 * The PageLayout component is used to wrap all pages in the application.
 * It provides a consistent header and footer, and a consistent layout for
 * the page content.
 * @param {object} props
 *   @param {React.ReactNode} props.children - The page content
 *   @param {"dark" | "light" | "black" | "tan"} props.variant - The color variant for the page
 * @returns {JSX.Element}
 **/
const PageLayout: PageLayout = ({ children, title }) => {

  /* etc */
```

## Don't learn TypeScript, just use it

...and by that I mean that TypeScript is a _great_ enhancement to building things with JavaScript, but you do not need to be an expert on TypeScript to use it by any means. I've been starting to use TypeScript more and more in my projects, and I've found that I can get a lot of mileage out of it without having to learn every single detail about it.

Theo from [t3.gg](https://t3.gg) has a great video that sums up my learning strategy for TypeScript pretty well, called Don't Learn TypeScript. I highly recommend watching it, or putting it in your queue for your next coffee break:

<YouTube youTubeId="kRiD6ZpAN_o" />

## Resources for learning TypeScript

As I mentioned, I'm fairly new to TypeScript - I only just started using it in the past few months. If you're learning TypeScript and are looking for some great places to learn, check these out:

- [Matt Pocock's YouTube channel](https://www.youtube.com/@mattpocockuk) is a library of really interesting videos about TypeScript. He shares tutorials as well as experience-driven, nuanced opinions about TypeScript (_when should I use an interface instead of a type?_ etc). IMO he's the defacto expert on TypeScript in real life.
- [TypeScript Course](https://www.typescriptcourse.com/) is a fantastic _free_ email course from [Joe Previte](https://jsjoe.io) [(@jsjoeio)](https://twitter.com/jsjoeio). It's a to learn TypeScript a little bit at a time.
- [TypeScript Deep Dive](https://basarat.gitbook.io/typescript/) is just what it sounds like - a thorough deep dive into TypeScript. It's a free book, with an available paid course on Udemy for those who want more .
- [TypeScript Handbook](https://www.typescriptlang.org/docs/handbook/intro.html) is the official TypeScript documentation. For better or worse, I don't think it's a great place to start, but it contains every detail you might possibly need. I've found myself coming back to it from time to time to look up specific features and to help debug this-and-that.


Refactoring TypeScript React components in VS Code

Extracting types from a JavaScript object

Using VS Code's refactor menu to extract types

Bonus: Add JSDoc comments to your types for better intellisense

#typescript: 12 posts tagged