book

Effective TypeScript, 2nd Edition

by Dan Vanderkam

April 2024

Beginner to intermediate

404 pages

10h 6m

English

O'Reilly Media, Inc.

Read now

Unlock full access

Includes

Has Sandbox

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
Acknowledgments to the First Edition
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 Annotations to Type AssertionsItem 10: Avoid Object Wrapper Types (String, Number, Boolean, Symbol, BigInt)Item 11: Distinguish Excess Property Checking from Type CheckingItem 12: Apply Types to Entire Function Expressions When PossibleItem 13: Know the Differences Between type and interfaceItem 14: Use readonly to Avoid Errors Associated with MutationItem 15: Use Type Operations and Generic Types to Avoid Repeating YourselfItem 16: Prefer More Precise Alternatives to Index SignaturesItem 17: Avoid Numeric Index Signatures
Item 18: Avoid Cluttering Your Code with Inferable TypesItem 19: Use Different Variables for Different TypesItem 20: Understand How a Variable Gets Its TypeItem 21: Create Objects All at OnceItem 22: Understand Type NarrowingItem 23: Be Consistent in Your Use of AliasesItem 24: Understand How Context Is Used in Type InferenceItem 25: Understand Evolving TypesItem 26: Use Functional Constructs and Libraries to Help Types FlowItem 27: Use async Functions Instead of Callbacks to Improve Type FlowItem 28: Use Classes and Currying to Create New Inference Sites
Item 29: Prefer Types That Always Represent Valid StatesItem 30: Be Liberal in What You Accept and Strict in What You ProduceItem 31: Don’t Repeat Type Information in DocumentationItem 32: Avoid Including null or undefined in Type AliasesItem 33: Push Null Values to the Perimeter of Your TypesItem 34: Prefer Unions of Interfaces to Interfaces with UnionsItem 35: Prefer More Precise Alternatives to String TypesItem 36: Use a Distinct Type for Special ValuesItem 37: Limit the Use of Optional PropertiesItem 38: Avoid Repeated Parameters of the Same TypeItem 39: Prefer Unifying Types to Modeling DifferencesItem 40: Prefer Imprecise Types to Inaccurate TypesItem 41: Name Types Using the Language of Your Problem DomainItem 42: Avoid Types Based on Anecdotal Data
Item 43: Use the Narrowest Possible Scope for any TypesItem 44: Prefer More Precise Variants of any to Plain anyItem 45: Hide Unsafe Type Assertions in Well-Typed FunctionsItem 46: Use unknown Instead of any for Values with an Unknown TypeItem 47: Prefer Type-Safe Approaches to Monkey PatchingItem 48: Avoid Soundness TrapsItem 49: Track Your Type Coverage to Prevent Regressions in Type Safety
Item 50: Think of Generics as Functions Between TypesItem 51: Avoid Unnecessary Type ParametersItem 52: Prefer Conditional Types to Overload SignaturesItem 53: Know How to Control the Distribution of Unions over Conditional TypesItem 54: Use Template Literal Types to Model DSLs and Relationships Between StringsItem 55: Write Tests for Your TypesItem 56: Pay Attention to How Types DisplayItem 57: Prefer Tail-Recursive Generic TypesItem 58: Consider Codegen as an Alternative to Complex Types
Item 59: Use Never Types to Perform Exhaustiveness CheckingItem 60: Know How to Iterate Over ObjectsItem 61: Use Record Types to Keep Values in SyncItem 62: Use Rest Parameters and Tuple Types to Model Variadic FunctionsItem 63: Use Optional Never Properties to Model Exclusive OrItem 64: Consider Brands for Nominal Typing
Item 65: Put TypeScript and @types in devDependenciesItem 66: Understand the Three Versions Involved in Type DeclarationsItem 67: Export All Types That Appear in Public APIsItem 68: Use TSDoc for API CommentsItem 69: Provide a Type for this in Callbacks if It’s Part of Their APIItem 70: Mirror Types to Sever DependenciesItem 71: Use Module Augmentation to Improve Types

Item 72: Prefer ECMAScript Features to TypeScript FeaturesItem 73: Use Source Maps to Debug TypeScriptItem 74: Know How to Reconstruct Types at RuntimeItem 75: Understand the DOM HierarchyItem 76: Create an Accurate Model of Your EnvironmentItem 77: Understand the Relationship Between Type Checking and Unit TestingItem 78: Pay Attention to Compiler Performance
Item 79: Write Modern JavaScriptItem 80: Use @ts-check and JSDoc to Experiment with TypeScriptItem 81: Use allowJs to Mix TypeScript and JavaScriptItem 82: Convert Module by Module Up Your Dependency GraphItem 83: Don’t Consider Migration Complete Until You Enable noImplicitAny

Content preview from Effective TypeScript, 2nd Edition

Chapter 4. Type Design

Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious.

Fred Brooks, The Mythical Man Month (Addison-Wesley Professional)

The language in Fred Brooks’s quote is dated, but the sentiment remains true: code is difficult to understand if you can’t see the data or data types on which it operates. This is one of the great advantages of a type system: by writing out types, you make them visible to readers of your code. And this makes your code understandable.

Other chapters cover the nuts and bolts of TypeScript types: using them, inferring them, transforming them, and writing declarations with them. This chapter discusses the design of the types themselves. The examples in this chapter are all written with TypeScript in mind, but most of the ideas are more broadly applicable.

If you write your types well, then with any luck your flowcharts will be obvious, too.

Item 29: Prefer Types That Always Represent Valid States

If you design your types well, your code should be straightforward to write. But if you design your types poorly, no amount of cleverness or documentation will save you. Your code will be confusing and prone to bugs.

A key to effective type design is crafting types that can only represent a valid state. This item walks through a few examples of how this can go wrong and shows you how to fix them.

Suppose you’re building a web application ...