When Structure Comes From Patterns: Understanding Record in TypeScript

There’s a point where defining objects manually starts to feel… repetitive.

You write something like:

type Config = {
  darkMode: boolean
  notifications: boolean
  autoSave: boolean
}

It’s clear.

It works.

But there’s something slightly rigid about it.

Because the structure isn’t really the interesting part.

What’s interesting is the pattern behind it.

All keys share the same type.

All values follow the same rule.

The only thing that changes is the name of the key.

And yet, we’re writing it out one by one.

When Keys Become the Source of Truth

Now imagine those keys aren’t just random.

They come from somewhere else.

type Settings = "darkMode" | "notifications" | "autoSave"

Now your intent changes.

You’re no longer thinking:

“This object has these fields”

You’re thinking:

“For each setting, there should be a value”

That’s a completely different perspective.

The structure is no longer primary.

The keys are.

From Writing Objects to Generating Them

This is where Record starts to make sense.

type Config = Record<Settings, boolean>

At first glance, it feels like a shortcut.

But it’s not just shorter.

It’s expressing something deeper.

You’re not manually defining an object anymore.

You’re generating one from a rule.

“For every key in Settings, assign a boolean value”

That’s a shift from definition to transformation.

A Different Way to Think About Objects

Without Record, objects feel static.

You write them out, field by field.

With Record, objects become derived.

They emerge from relationships between types.

Instead of saying:

“This object has these properties”

You’re saying:

“This object is built from these keys and this value type”

That makes your types more adaptable.

Because if Settings changes, the object updates automatically.

No duplication.

No drift.

What Record Actually Does

Under the surface, Record is very simple.

type Record<K extends keyof any, T> = {
  [P in K]: T
}

It loops over each key and assigns the same type.

Nothing more.

Nothing less.

So it doesn’t add complexity.

It removes repetition.

The Constraint That Defines It

Record is strict.

If you say:

type Config = Record<"a" | "b", number>

Then both keys must exist.

const config: Config = {
  a: 1
  // ❌ missing b
}

That strictness is intentional.

Because Record is about completeness.

It assumes that if a key exists in your set, it must be represented.

Where It Becomes Limiting

That same strictness can also be a limitation.

All values must share the same type.

All keys must be present.

There’s no room for variation.

Which means Record is not for everything.

It works best when your data follows a uniform pattern.

If different keys require different types, you’re solving a different problem.

A Subtle but Important Distinction

Compare these two:

type A = {
  darkMode: boolean
  notifications: boolean
}

type B = Record<"darkMode" | "notifications", boolean>

They look identical.

But they carry different meaning.

The first is a standalone definition.

The second is tied to a source.

And that connection makes your system more consistent over time.

Because one is a snapshot.

The other is a rule.

The Bigger Insight

Record exists because sometimes structure isn’t something you invent.

It’s something you derive.

It recognizes that patterns matter more than repetition.

That relationships between types can define structure more clearly than manual definitions ever could.

It’s not just about avoiding duplication.

It’s about expressing intent at a higher level.

Because in many systems, the question isn’t:

“What does this object look like?”

But:

“What rule generates this object?”