A couple of years ago, Sentry were having big problems with their React app. They'd pretty recently [migrated it to TypeScript](https://blog.sentry.io/slow-and-steady-converting-sentrys-entire-frontend-to-typescript) from JavaScript. And the app was part of a large monorepo.

But the IDE performance was slow. You'd often need to wait a couple of seconds after making a change for the TypeScript language server to update. And running `tsc` would take a long time.

Now, this isn't unusual for a large TypeScript codebase. But the Sentry team had a hunch that something was wrong. The problem felt out of proportion to the size of the codebase.

It turned out that the issue, outlined by [Jonas](https://twitter.com/JonasBadalic/status/1765006152150974919), was down to a single pattern.

## How To Tank Your React App's TS Performance

In tons of places in Sentry's codebase, they were extending HTML types in React. For instance, defining `ButtonProps` would look like this:

```tsx twoslash
import React from "react";

type ButtonProps =
  React.HTMLAttributes<HTMLButtonElement> & {
    extraProp: string;
  };

const Button = ({ extraProp, ...props }: ButtonProps) => {
  console.log(extraProp);
  return <button {...props} />;
};
```

This means that you could pass in all the props that a `<button>` element could take, plus an `extraProp`:

```tsx twoslash
import React from "react";

type ButtonProps =
  React.HTMLAttributes<HTMLButtonElement> & {
    extraProp: string;
  };

const Button = ({ extraProp, ...props }: ButtonProps) => {
  console.log(extraProp);
  return <button {...props} />;
};

// ---cut---

<Button
  extraProp="whatever"
  onClick={(e) => {
    //      ^?
  }}
/>;
```

But it turns out that this pattern is devilishly slow. So Jonas, following the advice of the [TypeScript Performance Wiki](https://github.com/microsoft/TypeScript/wiki/Performance), changed each of these to use an `interface` instead:

```tsx twoslash
import React from "react";

interface ButtonProps
  extends React.HTMLAttributes<HTMLButtonElement> {
  extraProp: string;
}
```

Suddenly, things got a lot snappier. The TypeScript language server was faster, and `tsc` ran quicker. Just from a little syntax change. Why?

## Why Did This Happen?

You may have heard that `interface` is slightly faster than `type`. This is not quite true. In fact, `interface extends` is slightly faster than `&`.

In an earlier version of this article, I'd posted an explanation based on some fuzzy thinking which, thanks to my old colleague [
Mateusz Burzyński](https://twitter.com/AndaristRake), I now understand was wrong.

The problem is more complex than I realised - check out [this thread](https://twitter.com/AndaristRake/status/1770743549325115459) for his critiques and our investigations.

Hopefully, I can update this article again with a definitive description of why this happens - but nothing is simple when it comes to TypeScript performance.

Suffice to say - `interface extends` is generally faster than `&`, and so it proved in this case too.

Improve React TypeScript performance by replacing type & with interface extends. Boost IDE and tsc speed significantly.

This Pattern Will Wreck Your React App's TS Performance

Let's talk about another crazy TypeScript trick: `Array[number]`.

```ts twoslash
const roles = ["admin", "editor", "contributor"] as const;

type RolesAsType = typeof roles;

type Role = RolesAsType[number];
//   ^?
```

It looks like absolute insanity.

But I promise by the end of this email, you'll know how it works.

## Extracting Types From Arrays

Let's start with a slightly simpler example.

First, we'll define an array of some fixture data we might use in some tests.

```ts twoslash
const possibleResponses = [
  {
    status: 200,
    body: "Hello, world!",
  },
  {
    status: 404,
    body: "Not found",
  },
  {
    status: 500,
    body: "Internal server error",
  },
];
```

We can use `typeof` on `possibleResponses` to extract its type.

We can see that it is an array of objects with a `status` and `body` property.

But what if we want to remove the 'array' part of the type and just get to the object inside?

```ts twoslash
const possibleResponses = [
  {
    status: 200,
    body: "Hello, world!",
  },
  {
    status: 404,
    body: "Not found",
  },
  {
    status: 500,
    body: "Internal server error",
  },
];
// ---cut---
type PossibleResponses = typeof possibleResponses;
//   ^?
```

We can use this arcane-looking trick, `Array[number]`, to extract the type of the array.

```ts twoslash
const possibleResponses = [
  {
    status: 200,
    body: "Hello, world!",
  },
  {
    status: 404,
    body: "Not found",
  },
  {
    status: 500,
    body: "Internal server error",
  },
];
type PossibleResponses = typeof possibleResponses;

// ---cut---
type PossibleResponse = PossibleResponses[number];
//   ^?
```

Why does this work? What even is this syntax?

## Indexed Access Types

Well, the syntax is an indexed access type. It's the way to access a property on a type.

A simpler version would be to grab a property from an object:

```ts twoslash
type NavbarProps = {
  onChange: () => void;
};

type OnChangeType = NavbarProps["onChange"];
//   ^?
```

By passing `number` to the indexed access type, we're saying "give me all the properties of the object that are accessed with numeric keys".

To demonstrate this, we can create an object with string keys, but a numeric index signature:

```ts twoslash
type ExampleObj = {
  // String keys
  stringKey1: "string-key";
  stringKey2: "string-key";

  // Numeric index signature
  [key: number]: "number-key";
};
```

We can then use `ExampleObj[number]` to extract only the numeric values from the object.

```ts twoslash
type ExampleObj = {
  // String keys
  stringKey1: "string-key";
  stringKey2: "string-key";

  // Numeric index signature
  [key: number]: "number-key";
};

type NumericValuesOnly = ExampleObj[number];
//   ^?
```

## What's The Point?

Keen observers might be looking at this with scepticism. Is this trick really useful?

Surely, you would just create the type _first_, then use it in your application.

No need to extract it from an array.

```ts twoslash
type Response = {
  status: number;
  body: string;
};

const possibleResponses: Response[] = [
  {
    status: 200,
    body: "Hello, world!",
  },
  {
    status: 404,
    body: "Not found",
  },
  {
    status: 500,
    body: "Internal server error",
  },
];
```

Well, this trick comes into its own in a few places.

It goes without saying that it's useful in library code.

But it's also great when you're building your own enums from arrays, like in the first example.

```ts twoslash
const roles = ["admin", "editor", "contributor"] as const;

type RolesAsType = typeof roles;

type Role = RolesAsType[number];
//   ^?
```

By the way, this example works because `roles` is marked `as const`, which makes TypeScript infer the literal values of the array.

Without it, TypeScript would infer the type as `string[]`:

```ts twoslash
const roles = ["admin", "editor", "contributor"];

type RolesAsType = typeof roles;

type Role = RolesAsType[number];
//   ^?
```

Deriving types from values is an extremely powerful concept - so much so that I wrote an [entire chapter of my book](https://www.totaltypescript.com/books/total-typescript-essentials/deriving-types) on it.

So, that's `Array[number]` in TypeScript. It extracts all the numeric keys from an object.

In the case of an array, that means it extracts the type of the array member.


Learn how to extract the type of an array element in TypeScript using the powerful `Array[number]` trick.

This Crazy Syntax Lets You Get An Array Element's Type

Learn how to publish a package to npm with a complete setup including, TypeScript, Prettier, Vitest, GitHub Actions, and versioning with Changesets.

How To Create An NPM Package

Let's start with a bit of context. I like enums. I like them a lot. I would really like JavaScript to have them.

But TypeScript's implementation of them is weird enough for me not to recommend them.

## Types Of Enums

You can declare three different types of values for your enums. Numeric, string and inferred:

```ts twoslash
// Numeric
enum PackStatus {
  Draft = 0,
  Approved = 1,
  Shipped = 2,
}

// String
enum PackStatus2 {
  Draft = "Draft",
  Approved = "Approved",
  Shipped = "Shipped",
}

// Inferred
enum PackStatus3 {
  Draft, // Inferred as 0
  Approved, // Inferred as 1
  Shipped, // Inferred as 2
}
```

## Numeric vs String Enums

Numeric and string enums actually behave differently in a couple of ways.

First, how many keys do you think the `PackStatus` object has?

```ts twoslash
enum PackStatus {
  Draft = 0,
  Approved = 1,
  Shipped = 2,
}
```

The answer is 6. Why? Because TypeScript generates both a value-to-key and a key-to-value mapping for numeric enums.

But for string enums, it doesn't do this, so you end up with the expected 3 keys:

```ts twoslash
enum PackStatus {
  Draft = 0,
  Approved = 1,
  Shipped = 2,
}

// [0, "Draft", 1, "Approved", 2, "Shipped"]
console.log(Object.keys(PackStatus));

enum PackStatus2 {
  Draft = "Draft",
  Approved = "Approved",
  Shipped = "Shipped",
}

// ["Draft", "Approved", "Shipped"]
console.log(Object.keys(PackStatus2));
```

They also behave differently when it comes to type-checking.

In places where a string enum is expected, it forces you to pass the enum value:

```ts twoslash
// @errors: 2345
enum PackStatus {
  Draft = "Draft",
  Approved = "Approved",
  Shipped = "Shipped",
}

const logStatus = (status: PackStatus) => {
  console.log(status);
};

logStatus(PackStatus.Draft);

// Errors, correctly!
logStatus("Draft");
```

But with numeric enums, you can pass a raw number in places where the enum is expected. What?

```ts twoslash
enum PackStatus {
  Draft = 0,
  Approved = 1,
  Shipped = 2,
}

const logStatus = (status: PackStatus) => {
  console.log(status);
};

logStatus(PackStatus.Draft);

// No error. WHAT?
logStatus(0);
```

Hilariously, you can even mix and match numeric and string values in the same enum.

Don't do this.

```ts twoslash
enum PackStatus {
  Draft = "Draft",
  Approved = 2,
  Shipped, // Inferred as 3
}
```

## Nominal Typing

My final frustration with enums is fairly subjective.

I like my TypeScript to be just JavaScript with types. Enums feel like they break that rule.

For example, you can't use an enum in place of another enum, even if the values are the same:

```ts twoslash
// @errors: 2345
enum PackStatus {
  Draft = "Draft",
  Approved = "Approved",
  Shipped = "Shipped",
}

enum PackStatus2 {
  Draft = "Draft",
}

const logStatus = (status: PackStatus) => {
  console.log(status);
};

// Errors, even though the values are the same
logStatus(PackStatus2.Draft);
```

EVEN if the second enum is just a reference to the first enum.

```ts twoslash
// @errors: 2345
enum PackStatus {
  Draft = "Draft",
  Approved = "Approved",
  Shipped = "Shipped",
}

// ---cut---
enum PackStatus2 {
  Draft = PackStatus.Draft,
}

const logStatus = (status: PackStatus) => {
  console.log(status);
};

// Errors, even though the values are the same
logStatus(PackStatus2.Draft);
```

There are currently [71 issues marked as bugs](https://github.com/microsoft/TypeScript/issues?q=is%3Aissue+is%3Aopen+enum+label%3Abug) related to enums in the TypeScript repo.

I've heard hints from the TS team that many of these are uncloseable due to the way enums are implemented.

## Conclusion

If I saw an enum in a codebase, I'm unlikely to get rid of it. If it's using inferred values, I'll probably add them explicitly.

But I wouldn't add an enum to a fresh codebase.

If you're desperate to use enums, I'd strongly recommend using string enums only.

They're explicit, behave more like enums, and look more like their transpiled code.

And if you want to see what I use instead of enums, check out [this section of my book](https://www.totaltypescript.com/books/total-typescript-essentials/deriving-types#using-as-const-for-javascript-style-enums).


Enums in TypeScript can be confusing, with differences between numeric and string enums causing unexpected behaviors.

Why I Don't Like Enums

A common refrain in the web development discourse is that TypeScript is 'just a linter for JavaScript'. It's an oddly multifaceted phrase. It can be used to disdain TypeScript as a 'mere' linter, or to praise it for its simplicity.

I want to give this statement the attention it deserves. Is TypeScript just a linter? No, but yes.

## TypeScript Is Just JavaScript

TypeScript is the most successful attempt ever to create a meta-language for JavaScript. It's JavaScript's tastiest flavor. Milder than CoffeeScript. Sweeter than ClojureScript.

Part of its success is its fidelity to JavaScript. It clings tightly to it. Since enums, TypeScript has added zero new runtime features not already present in JavaScript. Its early attempts to add runtime features are now [falling out of fashion](/books/total-typescript-essentials/typescript-only-features#when-to-prefer-es-vs-ts). These days, TypeScript concerns itself with typing JavaScript.

TypeScript requires far fewer annotations than most typed languages. It can [infer](/books/total-typescript-essentials/essential-types-and-annotations#type-inference) a great deal just by looking at your code. So your JavaScript outputs often look identical to your TypeScript inputs, but with the types stripped out.

Unmask TypeScript, and you'll find JavaScript. The space between them is thin. This is a good thing.

I've been curious about the more refined flavors of JavaScript for a while now. [Elm](https://elm-lang.org/) and [ReScript](https://rescript-lang.org/) especially. But betting company code on these languages feels risky. There are a lot more JavaScript developers than Elm developers. And TypeScript is just a linter for JavaScript.

## Is TypeScript "Strongly Typed"?

But TypeScript is not just a linter for JavaScript. According to its own [landing page](https://www.typescriptlang.org/), it is a 'strongly typed programming language'. This assertion feels controversial, and I've seen 'TypeScript is a linter' used in rebuttal. "TypeScript is just JavaScript with some types added, not a language by itself".

TypeScript certainly has some types. Basic types. Object types. Types for the DOM. But there's one type that calls the rest into question: [`any`](https://www.totaltypescript.com/books/total-typescript-essentials/essential-types-and-annotations#the-any-type).

`any` breaks the rules. It's a nuclear warhead against rock, paper, scissors. It can infect a codebase, metastasizing from a single function. Its mere presence in the language means, in my eyes, TypeScript cannot be considered 'strongly typed'. There are no guarantees. The center cannot hold.

`any` has to exist. If it didn't, TypeScript would be burdened with the challenge of describing the entirety of JavaScript in types. `any` is a pressure valve. It makes TypeScript simpler and leaner. I'm glad it exists.

But `any` is a virus that remakes its host. TypeScript's types are at best advisory. Guidelines, not rules. You can disable its checking at any time. TypeScript is just a linter for JavaScript.

## TypeScript Is Just A Linter

Let's state the obvious. TypeScript is not just a linter. It's an astonishingly advanced type system. It's a compiler. It's a language server that can run on any compatible IDE.

But thinking of it _like_ a linter is useful. Its type system lives to serve JavaScript. It's easy to adopt. It's easy to eject from. If you don't understand it, shut it up and move on.

And embrace it. You're not a TypeScript dev. You're a JavaScript dev. `typeof NaN` is a number and `typeof null` is an object. You'll get more out of TypeScript as a result.


Is TypeScript just a linter? No, but yes.

Is TypeScript Just A Linter?

Today is the biggest ship day of my life. After 11 months of work, I'm launching:

- Total TypeScript Essentials: a 16-chapter [TypeScript book](https://www.totaltypescript.com/books/total-typescript-essentials), for FREE.
- [Pro Essentials](https://www.totaltypescript.com/workshops/typescript-pro-essentials): a new, 200-exercise course for $200.
- A giveaway worth ~$80,000 to existing customers.
- A huge price cut on Total TypeScript.
- A 20% sale until Friday.

Here's the full story:

## The Book - Total TypeScript: Essentials

My book, [Total TypeScript: Essentials](https://www.totaltypescript.com/books/total-typescript-essentials), is finally ready.

It's been 11 months of work. 16 chapters. Hundreds of pages. And it's free.

It covers everything you need to get a job with TypeScript, from setting up your IDE to understanding generics.

And it's 100% freely available on Total TypeScript. Forever.

We'll also be releasing this as a printed book! You can pre-order a copy on [No Starch's site](https://nostarch.com/total-typescript).

## The Course - Pro Essentials

We're also releasing a new course, [Pro Essentials](https://www.totaltypescript.com/workshops/typescript-pro-essentials).

It's the ultimate TypeScript masterclass - the no-brainer training programme to help your team build TypeScript apps.

It contains over 200 exercises and requires no TypeScript experience.

And, until Friday, it's $200.

Pro Essentials is different from everything else I've shipped.

Before, I focused on advanced content to turn you into a TS wizard. The content in the [Core Volume](https://www.totaltypescript.com/workshops) is perfect for this.

But with Essentials (the book) and Pro Essentials (the course), I want Total TypeScript to be the default choice for teams.

Got a team transitioning to TS? Get them Pro Essentials, at $200 a pop (cheaper in bulk) and you'll have some happy engineers working at max capacity.

## Price Cut and Giveaway

We've slashed the price of Total TypeScript. You can now pick up the entire of TT, including Pro Essentials, for $500.

And until Friday, it's 20% off: $400.

This is a HUGE drop from where it was before.

What about the folks that already paid the higher price for the existing workshops?

Existing TT customers will get Pro Essentials for free. Over all our customers, that's around $80,000 of giveaway.

I'm so excited to finally share this with you. I hope you enjoy it as much as I enjoyed creating it.


It's a massive ship day. We're launching a free TypeScript book, new course, giveaway, price cut, and sale.

Announcing: A Free Book, A New Course, A Huge Price Cut...

Sometimes, the way you order your object properties matters.

## The Setup

Let's imagine we create a function that takes in an object as its argument. In this object, there are two properties: `produce` and `consume`.

```ts twoslash
const process = <T>(obj: {
  produce: (input: string) => T;
  consume: (t: T) => void;
}) => {
  const value = obj.produce("abc");
  obj.consume(value);
};

// ---cut---

process({
  produce: (input) => Number(input),
  consume: (output) => console.log(output),
  //                               ^?
});
```

`produce` takes in an input of `string` and returns some type. `consume` then takes in that value and does something with it. Because of a clever type definition, TypeScript can infer the type of the value returned by `produce` and pass it to `consume`:

```ts twoslash
const process = <T>(obj: {
  produce: (input: string) => T;
  consume: (t: T) => void;
}) => {
  const value = obj.produce("abc");
  obj.consume(value);
};
```

We can use this setup with any type of value, and it'll just work:

```ts twoslash
const process = <T>(obj: {
  produce: (input: string) => T;
  consume: (t: T) => void;
}) => {
  const value = obj.produce("abc");
  obj.consume(value);
};

// ---cut---
process({
  produce: (input) => input + "hello",
  consume: (output) => console.log(output),
  //                               ^?
});

process({
  produce: (input) => ({ value: input }),
  consume: (output) => console.log(output),
  //                               ^?
});
```

## The Problem

This all looks great, until one of our users complains to us. They're trying to use our function, but it's not working:

```ts twoslash
const process = <T>(obj: {
  produce: (input: string) => T;
  consume: (t: T) => void;
}) => {
  const value = obj.produce("abc");
  obj.consume(value);
};

// ---cut---

process({
  consume: (output) => console.log(output),
  //                               ^?
  produce: (input) => Number(input),
});
```

The `output` is being seen by TypeScript as `unknown`. This feels very odd, as the `produce` function is clearly returning a `number`. What's going on?

The difference here is that the user specified `consume` _before_ `produce`. Since TypeScript 4.7, in [this PR](https://github.com/microsoft/TypeScript/pull/48538), TypeScript now uses the order of properties to inform its inference. This was added to fix various long-standing bugs (linked in the PR) with context-sensitive functions.

This means that, in some very narrow cases, the order you specify your properties matters. So if you're running up against strange errors to do with property ordering, that's why!

## Could You Use `NoInfer`?

You might be wondering if you could use [`NoInfer`](https://www.totaltypescript.com/noinfer) to fix this. That seems sensible, given that `NoInfer` is used to force TypeScript to avoid inference on certain targets.

However, it doesn't:

```ts twoslash
const process = <T>(obj: {
  produce: (input: string) => T;
  consume: NoInfer<(t: T) => void>;
}) => {
  const value = obj.produce("abc");
  obj.consume(value);
};

process({
  consume: (output) => console.log(output),
  //                               ^?
  produce: (input) => Number(input),
});
```

The result is still `unknown`. How frustrating!


Learn why the order you specify object properties in TypeScript matters and how it can affect type inference in your functions.