Building type-safe string patterns in Typescript - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

Output of a template literal type with union

What is the type of Greeting and what will message contain after assignment?

Typescript

type Name = "Alice" | "Bob";
type Greeting = `Hello, ${Name}!`;

const message: Greeting = "Hello, Alice!";

console.log(message);

A "Hello, Charlie!"

B "Hello, Alice!"

C Type error at assignment

D "Hello, Bob!"

💡 Hint

Check which strings are allowed by the template literal type.

The type Greeting allows only strings formed by 'Hello, ' plus either 'Alice' or 'Bob' plus '!'. So 'Hello, Alice!' is valid and prints as is.

🧠 Conceptual

intermediate

Understanding type-safe string pattern constraints

Which of the following TypeScript types correctly restricts a string to only the patterns 'user-123' or 'admin-456'?

A type ID = 'user-123' | 'admin-456';

B type ID = string & (`user-123` | `admin-456`);

C type ID = `user-${number}` | `admin-${number}`;

D type ID = `${string}-${number}`;

💡 Hint

Think about exact string matches versus patterns.

Option A restricts the type to exactly 'user-123' or 'admin-456'. Option A allows any number after 'user-' or 'admin-'. Option A is invalid syntax. Option A allows any string-number pattern.

🔧 Debug

advanced

Identify the error in this type-safe string pattern

What error does this TypeScript code produce?

Typescript

type Event = `on${Capitalize<string>}`;

const clickEvent: Event = "onclick";

A Syntax error: Invalid template literal type

B Runtime error: Cannot capitalize string

C No error, code compiles fine

D Type error: 'onclick' is not assignable to type 'Event'

💡 Hint

Check what Capitalize means in a template literal type.

Capitalize expects a literal string type, but 'string' is a general type, so the template literal type is too broad. The value 'onclick' does not match 'on' + capitalized string, so assignment fails.

📝 Syntax

advanced

Which option correctly defines a type-safe pattern for hex colors?

Choose the option that correctly defines a TypeScript type for strings matching a hex color code like '#A1B2C3'.

A type HexColor = `#${string}`;

B type HexColor = `#${string & { length: 6 }}`;

C type HexColor = `#${Uppercase<string>}${Uppercase<string>}${Uppercase<string>}${Uppercase<string>}${Uppercase<string>}${Uppercase<string>}`;

D type HexColor = `#${string & { length: 6, pattern: /^[0-9A-F]{6}$/ }}`;

💡 Hint

TypeScript template literal types cannot enforce length or regex patterns directly.

Option A is valid syntax and allows any string after '#'. Options B and D use invalid syntax for length or pattern constraints. Option A is invalid because Uppercase cannot be repeated like that in a template literal type.

🚀 Application

expert

Determine the number of valid strings for this type-safe pattern

Given the type type Code = `${'A' | 'B'}${1 | 2 | 3}`;, how many unique strings are assignable to Code?

A 5

B 3

C 6

D 9

💡 Hint

Multiply the number of options in each union to find total combinations.

There are 2 options for the first character ('A' or 'B') and 3 options for the second (1, 2, or 3). Total combinations = 2 * 3 = 6.

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