03 — Primitive Types: The Building Blocks of the Type System

A vocabulary list to memorize was how I treated TypeScript's primitives, and the list stayed arbitrary. Writing it down rearranged the picture: a small set of primitives covers almost all data, and the interesting ones (tuple, enum, void) each exist to nail down one specific shape that a plain object or array can't. [1] Once I saw what each type is for, the list stopped feeling arbitrary.

The starting point is that TypeScript mirrors JavaScript's runtime primitives and then adds a few compile-time-only shapes on top. The runtime primitives — string, number, boolean, null, undefined — describe the actual values JavaScript holds. The compile-time shapes — array, tuple, enum, void, object — describe how those values are arranged or what a function produces. Keeping that split in mind is what made the types click for me.

The three primitives you write constantly

Three types show up in almost every signature:

• string — textual data, in single quotes, double quotes, or backticks [1].
• number — all numeric values. JavaScript has one number format (IEEE 754 double-precision 64-bit floating point), so 1, 3.14, and -42 are all just number — there's no separate int or float [1].
• boolean — exactly true or false, used for flags and conditional logic.

These three carry most of the weight in everyday code. The annotation syntax is the same for all of them: let name: string, let age: number, let isActive: boolean.

Arrays

An array is an ordered list where every element shares one type. The two equivalent notations:

let ids: number[] = [1, 2, 3];
let names: Array<string> = ["Ave", "Sam"];

Both mean "a list of numbers" or "a list of strings." The compiler enforces element consistency — pushing a string into ids is an error. Array length is mutable, which is why this is distinct from the next type [1].

Tuples: fixed-length, fixed-position

A tuple is a typed array with a pre-defined length and a specific type at each position [2]. This is the type that exists because a plain array can't express "two elements, the first a string and the second a number":

let response: [string, number] = ["OK", 200];

Each index has its own type, and the count is fixed. Tuples are the right tool for fixed-structure pairs like [value, status], HTTP responses, or key-value entries — anywhere the position carries meaning. They're not a replacement for arrays; they're the narrow tool for when the structure is known and small.

Enums: named sets of constants

An enum gives friendly names to a set of related constant values [3]:

enum Status {
  Pending,
  Active,
  Closed,
}

By default the members are numbers starting at 0, so Status.Pending is 0, Status.Active is 1. Enums make code readable — if (order.status === Status.Active) beats if (order.status === 1) — and they surface all the valid options in editor autocomplete. The trade-off is that numeric enums emit real JavaScript objects (they don't get erased like other types), which is worth knowing when watching bundle size. String enums and as const objects are common alternatives when that emit is undesirable.

void: the function that returns nothing

void marks the absence of a return value — the type assigned to functions that perform an action but produce nothing to hand back [4]:

function log(message: string): void {
  console.log(message);
}

It's almost exclusively a return type. The distinction from undefined is subtle but real: void says "the caller should ignore the return value," while undefined says "the value is specifically the absence." In practice I reach for void on callbacks and side-effecting functions.

null and undefined: two kinds of absence

JavaScript has two primitive values for absence — null for an intentionally empty value, undefined for an uninitialized one — and TypeScript mirrors them with two types by the same names [5]. Whether they're dangerous depends entirely on one compiler option: strictNullChecks. With it off, both sneak into every type and null/undefined can be assigned anywhere, which is a major source of bugs. With it on (the default under strict), a string cannot hold null — I have to write string | null to allow it, and the compiler forces me to check before using methods on a possibly-absent value. That single option is the difference between absence being a footgun and absence being handled.

Object types

Beyond primitives, TypeScript describes the shape of objects — the names, types, and optionality of their properties [6]. The inline form:

let user: { name: string; age?: number } = { name: "Ave" };

The ? marks age as optional. Object types are how I describe the data flowing through an app — API responses, config objects, component props. When a shape repeats, I lift it into an interface or type alias (covered in their own notes). The point here is that "object type" is the category, and inline shapes, interfaces, and aliases are all ways to spell one out.

How I use this

My defaults: reach for string/number/boolean and arrays for the bulk of data; use tuples only when the structure is genuinely fixed and positional; reach for an enum (or a as const object) when I have a closed set of options that deserves names; reserve void for side-effecting function returns; and treat null/undefined as types I must explicitly opt into via | null. The habit that pays off most is keeping strictNullChecks on so absence is a decision, not an accident.

References

[1] Microsoft, "Everyday Types," TypeScript Handbook, 2024. [Online]. Available: https://www.typescriptlang.org/docs/handbook/2/everyday-types.html

[2] Microsoft, "Tuple Types," TypeScript Handbook, 2024. [Online]. Available: https://www.typescriptlang.org/docs/handbook/2/objects.html#tuple-types

[3] Microsoft, "Enums," TypeScript Handbook, 2024. [Online]. Available: https://www.typescriptlang.org/docs/handbook/enums.html

[4] Microsoft, "Functions: void," TypeScript Handbook, 2024. [Online]. Available: https://www.typescriptlang.org/docs/handbook/2/functions.html#void

[5] Microsoft, "null and undefined," TypeScript Handbook, 2024. [Online]. Available: https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#null-and-undefined

[6] Microsoft, "Object Types," TypeScript Handbook, 2024. [Online]. Available: https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#object-types