What types exist only at compile time in Typescript - Time & Space Complexity
We want to understand how TypeScript handles types that only exist when the code is checked, not when it runs.
How does this affect the work the computer does as the program grows?
Analyze the time complexity of the following TypeScript code snippet.
type User = {
id: number;
name: string;
};
function greet(user: User) {
console.log(`Hello, ${user.name}`);
}
This code defines a type and uses it only to check the function input during development.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: There are no loops or repeated operations at runtime related to types.
- How many times: Type checks happen only once during compilation, not during running the program.
Type checking work grows as the code and types grow, but this does not affect the running program's speed.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 lines of typed code | Small amount of type checks |
| 100 lines of typed code | More type checks, but still only at compile time |
| 1000 lines of typed code | Much more type checking work, still no runtime cost |
Pattern observation: The checking work grows with code size, but it does not slow down the program when it runs.
Time Complexity: O(1)
This means the program's running speed does not change because of these compile-time-only types.
[X] Wrong: "Types slow down the program when it runs because they add extra work."
[OK] Correct: Types in TypeScript exist only during development and disappear when the program runs, so they do not affect runtime speed.
Knowing that some types only exist during compile time helps you explain how TypeScript keeps code safe without slowing down the program, a useful skill in real projects.
"What if we added runtime type checks inside the function? How would the time complexity change?"
Practice
Solution
Step 1: Understand TypeScript compile-time types
Interfaces and type aliases are used only to check types during compilation and do not exist in the final JavaScript.Step 2: Identify runtime constructs
Classes, enums, functions, variables, objects, and arrays exist in the JavaScript output and run at runtime.Final Answer:
Interfaces and type aliases -> Option CQuick Check:
Compile-time only types = Interfaces, type aliases [OK]
- Thinking classes are compile-time only
- Confusing enums with type aliases
- Assuming variables are compile-time types
Solution
Step 1: Identify type alias syntax
Usingtype User = { ... }declares a type alias that exists only during compilation.Step 2: Differentiate from runtime declarations
Const objects, classes, and enums produce JavaScript code and exist at runtime.Final Answer:
type User = { name: string; age: number }; -> Option AQuick Check:
Type alias syntax = type ... = ... [OK]
- Using const or class instead of type alias
- Confusing enums with types
- Missing semicolon in type alias
interface Person { name: string; age: number; }
const p: Person = { name: 'Bob', age: 25 };
console.log(typeof Person);Solution
Step 1: Understand interface removal at compile time
Interfaces do not exist in JavaScript output, soPersonis not defined at runtime.Step 2: Evaluate typeof on undefined identifier
Usingtypeof Personwhen Person is not defined returns "undefined" as a string.Final Answer:
"undefined" -> Option AQuick Check:
Interfaces vanish, typeof interface = "undefined" [OK]
- Expecting 'object' because of interface
- Thinking interface is a function
- Confusing interface with class
type Animal = { species: string };
console.log(Animal);Solution
Step 1: Recognize type alias compile-time only nature
Type aliases do not exist in JavaScript, soAnimalis not a runtime value.Step 2: Understand console.log usage
Trying to logAnimalcauses a runtime error because it is undefined in JavaScript.Final Answer:
Animal is not defined at runtime, so console.log causes an error -> Option DQuick Check:
Logging type alias = runtime error [OK]
- Thinking type aliases exist at runtime
- Ignoring runtime vs compile-time difference
- Assuming missing semicolon causes error
Solution
Step 1: Understand compile-time type checking
Interfaces define object shapes only at compile time and do not generate JavaScript code, so no runtime overhead.Step 2: Compare with other options
Classes and enums generate runtime code; type aliases do not create runtime objects unless explicitly instantiated.Final Answer:
Use an interface to define the object shape -> Option BQuick Check:
Interfaces = compile-time only, no runtime overhead [OK]
- Using classes which add runtime code
- Confusing enums with object shapes
- Thinking type aliases create runtime objects
Ready to prove it?
Pass the test and this pattern moves unknown
