Please enable JavaScript.
Coggle requires JavaScript to display documents.
TypeScript - Intermediate Concepts (Type compatibility (Function…
TypeScript - Intermediate Concepts
Type inference
Best common type
Union type of candidate types is used when no clear super type is present
Can be overridden by explicit type annotations
Picks the candidate type that's compatible with all other candidate types
Contextual typing
Type of an expression is implied by its location
Can be overridden by explicit type annotations
Uses the implicit any type when not in a contextually typed position
Uses the types on the left-hand side to infer types on the right-hand side in a contextually typed position
Simple inference
Initializing variables and members
Setting parameter default values
Determining function return values
Type compatibility
Typing
Nominal typing
Type relationships are explicitly described
Structural subtyping
Types are related based solely on their members
Soundness
Operations that can't be known as safe at compile time are unsound
Compatibility
Subtype
Assignment
Types
Target type is compatible with source type if the target type has at least the members of the source type
Members are evaluated recursively
Function comparison
Target function can have more parameters than the source function
Source function's return type should be a subtype of target function's return type
Parameter bivariance
Parameter types are compatible if either the source parameter is assignable to the target parameter, or vice versa
Unsound
Overloads
Source and target should have the same overloads
Optional and rest parameters
Optional and required parameters are considered interchangeable in terms of compatibility
Rest parameters
Unsound
Treated as an infinite series of optional parameters
Generics
Compatible if the specified type parameter isn't used in a differentiating manner
Compatible if the types are compatible after substituting any for type parameters that aren't specified
Classes
Compatible if the members of the instance sides are compatible
Compatible if private and protected members are compatible and originated in the same declaration
Enums
Compatible with numbers, or vice versa
Enum values from different enum types aren't compatible
Symbols, iterators, and generators
Symbols
Primitive data type
Created using the Symbol with an optional description
Immutable
Unique
As computed properties
Object properties
Class members
Iterators
An object is iterable if it has an implementation for the Symbol.iterator property
Symbol.iterator function returns the list of values to iterated on
for..of loops iterates over values by invoking the Symbol.iterator property of an iterable object
for..in loops iterates over properties of any object
Targeting ES5 and below
Only the Array type can be iterated on
for..of loops are transpiled to for loops
Modules
Relationships between modules are declaratively defined using import and export statements
Any file containing a top-level import or export statement
Module loaders
Locates and executes dependant modules at runtime
Node.js loader for CommonJS
RequireJS loader for AMD
Modules used only in type positions are not loaded at runtime
Exports
Export declarations
Export statements
Renaming exports
Re-exporting
Doesn't create a local variable
Re-exporting from a single variable
Default exports
One per module
Default exported class and function declaration names are optional
Imports
Renaming imports
Importing to a single variable
Importing for side-effects
import = syntax should be used when the exports object has been replaced in the consumed module
Structuring modules
Reduce indirection
Avoid exporting namespaces and classes that add extra levels of indirection
Use default exports for exporting a single export
Export everything from the top-level when exporting multiple exports
Re-export to extend modules
Avoid augmenting other exports to extend their functionality
Use module re-exporting to extend while retaining the original module's API
Avoid namespaces in modules
Namespaces are useful for avoiding naming collisions in the global scope
Modules have their own scope by design
Compiler options
--module
commonjs or amd
--outFile
Generate a single output file
--noResolve
Ignore triple-slash references
Namespaces
Namespacing
Exported members can be accessed through the namespace identifier
Members that aren't exported are hidden from outer scopes
Uses
Avoids polluting the global scope
Reduces naming collisions in the global scope
Multi-file namespaces
Code in different files can contribute to the same namespace
Reference tags should be added to define the file relationships for the compiler
Individual JavaScript files should be loaded in the appropriate order
Aliases
Creates a distinct reference to a symbol
import q = x.y.z
Changes to values are not reflected in the original symbol
Ambient namespaces
Used to define type definitions for libraries that expose their functionality as global objects
Named objects in the global scope
Triple-slash directives
Single line comments with a single XML tag
Functions as compiler directives
Only valid at the top of the containing file
reference
path
Declare dependencies between files
Includes additional files or orders output files in compilation
types
Declare dependency on a package