Using `Pick` for DTOs in TypeScript

Moorthy G — Thu, 29 Jan 2026 04:58:35 +0000

When working with DTOs in TypeScript, I often see (and use) Pick<T>.
It’s simple, expressive, and removes a lot of boilerplate — but it also has trade-offs that are easy to overlook.

Here’s how I think about it.

What `Pick<T>` Is Good At

Pick<T> creates a new type by selecting fields from an existing one.

type User = {
  id: string;
  email: string;
  passwordHash: string;
  createdAt: Date;
};

type UserDTO = Pick<User, "id" | "email">;

✅ Less Duplication

I don’t have to redefine the same fields over and over.
The DTO stays automatically in sync with the domain model.

✅ Refactor-Friendly

If I rename email or change its type, TypeScript tells me immediately what breaks.
That’s a big win in real-world codebases.

✅ Great for Simple Read DTOs

For internal tools or basic CRUD APIs where the DTO closely mirrors the entity, Pick<T> works really well.

Where `Pick<T>` Starts to Hurt

❌ Tight Coupling to the Domain

DTOs are contracts. Pick<T> ties them directly to internal models.

type PublicUserDTO = Pick<User, "id" | "email">;

Now a change in User can accidentally become a breaking API change — even if that wasn’t the intent.

❌ Semantic Mismatch

Sometimes the API shape isn’t the same as the domain shape.

Domain: firstName, lastName
API: fullName

Using Pick<T> hides the fact that transformation is required, which makes intent less clear.

How I Use It in Practice

I treat Pick<T> as a convenience, not a rule.

I’m happy to use it for:

Internal APIs
Read-only DTOs
Admin panels

For public or long-lived APIs, I prefer explicit DTOs:

type PublicUserDTO = {
  id: string;
  email: string;
};

Sometimes I mix both approaches:

type UserBaseDTO = Pick<User, "id" | "email">;

type UserWithStatusDTO = UserBaseDTO & {
  status: "active" | "inactive";
};

Final Thoughts

Pick<T> is great when the domain and the DTO mean the same thing.
It’s risky when they don’t.

I use it where it reduces noise, and avoid it where clarity and boundaries matter more.

Type safety is great — but clear intent is better.

TypeScript Function Overloads

Moorthy G — Wed, 28 Jan 2026 14:15:25 +0000

What is a Function Overload?

TypeScript function overloads allow you to define multiple function signatures for the same function. This helps TypeScript understand different valid ways a function can be called, while keeping strong type safety.

At runtime, only one function implementation exists.

Basic Syntax

A function overload consists of:

Overload signatures (no body)
Single implementation

// Overload signatures
function add(a: number, b: number): number;
function add(a: string, b: string): string;
// Implementation
function add(a: any, b: any) {
  return a + b;
}

Usage

add(2, 3);        // number
add("a", "b");   // string
add(2, "b");     // Error

Example 1: Different Number of Parameters

function greet(name: string): string;
function greet(firstName: string, lastName: string): string;

function greet(a: string, b?: string) {
  return b ? `Hello ${a} ${b}` : `Hello ${a}`;
}

greet("John");
greet("John", "Doe");

Example 2: Different Return Types

function parseInput(value: string): string;
function parseInput(value: number): number;

function parseInput(value: string | number) {
  if (typeof value === "string") {
    return value.toUpperCase();
  }
  return value * 2;
}

parseInput("hello"); // string
parseInput(10);      // number

Example 3: Object-Based Overloads

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

function getUser(id: number): User;
function getUser(user: User): string;

function getUser(value: number | User) {
  if (typeof value === "number") {
    return { id: value, name: "Guest" };
  }
  return value.name;
}

Overloads vs Union Types

Without Overload

function combine(a: string | number, b: string | number) {
  return a + b;
}

Return type becomes string | number (less precise).

With Overload

function combine(a: number, b: number): number;
function combine(a: string, b: string): string;

function combine(a: any, b: any) {
  return a + b;
}

Precise return types are preserved.

Rules to Remember

Overload signatures have no implementation
Only one implementation is allowed
The implementation signature is not visible to callers
Implementation must support all overloads

When to Use Function Overloads

Use when:

Return type depends on input type
Number of parameters varies
Designing public APIs

Avoid when:

Union types are sufficient
Logic is simple

Summary

Feature	Description
Purpose	Multiple valid call signatures
Runtime	Single JS function
Benefit	Better type safety & IntelliSense
Alternative	Union types

DEV Community: Moorthy G