Building type-safe string patterns in Typescript - Step-by-Step Execution

Concept Flow - Building type-safe string patterns

Define string pattern types

↓

Create template literal types

↓

Use pattern types in variables/functions

↓

TypeScript checks string correctness

↓

Compile error if pattern mismatch

↓

Correct strings pass type check

We define string pattern types, use them in variables or functions, and TypeScript checks if strings match the pattern, giving errors if not.

Execution Sample

Typescript

type ID = `user_${number}`;

const validId: ID = "user_123";
const invalidId: ID = "admin_123"; // Error

Defines a type-safe string pattern for IDs starting with 'user_' followed by a number, then checks valid and invalid assignments.

Execution Table

Step	Action	Evaluation	Result
1	Define type ID as template literal `user_${number}`	Type ID created	Type ID expects strings like 'user_123'
2	Assign 'user_123' to validId of type ID	Check if 'user_123' matches `user_${number}`	Passes type check
3	Assign 'admin_123' to invalidId of type ID	Check if 'admin_123' matches `user_${number}`	Type error: string does not match pattern
4	End of checks	No further code	Compilation stops due to error on step 3

💡 Compilation stops because 'admin_123' does not match the pattern `user_${number}`

Variable Tracker

Variable	Start	After Step 2	After Step 3	Final
validId	undefined	'user_123'	'user_123'	'user_123'
invalidId	undefined	undefined	Error (no value assigned)	Error (compilation fails)

Key Moments - 2 Insights

Why does assigning 'admin_123' to invalidId cause an error?

Because the type ID requires strings starting with 'user_' followed by a number, 'admin_123' does not match this pattern as shown in execution_table step 3.

Can I assign 'user_abc' to validId?

No, because 'abc' is not a number, so it does not match the pattern `user_${number}`. TypeScript enforces this as seen in the pattern definition.

Visual Quiz - 3 Questions

Look at the execution table, what is the result of assigning 'user_123' to validId at step 2?

A Runtime error

B Passes type check

C Type error

D No effect

💡 Hint

Check execution_table row with Step 2 for assignment result

At which step does the compilation stop due to a type error?

A Step 3

B Step 2

C Step 1

D Step 4

💡 Hint

See exit_note and execution_table row with Step 3

If we change the pattern to `admin_${number}`, what happens when assigning 'user_123'?

A Passes type check

B Runtime error

C Type error

D No effect

💡 Hint

Refer to how pattern matching works in execution_table steps 2 and 3

Concept Snapshot

Type-safe string patterns use template literal types.
Define patterns like `user_${number}`.
Assign strings matching pattern to typed variables.
TypeScript errors if string doesn't match.
Ensures string format correctness at compile time.

Full Transcript

This example shows how to build type-safe string patterns in TypeScript using template literal types. We define a type ID as `user_${number}`, meaning strings must start with 'user_' followed by a number. When we assign 'user_123' to a variable of type ID, TypeScript accepts it because it matches the pattern. But assigning 'admin_123' causes a compile-time error because it does not match the pattern. This helps catch mistakes early by enforcing string formats during coding.

Practice

1. What is the main benefit of using type-safe string patterns in TypeScript?

easy

A. They ensure strings follow a specific format at compile time.

B. They make strings run faster at runtime.

C. They automatically convert strings to numbers.

D. They allow strings to be used as arrays.

Solution

1. Step 1: Understand type-safe string patterns

   Type-safe string patterns use TypeScript's template literal types to enforce string formats during coding.

2. Step 2: Identify the benefit

   This enforcement helps catch errors early by ensuring strings match expected patterns before running the program.

3. Final Answer:

   They ensure strings follow a specific format at compile time. -> Option A

4. Quick Check:

   Type-safe string patterns = compile-time format check [OK]

Hint: Type-safe patterns check string format before running code [OK]

Common Mistakes:

• Thinking they improve runtime speed
• Confusing with string-to-number conversion
• Assuming they change string behavior at runtime

2. Which of the following is the correct syntax to define a type-safe string pattern for a URL starting with "https://" in TypeScript?

easy

A. type URL = 'https://' & string;

B. type URL = "https://" + string;

C. type URL = string | 'https://';

D. type URL = `https://${string}`;

Solution

1. Step 1: Recognize template literal type syntax

   Type-safe string patterns use backticks and ${} placeholders, like `https://${string}`.

2. Step 2: Compare options

   type URL = `https://${string}`; uses correct template literal syntax. Options A, B, and D use invalid or incorrect TypeScript syntax for this purpose.

3. Final Answer:

   type URL = `https://${string}`; -> Option D

4. Quick Check:

   Template literal type syntax = backticks + ${} [OK]

Hint: Use backticks and ${} for template literal types [OK]

Common Mistakes:

• Using quotes with + for concatenation in types
• Using & or | operators incorrectly
• Not using backticks for template literals

3. Given the type definition type ID = `user_${number}`;, which of the following assignments will cause a TypeScript error?

medium

A. const a: ID = 'user_123';

B. const d: ID = 'user_0';

C. const b: ID = 'user_abc';

D. const c: ID = `user_${456}`;

Solution

1. Step 1: Understand the pattern

   The type ID requires strings starting with 'user_' followed by a number.

2. Step 2: Check each assignment

   A is 'user_123' (valid number), B is 'user_0' (valid number), C uses template literal with number 456 (valid), D is 'user_abc' (letters, invalid).

3. Final Answer:

   const b: ID = 'user_abc'; causes error -> Option C

4. Quick Check:

   Pattern requires number after 'user_' = D error [OK]

Hint: Check if string part after prefix matches number type [OK]

Common Mistakes:

• Assuming any string after prefix is valid
• Confusing template literal with runtime string
• Ignoring number type constraint

4. Identify the error in this TypeScript code snippet:

type Email = `${string}@${string}.com`;
const myEmail: Email = 'john.doe@gmail';

medium

A. The variable myEmail should be a number, not a string.

B. The type Email does not allow missing '.com' suffix.

C. The template literal syntax is incorrect.

D. The '@' symbol is not allowed in template literal types.

Solution

1. Step 1: Analyze the type Email pattern

   Email requires a string, then '@', then another string, then '.com' exactly.

2. Step 2: Check the assigned value

   myEmail is 'john.doe@gmail' missing the '.com' suffix, so it does not match the pattern.

3. Final Answer:

   The type Email does not allow missing '.com' suffix. -> Option B

4. Quick Check:

   Pattern requires '.com' suffix = missing causes error [OK]

Hint: Match full pattern including suffix exactly [OK]

Common Mistakes:

• Ignoring required suffix in pattern
• Thinking '@' is invalid in template literals
• Confusing type errors with runtime errors

5. You want to create a type-safe pattern for a version string like v1.2.3 where each number can be one or more digits. Which of these TypeScript types correctly enforces this pattern?

hard

A. type Version = `v${number}.${number}.${number}`;

B. type Version = `v${string}.${string}.${string}`;

C. type Version = `v${number}.${string}.${number}`;

D. type Version = `v${number}.${number}`;

Solution

1. Step 1: Understand the version pattern

   The version string starts with 'v' followed by three numbers separated by dots.

2. Step 2: Evaluate each type

   A uses number for all three parts, matching the pattern exactly. B uses string, allowing invalid formats. C mixes number and string incorrectly. D misses the third number part.

3. Final Answer:

   type Version = `v${number}.${number}.${number}`; -> Option A

4. Quick Check:

   All parts as number with dots = type Version = `v${number}.${number}.${number}`; [OK]

Hint: Use ${number} for numeric parts in template literals [OK]

Common Mistakes:

• Using string instead of number for numeric parts
• Missing parts of the pattern
• Mixing types inconsistently