book

Effective TypeScript

by Dan Vanderkam

October 2019

Intermediate to advanced

261 pages

6h 14m

English

O'Reilly Media, Inc.

Book available

Read now

Unlock full access

Who This Book Is ForWhy I Wrote This BookHow This Book Is OrganizedConventions in TypeScript Code SamplesTypographical Conventions Used in This BookUsing Code ExamplesO’Reilly Online LearningHow to Contact UsAcknowledgments
Item 1: Understand the Relationship Between TypeScript and JavaScriptItem 2: Know Which TypeScript Options You’re UsingItem 3: Understand That Code Generation Is Independent of TypesItem 4: Get Comfortable with Structural TypingItem 5: Limit Use of the any Type
Item 6: Use Your Editor to Interrogate and Explore the Type SystemItem 7: Think of Types as Sets of ValuesItem 8: Know How to Tell Whether a Symbol Is in the Type Space or Value SpaceItem 9: Prefer Type Declarations to Type AssertionsItem 10: Avoid Object Wrapper Types (String, Number, Boolean, Symbol, BigInt)Item 11: Recognize the Limits of Excess Property CheckingItem 12: Apply Types to Entire Function Expressions When PossibleItem 13: Know the Differences Between type and interfaceItem 14: Use Type Operations and Generics to Avoid Repeating YourselfItem 15: Use Index Signatures for Dynamic DataItem 16: Prefer Arrays, Tuples, and ArrayLike to number Index SignaturesItem 17: Use readonly to Avoid Errors Associated with MutationItem 18: Use Mapped Types to Keep Values in Sync
Item 19: Avoid Cluttering Your Code with Inferable TypesItem 20: Use Different Variables for Different TypesItem 21: Understand Type WideningItem 22: Understand Type NarrowingItem 23: Create Objects All at OnceItem 24: Be Consistent in Your Use of AliasesItem 25: Use async Functions Instead of Callbacks for Asynchronous CodeItem 26: Understand How Context Is Used in Type InferenceItem 27: Use Functional Constructs and Libraries to Help Types Flow
Item 28: Prefer Types That Always Represent Valid StatesItem 29: Be Liberal in What You Accept and Strict in What You ProduceItem 30: Don’t Repeat Type Information in DocumentationItem 31: Push Null Values to the Perimeter of Your TypesItem 32: Prefer Unions of Interfaces to Interfaces of UnionsItem 33: Prefer More Precise Alternatives to String TypesItem 34: Prefer Incomplete Types to Inaccurate TypesItem 35: Generate Types from APIs and Specs, Not DataItem 36: Name Types Using the Language of Your Problem DomainItem 37: Consider “Brands” for Nominal Typing
Item 38: Use the Narrowest Possible Scope for any TypesItem 39: Prefer More Precise Variants of any to Plain anyItem 40: Hide Unsafe Type Assertions in Well-Typed FunctionsItem 41: Understand Evolving anyItem 42: Use unknown Instead of any for Values with an Unknown TypeItem 43: Prefer Type-Safe Approaches to Monkey PatchingItem 44: Track Your Type Coverage to Prevent Regressions in Type Safety
Item 45: Put TypeScript and @types in devDependenciesItem 46: Understand the Three Versions Involved in Type DeclarationsItem 47: Export All Types That Appear in Public APIsItem 48: Use TSDoc for API CommentsItem 49: Provide a Type for this in CallbacksItem 50: Prefer Conditional Types to Overloaded DeclarationsItem 51: Mirror Types to Sever DependenciesItem 52: Be Aware of the Pitfalls of Testing Types
Item 53: Prefer ECMAScript Features to TypeScript FeaturesItem 54: Know How to Iterate Over ObjectsItem 55: Understand the DOM hierarchyItem 56: Don’t Rely on Private to Hide InformationItem 57: Use Source Maps to Debug TypeScript
Item 58: Write Modern JavaScriptItem 59: Use @ts-check and JSDoc to Experiment with TypeScriptItem 60: Use allowJs to Mix TypeScript and JavaScriptItem 61: Convert Module by Module Up Your Dependency GraphItem 62: Don’t Consider Migration Complete Until You Enable noImplicitAny

Content preview from Effective TypeScript

Preface

In the spring of 2016, I visited my old coworker Evan Martin at Google’s San Francisco office and asked him what he was excited about. I’d asked him this same question many times over the years because the answers were wide-ranging and unpredictable but always interesting: C++ build tools, Linux audio drivers, online crosswords, emacs plugins. This time, Evan was excited about TypeScript and Visual Studio Code.

I was surprised! I’d heard of TypeScript before, but I knew only that it was created by Microsoft and that I mistakenly believed it had something to do with .NET. As a lifelong Linux user, I couldn’t believe that Evan had hopped on team Microsoft.

Then Evan showed me vscode and the TypeScript playground and I was instantly converted. Everything was so fast, and the code intelligence made it easy to build a mental model of the type system. After years of writing type annotations in JSDoc comments for the Closure Compiler, this felt like typed JavaScript that really worked. And Microsoft had built a cross-platform text editor on top of Chromium? Perhaps this was a language and toolchain worth learning.

I’d recently joined Sidewalk Labs and was writing our first JavaScript. The codebase was still small enough that Evan and I were able to convert it all to TypeScript over the next few days.

I’ve been hooked ever since. TypeScript is more than just a type system. It also brings a whole suite of language services which are fast and easy to use. The cumulative effect is ...