Switching from React to Typescript

When I first heard about Typescript, I was skeptical of what it had to offer. It turns out putting a little extra time into developing components can have compounding returns

I too was a non-believer...

A few years ago, I noticed a lot of buzz on Developer Twitter about Typescript. At that time, I had been primarily using React without PropTypes and didn't fully grasp the benefits of Typescript. My lack of understanding stemmed from the fact that I had mainly developed simple Headless E-Commerce websites with straightforward data structures that were well-documented by third-party platforms like Shopify or Wordpress. When coding these projects, my workflow typically involved coding, deploying, and then troubleshooting bugs as they arose. However, this process was challenging because most production bugs were anonymous, leaving me to guess which prop was receiving incorrect data or null/undefined values. As a result, I would spend hours trying to pinpoint the source of the issue.

A year later, I was deploying one of my first big SASS apps in pure React. While it was a simple app, it was one of the first projects I had worked on where I had created both the frontend and backend for an app that had a completely custom data structure. There was no longer a CMS to tell me what data type I would receive, and this resulted in a ton of bugs arising after launch. When these bugs appeared, I turned back to my only strategy for dealing with this

But the bugs kept coming, and it became very difficult to allocate time to build new features, while fixing bugs from the previous ones. I realized that this could not be how good senior devs ship JAMStack apps, so I started looking for a way to make my apps more sustainable and predictable.

Enter Typescript

TypeScript is JavaScript with syntax for types.

It really is that simple. Typescript makes React better because by specifying the data types that your components need to receive, you expose a ton of bugs before you go into production.

Here is a basic example of a typscript component

type HeadingType = {
  headingType: "h1" | "h2" | "h3";
  className?: string;
};

const Heading = ({ headingType, className }: HeadingType) => {
  return (
    <>
      {headingType === "h1" && <h1 className={className}>Heading 1</h1>}
      {headingType === "h2" && <h2 className={className}>Heading 2</h2>}
      {headingType === "h3" && <h3 className={className}>Heading 3</h3>}
    </>
  );
};

export default Heading;

The example above should seem familiar. There is a heading component that takes a mandatory prop of headingType, and an optional prop of className. I'm using a union type to define the expected values of headingType, while the optional className prop can be any string (the ? makes it an optional prop).

Now when I try to use this component in my project, VSCode will typecheck the component to make sure I'm passing it the right kind of data, and will throw an error if I'm missing a prop, or the prop data type is wrong:

This is a simple example, but by adding a type to our heading component, we will have errors in our code editor until Typescript is satisfied with the data we're providing it. By adding the type, we gurantee that heading will always recieve the right type of data, which reduces the chance that an error will arise from the component which would cause our build to crash. When we deploy to a hosting service, like Vercel, it will also run a typecheck to confirm we didn't miss anything. If it finds a Tyepscript error, it will cancel the build until the issue is resolved.

Long story short: Typescript protects developers from themselves, and forces them to slow down to make sure their data is organized. It also forces devs to understand their project needs, while encouraging them to re-use types and interfaces.

Sam Davidoff

Switching from React to Typescript

I too was a non-believer...

Enter Typescript