Chapter 11 #11

Andarist · 2024-07-20T07:19:22Z

No description provided.

Andarist · 2024-07-20T21:11:25Z

book-content/chapters/11-annotations-and-assertions.md

+This is because we've told TypeScript that `config` is a `Record` with a any number of string keys. We annotated the variable, but the actual _value_ got discarded. This is an important point - when you annotate a variable, TypeScript will:
+
+1. Ensure that the value passed to the variable matches the annotation.
+2. Forget about the value's type.


not always because there is something that internally is called an assignment reduced type:

const test: 1 | 2 = 1; test; // ^? const test: 1

Andarist · 2024-07-20T21:11:47Z

book-content/chapters/11-annotations-and-assertions.md

+
+There's a difference in TypeScript between annotating _variables_ and _values_. The way they conflict can be confusing.
+
+### When You Annotate A Variable, The Variable Wins


Suggested change

### When You Annotate A Variable, The Variable Wins

### When You Annotate A Variable, The Annotation Wins

Andarist · 2024-07-21T08:37:08Z

book-content/chapters/11-annotations-and-assertions.md

+
+But this isn't really what we want - this is a config object that shouldn't be changed.
+
+### With No Annotation, The Value Wins


what it "win" with here in such a situation? ;p

Suggested change

### With No Annotation, The Value Wins

### With No Annotation, The Inferred Type of a Value Is Used

Andarist · 2024-07-21T08:40:41Z

book-content/chapters/11-annotations-and-assertions.md

+
+- When you use a variable annotation, the variable's type wins.
+- When you don't use a variable annotation, the value's type wins.
+- When you use `satisfies`, you can tell TypeScript that a value must satisfy certain criteria, but still allow TypeScript to infer the type.


which has some notable surprising caveats at times, like:

type User = { name: string } const arr = [] satisfies User[] // ^? const arr: never[]

Andarist · 2024-07-21T08:44:00Z

book-content/chapters/11-annotations-and-assertions.md

+} satisfies Album;
+```
+
+Now, `album.format` is inferred as `"Vinyl"`, because we've told TypeScript that `album` satisfies the `Album` type. So, `satisfies` is narrowing down the value of `album.format` to a specific type.


more technical terms would be that the satisfies operator provides contextual information that helps the inferred value type to retain the literal string type here as otherwise it would be widened to a string.

This is the same mechanism as with:

const album: Album = { format: "Vinyl", };

Both of them provide the contextual type for that expression and it's what makes the literal string type to be retained in both of those examples

What I'm perhaps picky about here is that I wouldn't call it narrowing here. TS speaks of narrowing in its control flow analysis - when it narrow a union type to one of its members in a branch etc

Andarist · 2024-07-21T08:46:42Z

book-content/chapters/11-annotations-and-assertions.md

+const id = <string>searchParams.get("id");
+```
+
+This is less common than `as`, but behaves exactly the same way. `as` is more common, so it's better to use that.


it also just doesn't work in .tsx files (nor in .cts or .mts). I feel like you can mention this as an artifact of the past that people might see in some older codebases but strongly recommend that as is the way to go and the only way that should be used nowadays

Andarist · 2024-07-21T08:49:54Z

book-content/chapters/11-annotations-and-assertions.md

+
+#### The Limits of `as`
+
+`as` has some limits on how it can be used. It can't be used to convert between unrelated types.


It can only be used to "convert" (downcast or upcast) between comparable types (one has to be a subtype of the other one for it to work)... with a "beautiful" exception of:

declare const b: "b" const a = "a" as typeof b;

Those shouldn't quite be comparable - two literal types don't form the subtype/supertype relationship and yet this casting is allowed. I think I read that this was a bug that slipped through for enough period of time that it has now been codified as a feature :v

Andarist · 2024-07-21T08:53:39Z

book-content/chapters/11-annotations-and-assertions.md

+const paulsBoutiqueSales = paulsBoutique as SalesData;
+```
+
+Again, TypeScript shows us the warning about the lack of common properties.


since u mention common properties... it's also worth mentioning that TypeScript has a concept of "weak types". In an alternative universe this could be fine but in TS it isn't:

declare const obj1: { a?: number }; const obj2: { b?: number } = obj1; // error

When the type has only optional properties then a common property is still required for the assignment to work.

Andarist · 2024-07-21T08:54:52Z

book-content/chapters/11-annotations-and-assertions.md

+const id = searchParams.get("id")!;
+```
+
+This forces TypeScript to treat `id` as a string, even though it could be `null` at runtime. It's the equivalent of using `as string`, but is a little more convenient.


Suggested change

This forces TypeScript to treat `id` as a string, even though it could be `null` at runtime. It's the equivalent of using `as string`, but is a little more convenient.

This forces TypeScript to treat `id` as a string, even though it could be `null` at runtime. It's the equivalent of using `as string` in this example, but is a little more convenient.

It's more like an equivalent of as NonNullable<SomeNullableType>/as NonNullable<typeof foo>

Andarist · 2024-07-21T09:01:25Z

book-content/chapters/11-annotations-and-assertions.md

+
+#### `as any` vs Error Suppression Directives
+
+When there's a choice with how to suppress an error, I prefer using `as any`. Error suppression directives are too broad - they target the entire line of code. This can lead to accidentally suppressing errors that you didn't mean to:


It's also somewhat "easy" to reason about as any because there are certain rules around it. We know how it propagates through types etc. A suppression might easily result in an error type that is displayed as any on hover... but it doesn't really have well-defined rules around it and there is no plan to codify them. All bets are off at that point. In fact, one behavior around them changed in the recent 5.5... so it actually broke some libraries/tools relying on the old behavior and there is no intention to bring back the old behavior

Andarist · 2024-07-21T09:05:40Z

book-content/chapters/11-annotations-and-assertions.md

+
+In the first, we construct an object by passing in the keys and values. In the second, we construct an empty object and add the keys and values later. The first pattern is static, the second is dynamic.
+
+But in TypeScript, the first pattern is much easier to work with. TypeScript can infer the type of `obj` as `{ a: number, b: number }`. But it can't infer the type of `obj2` - it's just an empty object. In fact, you'll get errors when you try to do this.


Fun fact, TS supports the dynamic variant in JS files :D it doesn't do it in overly safe way though:

const obj = {} obj.a = 1 if (Math.random()) { obj.b = 'foo' } obj // { a: number; b: string }

Andarist · 2024-07-21T09:07:25Z

book-content/chapters/11-annotations-and-assertions.md

+
+Think of the time you invest in fixing TypeScript errors as an investment in yourself. You're both fixing potential bugs in the future, and levelling up your own understanding.
+
+## Exercises


weirdly there are no exercises 1, 3 and 5 here

Andarist · 2024-07-21T09:13:37Z

book-content/chapters/11-annotations-and-assertions.md

+
+<Exercise title="Exercise 8: Create a Deeply Read-Only Object" filePath="/src/045-annotations-and-assertions/148-satisfies-with-as-const.problem.ts"></Exercise>
+
+### Solution 2: Provide Additional Info to TypeScript


i'm surprised that a solution using a non-null assertion isn't mentioned here

Andarist · 2024-07-21T09:20:42Z

book-content/chapters/11-annotations-and-assertions.md

I think you mentioned auto-types elsewhere but I'm not sure if u mentioned auto array types. I'm not sure if it's the best chapter to dive deeper into them but I thought about them when reading this so i figured out that it might be worth sharing:

let something if (Math.random()) { something = 1 } else { something = 'foo' } something // number | string let someArray = [] if (Math.random()) { someArray.push(1) } else { someArray.push('foo') } someArray // (number | string)[]

TS is pretty smart 😅

One extra thing I thought of is this thing:

function test1() { let foo: string // allowed but even if we don't assign string right away return foo // it's smart enough to reject it now because it wasn't initialized! } function test2() { let foo: string if (Math.random()) { foo = 'a' } else { foo = 'b' } return foo // it's fine, it knows that it has been initialized! }

oh, i see that auto/evolving types are mentioned right in the next chapter, cool :)

Chapter 11

d8763c8

Andarist commented Jul 20, 2024

View reviewed changes

Andarist commented Jul 21, 2024

View reviewed changes

Andarist marked this pull request as ready for review July 21, 2024 09:20


		There's a difference in TypeScript between annotating _variables_ and _values_. The way they conflict can be confusing.

		### When You Annotate A Variable, The Variable Wins

	### When You Annotate A Variable, The Variable Wins
	### When You Annotate A Variable, The Annotation Wins


		But this isn't really what we want - this is a config object that shouldn't be changed.

		### With No Annotation, The Value Wins

	### With No Annotation, The Value Wins
	### With No Annotation, The Inferred Type of a Value Is Used


		#### The Limits of `as`

		`as` has some limits on how it can be used. It can't be used to convert between unrelated types.

	This forces TypeScript to treat `id` as a string, even though it could be `null` at runtime. It's the equivalent of using `as string`, but is a little more convenient.
	This forces TypeScript to treat `id` as a string, even though it could be `null` at runtime. It's the equivalent of using `as string` in this example, but is a little more convenient.


		#### `as any` vs Error Suppression Directives

		When there's a choice with how to suppress an error, I prefer using `as any`. Error suppression directives are too broad - they target the entire line of code. This can lead to accidentally suppressing errors that you didn't mean to:


		In the first, we construct an object by passing in the keys and values. In the second, we construct an empty object and add the keys and values later. The first pattern is static, the second is dynamic.

		But in TypeScript, the first pattern is much easier to work with. TypeScript can infer the type of `obj` as `{ a: number, b: number }`. But it can't infer the type of `obj2` - it's just an empty object. In fact, you'll get errors when you try to do this.


		Think of the time you invest in fixing TypeScript errors as an investment in yourself. You're both fixing potential bugs in the future, and levelling up your own understanding.

		## Exercises


		<Exercise title="Exercise 8: Create a Deeply Read-Only Object" filePath="/src/045-annotations-and-assertions/148-satisfies-with-as-const.problem.ts"></Exercise>

		### Solution 2: Provide Additional Info to TypeScript

Chapter 11 #11

Are you sure you want to change the base?

Chapter 11 #11

Uh oh!

Conversation

Andarist commented Jul 20, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Andarist Jul 21, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Andarist Jul 21, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Andarist Jul 21, 2024 •

edited

Loading

Andarist Jul 21, 2024 •

edited

Loading