Why Indexed access types in Typescript? - Purpose & Use Cases

The Big Idea

What if you could ask your code to tell you exactly what type a property has, without guessing or repeating yourself?

The Scenario

Imagine you have a big box of different toys, and you want to pick a specific toy by its label every time. Without a clear way to look up the toy by its label, you have to search through the whole box manually each time.

The Problem

Manually checking each toy's label is slow and can lead to mistakes, like picking the wrong toy or forgetting which labels exist. It's hard to keep track and easy to get confused when the box gets bigger.

The Solution

Indexed access types let you directly ask for the type of a specific property inside an object type by using its key. This means you can quickly and safely get the exact type you want without guessing or repeating yourself.

Before vs After

✗ Before

type User = { name: string; age: number };
type UserName = string; // manually repeating the type

✓ After

type User = { name: string; age: number };
type UserName = User['name']; // directly gets the type of 'name'

What It Enables

It makes your code smarter and safer by letting you reuse and check types automatically based on existing structures.

Real Life Example

When building a form, you can use indexed access types to ensure the input fields match the exact data types defined in your user profile, avoiding mistakes and extra work.

Key Takeaways

Manual type repetition is slow and error-prone.

Indexed access types let you get property types directly from objects.

This keeps your code clean, safe, and easy to maintain.

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