Understand how TypeScript infers literal types

It's really important to get a good mental model for things that the TypeScript compiler does. And, that's especially true for read-only properties. So up top here we've got this age variable. age here is inferred as a number.


export let age = 31
export const name = "Matt"
const tsPeople = ["Andarist", "Titian", "Devansh", "Anurag"]

So if I reassign age to another number, it's going to work because age is declared with a let and it's saying that age can change over time. Whereas, if I put age as a const, then I can't reassign to it.

So, age instead of just being inferred as a number, it's actually inferred as its literal type as 31 which is really interesting.


export const age = 31

I can sort of force this on the let by saying age is 31 and then it gets inferred. And then, if I try to reassign to it, it's not going to let me because 31 is not assignable to type 32.


export let age: 31 = 31
// type 31 is not assignable to type 32
age = 32

The same is true for strings too so the constant name "Matt" is actually being inferred as "Matt", but it gets more complicated when you go to arrays and objects.

Even though I'm declaring the tsPeople array as a const, members of the array can be manipulated. So I can say this for instance:


const tsPeople = ["Andarist", "Titian", "Devansh", "Anurag"]
tsPeople[0] = "Eddy"

So here it's being declared as string inside the member, whereas if I say as const to tsPeople, I'm not going to be able to reassign to it, and this is now going to be declared as its literal so it's going to be inferred all the way down.


const tsPeople = ["Andarist", "Titian", "Devansh", "Anurag"] as const
// Cannot assign to '0' because it is a read-only property
tsPeople[0] = "Eddy"

The same is true for objects too. I can say as const and now everything is inferred all the way down.


const moreTsPeople = {
  Andarist: "Andarist",
  Titian: "Titian",
  Devansh: "Devansh",
  Anurag: "Anurag",
} as const

This is really critical if you want like type checking or you want inference based on the members of the array that you're passing in, or the values of the objects that you're passing in.

Getting this mental model solid is going to help you in a ton of different places.

Transcript

0:00 It's really important to get a good mental model for things that the TypeScript compiler does. That's especially true for read only properties. Here, we've got this age property up top here, or variable. Age here is inferred as a number.
0:00

0:16 If I reassign age here, it's going to work because age is declared with a let. It's saying that this age can change over time. Whereas if I put this as a const, then I can't reassign to it. Age, instead of just being inferred as a number, it's actually inferred as its literal type as 31. Which is really interesting.

0:37 I can force this on the let by saying age is 31 and then it gets inferred. Then if I try to reassign to it, then it's not going to let me, because 31 is not assignable to type 32. The same is true for strings too. Name: "Matt" is actually being inferred as Matt.

0:55 It gets more complicated when you go to raise an object. Here, even though I'm declaring the array as a string, or rather as const, members of the array can be manipulated. I can say tsPeople [ = "Eddy";. Here, it's being declared as string inside the member.

1:15 Whereas if I say it as const;, then first of all, I'm not going to be able to reassign to it. Also, this is now going to be declared as it's literal. It's going to be inferred all the way down. The same is true for objects too.

1:28 Here I can say moreTsPeople. Andarist = 'whatever'. In here, I can say as const, and now everything is inferred all the way down. This is really critical. If you want like type checking or you want inference based on the members of the array that you're passing in, or the values of the objects that you're passing in.

1:50 This is where TypeScript, getting that mental model really solid is going to help you in a ton of different places.

This mental model is INCREDIBLY useful for all sorts of intermediate-advanced typings:

If TypeScript knows a value can't change, it'll infer it to its literal type.

Discuss on Twitter

More Tips

Derive a union type from an object

Use 'in' operator to transform a union to another union

Decode URL search params at the type level with ts-toolbelt

Use function overloads and generics to type a compose function

Use 'extends' keyword to narrow the value of a generic

Write your own 'PropsFrom' helper to extract props from any React component

Create your own 'objectKeys' function using generics and the 'keyof' operator

Use generics in React to make dynamic and flexible components

Create a 'key remover' function which can process any generic object

Throw detailed error messages for type checks

Use deep partials to help with mocking an entity

Create autocomplete helper which allows for arbitrary values

Turn a module into a type

Use 'declare global' to allow types to cross module boundaries

Use generics to dynamically specify the number, and type, of arguments to functions

Make accessing objects safer by enabling 'noUncheckedIndexedAccess' in tsconfig

Map over a union type

Know when to use generics

Assign local variables to default generic slots to dry up your code and improve performance

Use assertion functions inside classes

Get a TypeScript package ready for release to NPM in under 2 minutes

Ensure that all call sites must be given value

Access deeper parts of objects and arrays

Use infer in combination with string literals to manipulate keys of objects

Compare function overloads and generics

Understand assignability in TypeScript

Avoid unexpected behavior of React’s useState

Conform a Derived Type Without Losing Its Literal Values

TypeScript 5.0 Beta Deep Dive

Don't use return types, unless...

How to Name your Types

TypeScript 5.1 Beta is OUT!

Type Predicates