Readonly class properties in Typescript - Step-by-Step Execution

Concept Flow - Readonly class properties

Define class with readonly property

↓

Create instance of class

↓

Try to modify readonly property

↓

Error: Cannot assign

↓

End

This flow shows defining a class with a readonly property, creating an instance, and what happens when you try to change that property.

Execution Sample

Typescript

class Person {
  readonly name: string;
  constructor(name: string) {
    this.name = name;
  }
}

const p = new Person("Alice");
p.name = "Bob"; // Error

Defines a class with a readonly property 'name', creates an instance, then tries to change the readonly property which causes an error.

Execution Table

Step	Action	Evaluation	Result
1	Define class Person with readonly property 'name'	Class created	Class Person ready
2	Create instance p with name 'Alice'	Constructor sets this.name = 'Alice'	p.name = 'Alice'
3	Try to assign p.name = 'Bob'	Readonly property assignment	Error: Cannot assign to 'name' because it is a readonly property

💡 Execution stops at step 3 due to readonly property assignment error

Variable Tracker

Variable	Start	After Step 2	After Step 3
p.name	undefined	"Alice"	Error on assignment, value remains "Alice"

Key Moments - 2 Insights

Why can't we change the value of a readonly property after the object is created?

Because the property is marked as readonly, TypeScript prevents any assignment after initialization, as shown in execution_table step 3 where an error occurs.

Can we set the readonly property inside the constructor?

Yes, readonly properties can be assigned once inside the constructor, which is why in step 2 the assignment to 'Alice' works without error.

Visual Quiz - 3 Questions

Look at the execution table, what is the value of p.name after step 2?

A "Alice"

B "Bob"

C undefined

D Error

💡 Hint

Check the 'Result' column in step 2 of the execution_table.

At which step does the readonly property assignment cause an error?

A Step 1

B Step 3

C Step 2

D No error occurs

💡 Hint

Look at the 'Evaluation' and 'Result' columns in the execution_table.

If the property was not marked readonly, what would happen at step 3?

A The program would crash

B Error still occurs

C p.name would change to "Bob"

D The constructor would fail

💡 Hint

Consider how normal property assignment works without readonly, see variable_tracker for p.name changes.

Concept Snapshot

Readonly class properties in TypeScript
- Use 'readonly' keyword before property name
- Property can be assigned once inside constructor
- Any assignment after construction causes error
- Helps prevent accidental changes to important data

Full Transcript

This example shows how to use readonly properties in TypeScript classes. First, a class Person is defined with a readonly property called name. When we create an instance of Person with the name 'Alice', the constructor sets the property successfully. However, if we try to change the name property later, TypeScript gives an error because the property is readonly. This prevents accidental changes to important data after the object is created.

Practice

1. What does the readonly keyword do when used on a class property in TypeScript?

easy

A. It allows the property to be changed anytime.

B. It makes the property private and inaccessible outside the class.

C. It prevents the property from being changed after initialization.

D. It deletes the property after the constructor runs.

Solution

1. Step 1: Understand the purpose of readonly

   The readonly keyword marks a property so it cannot be changed after it is set initially.

2. Step 2: Check when assignment is allowed

   Assignment to a readonly property is only allowed during declaration or inside the constructor.

3. Final Answer:

   It prevents the property from being changed after initialization. -> Option C

4. Quick Check:

   Readonly means fixed value after set [OK]

Hint: Readonly means value can't change after constructor [OK]

Common Mistakes:

• Thinking readonly makes property private
• Assuming readonly allows changes anytime
• Confusing readonly with deleting properties

2. Which of the following is the correct way to declare a readonly property id of type number in a TypeScript class?

easy

A. id: readonly number;

B. readonly id: number;

C. let readonly id: number;

D. const id: number;

Solution

1. Step 1: Recall TypeScript readonly syntax

   The correct syntax places readonly before the property name and type.

2. Step 2: Check each option

   readonly id: number; matches the correct syntax: readonly id: number;. Others misuse keywords or order.

3. Final Answer:

   readonly id: number; -> Option B

4. Quick Check:

   Readonly keyword before property name [OK]

Hint: Put readonly before property name, not after type [OK]

Common Mistakes:

• Using const inside class properties
• Placing readonly after the type
• Combining let with readonly incorrectly

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

class User {
  readonly name: string;
  constructor(name: string) {
    this.name = name;
  }
  changeName(newName: string) {
    // @ts-ignore
    this.name = newName;
  }
}
const user = new User('Alice');
user.changeName('Bob');
console.log(user.name);

medium

A. Alice

B. undefined

C. Compilation error

D. Bob

Solution

1. Step 1: Understand readonly assignment rules

   The name property is readonly and assigned in the constructor, so initial value is 'Alice'. TypeScript enforces this at compile-time.

2. Step 2: Analyze the changeName method

   The @ts-ignore suppresses the TypeScript compile error for assigning to readonly. The code compiles to plain JavaScript, where objects are mutable, so this.name = newName; sets it to 'Bob' at runtime.

3. Final Answer:

   Bob -> Option D

4. Quick Check:

   Readonly is compile-time only; runtime allows changes [OK]

Hint: Readonly bypassed at runtime via @ts-ignore [OK]

Common Mistakes:

• Thinking readonly prevents runtime changes
• Expecting compilation error despite @ts-ignore
• Believing output remains 'Alice'

4. Identify the error in this TypeScript class:

class Product {
  readonly price: number;
  constructor() {
    // No assignment to price here
  }
}
const p = new Product();
p.price = 100;

medium

A. Error: readonly property 'price' is not initialized.

B. Error: Cannot assign to 'price' outside constructor.

C. No error, code runs fine.

D. Error: price must be declared as private.

Solution

1. Step 1: Check readonly property initialization

   The readonly property price must be assigned during declaration or in the constructor.

2. Step 2: Analyze constructor and assignment

   The constructor does not assign price, so TypeScript reports an error about missing initialization.

3. Final Answer:

   Error: readonly property 'price' is not initialized. -> Option A

4. Quick Check:

   Readonly props must be initialized at declaration or constructor [OK]

Hint: Always initialize readonly properties in constructor or declaration [OK]

Common Mistakes:

• Trying to assign readonly property after construction
• Ignoring missing initialization error
• Confusing readonly with private

5. Given this class, how can you safely allow updating the version property while keeping id readonly?

class Document {
  readonly id: string;
  version: number;
  constructor(id: string, version: number) {
    this.id = id;
    this.version = version;
  }
}

hard

A. Keep id readonly and update version normally via a method.

B. Make both id and version readonly and update via constructor only.

C. Remove readonly from id to allow all updates.

D. Make version readonly and update id instead.

Solution

1. Step 1: Understand readonly usage

   The id should remain readonly to keep it fixed after creation.

2. Step 2: Allow version updates

   The version property is not readonly, so it can be updated safely anytime, for example via a method.

3. Final Answer:

   Keep id readonly and update version normally via a method. -> Option A

4. Quick Check:

   Readonly for fixed, normal for changeable [OK]

Hint: Readonly for fixed props, normal for changeable ones [OK]

Common Mistakes:

• Making all properties readonly and losing flexibility
• Removing readonly from fixed properties
• Confusing which property should be updated