How Strings Work Differently Across Languages in DSA Typescript - Why This Approach

The Big Idea

Why does changing a letter in a word work in one language but fail silently in another?

The Scenario

Imagine you want to store and change a word in your program. In some languages, you can easily change letters inside the word, but in others, you cannot. This difference can confuse you when switching between languages.

The Problem

If you try to change a letter in a word directly in a language where words are fixed (immutable), your program will give errors or behave unexpectedly. Doing this manually means copying the whole word every time you want to change one letter, which is slow and messy.

The Solution

Understanding how strings behave in each language helps you write better code. You learn when you need to create new words to change letters and when you can change letters directly. This knowledge saves time and prevents bugs.

Before vs After

✗ Before

let word = "hello";
word[0] = 'H'; // No effect in JavaScript/TypeScript

✓ After

let word = "hello";
word = 'H' + word.slice(1); // Works by creating a new string

What It Enables

Knowing string behavior lets you handle text efficiently and avoid hidden bugs when switching languages.

Real Life Example

When building a chat app, you might want to update a message's text. If you don't know how strings work, your app might crash or show wrong messages.

Key Takeaways

Strings can be fixed (immutable) or changeable (mutable) depending on the language.

Trying to change strings directly in immutable languages causes errors or no effect.

Knowing this helps you write safer and faster text-handling code.

Practice

1. In TypeScript, what is the type of a string when you use single quotes like 'hello' compared to double quotes like "hello"?

easy

A. Both are of type string and behave the same

B. Single quotes create a character, double quotes create a string

C. Single quotes create a string, double quotes create a character

D. Single quotes are invalid syntax in TypeScript

Solution

1. Step 1: Understand string literals in TypeScript

   TypeScript treats both single and double quotes as string delimiters, so both create string values.

2. Step 2: Confirm no character type in TypeScript

   Unlike some languages, TypeScript does not have a separate character type; single quotes do not create characters.

3. Final Answer:

   Both are of type string and behave the same -> Option A

4. Quick Check:

   Single and double quotes create strings = A [OK]

Hint: Single and double quotes both create strings in TypeScript [OK]

Common Mistakes:

• Thinking single quotes create characters
• Confusing TypeScript with languages like C
• Assuming single quotes are invalid

2. Which of the following is the correct way to declare a multi-line string in TypeScript?

easy

A. Using double quotes with + operator: const s = "line1" + "line2";

B. Using single quotes with \n: const s = 'line1\nline2';

C. Using backticks: const s = `line1\nline2`;

D. Using triple quotes: const s = '''line1\nline2''';

Solution

1. Step 1: Identify multi-line string syntax in TypeScript

   TypeScript supports template literals using backticks (`) which allow multi-line strings directly.

2. Step 2: Check other options for correctness

   Single and double quotes require explicit \n for new lines; triple quotes are invalid in TypeScript.

3. Final Answer:

   Using backticks: const s = `line1\nline2`; -> Option C

4. Quick Check:

   Backticks allow multi-line strings = A [OK]

Hint: Use backticks for multi-line strings in TypeScript [OK]

Common Mistakes:

• Using triple quotes like Python
• Expecting single or double quotes to support multi-line directly
• Forgetting to escape newlines in single/double quotes

3. What will be the output of the following TypeScript code?

const s = `Hello\nWorld`;
console.log(s.length);

medium

A. Error

B. 12

C. 10

D. 11

Solution

1. Step 1: Understand the string content

   The string is a template literal with an actual newline character between Hello and World, not the two-character escape sequence.

2. Step 2: Count characters including the newline

   Characters: H(1) e(2) l(3) l(4) o(5) \n is a single newline character (counts as 1), W(6) o(7) r(8) l(9) d(10). So length is 11.

3. Final Answer:

   11 -> Option D

4. Quick Check:

   Template literals interpret \n as newline character = A [OK]

Hint: Template literals interpret \n as a single newline character [OK]

Common Mistakes:

• Assuming \n is two characters in length
• Counting only visible characters
• Expecting runtime error due to escape

4. Identify the error in this TypeScript code snippet:

const greeting = 'Hello;
console.log(greeting);

medium

A. Missing closing single quote for the string

B. Incorrect use of backticks instead of single quotes

C. Missing semicolon after console.log statement

D. No error, code runs fine

Solution

1. Step 1: Check string syntax

   The string starts with a single quote but does not have a closing single quote before the newline.

2. Step 2: Understand string literal rules

   Single-quoted strings cannot span multiple lines without escape; missing closing quote causes syntax error.

3. Final Answer:

   Missing closing single quote for the string -> Option A

4. Quick Check:

   Unclosed string literal = D [OK]

Hint: Strings must be closed before newline unless using backticks [OK]

Common Mistakes:

• Thinking backticks are required here
• Ignoring missing quote errors
• Assuming semicolon omission causes error

5. Given the following TypeScript code, what will be the output?

const s1 = 'café';
const s2 = 'cafe\u0301';
console.log(s1 === s2);

Note: \u0301 is a Unicode combining acute accent.

hard

A. true

B. false

C. SyntaxError

D. RuntimeError

Solution

1. Step 1: Understand Unicode normalization in strings

   s1 uses a single character 'é' (U+00E9), while s2 uses 'e' plus combining accent (U+0301).

2. Step 2: Compare strings with different Unicode forms

   Direct equality compares code units; different Unicode sequences mean s1 !== s2.

3. Final Answer:

   false -> Option B

4. Quick Check:

   Unicode composed vs decomposed forms differ = C [OK]

Hint: Unicode composed and decomposed strings are not equal by default [OK]

Common Mistakes:

• Assuming visually same means equal
• Ignoring Unicode combining characters
• Expecting automatic normalization in equality