005 — Objects & Arrays (inferred collection types)

Video: 005 · TypeScript Tutorial #4 - Objects & Arrays · watch · 7:36 · Net Ninja TypeScript tutorial series, lesson 5

Source: this is a written companion to the video. Part of the Favorite TypeScript Videos curated path, module 00 (foundations). Builds on 004 (strict types, inference): the same inference rule now applied to collections. The series project is the finance logger; the sandbox habit from 003 pays off — every rule below is demonstrated live in sandbox.ts, with the compiler’s red squiggles doing the teaching.

the big idea: collections infer their shape from the initializer

TypeScript looks at the initial value and locks the collection to that shape. A plain array initializer infers an element type and the array keeps it; an object literal infers a fixed structural type — property names and each property’s type all locked. Rule of thumb: the collection’s type is decided at declaration, and every later write is checked against it.

arrays: one type in, same type kept

let names = ["luigi", "mario", "yoshi"]; // string[]
names.push("toad"); // ok — string
// names.push(3);     // error — number not assignable to string
// names[0] = 3;      // error — same reason

Same story for numbers:

let numbers = [10, 20, 30, 40]; // number[]
numbers.push(25); // ok — number
// numbers.push('shaun'); // error — string not assignable to number

arrays: mixing types up front widens to a union

let mixed = ["ken", 4, "chun-li", 8, 9]; // (string | number)[]
mixed.push("ryu"); // ok — string is a member of the union
mixed.push(10); // ok — number is a member of the union
mixed[0] = 3; // ok — each write just has to match one member

objects: property types locked at definition

Object literals infer a fixed structural type: property names, and each property’s type, are all locked.

let ninja = { name: "mario", belt: "black", age: 30 };
// name: string, belt: string, age: number
ninja.age = 40; // ok — number
ninja.name = "ryu"; // ok — string
// ninja.age = '30'; // error — string not assignable to number

objects: no new properties, and reassignment must match the shape

Two structural rules close the lesson. First, you cannot add properties after definition:

// ninja.skills = ['fighting', 'sneaking']; // error — property does not exist

Once the object is defined, additional properties cannot be added — skills did not exist on the ninja object to begin with.

Second, wholesale reassignment must match the original shape — same properties, same types:

ninja = { name: "yoshi", belt: "orange", age: 40 }; // ok — same structure
// ninja = { name: 'yoshi', belt: 'orange' };        // error — age missing
// ninja = { name: 'yoshi', belt: 'orange', age: 40, skills: [] }; // error — excess property

Values can differ and still have to be the same type (name cannot become a number), every property name must be present, and no extra property may be added — the reassignment must match the structure of the initially declared object exactly. TypeScript is strict with these types, and that strictness is the point: less error-prone, cleaner, more predictable code.

Next video teaser: inference needs an initial value — when the value comes later, the type must be declared up front (006 — Explicit Types).

Prev: 004 — Type Basics · Next: 006 — Explicit Types

Module 00 covered: array element-type inference, union widening for mixed initializers, push and index-write checks, fixed object shapes, no post-hoc properties, exact-shape reassignment; explicit annotations deferred to 006. Transcript notes: the frame-008 reassignment line shows the instructor mid-edit on the negative skills: [] example; the transcript is authoritative and the working state keeps the name/belt/age contract.