Indexed access types in Typescript - Time & Space Complexity

Time Complexity: Indexed access types

O(n)

Understanding Time Complexity

We want to understand how the time it takes to access types using indexed access changes as the input grows.

Specifically, how does the cost grow when we use indexed access types in TypeScript?

Scenario Under Consideration

Analyze the time complexity of the following code snippet.

type Person = {
  name: string;
  age: number;
  location: string;
};

// Access the type of the 'age' property
type AgeType = Person['age'];

// Access the type of a union of keys
type NameOrLocation = Person['name' | 'location'];
    

This code uses indexed access types to get the type of specific properties from an object type.

Identify Repeating Operations

Identify the loops, recursion, array traversals that repeat.

• Primary operation: Type lookup for each key in the union inside the indexed access.
• How many times: Once per key in the union type (for example, 1 for 'age', 2 for 'name' | 'location').

How Execution Grows With Input

As the number of keys in the union grows, the number of type lookups grows linearly.

Input Size (number of keys)	Approx. Operations (type lookups)
1	1
10	10
100	100

Pattern observation: The work grows directly with the number of keys accessed.

Final Time Complexity

Time Complexity: O(n)

This means the time to resolve the indexed access type grows linearly with the number of keys in the union.

Common Mistake

[X] Wrong: "Indexed access types always take constant time regardless of keys."

[OK] Correct: When accessing multiple keys in a union, each key requires a separate lookup, so time grows with the number of keys.

Interview Connect

Understanding how type operations scale helps you reason about code maintainability and performance in TypeScript projects.

Self-Check

"What if we changed the union of keys to a single key type? How would the time complexity change?"

Practice

1. What does the TypeScript indexed access type Person['name'] represent?

easy

A. A function that returns the 'name' property

B. The type of the 'name' property in the Person type

C. An error because 'name' is not a valid type

D. A new property called 'name' added to Person

Solution

1. Step 1: Understand indexed access syntax

   The syntax Type['property'] extracts the type of the specified property from the given type.

2. Step 2: Apply to Person['name']

   This means Person['name'] is the type of the 'name' property inside the Person type.

3. Final Answer:

   The type of the 'name' property in the Person type -> Option B

4. Quick Check:

   Indexed access type = property type [OK]

Hint: Remember: Type['prop'] gives the type of that property [OK]

Common Mistakes:

• Thinking it creates a new property
• Confusing it with a function call
• Assuming it causes a syntax error

2. Which of the following is the correct syntax to get the type of property age from type Person using indexed access types?

easy

A. type AgeType = Person['age'];

B. type AgeType = Person.age;

C. type AgeType = Person("age");

D. type AgeType = Person<age>;

Solution

1. Step 1: Recall indexed access syntax

   The correct syntax uses square brackets with the property name as a string: Type['property'].

2. Step 2: Check each option

   type AgeType = Person['age']; matches this syntax exactly: Person['age']. Others use dot notation or parentheses which are invalid here.

3. Final Answer:

   type AgeType = Person['age']; -> Option A

4. Quick Check:

   Use square brackets with quotes for indexed access [OK]

Hint: Use square brackets and quotes for property names [OK]

Common Mistakes:

• Using dot notation instead of brackets
• Using parentheses like a function call
• Using angle brackets incorrectly

3. Given the type type Person = { name: string; age: number; }, what is the type of Person['age']?

medium

A. string

B. boolean

C. any

D. number

Solution

1. Step 1: Look at the Person type definition

   The property 'age' in Person is defined as a number.

2. Step 2: Indexed access extracts that type

   So Person['age'] is the type number.

3. Final Answer:

   number -> Option D

4. Quick Check:

   Person['age'] = number [OK]

Hint: Check the property type inside the original type [OK]

Common Mistakes:

• Confusing 'age' type with 'name' type
• Assuming default any type
• Mixing up string and number types

4. What is wrong with this TypeScript code?

type Person = { name: string; age: number; };
type AgeType = Person[age];

medium

A. AgeType cannot be assigned

B. Person type is not defined

C. Missing quotes around 'age' in indexed access

D. No error, code is correct

Solution

1. Step 1: Identify the indexed access syntax error

   In Person[age], 'age' should be a string literal in quotes: Person['age'].

2. Step 2: Understand why quotes are needed

   Without quotes, TypeScript treats age as a variable, which is undefined here, causing an error.

3. Final Answer:

   Missing quotes around 'age' in indexed access -> Option C

4. Quick Check:

   Property names in indexed access need quotes [OK]

Hint: Always put property names in quotes inside brackets [OK]

Common Mistakes:

• Omitting quotes around property names
• Assuming dot notation works in type access
• Confusing variables with string literals

5. Given the type type Config = { options: { debug: boolean; verbose: boolean; }; version: string; }, which type correctly extracts the type of the debug property using indexed access types?

hard

A. Config['options']['debug']

B. Config.options.debug

C. Config['debug']

D. Config['options.debug']

Solution

1. Step 1: Understand nested indexed access

   The 'debug' property is inside 'options', so we first access 'options' then 'debug'.

2. Step 2: Apply chained indexed access syntax

   Use Config['options']['debug'] to get the type of 'debug'.

3. Step 3: Check other options

   Config.options.debug uses dot notation which is invalid in type access. Config['debug'] tries to access 'debug' directly on Config which doesn't exist. Config['options.debug'] treats 'options.debug' as a single property name which is incorrect.

4. Final Answer:

   Config['options']['debug'] -> Option A

5. Quick Check:

   Use chained brackets for nested properties [OK]

Hint: Chain brackets for nested property types [OK]

Common Mistakes:

• Using dot notation in type access
• Accessing nested property directly without parent
• Treating nested keys as single string