[FE] 《TypeScript Deep Dive》a gla
Goals
https://basarat.gitbook.io/typescript/getting-started/why-typescript
There are two main goals of TypeScript:
- Provide an optional type system for JavaScript.
- Provide planned features from future JavaScript editions to current JavaScript engines
Types
https://basarat.gitbook.io/typescript/getting-started/why-typescript#the-typescript-type-system
Types have proven ability to enhance code quality and understandability. Large teams (Google, Microsoft, Facebook) have continually arrived at this conclusion. Specifically:
- Types increase your agility when doing refactoring. It's better for the compiler to catch errors than to have things fail at runtime.
- Types are one of the best forms of documentation you can have. The function signature is a theorem and the function body is the proof.
In programming language theory and proof theory, the Curry–Howard correspondence (also known as the Curry–Howard isomorphism or equivalence, or the proofs-as-programs and propositions- or formulae-as-types interpretation) is the direct relationship between computer programs and mathematical proofs.
—— https://en.wikipedia.org/wiki/Curry%E2%80%93Howard_correspondence
However, types have a way of being unnecessarily ceremonious.
Structural Type System
A structural type system (or property-based type system) is a major class of type system in which type compatibility and equivalence are determined by the type's actual structure or definition and not by other characteristics such as its name or place of declaration.
Structural systems are used to determine if types are equivalent and whether a type is a subtype of another. It contrasts with nominative systems, where comparisons are based on the names of the types or explicit declarations, and duck typing, in which only the part of the structure accessed at runtime is checked for compatibility.
https://basarat.gitbook.io/typescript/getting-started/why-typescript#types-are-structural
In some languages (specifically nominally typed ones) static typing results in unnecessary ceremony because even though you know that the code will work fine the language semantics force you to copy stuff around. This is why stuff like automapper for C# is vital for C#. In TypeScript because we really want it to be easy for JavaScript developers with a minimum cognitive overload, types are structural. This means that duck typing is a first class language construct.
https://basarat.gitbook.io/typescript/type-system/type-compatibility#structural
TypeScript objects are structurally typed. This means the names don't matter as long as the structures match.
Bottom Type
In type theory, a theory within mathematical logic, the bottom type is the type that has no values. It is also called the zero or empty type, and is sometimes denoted with the up tack (
⊥) symbol.
https://basarat.gitbook.io/typescript/type-system/never
Programming language design does have a concept of bottom type that is a natural outcome as soon as you do code flow analysis. TypeScript does code flow analysis and so it needs to reliably represent stuff that might never happen.
The never type is used in TypeScript to denote this bottom type. Cases when it occurs naturally:
- A function never returns (e.g. if the function body has
while(true){}) - A function always throws (e.g. in function
foo(){throw new Error('Not Implemented')} the return type of foo is never)
Soundness
Soundness also has a related meaning in mathematical logic, wherein logical systems are sound if and only if every formula that can be proved in the system is logically valid with respect to the semantics of the system.
https://basarat.gitbook.io/typescript/type-system/type-compatibility#soundness
TypeScript's type system is designed to be convenient and allows for unsound behaviours e.g. anything can be assigned to any which means telling the compiler to allow you to do whatever you want.
Freshness (Strict Object Literal Checking)
https://basarat.gitbook.io/typescript/type-system/freshness#freshness
TypeScript provides a concept of Freshness (also called strict object literal checking) to make it easier to type check object literals that would otherwise be structurally type compatible.
Trivia
https://basarat.gitbook.io/typescript/overview/ast/ast-trivia
Trivia (called that because it's trivial) represent the parts of the source text that are largely insignificant for normal understanding of the code. For example; whitespace, comments, and even conflict markers. Trivia is not stored in the AST (to keep it lightweight). However, it can be fetched on demand using a few ts.* APIs.
Semantic system
https://basarat.gitbook.io/typescript/overview/binder
Most JavaScript transpilers out there are simpler than TypeScript because they provide little in the way of code analysis. The typical JavaScript transpilers only have the following flow:
SourceCode ~~Scanner~~> Tokens ~~Parser~~> AST ~~Emitter~~> JavaScript
While the above architecture is true as a simplified understanding of TypeScript js generation, a key feature of TypeScript is its Semantic system. In order to assist type checking, the binder is used to connect the various parts of the source code into a coherent type system that can then be used by the checker. The main responsibility of the binder is to create Symbols.
Symbols
https://basarat.gitbook.io/typescript/overview/binder#symbol
Symbols connect declaration nodes in the AST to other declarations contributing to the same entity. Symbols are the basic building blocks of the Semantic system.
Checker
https://basarat.gitbook.io/typescript/overview/checker
Like we mentioned before checker is the thing that makes TypeScript uniquely more powerful than just another JavaScript transpiler.
