TypeScript 9 🔷 Object Types and Optional Properties - KandZ

Object types are how TypeScript describes structured data — records, entities, configuration, API responses, component props. Almost every non-trivial type in a real codebase is an object type, and almost every object type has at least one field that might be missing. That’s where optional properties come in: the ? modifier, the interaction with undefined, the difference between “missing” and “present but undefined,” and how all of that flows through assignment, reading, and narrowing. Getting object types right — especially optional fields — is the difference between types that catch bugs and types that quietly allow them.

Key point: An object type is a shape — a set of property names and their types. It’s structural, not nominal: any value with the right shape matches. Optional properties (name?: string) mean the property may be absent, and TypeScript tracks that fact through every read and write. The distinction between name?: string and name: string | undefined matters more than it looks.

Object type syntax

An object type lists properties and their types.

type User = {
  id: number;
  name: string;
  email: string;
};

Same with an interface:

interface User {
  id: number;
  name: string;
  email: string;
}

Both describe the same shape. Use interface for object shapes by convention (see Chapter 7), type when you need a union or a more complex alias.

Property separators: Commas, semicolons, or newlines all work. Semicolons are the TypeScript convention.

type A = { id: number; name: string; };   // semicolons
type B = { id: number, name: string };    // commas
type C = {                                // newlines
  id: number;
  name: string;
};

Types of properties can be anything — primitives, other object types, unions, functions, arrays.

interface Product {
  id: string;
  name: string;
  price: number;
  tags: string[];
  metadata: { created: Date; updated: Date };
  getDisplayName: () => string;
}

Nesting: Object types nest freely. Each level is its own shape.

interface Order {
  id: string;
  customer: {
    id: string;
    name: string;
    address: {
      street: string;
      city: string;
      zip: string;
    };
  };
  items: Array<{
    sku: string;
    quantity: number;
  }>;
}

That’s a five-level shape. TypeScript checks every level, every property, every call site.

Why structural typing matters here: A User isn’t a class instance. It’s any value with id: number, name: string, and email: string. That means object literals, JSON-parsed data (with validation), and instances of other classes all qualify if their shapes match. TypeScript follows JavaScript’s model — shapes, not names.

Optional properties — `?`

A property marked with ? may be absent from the object.

interface User {
  id: number;
  name: string;
  nickname?: string;              // may be missing
}

const alice: User = { id: 1, name: 'Alice' };                  // ✅
const bob: User = { id: 2, name: 'Bob', nickname: 'Bobby' };   // ✅

Both are valid User values. nickname is optional.

The type of an optional property when read:

alice.nickname;                   // string | undefined

Reading nickname gives string | undefined — because it may be absent, and if absent it’s undefined. TypeScript adds undefined to the property’s type automatically.

You must handle the undefined case:

alice.nickname.length;            // ❌ possibly undefined
alice.nickname?.length;           // ✅
alice.nickname ?? 'Anonymous';    // ✅

Writing an optional property:

alice.nickname = 'Al';            // ✅
alice.nickname = undefined;       // ✅ — explicit
delete alice.nickname;            // ✅ — removes the property

All three are allowed. undefined and absence are both valid for an optional property.

? only applies to properties, not to the enclosing object: nickname?: string doesn’t make alice itself optional. It just makes the property omittable.

Why ? adds undefined: An optional property can be missing. When you read a missing property in JavaScript, you get undefined. TypeScript models that reality — reading user.nickname gives string | undefined, forcing you to handle the missing case. This is the single most useful thing optional properties do: they make absence explicit in the type.

Optional vs `| undefined`

name?: string and name: string | undefined look similar but mean different things.

interface A {
  name?: string;                  // optional — may be absent
}

interface B {
  name: string | undefined;       // required — may be undefined
}

Assignment:

const a1: A = {};                                    // ✅
const a2: A = { name: 'Alice' };                     // ✅
const a3: A = { name: undefined };                   // ✅

const b1: B = {};                                    // ❌ missing name
const b2: B = { name: 'Alice' };                     // ✅
const b3: B = { name: undefined };                   // ✅

For A, all three are valid — name may be omitted, present, or explicitly undefined.

For B, name is required. It must be present, but its value may be undefined.

The difference in one sentence: ? means “may be missing”; | undefined means “must be present, may be undefined.”

Which to use:

Goal	Syntax
Property may be omitted entirely	`name?: T`
Property always present, may be `undefined`	`name: T \| undefined`
Property may be omitted OR explicit `null`	`name?: T \| null`
Property always present, may be `null`	`name: T \| null`

When the difference matters: Consider a PATCH API payload.

interface UserPatch {
  name?: string;
  email?: string;
}

If the client doesn’t send name, the server treats it as “don’t change the name.” That’s different from sending name: undefined, which might mean “set the name to undefined.” The type system can express the difference — pick the form that matches the semantics.

exactOptionalPropertyTypes — the strict option:

Under this compiler flag, name?: string forbids name: undefined explicitly.

// With exactOptionalPropertyTypes: true
const a: A = { name: undefined };   // ❌
const a: A = {};                    // ✅

The strictest reading: an optional property is either present with a T value or absent — never present with undefined. This catches bugs where code accidentally sets an optional field to undefined instead of omitting it. It’s off by default; enable it if your team wants that precision.

Why the distinction is real: In JavaScript, { name: undefined } and {} differ in 'name' in obj. Some libraries and APIs care. TypeScript’s default treats them the same for optional properties, but exactOptionalPropertyTypes makes the type system track the difference. Use it when it matters.

Readonly properties

A property marked readonly can’t be reassigned after creation.

interface User {
  readonly id: number;
  name: string;
}

const alice: User = { id: 1, name: 'Alice' };
alice.name = 'Alicia';            // ✅
alice.id = 2;                     // ❌ readonly

readonly is compile-time only — the property is still mutable at runtime. It documents intent and catches accidental writes.

Readonly is shallow:

interface Config {
  readonly server: {
    host: string;
    port: number;
  };
}

const cfg: Config = { server: { host: 'localhost', port: 8080 } };
cfg.server = { host: 'x', port: 1 };  // ❌ readonly
cfg.server.host = 'x';                // ✅ inner object isn't readonly

Only the top-level property is protected. For deep immutability, you need recursive readonly types or as const.

Readonly arrays and tuples:

interface Data {
  readonly items: readonly string[];
}

const d: Data = { items: ['a', 'b'] };
d.items.push('c');                // ❌
d.items = ['x'];                  // ❌

readonly T[] prevents mutation of the array contents; readonly before the property name prevents reassignment of the property itself.

Readonly in classes:

class User {
  readonly id: number;

  constructor(id: number) {
    this.id = id;                 // ✅ assignment in constructor allowed
  }

  changeId() {
    // this.id = 2;               // ❌ after construction
  }
}

readonly on class properties allows assignment in the constructor only.

Why readonly is useful: It documents which fields should never change and prevents accidental writes. For domain objects like IDs and creation timestamps, this catches real bugs. It’s also enforced through parameter types: a function accepting readonly User[] can read but not mutate the elements.

Object type modifiers summary

Modifier	Syntax	Effect
Optional	`name?: T`	May be absent
Readonly	`readonly name: T`	Can’t be reassigned
Index signature	`[key: string]: T`	Dynamic keys
Method	`fn(): T`	Call signature as property
Function property	`fn: (x: T) => U`	Function-typed property

Methods vs function properties:

interface A {
  greet(): string;                // method
}

interface B {
  greet: () => string;            // function property
}

They’re structurally compatible but subtly different. Method syntax has this typing and supports declaration merging better; function property syntax is more precise about mutability. For most cases they’re interchangeable.

Index signatures:

interface Dict {
  [key: string]: number;
}

Allows any string key with a number value. Useful for maps and JSON-like data. See Chapter 5 for indexed access.

Why these modifiers matter: They turn a bare object type into a precise contract. readonly id: number says “never change this.” nickname?: string says “may be missing.” [key: string]: number says “any key, number values.” Each modifier is a small constraint that adds up to types that catch real mistakes.

Object literals — excess property checks

TypeScript checks object literals for excess properties — extra keys that aren’t in the target type.

interface User {
  id: number;
  name: string;
}

const a: User = { id: 1, name: 'Alice', age: 30 };   // ❌ excess property 'age'

The object literal has age, which isn’t on User. TypeScript rejects it.

But it only applies to object literals — direct assignments. Through a variable, excess properties are allowed:

const obj = { id: 1, name: 'Alice', age: 30 };
const b: User = obj;              // ✅ — obj has at least User's shape

This is the structural typing rule: as long as a value has the required properties, extras are fine. Excess property checks are a special case for object literals to catch typos.

Where excess checks help:

interface Config {
  apiUrl: string;
  timeout: number;
}

const bad: Config = {
  apiUrl: 'https://x',
  timeout: 5000,
  tmieout: 10000              // ❌ typo — caught by excess check
};

Without excess checks, tmieout would be silently allowed as an extra property, and the typo would never be caught.

Working around excess checks:

// Option 1: variable
const cfg = { apiUrl: 'x', timeout: 5, extra: true };
const good: Config = cfg;         // ✅

// Option 2: spread
const good2: Config = { apiUrl: 'x', timeout: 5, ...({ extra: true }) };  // ✅

// Option 3: add an index signature
interface Config {
  apiUrl: string;
  timeout: number;
  [key: string]: unknown;         // allow extras
}

Use these deliberately — excess checks catch typos, and working around them should be a conscious choice.

Why excess checks exist but only for literals: Object literals are usually written inline for a specific target type. If you typed tmieout and meant timeout, the typo is right there. Variables may carry extra properties for other reasons, so the check is relaxed. The rule catches the common case without being overly strict.

Reading and narrowing optional properties

Optional properties require narrowing before use.

interface User {
  id: number;
  nickname?: string;
}

function greet(u: User): string {
  if (u.nickname) {
    return `Hello, ${u.nickname}`;    // u.nickname is string here
  }
  return `Hello, user #${u.id}`;
}

Truthiness narrowing removes undefined and also the empty string. If empty-string nicknames are valid, use !== undefined instead:

if (u.nickname !== undefined) {
  return `Hello, ${u.nickname}`;      // string, but '' is allowed
}

Checking for property presence:

if ('nickname' in u) {
  // u.nickname is string | undefined
  // the property exists, but might be undefined
}

in narrows to “the property exists” but not “the value isn’t undefined.” Under default TypeScript settings, 'nickname' in u gives u.nickname: string in the if branch — because for optional properties, “exists” and “not undefined” are usually the same. Under exactOptionalPropertyTypes, in doesn’t remove undefined.

?. and ?? are the standard tools:

const display = u.nickname ?? u.name;
const length = u.nickname?.length;

Optional chaining short-circuits on undefined and null. Nullish coalescing provides a fallback only when the value is undefined or null — not for '' or 0.

Destructuring with defaults:

const { nickname = 'Anonymous' } = u;
// nickname: string

The default removes undefined from the destructured variable’s type.

Why narrowing is essential for optional: Without narrowing, every optional field access would either fail to compile or require ?. everywhere. Narrowing — via if, ?., or defaults — lets you tell TypeScript “I know this is present” and then use it directly. That’s the ergonomic payoff of tracking nullability.

Object types in practice

Function parameters:

function sendEmail(message: {
  to: string;
  subject: string;
  body: string;
}): void {
  // ...
}

Inline object types in parameters work but become unwieldy. Extract them:

interface Email {
  to: string;
  subject: string;
  body: string;
}

function sendEmail(message: Email): void { }

Return values:

function makeUser(name: string): { id: string; name: string } {
  return { id: crypto.randomUUID(), name };
}

Extracting is cleaner:

interface User {
  id: string;
  name: string;
}

function makeUser(name: string): User { }

Partial objects: Use Partial<T> (from Chapter 2’s utility types, covered later in depth) to make all properties optional.

interface User {
  id: number;
  name: string;
  email: string;
}

type UserUpdate = Partial<User>;
// { id?: number; name?: string; email?: string }

Required objects: Use Required<T> to make all properties required.

type Config = Required<{
  apiUrl?: string;
  timeout?: number;
}>;
// { apiUrl: string; timeout: number }

Pick and Omit: Select subsets of properties.

type UserSummary = Pick<User, 'id' | 'name'>;
type UserWithoutId = Omit<User, 'id'>;

These utility types are covered in depth in later chapters.

Why extracting object types matters: Inline object types in parameters become unreadable after two properties. Named types are shorter to use and easier to update. When you change Email, every function that accepts it is checked automatically. That’s the whole point of named types — one place to change, everywhere checked.

A full example

A config system with optional, readonly, and index-signature properties.

interface ServerConfig {
  readonly host: string;
  readonly port: number;
  readonly ssl?: boolean;              // optional
  readonly timeout?: number;           // optional
}

interface AppConfig {
  readonly name: string;
  readonly version: string;
  readonly server: ServerConfig;
  readonly features: readonly string[];
  readonly metadata?: Record<string, string>;  // optional map
}

function createServer(config: ServerConfig): string {
  const { host, port, ssl = false, timeout = 30_000 } = config;
  const protocol = ssl ? 'https' : 'http';
  return `${protocol}://${host}:${port} (timeout: ${timeout}ms)`;
}

function hasFeature(config: AppConfig, feature: string): boolean {
  return config.features.includes(feature);
}

const config: AppConfig = {
  name: 'my-app',
  version: '1.0.0',
  server: {
    host: 'localhost',
    port: 8080
  },
  features: ['auth', 'logging']
};

console.log(createServer(config.server));
console.log(hasFeature(config, 'auth'));
console.log(hasFeature(config, 'metrics'));

// Readonly enforcement
// config.name = 'other';            // ❌
// config.server.host = 'x';         // ❌
// config.features.push('y');        // ❌

Every optional field (ssl, timeout, metadata) is safely omitted. Every readonly field is protected. Destructuring with defaults handles the optional values cleanly.

Why this shape: It models a real configuration file — required and optional keys, nested objects, read-only settings, and a list of feature flags. The type system prevents accidental mutation and requires you to handle optional fields correctly. That’s how object types pay off in production.

Complete Example Session

# ============================================
# PART 1: BASIC OBJECT TYPES
# ============================================

cat > objects.ts << 'EOF'
interface User {
  id: number;
  name: string;
  email: string;
}

const alice: User = {
  id: 1,
  name: 'Alice',
  email: 'alice@example.com'
};

console.log(alice);
EOF

npx tsc --noEmit objects.ts
# (no errors)

# ============================================
# PART 2: OPTIONAL PROPERTIES
# ============================================

cat > optional.ts << 'EOF'
interface User {
  id: number;
  name: string;
  nickname?: string;
}

const a: User = { id: 1, name: 'Alice' };
const b: User = { id: 2, name: 'Bob', nickname: 'Bobby' };

function display(u: User): string {
  return u.nickname ?? u.name;
}

console.log(display(a));
console.log(display(b));
EOF

npx tsc --noEmit optional.ts
# (no errors)

# ============================================
# PART 3: OPTIONAL VS | undefined
# ============================================

cat > distinction.ts << 'EOF'
interface A {
  name?: string;                  // may be absent
}

interface B {
  name: string | undefined;       // required, may be undefined
}

const a1: A = {};                 // ✅
const a2: A = { name: undefined }; // ✅

const b1: B = { name: undefined }; // ✅
// const b2: B = {};              // ❌ missing name

console.log(a1, a2, b1);
EOF

npx tsc --noEmit distinction.ts
# (no errors)

# ============================================
# PART 4: READONLY
# ============================================

cat > readonly.ts << 'EOF'
interface User {
  readonly id: number;
  name: string;
}

const u: User = { id: 1, name: 'Alice' };
u.name = 'Alicia';                // ✅
// u.id = 2;                      // ❌ readonly

interface Config {
  readonly features: readonly string[];
}

const c: Config = { features: ['a', 'b'] };
// c.features.push('x');          // ❌
// c.features = ['y'];            // ❌

console.log(u, c);
EOF

npx tsc --noEmit readonly.ts
# (no errors)

# ============================================
# PART 5: EXCESS PROPERTY CHECKS
# ============================================

cat > excess.ts << 'EOF'
interface User {
  id: number;
  name: string;
}

// ❌ excess property
// const a: User = { id: 1, name: 'Alice', age: 30 };

// ✅ via variable
const obj = { id: 1, name: 'Alice', age: 30 };
const b: User = obj;

console.log(b);
EOF

npx tsc --noEmit excess.ts
# (no errors)

# ============================================
# PART 6: FULL EXAMPLE
# ============================================

cat > config.ts << 'EOF'
interface ServerConfig {
  readonly host: string;
  readonly port: number;
  readonly ssl?: boolean;
  readonly timeout?: number;
}

interface AppConfig {
  readonly name: string;
  readonly version: string;
  readonly server: ServerConfig;
  readonly features: readonly string[];
}

function createServer(config: ServerConfig): string {
  const { host, port, ssl = false, timeout = 30_000 } = config;
  return `${ssl ? 'https' : 'http'}://${host}:${port} (${timeout}ms)`;
}

const cfg: AppConfig = {
  name: 'my-app',
  version: '1.0.0',
  server: { host: 'localhost', port: 8080 },
  features: ['auth']
};

console.log(createServer(cfg.server));
console.log(cfg.features.includes('auth'));
EOF

npx tsc --noEmit config.ts
# (no errors)

# ============================================
# PART 7: COMPILE AND RUN
# ============================================

npx tsc objects.ts optional.ts distinction.ts readonly.ts excess.ts config.ts
node objects.js
# [ { id: 1, name: 'Alice', email: 'alice@example.com' } ]

node optional.js
# [ Alice ]
# [ Bobby ]

node readonly.js
# [ { id: 1, name: 'Alicia' } { features: [ 'a', 'b' ] } ]

node config.js
# [ http://localhost:8080 (30000ms) ]
# [ true ]

Quick Reference

Object Type Syntax

Form	Meaning
`{ a: T; b: U }`	Object with a and b
`interface X { a: T }`	Named shape
`type X = { a: T }`	Alias
`{ a?: T }`	Optional property
`{ readonly a: T }`	Readonly property
`{ [k: string]: T }`	Index signature
`{ fn(): T }`	Method
`{ fn: () => T }`	Function property

Property Modifiers

Modifier	Syntax	Effect
Optional	`a?: T`	May be absent
Readonly	`readonly a: T`	Can’t be assigned
Both	`readonly a?: T`	Optional and readonly

Optional vs `| undefined`

Form	Required	Accepts `undefined`	Can omit
`a?: T`	❌	✅	✅
`a: T \| undefined`	✅	✅	❌
`a: T`	✅	❌	❌
`a?: T \| null`	❌	✅ + null	✅
`a: T \| null`	✅	✅ + null	❌

Reading Optional Properties

Code	Type
`u.nickname`	`string \| undefined`
`u.nickname?.length`	`number \| undefined`
`u.nickname ?? 'x'`	`string`
`if (u.nickname) { u.nickname }`	`string` (narrowed)
`if (u.nickname !== undefined) { }`	`string` (narrowed)

Readonly Effects

Location	Behavior
Interface property	Can’t reassign
Class property	Assignable only in constructor
`readonly T[]`	Array contents immutable
Parameter `readonly T[]`	Caller’s array can’t be mutated
Deep readonly	Not automatic — use recursive types

Excess Property Checks

Context	Check applies
Object literal assigned to typed variable	✅
Via intermediate variable	❌
Via spread	❌
Via `as` cast	❌
Function argument (literal)	✅

Utility Combinations

Type	Result
`Partial<User>`	All properties optional
`Required<User>`	All properties required
`Readonly<User>`	All properties readonly
`Pick<User, 'id'>`	Only those properties
`Omit<User, 'id'>`	All except those

`exactOptionalPropertyTypes`

Setting	`{ a?: T }` allows `{ a: undefined }`
`false` (default)	✅
`true`	❌ — must be absent

Best Practices

✅ Do This:

// Use interfaces for object shapes
interface User { id: number; name: string; }             // ✅

// Mark optional fields with `?`
interface User { nickname?: string; }                    // ✅

// Use `readonly` for immutable fields
interface User { readonly id: number; }                  // ✅

// Handle optional reads with `?.` or `??`
const n = user.nickname ?? 'Anonymous';                  // ✅

// Use `readonly T[]` for immutable arrays
interface Data { items: readonly string[]; }             // ✅

// Extract inline object types
interface Email { to: string; subject: string; }         // ✅

// Use utility types for transformations
type Update = Partial<User>;                             // ✅

// Destructure with defaults for optional fields
const { nickname = 'Anon' } = user;                      // ✅

❌ Don’t Do This:

// Don't use | undefined when ? is cleaner
interface U { name: string | undefined; }                // ⚠️  required

// Don't access optional fields without narrowing
user.nickname.length;                                    // ❌ possibly undefined

// Don't expect readonly to be deep
interface C { readonly inner: { x: number }; }
c.inner.x = 5;                                            // ✅ — inner isn't readonly

// Don't work around excess checks lightly
const u: User = { id: 1, name: 'A', extra: 2 } as any;   // ⚠️  hides typos

// Don't write huge inline object types
function f(data: { a: string; b: number; c: boolean; d: Date; }): void { }  // ⚠️  extract

// Don't mix `?` and `| undefined` inconsistently
interface A { x?: number; y: number | undefined; }       // ⚠️  pick one convention

// Don't ignore the empty-string case with truthiness
if (user.nickname) { }  // '' skipped                     // ⚠️  use !== undefined

Common Pitfalls

Pitfall	Problem	Solution
`?` vs `\| undefined` confusion	Wrong assignment rules	Know which you need
Accessing optional without narrowing	Compile error	Use `?.` or `if`
Readonly is shallow	Inner objects mutable	Recursive readonly or `as const`
Excess check missed	Typos sneak through	Assign object literals directly
Working around excess checks	Real typos hidden	Only use `as` deliberately
Truthiness skips `''`	Empty string treated as missing	Use `!== undefined`
`?` doesn’t make the object optional	Different concept	`?:` on the property, not the object
`readonly` on arrays	Still pushes	Use `readonly T[]`
Deleting readonly prop	Compile error	Don’t
Object literal excess check	Unexpected error	Assign via variable or spread

Real-World Examples

1. Basic user

interface User {
  id: number;
  name: string;
  email: string;
}

2. Optional field

interface User {
  id: number;
  name: string;
  nickname?: string;
}

3. Readonly ID

interface User {
  readonly id: number;
  name: string;
}

4. Optional and readonly

interface Config {
  readonly apiUrl: string;
  readonly timeout?: number;
}

5. Nested object

interface Order {
  id: string;
  customer: { id: string; name: string };
}

6. Readonly array

interface Data {
  readonly items: readonly string[];
}

7. Optional array

interface Data {
  items?: string[];
}

8. Index signature

interface Dict {
  [key: string]: number;
}

9. Partial

type UserUpdate = Partial<User>;

10. Pick

type UserSummary = Pick<User, 'id' | 'name'>;

11. Omit

type UserWithoutId = Omit<User, 'id'>;

12. Destructure with defaults

const { nickname = 'Anon' } = user;

13. Nullish coalescing

const display = user.nickname ?? user.name;

14. Optional chaining

const city = user.address?.city;

15. Function parameter

function send(msg: { to: string; body: string }): void { }

16. Return object

function makeUser(name: string): User {
  return { id: '1', name, email: 'a@b.c' };
}

17. Excess check

const u: User = { id: 1, name: 'Alice', typo: true };  // ❌

18. Excess check via variable

const obj = { id: 1, name: 'Alice', extra: true };
const u: User = obj;                                    // ✅

19. Method property

interface Calc {
  sum(a: number, b: number): number;
}

20. Function property

interface Calc {
  sum: (a: number, b: number) => number;
}

Visual: Optional Property Behavior

┌──────────────────────────────────────────────┐
│  interface User {                            │
│    id: number;                               │
│    nickname?: string;                        │
│  }                                           │
│                                              │
│  Valid values:                               │
│  { id: 1 }                  ✅               │
│  { id: 1, nickname: 'Al' }  ✅               │
│  { id: 1, nickname: undefined } ✅ (default) │
│                                              │
│  Read type of nickname:                      │
│  string | undefined                          │
│                                              │
└──────────────────────────────────────────────┘

Visual: `?` vs `| undefined`

┌──────────────────────────────────────────────┐
│  a?: T                                       │
│                                              │
│  {}                       ✅                 │
│  { a: value }             ✅                 │
│  { a: undefined }         ✅ (default)       │
│                                              │
│  → May be absent                             │
│                                              │
└──────────────────────────────────────────────┘

┌──────────────────────────────────────────────┐
│  a: T | undefined                            │
│                                              │
│  {}                       ❌ missing         │
│  { a: value }             ✅                 │
│  { a: undefined }         ✅                 │
│                                              │
│  → Must be present, may be undefined         │
│                                              │
└──────────────────────────────────────────────┘

Visual: Readonly Shallow vs Deep

┌──────────────────────────────────────────────┐
│  Shallow — only the top level                │
│                                              │
│  interface C {                               │
│    readonly server: { host: string };        │
│  }                                           │
│                                              │
│  c.server = { host: 'x' };  ❌               │
│  c.server.host = 'x';       ✅               │
│                                              │
└──────────────────────────────────────────────┘

┌──────────────────────────────────────────────┐
│  Deep — with recursive Readonly              │
│                                              │
│  type DeepReadonly<T> = {                    │
│    readonly [K in keyof T]: DeepReadonly<T[K]>;│
│  };                                          │
│                                              │
│  All levels readonly — see mapped types.     │
│                                              │
└──────────────────────────────────────────────┘

Visual: Excess Property Checks

┌──────────────────────────────────────────────┐
│  Direct literal assignment                   │
│                                              │
│  const u: User = {                           │
│    id: 1,                                    │
│    name: 'Alice',                            │
│    age: 30         ← extra                   │
│  };                                          │
│                                              │
│  ❌ Excess property 'age'                     │
│                                              │
└──────────────────────────────────────────────┘

┌──────────────────────────────────────────────┐
│  Via intermediate variable                   │
│                                              │
│  const obj = { id: 1, name: 'Alice', age: 30 };│
│  const u: User = obj;                        │
│                                              │
│  ✅ Allowed — obj has at least User's shape   │
│                                              │
└──────────────────────────────────────────────┘

Visual: Object Type Composition

┌──────────────────────────────────────────────┐
│  interface User {                            │
│    readonly id: number;                      │
│    name: string;                             │
│    email?: string;                           │
│  }                                           │
│                                              │
│  id      → required, readonly                │
│  name    → required, mutable                 │
│  email   → optional, mutable                 │
│                                              │
└──────────────────────────────────────────────┘

┌──────────────────────────────────────────────┐
│  Mapped: Partial<User>                       │
│                                              │
│  {                                           │
│    id?: number;                              │
│    name?: string;                            │
│    email?: string;                           │
│  }                                           │
│                                              │
│  readonly removed, all optional              │
│                                              │
└──────────────────────────────────────────────┘

┌──────────────────────────────────────────────┐
│  Mapped: Readonly<Partial<User>>             │
│                                              │
│  {                                           │
│    readonly id?: number;                     │
│    readonly name?: string;                   │
│    readonly email?: string;                  │
│  }                                           │
│                                              │
└──────────────────────────────────────────────┘

Visual: Narrowing Optional

┌──────────────────────────────────────────────┐
│  u.nickname                                  │
│  type: string | undefined                    │
│                                              │
│  u.nickname?.length                          │
│  type: number | undefined                    │
│                                              │
│  u.nickname ?? 'Anonymous'                   │
│  type: string                                │
│                                              │
│  if (u.nickname) {                           │
│    // u.nickname is string                   │
│  }                                           │
│                                              │
│  if (u.nickname !== undefined) {             │
│    // string, including ''                   │
│  }                                           │
│                                              │
└──────────────────────────────────────────────┘

Visual: Method vs Function Property

┌──────────────────────────────────────────────┐
│  Method syntax                               │
│                                              │
│  interface A {                               │
│    greet(): string;                          │
│  }                                           │
│                                              │
│  • this typed via interface                  │
│  • supports overloads                        │
│  • bivariant parameter check (looser)        │
│                                              │
└──────────────────────────────────────────────┘

┌──────────────────────────────────────────────┐
│  Function property syntax                    │
│                                              │
│  interface B {                               │
│    greet: () => string;                      │
│  }                                           │
│                                              │
│  • no special this                            │
│  • stricter contravariance                   │
│  • more precise for objects                  │
│                                              │
└──────────────────────────────────────────────┘

Summary

Concept	Meaning
Object type	Shape of properties and their types
`?`	Property may be absent
`readonly`	Property can’t be reassigned
`\| undefined`	Property required, may be `undefined`
Index signature	Any key with a given value type
Method syntax	`fn(): T`
Function property	`fn: () => T`
Excess property check	Reject extra keys in object literals
Utility types	`Partial`, `Required`, `Readonly`, `Pick`, `Omit`

Key takeaways:

Object types describe shapes — TypeScript checks structure, not names
Object types nest freely — every level is checked
? makes a property optional — may be absent or undefined
| undefined makes the property required but its value may be undefined
These two differ in what they allow at the call site — know which you need
readonly prevents reassignment — and is shallow, not deep
readonly T[] prevents array mutation — use for immutability
Excess property checks reject extra keys in object literals, but not through variables
Narrowing is required to use optional properties — ?., ??, if, or destructuring with defaults
exactOptionalPropertyTypes makes optional properties forbid explicit undefined
Utility types (Partial, Required, Readonly, Pick, Omit) transform object shapes — covered in depth later
Extract inline object types into named interfaces — better errors, easier updates

Remember: Object types are the workhorse of TypeScript. Almost every type you write describes an object shape — a User, an Order, a config, a payload. Optional properties add flexibility but require narrowing. Readonly properties add safety but are shallow. The ? and | undefined distinction matters for what the API allows. Get these right, and the bulk of your type system does what it’s supposed to: catches mistakes before they reach production, and documents your domain in code that the compiler enforces.

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!

Object type syntax

Optional properties — ?

Optional vs | undefined

Readonly properties

Object type modifiers summary

Object literals — excess property checks

Reading and narrowing optional properties

Object types in practice

A full example

Complete Example Session

Quick Reference

Object Type Syntax

Property Modifiers

Optional vs | undefined

Reading Optional Properties

Readonly Effects

Excess Property Checks

Utility Combinations

exactOptionalPropertyTypes

Best Practices

Common Pitfalls

Real-World Examples

1. Basic user

2. Optional field

3. Readonly ID

4. Optional and readonly

5. Nested object

6. Readonly array

7. Optional array

8. Index signature

9. Partial

10. Pick

11. Omit

12. Destructure with defaults

13. Nullish coalescing

14. Optional chaining

15. Function parameter

16. Return object

17. Excess check

18. Excess check via variable

19. Method property

20. Function property

Visual: Optional Property Behavior

Visual: ? vs | undefined

Visual: Readonly Shallow vs Deep

Visual: Excess Property Checks

Visual: Object Type Composition

Visual: Narrowing Optional

Visual: Method vs Function Property

Summary

Optional properties — `?`

Optional vs `| undefined`

Optional vs `| undefined`

`exactOptionalPropertyTypes`

Visual: `?` vs `| undefined`