Typescript 유틸리티 타입(Partial, Pick, Omit, Record, Readonly)

공통 타입 변환을 위한 유틸리티 타입

타입스크립트에서 제공하는 유틸리티 타입(Utility Types)은 type, interface를 입맛에 맞게 사용할 수 있도록 도와주는 유용한 기능이다.

유틸리티 타입의 종류는 다음 그림과 같이 매우 많다(타입스크립트 공식 페이지).

이 중 사용 빈도가 잦은 Partial, Pick, Omit, Record, Readonly에 대해 알아보자.

1. Partial

partial은 ‘부분적인’이라는 뜻으로, 정의된 타입의 속성을 모두 옵셔널로 사용하여 부분적으로 원하는 속성만 사용하도록 할 수 있다.

우선 Partial의 정의는 다음과 같다.

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

Partial<Type>의 방식을 통해 속성을 옵셔널하게 사용하며, 예시는 다음과 같다.

 
interface Hardware{
    cpu: string;
    gpu: string;
    memory: number;
    storage: number;
    accessary: string;
}

const selectOptions = (default: Hardware, selected: Partial<Hardware>) => {
    setOptions({...default, ...selected});
};

const defaultOption = {
    cpu: "M1";
    gpu: "10-core";
    memory: 16;
    storage: 512;
    accessary: "Touch ID";
}

const selectedOption = {
    cpu: "M2";
    memory: "32";
    storage: "1024";
}

이와 같은 방법으로 사용하지 않는 속성을 옵셔널로 변경하여 사용할 수 있다.

2. Pick

pick은 ‘뽑다’는 뜻으로, 정의된 타입에서 속성을 지정하여 사용할 수 있다.

Pick의 정의는 다음과 같다.

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

Pick<Type, Keys>의 방식을 사용해 사용할 속성을 문자열이나 유니온 타입으로 Keys에 지정하여 해당 속성만 사용한다.

interface Exercise{
    title: string;
    type: string;
    time: number;
    complete: boolean;
}

type BriefExercise = Pick<Exercise, "title" | "complete">;

const today = {
    title: "jogging";
    complete: true;
}

Partial은 모든 속성을 옵셔널로 사용하지만 Pick은 속성을 지정하여 필요한 타입만 정의하는 방식으로 사용한다.

3. Omit

omit은 ‘생략하다’라는 뜻으로, 정의된 타입에서 생략할 속성을 지정하여 사용할 수 있다.

Omit의 정의는 다음과 같다.

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

Omit<Type, Keys>의 방식으로 사용하며, Pick과 반대로 필요하지 않은 타입을 지정하여 정의하는 방식으로 사용한다.

interface Exercise{
    title: string;
    type: string;
    time: number;
    complete: boolean;
}

type BriefExercise = Omit<Exercise, "type" | "time">;

const today = {
    title: "jogging";
    complete: true;
}

Pick과 Omit의 용도는 같지만 정의 방법은 상반된다.

정의된 타입에서 생략하고 싶은 속성이 많을 때는 Pick, 생략하고 싶은 속성이 적을 때는 Omit을 사용하면 효과적이다.

4. Record

record는 ‘기록하다’는 뜻으로, key-value 세트를 생성하여 사용할 수 있다.

Record의 정의는 다음과 같다.

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

Record<Keys, Type>의 방식으로 사용하며, 두 개의 타입에서 한 타입을 Keys, 한 타입을 Type으로 조합하여 사용할 수 있다.

type MacBookType = "air13" | "air15" | "pro13" | "pro14" | "pro16";

interface Performance{
    cpu: string;
    memory: number;
    storage: number;
};

const OnTheMarket: Record<MacBookType, Performance> = {
    air13: { cpu:"M1", memory:8, storage: 256 };
    air15: { cpu:"M2", memory:16, storage: 512 };
    pro13: { cpu:"M2", memory:16, storage: 1024 };
    pro14: { cpu:"M2 pro", memory:32, storage: 1024 };
    pro16: { cpu:"M2 ultra", memory:96, storage: 2048 };
}

위와 같은 방식으로 두 타입을 조합해서 사용할 수 있다.

5. Readonly

readonly는 ‘읽기 전용’이므로 타입을 읽기 전용으로 정의하여 사용할 수 있다.

Readonly의 정의는 다음과 같다.

type Readonly<T> = {
  readonly [P in keyof T]: T[P];
};

타입을 사용해 readonly 속성을 부여하고 싶은 경우에 사용할 수 있다.

interface LimitSize{
    size: number;
}

const myData: Readonly<LimitSize> = {
    size: 32;
}

myData.size = 64; // error

interface, type 차이점이 뭘까(Typescript)

비슷하지만 동일하지 않은 interface vs type

타입스크립트에서 타입을 선언하기 위해서는 interface 또는 type 키워드를 사용합니다.

각각의 선언 방식은 다음과 같으며 =의 유무만 다릅니다.

// interface
interface Team{
  name : string
}

// type
type Team = {
  name : string
}

그리고 타입의 확장 방법은 다음과 같습니다.

// interface
interface City extends Team {
  city : string
}

// type
type City = Team & {
  city : string
}

interface와 type의 가장 큰 차이점은 바로 선언적 확장(Declaration Merging) 기능인데요.

선언적 확장이란 이미 선언된 타입 선언에 필드를 추가하는 것입니다.

하나는 가능하고 하나는 가능하지 않은데 interface만 가능한 것이 특징입니다.

사용 방법은 다음과 같습니다.

interface Team {
  name : string
}

interface Team {
  manager : string
}

위와 같은 방법으로 이미 선언된 interface에 다시 필드를 선언할 수 있습니다.

하지만 type을 다음과 같은 방법으로 사용하면 에러가 발생합니다.

type Team = {
  name : string
}


// Error 발생 -> 'Duplicate identifier 'Team'
type Team = {
  manager : string
}

추가로 type은 원시형(number, string 등) 데이터를 다른 이름으로 지정해서 사용할 수 있지만 interface는 불가능합니다.

자세한 내용은 다음 코드와 같습니다.

//type으로 원시형 데이터의 이름을 지정
type NameDataType = string;

const printName = (name : NameDataType ) => {
  console.log(name);
}

//interface는 불가
interface NameType extends string {
}

차이점을 신경써도 되지 않을 상황이라면 취향에 따라 선택하면 되지만 기본적으로는 interface를 쓰면 큰 문제가 없다고 합니다.

참고 : typescript 공식 문서

Next.js + Typescript + Emotion + Tailwind 환경 구축하기

Next.js에서 Emotion과 TailwindCSS를 함께 사용하기 위한 설정

1. Next.js 설치

다음 명령을 사용해 Next.js의 최신 버전 + typescript를 설치한다.

npx create-next-app@latest --ts

아래 명령어로 설치 및 버전을 확인한다.

npx next -v

2. emotion 관련 라이브러리 설치

emotion 관련 라이브러리를 설치한다.

npm i @emotion/react @emotion/styled @emotion/css @emotion/server

3. tailwind, twin.macro 라이브러리 설치

tailwind, twin.macro 관련 라이브러리를 설치하고 devDependencies에 추가한다.

npm i twin.macro tailwindcss postcss@latest autoprefixer@latest @emotion/babel-plugin babel-plugin-macros --save-dev

config 파일 생성을 위해 다음 명령어를 사용한다.

tailwind.config.js를 사용하면 입맛에 맞게 사용자 지정 스타일을 사용할 수 있다.

npx tailwindcss init -p
/** @type {import('tailwindcss').Config} */
module.exports = {
  content: [
    "./pages/**/*.{js,ts,jsx,tsx}",
    "./components/**/*.{js,ts,jsx,tsx}",
  ],
  theme: {
    extend: {},
  },
  plugins: [],
};

styles/globals.css의 상단에 다음 코드를 추가한다. (HTML 태그 내에서 인라인으로 tailwind를 사용 가능하게 함)

@tailwind base;
@tailwind components;
@tailwind utilities;

4. .babelrc 생성

twin.macro의 사용이 가능하도록 plugin 설정을 해야 하므로 .babelrc 파일을 생성한다.

내부 설정은 다음과 같다.

{
  "presets": ["next/babel"],
  "plugins": ["babel-plugin-macros"]
}

5. 작동 테스트

emotion 및 emotion +tw(tailwind) 작동을 테스트한다.

아래 코드를 pages/index.tsx에 작성하고 npm run dev로 실행한다.

import type { NextPage } from "next";
import styles from "../styles/Home.module.css";
import styled from "@emotion/styled/macro";
import tw from "twin.macro";

const Input = tw.input`
    text-center border h-28
`;

const MyDiv = styled.div`
  background: gold;
  font-size: 5rem;
  margin-top: 10px;
`;

const Home: NextPage = () => {
  return (
    <div className={styles.container}>
      <main className={styles.main}>
        <h1 className={styles.title}>
          <Input placeholder="box" />
          <MyDiv>Test Text</MyDiv>
        </h1>
      </main>
    </div>
  );
};

export default Home;

결과는 다음과 같다.


관련 링크

nextJS https://nextjs.org/

tailwindCSS https://tailwindcss.com/

emotion https://emotion.sh/docs/introduction

twin.macro https://github.com/ben-rogerson/twin.macro#readme

타입스크립트와 제네릭의 이해(Typescript and Generics)

클래스, 함수, 인터페이스, 타입의 재활용을 가능하게 만드는 제네릭

타입스크립트는 변수나 파라미터 등에 데이터 타입을 명시하여 코드 작성 단계에서 오류를 확인할 수 있고 미리 타입을 결정하여 실행 속도가 빠르다는 장점이 있습니다.

그러나 매번 타입을 지정하는 것은 분명 번거로운 일이므로 타입스크립트의 단점으로 꼽힙니다.

더욱이 똑같은 기능을 하는 함수지만 상황에 따라 다른 데이터 타입을 전달받는 함수는 매번 타입에 맞는 함수를 생성해야 합니다.

그렇다면 데이터를 전달할 때 데이터 타입 정보도 함께 전달해서 함수에게 알려주면 어떨까요?

전달하는 데이터의 타입 정보를 함께 전달하여 선언 시점이 아닌 생성 시점에 타입 정보도 변수처럼 변경할 수 있도록 하는 기능이 바로 제네릭입니다.

제네릭은 오래 전 C++부터 사용되어 왔는데요.

제네릭 함수의 모양새는 다음과 같습니다.

//함수형
const thisGeneric = <T>(value: T):T => {
     return value;
}

//클래스형
function thisGeneric2<T>(value: T) : T {
     return value;
}

const myVariable = thisGeneric<string>('my generic');
const myVariable2 = thisGeneric2('my generic2');  //< >생략 시 타입 추론

< >를 사용해 제네릭을 표현하고 안의 T는 정해진 것이 아니므로 다른 글자를 사용해도 되지만 관습적으로 T(type의 t)를 많이 사용합니다. 만약 두 개의 제네릭 정보를 받는 경우에는 <T, U>와 같이 표기합니다.

많이 사용되는 알파벳의 의미는 다음과 같습니다.

T : type
E : element
K : key
V : value

어떤 타입을 전달해도 사용이 가능한 any도 제네릭으로 볼 수 있지만 any는 타입을 체크하지 않으므로 전달받은 데이터의 타입을 알 수 없고 리턴 시에도 타입 정보를 반환하지 않습니다. 그러나 제네릭은 전달받은 타입을 확인하고 정보를 함께 반환할 수 있으며 세부적인 제한을 둘 수도 있습니다.

제네릭 인터페이스도 사용 방법은 제네릭 함수와 동일합니다.

interface ValueInterface<T> { 
   value : T
}

let myValue : ValueInterface<string> {
  value : 'data'
}

그렇다면 or의 연산자 | 를 사용하여 여러 타입을 지정할 수 있는 유니온 타입과는 어떤 차이가 있을까?

유니온은 | 로 지정한 여러 타입의 공통 메서드만 사용할 수 있으며 리턴 데이터의 타입도 하나가 아닌 유니온 타입이 반환됩니다.

function myUnion(val:number|string){
   return val;
}

const test = myUnion('string');
console.log(test.length); //에러 (length는 number와 string의 공통 메서드가 아니므로)

유사한 기능이 존재하지만 제네릭이 갖는 장점이 명확합니다.

제네릭을 사용하면 깔끔하게 코드를 줄이면서도 코드의 재활용이 가능해 매우 유용합니다.

제네릭을 사용한 오픈 소스들이 매우 많으므로 제네릭을 익혀두면 다른 고급 개발자들의 코드를 살펴볼 때도 큰 도움이 될 것 같습니다.