diff --git a/chapters/Basics.md b/chapters/Basics.md index 1335d7b..48c72ca 100644 --- a/chapters/Basics.md +++ b/chapters/Basics.md @@ -185,7 +185,7 @@ npm install -g typescript > This installs the TypeScript Compiler `tsc` globally. > You can use `npx` or similar tools if you'd prefer to run `tsc` from a local `node_modules` package instead. -Now let's move to an empty folder and try writing our first TypeScript program: `hello.ts`: +Now create an empty directory named ts-example and create a new file called: `hello.ts` and input the following code: ```ts // Greets the world. @@ -208,7 +208,7 @@ Well, there were no type errors, so we didn't get any output in our console sinc But check again - we got some *file* output instead. If we look in our current directory, we'll see a `hello.js` file next to `hello.ts`. That's the output from our `hello.ts` file after `tsc` *compiles* or *transforms* it into a JavaScript file. -And if we check the contents, we'll see what TypeScript spits out after it processes a `.ts` file: +And if we check the contents of the .js file, we'll see what TypeScript spits out after it processes a `.ts` file: ```js // Greets the world. @@ -217,7 +217,10 @@ console.log("Hello world!"); In this case, there was very little for TypeScript to transform, so it looks identical to what we wrote. The compiler tries to emit clean readable code that looks like something a person would write. -While that's not always so easy, TypeScript indents consistently, is mindful of when our code spans across different lines of code, and tries to keep comments around. +While that's not always so easy, TypeScript: +* Indents consistently +* Is mindful of when our code spans across different lines of code +* And tries to keep comments around What about if we *did* introduce a type-checking error? Let's rewrite `hello.ts`: @@ -246,7 +249,7 @@ Thanks TypeScript! One thing you might not have noticed from the last example was that our `hello.js` file changed again. If we open that file up then we'll see that the contents still basically look the same as our input file. -That might be a bit surprising given the fact that `tsc` reported an error about our code, but this based on one of TypeScript's core values: much of the time, *you* will know better than TypeScript. +That might be a bit surprising given the fact that `tsc` reported an error about our code, but this is based on one of TypeScript's core values: much of the time, *you* will know better than TypeScript. To reiterate from earlier, type-checking code limits the sorts of programs you can run, and so there's a tradeoff on what sorts of things a type-checker finds acceptable. Most of the time that's okay, but there are scenarios where those checks get in the way. @@ -321,7 +324,7 @@ That's a feature, and it's best not to add annotations when the type system woul ## Erased Types -Let's take a look at what happens when we compile with `tsc`: +Let's take a look at the differences in the JavaScript code created from `tsc`: ```js function greet(person, date) { diff --git a/chapters/More on Functions.md b/chapters/More on Functions.md index c0fa623..61c68a5 100644 --- a/chapters/More on Functions.md +++ b/chapters/More on Functions.md @@ -525,7 +525,7 @@ function noop() { In JavaScript, a function that doesn't return any value will implicitly return the value `undefined`. However, `void` and `undefined` are not the same thing in TypeScript. -See the reference page [[Why void is a special type]] for a longer discussion about this. +See the reference page [[Why Void Is A Special Type]] for a longer discussion about this. > `void` is not the same as `undefined`. @@ -533,7 +533,7 @@ See the reference page [[Why void is a special type]] for a longer discussion ab The special type `object` refers to any value that isn't a primitive (`string`, `number`, `boolean`, `symbol`, `null`, or `undefined`). This is different from the *empty object type* `{ }`, and also different from the global type `Object`. -You can read the reference page about [[The global types]] for information on what `Object` is for - long story short, don't ever use `Object`. +You can read the reference page about [[The Global Types]] for information on what `Object` is for - long story short, don't ever use `Object`. > `object` is not `Object`. **Always** use `object`! diff --git a/chapters/Narrowing.md b/chapters/Narrowing.md index 4125573..82b631b 100644 --- a/chapters/Narrowing.md +++ b/chapters/Narrowing.md @@ -187,7 +187,7 @@ TypeScript doesn't hurt us here at all, but this is behavior worth noting if you TypeScript can often help you catch bugs early on, but if you choose to do *nothing* with a value, there's only so much that it can do without being overly prescriptive. If you want, you can make sure you handle situations like these with a linter. -One last word on narrowing by truthiness is that Boolean negations with `!` filter out from negated branches. +One last word on narrowing by truthiness is that Boolean negations with `!`, filter out from negated branches. ```ts function multiplyAll(values: number[] | undefined, factor: number): number[] | undefined { diff --git a/chapters/Type Declarations.md b/chapters/Type Declarations.md index b2b39e4..61c6566 100644 --- a/chapters/Type Declarations.md +++ b/chapters/Type Declarations.md @@ -85,7 +85,7 @@ TypeScript automatically finds type definitions under `node_modules/@types`, so ### Your Own Definitions -In the uncommon event that a library didn't bundle its own types and didn't have a definition on DefinitelyTyped, you can write a declaration file yourself. +In the uncommon event that a library didn't bundle its own types and does not have a definition in the DefinitelyTyped repo, you can write a declaration file yourself. See the appendix [[Writing Declaration Files]] for a guide. If you want to silence warnings about a particular module without writing a declaration file, you can also quick declare the module as type `any` by putting an empty declaration for it in a `.d.ts` file in your project. diff --git a/chapters/Types from Transformation.md b/chapters/Types from Transformation.md index 3be4f85..af908c2 100644 --- a/chapters/Types from Transformation.md +++ b/chapters/Types from Transformation.md @@ -171,9 +171,8 @@ For example, we could have inferred the element type in `Flatten` instead of fet type Flatten = T extends Array ? U : T; ``` -Here, we used the `infer` keyword declaratively introduced a new generic type variable named `U` instead of specifying how to retrieve the element type of `T`. -Within the true branch -This frees us from having to think about how to dig through and probing apart the structure of the types we're interested. +Here, using the `infer` keyword declaratively introduced a new generic type variable named `U` instead of specifying how to retrieve the element type of `T`. +This frees us from having to think about how to dig through and probe apart the structure of the types we're interested. We can write some useful helper type aliases using the `infer` keyword. For example, for simple cases, we can extract the return type out from function types: