Arrays, Tuples and Objects

Single values were the warm-up; real programs in the TypeScript for Beginners series move in groups. This chapter types the three containers you will use constantly — arrays for lists of one kind of thing, tuples for fixed recipes of different things, and object types for the shape of your data — along with optional properties, index signatures, readonly guards, and what “shape typing” actually means.

Arrays of one type

An array of strings is written string[], or equivalently Array<string> — the two forms are interchangeable, and beginners often prefer the bracket form for simple types and the angle-bracket form for nested ones:

const titles: string[] = ["Basics", "Types", "Interfaces"];
const scores: number[] = [91, 84, 77];
const names: Array<string> = ["Ada", "Grace"];

scores.push("high");

Expected output:

error TS2345: Argument of type 'string' is not assignable to parameter of type 'number'.

The guarantee is two-sided: nothing wrong can go in, and — just as valuable — every element read out is known to be a number, so scores[0].toFixed() needs no guard. Lists genuinely holding a mixture declare it honestly with a union such as (string | number)[], which you will meet properly in chapter 7. Remember from the JavaScript series that arrays are objects: .length, .push() and .map() all type-check against the element type.

Tuples: fixed recipes

Sometimes the positions matter as much as the values: a coordinate pair, a [key, value] row, a two-item response. A tuple states the type at every index:

let entry: [string, number] = ["chapters", 24];

entry = [42, "chapters"];
const third = entry[2];

Expected output:

error TS2322: Type '[number, string]' is not assignable to type '[string, number]'.
error TS2493: Tuple type '[string, number]' of length '2' has no element at index '2'.

Order, length and per-index type are all enforced, and each index reads back as its declared type — entry[0] is a string, entry[1] is a number. Two refinements cover most real uses:

• Optional elements — a trailing ? allows the slot to be skipped, and its type widens to include undefined: in [id: number, label?: string] the second element is string | undefined.
• readonly tuples — const origin: readonly [number, number] = [0, 0] refuses writes: attempting origin.push(1) reports error TS2339: Property 'push' does not exist on type 'readonly [number, number]'.

Named tuple elements such as [name: string, age: number] document each position while behaving exactly like the unnamed form. Use tuples for fixed-size data only — if it grows, it is an array.

Object literal types

An object type describes a shape: which properties exist, and what type each one holds. Inline, it looks like this:

const user: { name: string; age: number; active: boolean } = {
  name: "Ada",
  age: 36,
  active: true,
};

From that point the compiler knows every property. Omit one and it says so precisely:

const broken: { name: string; age: number } = { name: "Ada" };

Expected output:

error TS2739: Type '{ name: string; }' is missing properties from type '{ name: string; age: number; }': 'age'.

And when a literal carries a property the shape never declared — the classic typo — the object is rejected rather than silently accepted:

const ada: { name: string; age: number } = {
  name: "Ada",
  age: 36,
  emial: "ada@example.com",
};

Expected output:

error TS2353: Object literal may only specify known properties, and 'emial' does not exist in type '{ name: string; age: number; }'.

That check applies only to literals written on the spot; values arriving from variables are judged purely on shape. The distinction matters, and the next chapter explains it properly.

Optional properties

Real data has gaps, and a property that may be missing gets a ?:

const account: { id: number; nickname?: string } = { id: 7 };

console.log(account.nickname);

Expected output: undefined — but that is the honest result: the property is typed string | undefined, so the compiler requires a check before it is used. Optional means “may be absent”, never “may be the wrong type”: supplying nickname: 42 is still TS2322. Compare nickname?: string with nickname: string | undefined — the first also allows you to delete the property outright, which the second does not.

Index signatures: typed dictionaries

When property names are not known in advance — scores by subject, translations by locale — an index signature types every key at once:

const scores: { [subject: string]: number } = { maths: 90, english: 84 };

scores.history = 77;
scores.geography = "A";

Expected output:

error TS2322: Type 'string' is not assignable to type 'number'.

Every property must satisfy the signature, so the dictionary stays homogeneous no matter how it grows. Two consequences worth knowing:

• Any key looks valid — scores.mathm type-checks and returns number, yet is undefined at runtime. An index signature trades typo detection for flexibility.
• Mixing types means a union — a report card with numbers and strings needs { [key: string]: number | string }, not two signatures.

readonly arrays, and what “shape” means

A readonly modifier protects the container itself. const stops you reassigning the variable; readonly stops you mutating what it points at:

const locked: readonly string[] = ["first"];
locked.push("second");

Expected output:

error TS2339: Property 'push' does not exist on type 'readonly string[]'.

The same idea applies to properties (readonly id: number) and to whole objects built with as const, which freezes literals deeply. Underneath all of this sits one principle you will rely on for the rest of the series: TypeScript checks the shape of a value, not its identity or its class. An object with the right properties in the right types satisfies the type — there is no nameplate, no constructor check, no instanceof. Inline shapes work fine for one or two uses, but copy-pasted shapes drift apart the moment a field changes, which is exactly the problem the next chapter solves by giving a shape a name.

Common mistakes

• Mixing up the two array forms — string[] and Array<string> are identical; what never works is string[]<number> or forgetting the brackets on a general type.
• Treating optional like “wrong type allowed” — ? only permits absence; the value still has to match when it is present.
• Using a tuple for a growing list — fixed length is the point of a tuple; a list that gains items belongs in an array.
• Trusting an index signature to catch typos — any key type-checks, so a misspelled subject compiles and fails quietly at runtime.
• Confusing const with readonly — const list = [1] still allows list.push(2); only readonly blocks mutation.

Practice checklist

1. Build a number[], push a string into it, and read the TS2345 message until it makes sense.
2. Create a [string, number] tuple, pass the elements in the wrong order, then add an optional third element and observe its type.
3. Type an object literal with two properties, mistype one value, and add a property that does not exist — capture both error messages.
4. Give an object an optional property, access it without a guard, and fix the complaint.
5. Convert a plain array to readonly, then try push and an index assignment to see which one the compiler refuses.

What's next?

Copy-pasted shapes are asking for trouble — next you give them names with Interfaces and Type Aliases.