When Data Isn’t Complete Yet: Rethinking Types Through Partial

There’s a quiet assumption we make when defining a type.

We treat it like a finished thing.

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

This doesn’t just describe structure.

It carries an expectation:

“If you have a User, you have everything.”

And most of the time, that’s exactly what we want.

But reality doesn’t always hand us complete things.

Sometimes you’re updating a user, and only the email changes.

Sometimes you’re building a form, and half the fields are still empty.

Sometimes data arrives in fragments, not wholes.

And that’s where the tension begins.

The Moment Duplication Starts to Hurt

At first, the solution feels obvious.

Just make another type.

type UpdateUser = {
  id?: number
  name?: string
  email?: string
}

It works.

But something subtle breaks.

You’ve now duplicated the same idea in two places.

And duplication is never just duplication.

It’s a maintenance cost.

If User changes, UpdateUser has to follow.

If you forget, your system slowly drifts out of sync.

From Defining to Transforming

This is the moment where Partial starts to make sense.

Not as a feature.

But as a shift in thinking.

type UpdateUser = Partial<User>

Now you’re no longer defining a new type.

You’re transforming an existing one.

That distinction matters more than it looks.

Because Partial doesn’t change what a User is.

It changes how strict you are about having it fully formed.

A Different Way to Think About Types

Instead of saying:

“This is a different kind of object”

You’re saying:

“This is the same object, just not complete yet”

That’s a very different mental model.

It turns types from static definitions into something more fluid.

Something that can adapt depending on context.

What Partial Actually Does

Under the hood, Partial is surprisingly simple.

type Partial<T> = {
  [P in keyof T]?: T[P]
}

For every property in T, it keeps the type exactly the same.

But it removes the obligation.

So it doesn’t distort the shape.

It loosens the rules.

And that’s the real role of Partial.

Not to redefine data.

But to relax constraints.

Where the Flexibility Stops

There’s an important boundary here.

Partial only works at the surface.

If you have nested structures:

type User = {
  name: string
  address: {
    city: string
  }
}

Applying Partial gives you:

{
  name?: string
  address?: {
    city: string
  }
}

The outer layer becomes optional.

The inside stays strict.

Which means Partial isn’t trying to make everything flexible.

It’s making a very specific trade-off:

“You may omit properties entirely, but if you provide them, they must still be valid.”

The Trade-off You Don’t See at First

If you write something like:

function updateUser(user: Partial<User>) {
  // ...
}

You’ve allowed this:

updateUser({})

An update with no data at all.

Technically valid.

Conceptually questionable.

This is where Partial reveals its trade-off.

It increases flexibility.

But it weakens guarantees.

Why This Isn’t the Default

You might wonder:

Why not make everything optional by default?

Why not require us to explicitly mark fields as required instead?

Because most of the time, we want strictness.

We want types to say:

“This must exist”

Not:

“This might exist”

Partial only becomes meaningful in situations where incompleteness is part of the problem.

It’s not about making types easier.

It’s about making them more honest.

A Subtle but Important Shift

Partial introduces a small but powerful idea:

Types don’t always represent finished data.

Sometimes they represent data in progress.

And that shift changes how you model systems.

Because sometimes, the most accurate description of your data isn’t:

“This is what it is”

But:

“This is what it could become”