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.
More Tips
Type Predicates
1 min
TypeScript 5.1 Beta is OUT!
2 mins
How to Name your Types
4 mins
Don't use return types, unless...
4 mins
TypeScript 5.0 Beta Deep Dive
6 mins
Conform a Derived Type Without Losing Its Literal Values
1 min
Avoid unexpected behavior of React’s useState
1 min
Understand assignability in TypeScript
2 mins
Compare function overloads and generics
1 min
Use infer in combination with string literals to manipulate keys of objects
1 min
Access deeper parts of objects and arrays
1 min
Ensure that all call sites must be given value
1 min
Get a TypeScript package ready for release to NPM in under 2 minutes
1 min
Use assertion functions inside classes
1 min
Assign local variables to default generic slots to dry up your code and improve performance
2 mins
Know when to use generics
2 mins
Map over a union type
1 min
Make accessing objects safer by enabling 'noUncheckedIndexedAccess' in tsconfig
1 min
Use generics to dynamically specify the number, and type, of arguments to functions
1 min
Use 'declare global' to allow types to cross module boundaries
2 mins
Turn a module into a type
2 mins
Create autocomplete helper which allows for arbitrary values
2 mins
Use deep partials to help with mocking an entity
1 min
Throw detailed error messages for type checks
1 min
Create a 'key remover' function which can process any generic object
1 min
Use generics in React to make dynamic and flexible components
1 min
Create your own 'objectKeys' function using generics and the 'keyof' operator
1 min
Write your own 'PropsFrom' helper to extract props from any React component
1 min
Use 'extends' keyword to narrow the value of a generic
1 min
Use function overloads and generics to type a compose function
2 mins
Decode URL search params at the type level with ts-toolbelt
2 mins
Use 'in' operator to transform a union to another union
2 mins
Derive a union type from an object
2 mins