Overview

When working with a Headless CMS like microCMS, it is common to define a type that represents the data structure returned from the CMS.

For example, in microcms.ts, I defined a type that represents the data returned by the API:

import type {
  MicroCMSImage,
  MicroCMSListContent,
} from 'microcms-js-sdk';

export type TechStack = {
  id: string;
  name: string;
};

export type Works = {
  title: string;
  category: string;
  techStack: TechStack[];
  content: string;
  thumbnail: MicroCMSImage;
} & MicroCMSListContent;

This Works type represents the structure of the data source.

However, in a UI component like WorksCard, I only need some of these fields.
So I defined a separate Props type inside the component:

import type { MicroCMSImage } from 'microcms-js-sdk';

type TechStack = {
  id: string;
  name: string;
};

type Works = {
  id: string;
  title: string;
  thumbnail: MicroCMSImage;
  category: string;
  techStacks: TechStack[];
};

export default function WorksCard({
  id,
  title,
  thumbnail,
  category,
  techStacks,
}: Works) {
  ...
}

At this point, I realized something felt uncomfortable.

The Props type was almost identical to the original Works type from the CMS definition. I was essentially defining very similar types in two different places.

The Problem

Redefining similar types is not technically wrong. The code works.

However, maintaining two nearly identical type definitions introduces risk.
For example, if the CMS structure changes in the future:

• id is renamed to slug
• category changes from a string to an object
• the structure of thumbnail changes

I would need to update both the data source type and the Props type manually.
It would be easy to forget one of them.

The discomfort came from realizing that I was duplicating type information.

The Solution: Using Pick

To avoid redefining similar types, I used TypeScript’s Pick utility type.

import type { Works } from '@/lib/microcms';

type WorksCardProps = Pick<
  Works,
  'id' | 'title' | 'thumbnail' | 'category'
>;

Pick<T, K> creates a new type by selecting specific properties K from an existing type T.
With this approach:

• The Props type depends on the original Works type.
• Property definitions stay in sync automatically.
• I no longer need to redefine similar structures manually.

In this case, the goal was simply to avoid redefining nearly identical types. Using Pick allowed me to reuse the existing type definition and avoid maintaining two nearly identical types.

When Not to Use Pick

Using Pick is not always the right choice.

If the UI requires a fully transformed data structure — for example:

• Passing only thumbnail.url as a string
• Converting CMS data into a completely different shape
• Intentionally decoupling the UI from CMS types

Then it is better to define an independent Props type.