Sunghyun Moon

6장 타입스크립트 컴파일

Tue, 02 Apr 2024 00:00:00 +0900

타입스크립트가 웹에서 실행되려면 먼저 자바스크립트로 바뀌어야 한다. 이 장에서는 타입스크립트가 실행되는 전반적인 흐름을 살펴보고, 타입스크립트 컴파일러의 주요 역할과 구조에 대해 알아본다. 그리고 실제로 어떻게 컴파일하는지를 확인해본다.

6.1 자바스크립트의 런타임과 타입스크립트의 컴파일

6.1.1 런타임과 컴파일타임

프로그래밍 언어는 일반적으로 고수준과 저수준 언어로 구분할 수 있다. 고수준 언어는 사람이 이해하기 쉬운 형식으로 작성되며, 저수준 언어는 컴퓨터가 이해하기 쉬운 형식으로 작성된다. 자바스크립트는 대표적인 고수준 언어에 속하며 컴파일러나 인터프리터에 의해 저수준 프로그래밍 언어 즉, 기계가 이해할 수 있는 언어로 번역되어 실행된다.
컴파일타임은 소스코드가 컴파일 과정을 거쳐 컴퓨터가 인식할 수 있는 기계어(=바이트 코드)로 변환되어 실행할 수 있는 프로그램이 되는 과정을 의미한다.
소스코드의 컴파일이 완료되면 프로그램이 메모리에 적재되어 실행되는데 이 시간을 런타임이라고 한다. 즉, 런타임은 컴파일 과정을 마친 응용 프로그램이 사용자에 의해 실행되는 과정이다.

6.1.2 자바스크립트 런타임

자바스크립트 런타임은 자바스크립트가 실행되는 환경을 의미한다. 대표적인 자바스크립트 런타임으로 크롬이나 사파리 같은 인터넷 브라우저와 Node.js 등이 있다.

6.1.3 타입스크립트의 컴파일

일반적으로 컴파일은 추상화 단계가 다른 고수준 언어에서 저수준 언어로 변환되는 과정을 가리 킨다.
타입스크립트는 tsc라고 불리는 컴파일러를 통해 자바스크립트 코드로 변환된다. 하지만 타입스크립트는 고수준 언어가 저수준 언어로 변환되는 것이 아니라 고수준 언어（타입스크립트）가 또 다른 고수준 언어 （자바스크립트）로 변환되는 것이기 때문에 컴파일이 아닌 트랜스파일(Transpile)이라고 부르기도 한다.
타입스크립트 컴파일러는 소스코드를 해석하여 AST(Abstract Syntax Tree, 최소구문 트리）를만들고 이후 타입 확인을거친다음에 결과 코드를 생성한다.
타입스크립트 컴파일러가 소스코드를 컴파일하여 프로그램이 실행되기 까지의 과정을 정리하면 다음과 같다.
- 타입스크립트 소스코드를 타입스크립트 AST로 만든다.（tsc）
- 타입 검사기가 AST를 확인하여 타입을 확인한다.（tsc）
- 타입스크립트 AST 자바스크립트 소스로 변환한다.（tsc）
- 자바스크립트 소스코드를 자바스크립트 AST로 만든다.（런타임）
- AST가 바이트 코드로 변환된다.（런타임）
- 런타임에서 바이트 코드가 평기되어 프로그램이 실행된다.（런타임）
이때 타입스크립트 소스코드의 타입은 1〜2단계에서만 사용된다. 즉, 개발자가 작성한 타입 정보는 단지 타입을 확인하는 데만 쓰이며, 최종적으로 만들어지는 프로그램에는 아무런 영향을 주지 않는다.
타입스크립트는 컴파일타임에 타입을 검사하기 때문에 에러가 발생하면 프로그램이 실행되지않는다. 이러한 특징 때문에 타입스크립트를 컴파일타임에 에러를 발견할 수 있는 정적 타입 검사기라고 부른다.

6.2 타입스크립트 컴파일러의 동작

타입스크립트 컴파일러는 타입스크립트 소스가 자바스크립트 소스로 변환되는 모든 과정에 영향을 준다. 이절에서는 타입스크립트 컴파일러의 주요 역할에 대해 살펴볼 것이다.

6.2.1 코드 검사기로서의 타입스크립트 컴파일러

타입스크립트 컴파일러는 코드에 타입 오류가 없는지를 확인한다. 타입스크립트에서는 컴파일 타임에 코드 타입을 확인하기 때문에 코드를 실행하지 않고도 오류가 있다는 것을 바로 알 수 있다.
타입스크립트는 코드를 실행하기 전에 에러를 사전에 발견하여 알려준다. 자바스크립트에서는 런타임에서 발견할 수 있는 에러를, 타입스크립트에서는 컴파일타임에 발견하여 실행 과정에서 발생할 수 있는 문제를 방지한다.
타입스크립트 컴파일러는 tsc binder를 사용하여 타입 검사를 하며, 컴파일타임에 타입 오류를 발견한다. 타입 검사를 거쳐 코드를 안전하게 만든 이후에는 타입스크립트 AST를 자바스크립트로 코드로 변환한다.

6.2.2 코드 변환기로서의 타입스크립트 컴파일러

타입스크립트 컴파일러는 타입을 검사한 다음에 타입스크립트 코드를 각자의 런타임 환경에서 동작할 수 있도록 구버전의 자바스크립트로 트랜스파일한다. 이것이 타입스크립트 컴파일러의 두 번째 역할이다.
다음 예시는 타입스크립트 컴파일러가 타입스크립트 파일을 자바스크립트로 변환한 결과를 보여준다. 타입스크립트 컴파일러의 target 옵션을 사용하여 특정 버전의 자바스크립트 소스코드로 컴파일할 수 있다. 여기에서는 ES5로 설정했다.

type Fruit = "banana" | "watermelon" | "orange" | "apple" | "kiwi" | "mango";
const fruitBox： Fruit[] = ["banana", "apple", "mango"]；
const welcome = (name: string) => {
  console.log(`hi! ${name} ：)`);
}；

"use strict";
var fruitBox = ["banana", "apple", "mango"];
var welcome = function (name) {
console.log("hi! ".concat(name, " ：)"));
};

타입스크립트가 자바스크립트로 컴파일되어야 브라우저는 코드를 비로소 이해하고 정상적=실행할 수 있다.
타입스크립트 컴파일러는 타입 검사를 수행한 후 코드 변환을 시작하는데, 이때 타입 오류가 있더라도 일단 컴파일을 진행한다. 타입스크립트 코드가 자바스크립트 코드로 변환되는 과정은 타입 검사와 독립적으로 동작하기 때문이다. 타입스크립트 코드의 타이핑이 잘못되어 발생하는 에러는 자바스크립트 실행 과정에서 런타임 에러로 처리된다.
컴파일된 코드가 실행되고 있는 런타임에서는 타입 검사를 할 수 없기 때문에 주의해야 하는 경우도 있다. 다음 예시를 살펴보자.

interface Square {
  width： number;
}
interface Rectangle extends Square {
  height: number;
}

type Shape = Square | Rectangle;
function calculateArea(shape： Shape) {
  if (shape instanceof Rectangle) {
    // 'Rectangle' only refers to a type, but is being used as a value here
    // Property 'height' does not exist on type 'Shape'
    // Property 'height' does not exist on type 'Square'
    return shape.width * shape.height;
  } else {
    return shape.width * shape.width;
  }
}

instanceof 체크는 런타임에 실행되지만 Rectangle은 타입이기 때문에 자바스크립트 런타임은 해당 코드를 이해하지 못한다. 타입스크립트 코드가 자바스크립트로 컴파일되는 과정에서 모든 인터페이스, 타입, 타입 구문이 제거되어 버리기 때문에 런타임에서는 타입을 사용할 수없다.
정리하면 타입스크립트 컴파일러의 역할을 크게 2가지로 나눌 수 있다.
- 최신 버전의 타입스크립트 - 자바스크립트 코드를 구버전의 자바스크립트로 트랜스파일한다.
- 코드의타입 오류를 검사한다.

6.3 타입스크립트 컴파일러의 구조

타입스크립트 소스코드가 자바스크립트로 변환되기까지 많은 일이 일어난다. 이제 실제 타입스크립트 컴파일러의 구성 요소를 훑어보며 타입스크립트 컴파일러의 동작 방식을 이해해보자.
컴파일러는 하나의 프로그램으로 이를 구현한 소스 파일이 존재한다.
타입스크립트 컴파일러는 다섯 단계를 거쳐 타입 검사와 자바스크립트 소스 변환을 진행한다.

6.3.1 프로그램

타입스크립트 컴파일러는 tsc 명령어로 실행된다. 컴파일러는 tsconfig.json에 명시된 컴파일 옵션을 기반으로 컴파일을 수행한다.
먼저 전체적인 컴파일 과정을 관리하는 프로그램 객체（인스턴스）가 생성된다. 이 프로그램 객체는 컴파일할 타입스크립트 소스 파일과 소스 파일 내에서 임포트된 파일을 불러오는데, 가장 최초로 불러온 파일을 기준으로 컴파일 과정이 시작된다.

6.3.2 스캐너

타입스크립트 소스를 자바스크립트로 변환하기 위한 첫 번째 단계는 스캐너이다. 스캐너는 타입스크립트 소스 파일을 어휘적으로 분석하여 토큰을 생성하는 역할을 한다.
다시 말해 소스코드를 작은 단위로 나누어 의미 있는 토큰으로 변환하는 작업을 수행한다.

6.3.3 파서

스캐너가 소스 파일을 토큰으로 나눠주면 파서는 그 토큰 정보를 이용하여 AST를 생성한다.
AST는 컴파일러가 동작하는 데 핵심 기반이 되는 자료 구조로, 소스코드의 구조를 트리 형태로 표현한다. AST의 최상위 노드는 타입스크립트 소스 파일이며, 최하위 노드는 파일의 끝 지점으로 구성된다.
스캐너는 어휘적 분석을 통해 토큰 단위로 소스코드를 나누지만 파서는 이렇게 생성된 토큰 목록을 활용하여 구문적 분석을 수행한다. 이를 통해 코드의 실질적인 구조를 노드단위의 트리 형태로 표현한다. 각각의 노드는 코드상의 위치, 구문 종류, 코드 내용과 같은 정보를 담고 있다.

6.3.4 바인더

바인더의 주요 역할은 체커 단계에서 타입 검사를 할 수 있도록 기반을 마련하는 것이다. 바인더는 타입 검사를 위해 심볼이라는 데이터 구조를 생성한다. 심볼은 이전 단계의 AST에서 선언된 타입의 노드 정보를 저장한다.

6.3.5 체커와 이미터

체커는 파서가 생성한 AST와 바인더가 생성한 심볼을 활용하여 타입 검사를 수행한다.
체커의 주요 역할은 AST의 노드를 탐색하면서 심볼 정보를 불러와 주어진 소스 파일에 대해 타입 검사를 진행하는 것이다.
체커의 타입 검사는 다음 컴파일 단계인 이미터에서 실행된다.
이미터는 타입스크립트 소스 파일을 변환하는 역할을 한다. 즉, 타입스크립트 소스를 자바스크립트(js) 파일과 타입 선언 파일(d.ts)로 생성한다.
이미터는 타입스크립트 수、 파일을 변환하는 과정에서 개발자가 설정한 타입스크립트 설정 파일을 읽어오고, 체커를 통해 코드에 대한 타입 검증 정보를 가져온다.
지금까지 살펴본 타입스크립트의 컴파일 과정을 정 리하면 다음과 같다.
- tsc 명령어를 실행하여 프로그램 객체가 컴파일 과정을 시작한다.
- 스캐너는 소스 파일을 토큰 단위로 분리한다.
- 파서는토큰을이용하여 AST를생성한다.
- 바인더는 AST의 각 노드에 대응하는 심볼을 생성한다. 심볼은 선언된 타입의 노드 정보를 담고 있다.
- 체커는 AST를 탐색하면서 심볼 정보를 활용하여 타입 검사를 수행한다.
- 타입 검사 결과 에러가 없다면 이미터를 사용해서 자바스크립트 소스 파일로 변환한다.

끝!

실무에서 Typescript Mixin 적용해보기

Sat, 09 Mar 2024 00:00:00 +0900

이번에 오피스에 댓글 기능 공통 프레임워크를 개발을 하면서, 타입스크립트 Mixin을 사용해봤고, Mixin을 실무에 적용해보면서 공부했던 것들을 한번 정리해보고자 한다.

Mixin이 필요했던 상황

문서에서 본문 content내의 객체와 content와 별개인 댓글 객체와 연결을 시키려면, 기존엔 content 내 특정 객체에서 댓글 객체에 대한 Id 리스트(commentList)를 들고 있었다.
하지만, 특정 모듈에만 있는 댓글 기능을 전 모듈로 올리는 공통 프레임워크 작업을 진행하면서, 댓글을 삽입할 수 있는 객체들이 많아졌고, 댓글이 삽입 가능한 모든 클래스들에 대해 commentList 프로퍼티와 그것을 관리하는 메서드 들이 중복으로 필요한 상황이 생겼다.
또한, 기존의 클래스들은 이미 공통 Node 속성들을 갖고 있는 Base 클래스들을 통해 상속받고 있는 상황이었다.
따라서, 다중 상속을 받는 것과 유사한 효과를 얻을 수 있고, 중복 코드없이 하나의 코드로 코드의 재사용성을 증가시키기 위해 떠오르는 것이 바로 Typescript Mixin이었다.

Mixin이란?

타입스크립트에서 Mixin은 여러 클래스 간에 공통된 기능을 재사용할 수 있도록 하는 디자인 패턴이다. Mixin은 클래스를 정의하는 대신 함수 형태로 구현되며, 이 함수는 다른 클래스에 특정 기능을 추가하거나 확장할 때 사용된다. Mixin은 다중 상속을 지원하지 않는 자바스크립트의 특성상, 클래스를 여러 소스로부터 기능을 결합하거나 공유하는 방법으로 활용된다.
조금 더 구체적으로 얘기해보자. 클래스 A가 클래스 B를 확장 해서 그 기능을 받는 것이 아니라 함수 B가 클래스 A 를 받고 기능이 추가된 새 클래스를 반환하는 것이다. 함수 B가 믹스인이다.
따라서 믹스인은 아래와 같은 함수다.
- 1) 생성자(constructor)를 받음
- 2) 생성자를 확장하여 새 기능을 추가한 클래스 생성
- 3) 새 클래스 반환

실무 Mixin 코드

아래는 완전히 동일하지는 않지만, 실무에 적용한 Mixin 코드다.

type CommentConstructor<T extends object = object> = abstract new (...args: any[]) => T;

/**
 * CommentMixin이 결합된 클래스의 인스턴스 타입 정의
 */
export type CommentableDocumentNode = Commentable & DocumentNode;

export function CommentMixin<NodeBase extends CommentConstructor<DocumentNode>>(
  DocumentNodeBase: NodeBase
) {
  abstract class CommentableNode extends DocumentNodeBase implements Commentable {
    /**
     * CommentableDocumentNode의 commentList를 deserialize
     */
    @serializable(
      alias(
        'elementType',
        custom(
          () => SKIP,
          (value, context) => {
            const data = context.json;
            const { commentList } = data;
            if (commentList !== undefined) {
              const parsedCommentList = JSON.parse(commentList);
              context.target.setCommentList(parsedCommentList);
              return parsedCommentList;
            }
            return [];
          }
        )
      )
    )
    /**
     * CommentableDocumentNode에서 관리하는 commentList
     */
    @observable.shallow
    private commentList: Array<number> = [];

    // eslint-disable-next-line @typescript-eslint/no-explicit-any
    constructor(...args: any[]) {
      super(...args);
      makeObservable(this);
    }

    public setCommentList(commentList: Array<number>): void {
      this.commentList = commentList;
    }

    public getCommentList(): Array<number> {
      return this.commentList;
    }

    public addComment(commentId: number): void {
      this.commentList.push(commentId);
    }

    public removeComment(commentId: number): void {
      this.commentList = this.commentList.filter(curId => curId !== commentId);
    }

    public hasComment(): boolean {
      return this.commentList.length > 0;
    }

    public isCommentMixin(): boolean {
      return true;
    }
  }

  return CommentableNode;
}

/**
 * CommentableDocumentNode에 대한 타입 가드
 */
// eslint-disable-next-line @typescript-eslint/no-explicit-any
export const isCommentable = (obj: OfficeTreeNodeTypes | any): obj is CommentableDocumentNode =>
  typeof obj === 'object' &&
  obj !== null &&
  typeof obj.isCommentMixin === 'function' &&
  obj.isCommentMixin();

먼저 생성자 타입 코드를 보자.

type CommentConstructor<T extends object = object> = abstract new (...args: any[]) => T; 

CommentContsructor라는 생성자 타입을 정했다. 생성자 타입의 반환값이 제네릭으로 되어있고, 이 제네릭은 object 타입으로 제한했고, 기본값으로도 object 타입을 설정했다.
인자는 가변 인자를 받을 수 있고 타입은 any[]로 정의된다. 즉, 인수의 개수나 타입에 상관없이 어떤 인자로도 허용된다.
그리고 생성자 합수의 반환 타입을 T다. 이 생성자를 사용해 인스턴스화한 객체의 타입이 T로 설정된다.
위 코드처럼 생성자 타입의 인자를 …args: any[]로 받는 것은 어떠한 객체나 인수도 허용하도록하는 일반적인 방식이다. 하지만, 특정 구조나 속성을 가진 객체만 받을 수 있도록 제약을 둘 수 도 있다.
- 예를 들어, x: number와 y: string 같은 특정 인수를 요구하는 생성자 타입을 정의하려면, 아래와 같이 생성자 타입을 정의할 수 있다.

type Constructor = new (x: number, y: string) => any;

따라서, 위와 같이 생성자 타입을 정의하면, Mixin이 받는 기본 클래스의 생성자 타입을 명확히 지정할 수 있다. 이것은 타입스크립트가 코드의 타입 체크를 더욱 정확하게 할 수 있도록 도와준다.
정리하면, Mixin 함수의 타입을 명확하게 정의함으로써, 이 함수를 사용할 때 필요한 인수와 반환 타입을 명확히 할 수 있다. 당연히 코드의 가독성와 유지보수성에 좋은 영향을 미친다.

export function CommentMixin<NodeBase extends CommentConstructor<DocumentNode>>(
  DocumentNodeBase: NodeBase
) {
  abstract class CommentableNode extends DocumentNodeBase implements Commentable {
      ...
      return CommentableNode;
  }
}

위 코드를 통해 Mixin 패턴을 사용하여 클래스를 확장한다. CommentMixin이라는 함수가 특정 클래스에 commentList 관리 기능을 추가하는 구조다.
CommentMixin 적용이 필요한 모든 클래스가 DocumentNode라는 클래스를 상속 받고 있고, CommentMixn을 통해 확장된 클래스에서 기존 DocumentNode 클래스의 프로퍼티와 메서드를 사용하기 위해서 CommentMixin 내부 클래스도 DocumentNode를 상속 받도록 했다.
이 CommentMixin 함수에 인자의 타입은 제네릭 타입의 NodeBase이고, 이 NodeBase는 CommentConstructor<DocumentNode> 타입을 상속하는 타입이어야 한다. 즉, CommentMixin 함수의 인자는 DocumentNode라는 객체를 생성할 수 있는 클래스 또는 생성자여야 한다는 뜻이다.
그리고, CommentableNode라는 새로운 추상 클래스를 선언했고, CommentableNode 클래스는 인자로 들어온 DocumentNodeBase 클래스를 상속 받는다.
즉 위코드를 정리하면, CommentMixin 함수는 DocumentNode 기본 클래스를 확장하여, Commentable이라는 interface로 구현하는 추상 클래스 CommentableNode를 반환하는 것을 의미한다.
그리고 isCommentable이라는 타입가드를 만들어, 정적으로 타입을 좁히고 commentList 관리 메서드를 사용할 수 있도록 했다.

Mixin 장점

댓글이 삽입 가능한 클래스들에서 commentList를 관리해야하는 중복 코드를 줄일 수 있다.
그리고, commentList를 관리하는 기능을 독립적인 단위로 분리해 모듈화했기 때문에 코드 가독성 및 유지보수에 용이하다.
그리고 댓글 객체에서도 맵핑되어 있는 객체를 프로퍼티로 들고 있는데, 이 맵핑 객체의 타입이 다양할 수 있다. 예를 들어, 텍스트, 도형, 그림, 테이블 등등이 있을 수 있다. 그러면 댓글 삽입 가능한 클래스를 추가할때 마다 유니온 타입으로 추가하거나 혹은 맵핑 객체가 특정 모듈에만 있다면 댓글 클래스 자체를 상속받아서 별도로 구현할 수도 있다.
CommentMixin을 통해 commentList 기능이 확장된 클래스들에 대해 위와 같이 CommentableDocumentNode라고 타입을 정하였기 때문에, 댓글 객체에서는 별도의 타입 추가나 상속 구현 없이, 맵핑된 객체의 프로퍼티 타입으로 CommentableDocumentNode라고만 정해주면 된다.

끝!

HOC 패턴

Tue, 05 Mar 2024 00:00:00 +0900

종종 여러 컴포넌트에서 같은 로직을 사용해야 하는 경우가 있다. 이런 로직은 컴포넌트의 스타일시트를 설정하는 것일 수 있고, 권한을 요청하거나, 전역 상태를 추가하는 것일 수 있다.

같은 로직을 여러 컴포넌트에서 재사용하는 방법 중 하나로 고차 컴포넌트 패턴을 활용하는 방법이 있다. 이 패턴은 앱 전반적으로 재사용 가능한 로직을 여러 컴포넌트들이 쓸 수 있게 해 준다.

HOC 패턴에 대해 공부해보자.

고차 컴포넌트 소개

고차 컴포넌트(HOC, Higher Order Component)는 컴포넌트 자체의 로직을 재사용하기 위한 방법이다. 사용자 정의 훅은 리액트 훅을 기반으로 하므로 리액트에서만 사용할 수 있는 기술이지만 고차 컴포넌트는 고차 함수(Higher Order Function)의 일종으로, 자바스크립트의 일급 객체, 함수의 특징을 이용하므로 굳이 리액트가 아니더라도 자바스크립트 환경에서 널리 쓰일 수 있다.
리액트에서는 이러한 고차 컴포넌트 기법으로 다양한 최적화나 중복 로직 관리를 할 수 있다. 고차 컴포넌트의 사전적 정의는 “컴포넌트를 인수로 받거나 결과로 반환하는 컴포넌트”이다.

고차 컴포넌트 만들기 (1)

여러 컴포넌트에게 동일한 스타일을 적용하고 싶다고 가정하자. 로컬 스코프에 style 객체를 직접 만드는 대신, HOC가 style 객체를 만들어 컴포넌트에게 전달하도록 한다.

function withStyles(Component) {
  return props => {
    const style = { padding: '0.2rem', margin: '1rem' }
    return <Component style={style} {...props} />
  }
}

const Button = () = <button>Click me!</button>
const Text = () => <p>Hello World!</p>

const StyledButton = withStyles(Button)
const StyledText = withStyles(Text)

이 패턴에서는 기존 컴포넌트를 입력받아, 변경된(혹은 추가된) 기능을 가진 새로운 컴포넌트를 반환한다. 다시 말해, withStyles는 HOC로서, 기존 컴포넌트를 입력받아 스타일이 추가된 새 컴포넌트를 반환한다.
사용자 정의 훅이 use로 시작하는 이름을 사용했다면 리액트의 고차 컴포넌트도 마찬가지로 with로 시작하는 이름을 사용해야 한다. ESLint 규칙 등으로 강제되는 사항은 아니지만 리액트 라우터의 withRouter와 같이 리액트 커뮤니티에 널리 퍼진 일종의 관습이다.

고차 컴포넌트 만들기 (2)

데이터를 받아오는 중에는 “로딩 중…” 이라는 메시지를 화면에 보여주고 싶다. DogImages에 직접 기능을 구현하는 대신 고차 컴포넌트 패턴을 활용할 것이다.

import React, { useEffect, useState } from "react";

// withLoader는 Element(컴포넌트)와 url(데이터를 불러올 주소)을 인자로 받고,
// 데이터 로딩 로직을 담은 새로운 컴포넌트를 반환하는 HOC이다.
export default function withLoader(Element, url) {
  return (props) => {
    const [data, setData] = useState(null);

    useEffect(() => {
      async function getData() {
        const res = await fetch(url);
        const data = await res.json();
        setData(data);
      }

      getData();
    }, [url]);

    // 데이터가 아직 로딩 중이라면 로딩 메시지를 표시
    if (!data) {
      return <div>Loading...</div>;
    }

    // 데이터 로딩이 완료되면, 원래의 Element 컴포넌트에 data를 props로 넘겨 렌더링
    return <Element {...props} data={data} />;
  };
}

특정 URL로부터 데이터를 로드한 뒤, 로딩 상태를 관리하고, 로드된 데이터를 원하는 컴포넌트에 주입하는 역할을 수행한다.
이를 통해 데이터 페칭 로직을 별도의 고차 컴포넌트로 분리하고, 실제 UI를 구현하는 컴포넌트에서는 데이터 처리 로직 없이 화면 렌더링에만 집중할 수 있게 된다.

끝!

8장 JSX에서 TSX로

Sun, 03 Mar 2024 00:00:00 +0900

리액트 애플리케이션을 타입스크립트로 작성할 때 @types/react 패키지에 정의된 리액트 내장 타입을 사용해본 경험이 있을 것이다. 리액트 내장 타입 중에는 역할이 명확한 것도 있지만, 역할이 비슷해 보이는 타입도 존재하기 때문에 어떤 것을 사용해야 할지 헷갈릴 때가 있 다. 이 절에서는 헷갈릴 수 있는 대표적인 리액트 컴포넌트 타입을 살펴보면서 상황에 따라 어떤 것을 사용하면 좋을지 그리고 사용할 때의 유의점은 무엇인지 알아보자.

8.2 함수 컴포넌트 타입

interface WelcomeProps {
    name： string；
}

class Welcome extends React.Component<WelcomeProps> {
/* ... 생략 */
}

// 함수 선언을 사용한 방식
function Welcome (props： WelcomeProps)： JSX.Element {}

// 함수 표현식을 사용한 방식 - React.FC 사용
const Welcome： React.FC<WelcomeProps> = ({ name }) => {}；

// 함수 표현식을 사용한 방식 - React.VFC 사용
const Welcome： React.VFC<WelcomeProps> = ({ name }) => {};

// 함수 표현식을 사용한 방식 - JSX.Element를 반환 타입으로 지정
const Welcome = ({ name }： WelcomeProps)： JSX.Element => {};

type FC<P = {}> = FunctionComponent<P>;

interface FunctionConiponent<P = {}> {
    // props에 children을 추가
    (props： PropsWithChildren<P>, context?： any)： ReactElementony, any> | null;
    propTypes?: WeakValiclationMap<P> | undefined;
    contextTypes?： ValidationMap<any> | undefined;
    defaultProps?: Partial<P> | undefined;
    displayName?： string | undefined;
}

type VFC<P = {}> = VoidFunctionComponent<P>;

interface VoidFunctionComponent<P = {}> {
    // children 없음
    (props： P, context?; any): ReactElementony, any> | null;
    propTypes?: WeakValidationMap<P> | undefined;
    contextTypes?： ValidationMap<any> | undefined;
    defaultprops?： Partial<P> | undefined;
    displayName?： string | undefined;
}

함수 표현식을 사용하여 함수 컴포넌트를 선언할 때 가장 많이 볼 수 있는 형태는 React.FC 혹은 React.VFC로 타입을 지정하는 것이다. FC는 Functioncomponent의 약자로 React.FC와 React.VFC는 리액트에서 함수 컴포넌트의 타입 지정을 위해 제공되는 타입이다.
먼저 React.FC가등장하고 이후@types/react 16.9.4버전에서 React.VFC 타입이 추가되었다. 둘 사이에는 children이라는 타입을 허용하는지 아닌지에 따른 차이를 보인다.
하지만 리액트 V18로 넘어오면서 React.VFC가삭제되고 React.FC에서 children이 사라졌다. 그래서 앞으로는 React.VFC 대신 React.FC 또는 props 타입 - 반환 타입을 직접 지정하는 형태로 타이핑해줘야 한다.

8.3 Children props 타입 지정

type PropsWithChildren<P> = P & { children?： ReactNode | undefined };
type ReactNode = ReactElement | string | number | boolean | null | undefined | ReactNode[];

ReactNode는 TypeScript에서 React 컴포넌트가 렌더링할 수 있는 모든 유형의 값을 표현하는 타입이다. 이는 React 컴포넌트의 반환값이 될 수 있는 다양한 값들을 포괄적으로 나타내며, 자식 요소로 무엇이든 받을 수 있게 해준다.

가장 보편적인 children 타입은 ReactNode

undefined가 된다. ReactNode는 ReactElement 외에도 boolean, number 등 여러 타입을 포함하고 있는 타입으로, 더 구체적으로 타이핑하는 용도에는 적합하지 않다. 예를 들어 특정 문자열만 허용하고 싶을 때는 children에 대해 추가로 타이핑해줘야 한다.

// example 1
type WelcomeProps = {
    children: "천생연분" | "더 귀한 분" | "귀한 분" | "고마운 분";
}；
// example 2
type WelcomeProps = {
    children: string;
}；
// example 3
type WelcomeProps = {
    children： ReactElement;
};

8.4 render 메서드와 함수 컴포넌트의 반환 타입 - React.ReactElement vs JSX.Element vs ReactReactNode

React.ReactElement, JSX.Element. React.ReactNode 타입은 쉽게 헷갈릴 수 있기 때문에 자세히 살펴보자. 함수 컴포넌트의 반환 타입인 ReactElement는 아래와 같이 정의된다.
ReactElement는 React가 JSX 코드를 변환한 후 반환하는 JavaScript 객체다. 가상 DOM에서 사용되며, 실제 DOM과는 분리된 중간 데이터 구조다.

interface ReactElement<P = any,
    T extends string | JSXElementConstructor<any> =
    | string
    | JSXElementConstructor<any>
> {
    type： T;
    props： P;
    key: Key | null;
}

React.createElement를 호출하는 형태의 구문으로 변환하면 React.createElement의 반환 타입은 ReactElement이다. 리액트는 실제 DOM이 아니라 가상의 DOM을 기반으로 렌더링하는데 가상 DOM의 엘리먼트는 ReactElement 형태로 저장된다. 즉, ReactElement 타입은 리액트 컴포넌트를 객체 형태로 저장하기 위한 포맷이다.

// JSX
const element = <div className="container">Hello, world!</div>;
// React.createElement 함수로 반환된 ReactElement
const element = {
  type: 'div',                        // 요소 타입 (HTML 태그 'div')
  props: {                            // 요소에 전달된 속성
    className: 'container',
    children: 'Hello, world!',
  },
  key: null,                          // 리스트에서 사용되는 고유한 키 (현재는 null)
  ref: null,                          // 참조 (ref) 값 (현재는 null)
};

declare global {
    namespace JSX {
        interface Element extends React.ReactElement<any, any> {}
    }
}

JSX.Element 타입은 앞의 코드를 보면 알 수 있다시피 리액트의 ReactElement를 확장하고 있는 타입이며, 글로벌 네임스페이스에 정의되어 있어 외부 라이브러리에서 컴포넌트 타입을 재정의 할 수 있는 유연성을 제공한다.
이러한 특성으로 인해 컴포넌트 타입을 재정의하거나 변경하는것이 용이해진다. React.Node는 다음과 같이 타입이 정의되어 있다.

type ReactText = string | number;
type ReactChild = ReactElement | ReactText;
type ReactFragment = {} | Iterable<ReactNode>;
type ReactNode =
    | ReactChild
    | ReactFragment
    | ReactPortal
    | boolean
    | null
    | undefined;

단순히 ReactElement 외에도 boolean, string, number 등의 여러 타입을 포함하고 있다. ReactNode, JSX.Element, ReactElement 사이의 포함관계를 정리하면 아래 그림과 같다.

8.5 ReactElement, ReactNode, JSX.Element 활용하기

ReactElement, ReactNode, JSX.Element는 모두 리액트의 요소를 나타내는 타입이다. 리액트의 요소를 나타내는 데 왜 이렇게 많은 타입이 존재하는지 의문이 생길 수도 있을 것이다.
이 절에서는 이 3가지 타입의 차이점과 어떤 상황에서 어떤 타입을 사용해야 더 좋은 코드를 작성할 수 있는지를 소개한다.

8.5.1 ReactElement

리액트 엘리먼트를 생성하는 createElement 메서드에 대해 들어본 적이 았을 것이다. 리액트를 사용하면서 JSX라는 자바스크립트를 확장한 문법을 자주 접했을 텐데 JSX가 createElement 메서드를 호출하기 위한 문법이다.
JSX?
- JSX는 자바스크립트의 확장 문법으로 리액트에서 UI를 표현하는 데 사용된다. HTML과 유사한 문법을 제공하여 리액트 사용자에게 렌더링 로직（마크업）을 쉽게 만들 수 있게 해주고, 컴포넌트 구조와 계충 구조를 편리하게 표현할 수 았도록 해준다.
즉, JSX는 리액트 엘리먼트를 생성하기 위한 문법이며 트랜스파일러는 JSX 문법을 createElement 메서드 호출문으로 변환하여 아래와 같이 리액트 엘리먼트를 생성한다.

const element = React.createElement(
    "hl",
    { ClassName： "greeting" },
    "Hello, world!"
);

// 주의: 다음 구조는 단순화되었다
const element = {
        type： "hl",
    props： {
        className： "greeting",
        children： "Hello, world!",
    },
};

declare global {
    namespace JSX {
        interface Element extends React.ReactElement<any, any> {
            // ...
        }
        // ... 
    }
}

리액트는 이런 식으로 만들어진 리액트 엘리먼트 객체를 읽어서 DOM을 구성한다. 리액트에는 여러 개의 createElement 오버라이딩 메서드가 존재하는데, 이 메서드들이 반환하는 타입은 ReactElement 타입을 기반으로 한다.
정리하면 ReactElement 타입은 JSX의 createElement 메서드 호출로 생성된 리액트 엘리먼트를 나타내는 타입이라고 볼 수 있다.

8.5.2 ReactNode

R은actChild 타입은 ReactElement string number로 정의되어 ReactElement보다는 좀 더 넓은 범위를 갖고 있다.
ReactNode는 앞에서 설명한 ReactChild 외에도 boolean, null, undefined 등 훨씬 넓은 범주의 타입을 포함한다. 즉, ReactNode는 리액트의 render 함수가 반환할 수 있는 모든 형태를 담고 있다고 볼 수 있다

8.5.3 JSX.Element

JSX. Element는 ReactElement의 제네릭으로 props와 타입 필드에 대해 any 타입을 가지도록 확장하고 있다. 즉, JSX.Element는 ReactElement의 특정 타입으로 props와 타입 필드를 any로 가지는 타입이라는 것을 알 수 있다.

8.6 사용 예시

이렇게 ReactElement, ReactNode, JSX.Element 3가지 타입에 대해 자세히 살펴보았는데, 이들의 공통점은 모두 리액트에서 제공하는 컴포넌트를 나타낸다는 것이다. 그러면 어떤 상황에 어떤 타입을 사용하는 게 좋을까? 예시를 통해 알아보자.

8.6.1 ReactNode

type ReactNode = ReactElement | string | number | boolean | null | undefined | ReactNode[];

ReactNode 타입은 앞서 언급한 대로 리액트의 render 함수가 반환할 수 있는 모든 형태를 담고 있기 때문에 리액트 컴포넌트가 가질 수 있는 모든 타입을 의미한다.
리액트의 Composition(합성) 모델을 활용하기 위해 prop으로 children을 많이 사용해봤을 것이다. children을 포함하는 props 타입을 선언하면 다음과 같다.

interface MyComponentProps {
    children?： React.ReactNode;
    // ...
}

JSX 형태의 문법을 때로는 string, number, null, undefined같이 어떤 타입이든 children prop으로 지정할 수 있게 하고 싶다면 ReactNode 타입으로 children을 선언하면 된다.

8.6.2 JSX.Element

JSX.Element는 앞서 언급한 대로 props와 타입 필드가 any 타입인 리액트 엘리먼트를 나타낸다. 이러한 특성 때문에 리액트 엘리먼트를 prop으로 전달받아 render props 패턴으로 컴포넌트를 구현할 때 유용하게 활용할 수 있다. 다음 코드를 살펴보자.

interface Props {
    icon： JSX.Element;
}

const Item = ({ icon }: Props) => {
    // prop으로 받은 컴포넌트의 props에 접근할 수 있다
    const iconsize = icon.props.size;
    return (<li>{icon}</ll>);
};

// icon prop에는 JSX.Element 타입을 가진 요소만 할당할 수 있다
const App = 0 => {
    return <Item icon={<Icon size={14} />} />
}；

icon prop을 JSX.Element 타입으로 선언함으로써 해당 prop에는 JSX 문법만 삽입할 수 있다. 또한 icon.props에 접근하여 prop으로 넘겨받은 컴포넌트의 상세한 데이터를 가져올 수 있다.

8.6.3 ReactElement

앞서 살펴본 JSX.Element 예시를 확장하여 추론 관점에서 더 유용하게 활용할 수 있는 방법은 JSX.Element 대신에 ReactElement을 사용하는 것이다.
이때 원하는 컴포넌트의 props를 ReactElement의 제네릭으로 지정해줄 수 있다. 만약 JSX.EIement가 ReactElement의 props 타입으로 any가 지정되었다면, ReactElement 타입을 활용하여 제네릭에 직접 해당 컴포넌트의 props 타입을 명시해준다.

interface IconProps {
    size： number；
}
interface Props {
    // ReactElement의 props 타입으로 IconProps 타입 지정
    icon： React.ReactEleinent<IconProps>;
}

const Item = ({ icon }： Props) => {
    // icon prop으로 받은 컴포넌트의 props에 접근하면, props의 목록이 추론된다
    const iconsize = icon.props.size;
    return <li>{icon}</li>;
};

8.7 리액트에서 기본 HTML 요소 타입 활욤하기

리액트를 사용하면서 HTML button 태그를 확장한 Button 컴포넌트를 만들어본 경험이 있을 것이다.

 const SquareButton = () => <button>정사각형 버튼</button>;

이렇게 새롭게 만든 Button 컴포넌트는 기존 HTML button과 같은 역할을 하면서도 새로운 기능이나 UI가 추가된 형태이다. 기존의 button 태그가 클릭 이벤트를 등록하기 위한 onClick 이벤트 핸들러를 지원하는 것처럼, 새롭게 만든 Button 컴포넌트도 onClick 이벤트 핸들러를 지원해야만 일관성과 편의성을 모두 챙길 수 있다. 이 절에서는 기존 HTML 태그의 속성 타입을 활용하여 타입을 지정하는 방법에 대해 알아보자.

8.7.1 DetailedHTMLProps와 ComponentWithoutRef

HTML 태그의 속성 타입을 활용하는 대표적인 2가지 방법은 리액트의 DetaiiedHTMLProps와 ComponentPropsWithoutRef 타입을 활용하는 것이다.
먼저 React.DetaiiedHTMLProps를 활용하는 경우에는 아래와 같이 쉽게 HTML 태그 속성과 호환되는 타입을 선언할 수 있다

type NativeButtonProps =React.DetailedHTMLProps<
    React.ButtonHTMLAttributes<HTMLButtonElement>,
    HTMLButtonElement
>;

// ButtonProps의 onClick 타입은 실제 HTML button 태그의 onClick 이벤트 핸들러 타입과 동일
type ButtonProps = {
    onClick?： NativeButtonProps["onClick"];
}；

그리고 React. ComponentPropsWithoutRef 타입은 아래와 같이 활용할 수 있다.

type NativeButtonType = React.ComponentPropsWithoutRef<"button">;
// 마찬가지로 리액트의 button onClick 이벤트 핸들러에 대한 타입이 할당
type ButtonProps = {
    onClick?： NativeButtonType["onClick"];
}；

끝!

5장 타입 활용하기

Thu, 15 Feb 2024 00:00:00 +0900

우아한형제들의 실무 코드 예시를 살펴보면서 정확한 타이핑을 하지 못해 발생하는 문제를 타입스크립트의 다양한 기법과 유틸리티 타입을 활용해 해결해본다. 5장의 내용은 타입스크립트의 기본적인 문법과 리액트 및 react-query의 코드를 포함하고 있다. 하지만 기본적인 관련 지식만 알고 있다면 읽는 데 무리가 없을것이다.

5.1 조건부 타입

프로그래밍에서는 다양한 상황을 다루기 위해 조건문을 많이 활용한다. 타입도 마찬가지로 조건에 따라 다른 타입을 반환해야 할 때가 있다. 타입스크립트에서는 조건부 타입을 사용해 조건에 따라 출력 타입을 다르게 도출할 수 있다. 타입스크립트의 조건부 타입은 자바스크립트의 삼항 연산자와 동일하게 Condition ? A : B 형태를 가지는데 A는 Condition이 true일 때 도출되는 타입이고, B는 false일 때 도출되는 타입이다.
조건부 타입을 활용하면 중복되는 타입 코드를 제거하고 상황에 따라 적절한 타입을 얻을 수 있기 때문에 더욱 정확한 타입 추론을 할 수 있게 된다. 이 절에서는 extends, infer, never 등을 활용해 원하는 타입을 만들어보며 어떤 상황에서 조건부 타입이 필요한지 알아본다. 또한 조건부 타입을 적용했을 때 어떤 장점을 얻을 수 있는지 알아보자.

5.1.1 extend와 제네릭을 활용한 조건부 타입

extends 키워드는 타입스크립트에서 다양한 상황에서 활용된다. 타입을 확장할 때와 타입을 조건부로 설정할 때 사용되며, 제네릭 타입에서는 한정자 역할로도 사용된다. extends를 사용한 조건부 타입의 활용 예시를 보기 전에 간단하게 extends가 어떻게 조건부 타입으로 사용되는지 알아보자.

T extends U ? X : Y

조건부 타입에서 extends를 사용할 때는 자바스크립트 삼항 연산자와 함께 쓴다. 이 표현은 타입 T를 U에 할당할 수 있으면 X 타입, 아니 면 Y 타입으로 결정됨을 의미한다. 간단한 예시를 통해 좀 더 면밀히 살펴보자.

interface Bank {
financialCode: string;
companyName： string;
name： string;
fuIlName; string;
}

interface Card {
financialCode： string;
companyName： string;
name: string;
appCardType?: string;
}

type PayMethod<T> = T extends "card" ? Card : Bank;
type CardPayMethodType = PayMethod<"card">;
type BankPayMethodType = PayMethod<"bank">;
// extends 키워드를 일반적으로 문자열 리터럴과 함께 사용하지는 않지만. 예시에서는 extends의 활용법을 설명하기 위해 문자열 리터럴에 사용되고 있다.

PayMethod 타입은 제네릭 타입으로 extends를 사용한 조건부 타입이다. 제네릭 매개변수에 “card”가 들어오면 Card 타입, 그 외의 값이 들어오면 Account 타입으로 결정된다. PayMethod를 사용해서 CardPayMethodType, BankPayMethodType을 도출할 수 있다. 이제 어떤 상황에서 조건부 타입을 효율적으로 사용할 수 있는지 알아보자.

5.1.2 조건부 타입을 사용하지 않았을 때의 문제점

조건부 타입을 사용하기 전에 어떤 이슈가 있었는지 알아보자. 아래는 react-query（리액트 쿼리）를 활용한 예시다. 계좌, 카드, 앱 카드 등 3가지 결제 수단 정보를 가져오는API가 있으며, API의 엔드포인트는 다음과 같다고 해보자.

계좌 정보 엔드포인트: www.baemin .com/baeminpay/.../bank
카드 정보 엔드포인트: www.baemin.com/baeminpay/.../card
앱 카드 정보 엔드포인트: www.baemin.com/baeminpay/.../appcard

각 API는 계좌, 카드, 앱카드의 결제 수단 정보를 배열 형태로 반환한다. 3가지 API의 엔드포인트가 비슷하기 때문에 서버 응답을 처리하는 공통 함수를 생성하고, 해당 함수에 타입을 전달하여 타입별로 처리 로직을 구현할 것이다.
함수를 구현하기 앞서 이전에 사용되는 타입들을 서버에서 받아오는 타입, UI 관련 타입 그리고 결제 수단별 특성에 따라 구분하여 살펴보자.
- PayMethodBaseFromRes: 서버에서 받아오는 결제 수단 기본 타입으로 은행과 카드에 모두 들어가 있다
- Bank, Card: 은행과 카드 각각에 맞는 결제 수단 타입이다. 결제 수단 기본 타입인 PayMethodBaseFromRes를 상속받아 구현한다.
- PayMethodlnterface： 프론트에서 관리하는 결제 수단 관련 데이터로 UI를 구현하는 데 사용되는 타입이다.
- PayMethodInfo<T extends Bank | Card> :
  - 최종적인 은행, 카드 결제 수단 타입이다. 프론트에서 추가되는 UI 데이터 타입과 제네릭으로 받아오는 Bank 또는 Card를 합성한다.
  - extends를 제네릭에서 한정자로 사용하여 Bank 또는 Card를 포함하지 않는 타입은 제네릭으로 넘겨주지 못하게 방어한다.
  - BankPayMethodInfo = PayMethodlnterface & Bank처럼 카드와 은행의 타입을 만들어줄 수 있지만 제네릭을 활용해서 중복된 코드률 제거한다.

interface PayMethodBaseFromRes {
    financialCode： string;
    name： string;
}
interface Bank extends PayMethodBaseFromRes {
    fullName： string;
}
interface Card extends PayMethodBaseFromRes {
    appCardType?: string;
}
type PayMethodInfo<T extends Bank | Card> = T & PayMethodlnterface;
type PayMethodlnterface = {
    companyName： string;
    // ...
}

이제 react-query의 useQuery를 사용하여 구현한 커스텀 훅인 useGetRegisteredList 함수를 살펴보자.
useGetRegisteredList 함수는 useQuery의 반환 값을 돌려준다. useCommonQuery<T>는 useQuery를 한 번 래핑해서 사용하고 있는 함수로 useQuery의 반환 data를 T타입으로 반환한다. fetcherFactory는 axios를 래핑해주는 함수이며, 서버에서 데이터를 받아온 후 onSuccess 콜백 함수를 거친 결괏값을 반환한다.

type PayMethodType = PayMethodInfo<Card> | PayMethodInfo<Bank>;
export const useGetRegisteredList = (
type： "card" | "appcard" | "bank"
): UseQueryResult<PayMethodType[]> => {
    const url = `baeminpay/codes/${type === "appcard" ? "card" : type}`;

    const fetcher = fetcherFactory<PayMethodType[]>({
        onSuccess： (res) => {
            //  res는 PayMethodType[] 타입으로, 이는 PayMethodInfo<Card>[] 또는 PayMethodInfo<Bank>[]의 배열
            const usablePocketList =
            res?.filter(
            (pocket： PocketInfo<Card> | PocketInfo<Bank>) =>
            pocket?.useType === "USE"
            ) ?? []；
            // res 배열에서 PocketInfo<Card> 또는 PocketInfo<Bank> 타입의 요소 중 useType이 "USE"인 요소만 남기고 usablePocketList 배열로 반환
            return usablePocketList;
        },
    })；

    const result = useCommonQuery<PayMethodType[]>(url, undefined, fetcher);
    return result;
};

즉, useGetRegisteredList 함수는 타입으로 “card”, “appcard”, “bank”를 받아서 해당 결제 수단의 결제 수단 정보 리스트를 반환하는 함수이다. 함수 useGetRegisteredList가 반환하는 데이터는 UseQueryResult<PayMethodType[]>이다. PayMethodType은 PayMethodInfo<Card>와 PayMethodInfo<Bank>의 유니온 타입이므로, 이 함수가 반환하는 데이터는 PayMethodInfo<Card>와 PayMethodInfo <Bank>의 배열이다. 그러나 필터링을 통해 반환된 데이터는 PocketInfo<Card> | PocketInfo<Bank> 타입의 요소를 포함하게 된다.
따라서, 최종적으로 useGetRegisteredList 함수가 반환하는 데이터의 타입은 PocketInfo[] | PocketInfo[] 요소를 포함할 수 있는 UseQueryResult<PayMethodType[]>이다.
인자로 넣는 타입에 알맞은 타입을 반환하고 싶지만, 타입설정이 유니온으로만 되어있기 때문에 타입스크립트는 해당 타입에 맞는 Data 타입을 추론할 수없다. 이처럼 인자에 따라 반환되는 타입을 다르게 설정하고 싶다면 extends를 사용한 조건부 타입을 활용하면 된다.

5.1.3 extends 조건부 타입을 활용하여 개선하기

useGetRegisteredList 함수의 반환 Data는 인자 타입에 따라 정해져 있다. 타입으로 “card” 또는 “appcard”를 받으면 카드 결제 수단 정보 타입인 Pocketlnfo를 반환하고, "bank"를 받는다면 Pocketlnfo를 반환한다.
- type: “card” | “appcard => PocketInfo
- type: “bank” => PocketInfo
이러한 상황에서 조건부 타입을 활용하면 하나의 API 함수에서 타입에 따른 정확한 반환 타입을 추론하게 만들 수 있다.
조건부 타입을 사용해서 PayMethodInfo<Card> | PayMethodInfo<Bank> 타입이었던 PayMethodType 타입을 개선해보자.

type PayMethodType<T extends "card" | "appcard" | "bank"> = T extends
| "card"
| "appcard"
? Card
: Bank;

PayMethodType의 제네릭으로 받은 값이 “card” 또는 “appcard”일 때는 PayMethodlnfo<Card> 타입을, 아닐 때는 PayMethodInfo<Bank> 타입을 반환하도록 수정했다. 또한 결제 수단 타입에는 “card”, “appcard”. “bank”만 들어올 수 있기 때문에 extends를 한정자로 활용해서 제네릭에 넘 겨오는 값을 제한하도록 했다.
새롭게 정의한 PayMethodType 타입에 제네릭 값을 넣어주기 위해서는 useGetRegisteredList 함수 인자의 타입을 넣어줘야 한다. useGetRegisteredList 인자 타입을 제네릭으로 받으면서 extends를 활용하여 “card”, “appcard”, “bank” 이외에 다른 값이 인자로 들어올 경우에는 타입 에러를 반환하도록 구현해보자.

export const useGetRegisteredList = <T extends "card" | "appcard" | "bank">(
    type:T
): UseQueryResult<PayMethodType<T>[]> => {
    const url = `baeminpay/codes/${type === "appcard" ? "card" : type}`;

    const fetcher = fetcherFactory<PayMethodType<T>>({
        // PayMethodType<T> 타입은 T가 "card" 또는 "appcard"일 때 PayMethodInfo<Card>, T가 "bank"일 때 PayMethodInfo<Bank>를 반환
        onSuccess： (res) => {
            const usablePocketList =
            res?.filter(
            (pocket： PocketInfo<Card> | PocketInfo<Bank>) =>
            pocket?.useType === "USE"
            ) ?? []；
            return usablePocketList;
            // 이 필터링된 결과는 PayMethodType<T>[] 타입이다. 즉, T가 "card" 또는 "appcard"인 경우 PayMethodInfo<Card>[], T가 "bank"인 경우 PayMethodInfo<Bank>[]가 반환된다.
        },
    })；

    const result = useCommonQuery<PayMethodType[]>(url, undefined, fetcher);
    return result;
};

조건부 타입을 활용하여 PayMethodType이 사용자가 인자에 넣는 타입 값에 맞는 타입만을 반환하도록 구현했다. 이제 인자로 “card” 또는 “appcard”를 넣는다면 PocketInfo를 반환하고, "bank"를 넣는다면 PocketInfo를 반환한다.
지금까지 타입 확장을 제외한 타입에서 다양한 extends 활용 사례를 살펴봤다. extends 활용 예시는 크게 다음과 같이 정리할 수 있다.
- 제네릭과 extends를 함께 사용해 제네릭으로 받는 타입을 제한했다. 따라서 개발자는 잘못된 값을 넘길 수 없기 때문에 휴먼 에러를 방지할수 있다.
- extends를 활용해 조건부 타입을 설정했다. 조건부 타입을 사용해서 반환 값을 사용자가 원하는 값으로 구체화할수 얐었다. 이에 따라불필요한 타입 가드, 타입 단언 등을 방지할수 있다.

5.1.4 infer를 활용해서 타입 추론하기

extends를 사용할 때 infer 키워드를 사용할 수 있다. infer는 ‘추론하다’라는 의미를 지니고 있는데 타입스크립트에서도 단어 의미처럼 타입을 추론하는 역할을 한다. 삼항 연산자를 사용한 조건문의 형태를 가지는데, extends로 조건을 서술하고 infer로 타입을 추론하는 방식을 취한다.
infer를 활용한 예시를 살펴보자.

 type UnpackPromise<T> = T extends Promise<infer K>[] ? K : any;

UnpackPromise 타입은 제네릭으로 T를 받아 T가 Promise로 래핑된 경우라면 K를 반환하고,그렇지 않은 경우에는 any를 반환한다. Promise<infer K>는 Promise의 반환 값을 추론해 해당 값의 타입을 K로 한다는 의미이다.
이번에는 배민 라이더를 관리하는 라이더 어드민 서비스에서 사용하는 타입으로 infer를 살펴보자.

interface RouteBase {
    name: string;
    path: string;
    component： ComponentType;
}

export interface Routeitem {
    name： string;
    path： string;
    component?: ComponentType;
    pages?： RouteBase[];
}

export const routes： Routeitem[] = [
    {
        name： "기기 내역 관리",
        path： "/device-history",
        component： DeviceHistoryPage,
    },
    {
        name： "헬멧 인증 관리",
        path： "/helmet-certification",
        component: HelmetCertificationPag,
    },
    //...
];

RouteBase와 Routeitem은 라이더 어드민에서 라우팅을 위해 사용하는 타입이다. routes같이 배열 형태로 사용되며, 권한 API로 반환된 사용자 권한과 name을 비교하여 인가되지 않은 사용자의 접근을 방지한다. Routeitem의 name은 pages가 있을 때는 단순히 이름의 역할만하며 그렇지 않을 때는 사용자 권한과 비교한다.

export interface SubMenu {
    name： string;
    path: string;
}

export interface MainMenu {
    name： string;
    path?： string;
    subMenus?： SubMenu[]；
}

export type Menultem = MainMenu | SubMenu;
export const menuList: MenuItem[] = [
    {
        name： "계정 관리",
        subMenus: [
                {
                name： "기기 내역 관리",
                path： "/device-history",
            },
            {
                name： "헬멧 인증 관리",
                path： "/helmet-certification",
            },
        ],
    },
    {
        name： "운행 관리",
        path： "/operation",
    },
//...
];

MainMenu와 SubMenu는 메뉴 리스트에서 사용하는 타입으로 권한 API를 통해 반환된 사용자 권한과 name을 비교하여 사용자가 접근할 수 있는 메뉴만 렌더링한다. MainMenu의 name은 subMenus를 가지고 있을 때 단순히 이름의 역할만 하며, 그렇지 않을 때는 권한으로 간주된다.
menuList에는 MainMenu와 SubMenu 타입이 올 수 있기 때문에 유니온 타입인 Menuitem를 정의하여 사용하고 있다. 따라서 menuList에서 subMenus가 없는 MainMenu의 name(권한)과 subMenus에서 쓰이는 name(권한), route name(권한)에 동일한 문자열만 입력해야 한다는 제약이 존재한다.
하지만 앞서 말한 바와 같이 name은 string 타입으로 정의되어 있기 때문에 routes와 menuList에서 subMenus의 기기 내역 관리처럼 서로 다른 값이 입력되어도 컴파일타임에서 에러가 발생하지 않는다. 또한 런타임에서도 인가되지 않음을 안내하는 페이지를 보여주거나 메뉴 리스트를 렌더링하지 않는 정도에 그치기 때문에, 존재하지 않는 권한에 대한 문제로 잘못인지할수있다.

vtype PermissionNames = "기기 정보 관리" | "안전모 인증 관리" | "운행 여부 조회"; // ...

이를 개선하기 위해 PermissionNames처럼 별도 타입을 선언하여 name을 관리하는 방법도 있지만, 권한 검사가 필요 없는 subMenus나 pages가 존재하는 name은 따로 처리해야 한다.
이때 infer와 불변 객체 (as const)를 활용해서 menuList 또는 routes의 값을 추출하여 타입으로 정의하는 식으로 개선할 수 있다. 여기에서는 menuList 값을 추출하는 예시를 소개한다.

export interface MainMenu {
    // ...
    subMenus?： ReadonlyArray<SubMenu>;
}

export const menuList = [
// ...
] as const;

interface RouteBase {
    name： PermissionNames;
    path： string;
    component： ComponentType;
}

// Routeitem은 두 가지 형태로 가질 수 있는 유니온 타입
export type Routeitem =
| {
    name： string;
    path： string;
    component?： ComponentType;
    pages： RouteBase[];
}
| {
    name： PermissionNames;
    path: string;
    component?: ComponentType;
};

먼저 subMenus의 타입을 ReadonlyArray로 변경하고, menuList에 as const 키워드를 추가하여 불변 객체로 정의한다. Route 관련 타입의 name은 menuList의 name에서 추출한 타입인 PermissionNames만 올 수 있도록 변경한다.

type UnpackMenuNames<T extends ReadonlyArray<MenuItem>> = T extends
ReadonlyArray<infer U>
    ? U extends MainMenu
        ? U["subMenus"] extends infer V
            ? V extends ReadonlyArray<SubMenu>
                ? UnpackMenuNames<V>
                : U["name"]
            : never
        : U extends SubMenu
    ? U["name"]
    : never
: never;

자세히 위 코드를 이해해보자.
T extends ReadonlyArray<infer U>
- T가 ReadonlyArray 타입인 경우, U는 배열의 요소 타입
- 예를 들어, T가 ReadonlyArray<MainMenu | SubMenu>라면 U는 MainMenu | SubMenu 타입
U extends MainMenu
- U가 MainMenu 타입인 경우를 처리
- MainMenu는 선택적 subMenus 속성을 포함할 수 있음
U[“subMenus”] extends infer V
- U의 subMenus 속성을 V 타입으로 추론
- V는 ReadonlyArray<SubMenu> 타입
V extends ReadonlyArray<SubMenu>
- V가 ReadonlyArray<SubMenu> 타입인 경우를 처리
- V가 ReadonlyArray<SubMenu>라면 UnpackMenuNames<V>를 재귀적으로 호출
- 재귀 호출을 통해 SubMenu의 이름을 추출
: U[“name”]
- V가 ReadonlyArray<SubMenu>가 아닌 경우, U[“name”]을 반환
- 이는 MainMenu의 이름을 의미
구체적인 예시를 살펴보자.

const mainMenu: MainMenu = {
    name: "MainMenu1",
    subMenus: [
        { name: "SubMenu1" },
        { name: "SubMenu2" }
    ]
};

type MenuNames = UnpackMenuNames<readonly [typeof mainMenu]>;
// MenuNames 타입은 "SubMenu1" | "SubMenu2"

T는 readonly [MainMenu] 타입
U는 MainMenu 타입
U[“subMenus”]는 ReadonlyArray 타입
따라서 V는 ReadonlyArray 타입으로 추론
재귀 호출
- UnpackMenuNames는 UnpackMenuNames<ReadonlyArray>
- 이제 T는 ReadonlyArray 타입
- 이로 인해 U는 SubMenu 타입
- U extends SubMenu가 성립
- U[“name”]가 추출
이 과정을 통해 UnpackMenuNames는 MainMenu 객체의 subMenus 배열에서 모든 SubMenu의 이름을 추출
PermissionNames는 menuList에서 권한으로 유효한 값만 추출하여 배열로 반환하는 타입임 을 확인할 수 있다.

5.2 템플릿 리터럴 타입 활용하기

타입스크립트에서는 유니온 타입을 사용하여 변수 타입을 특정 문자열로 지정할 수 있다.

 type HeaderTag = "h1" | "h2" | "h3" | "h4" | "h5"；

이 기능을 사용하면 컴파일타임의 변수에 할당되는 타입을 특정 문자열로 정확하게 검사하여 휴먼 에러를 방지할 수 있고, 자동 완성 기능을 통해 개발 생산성을높일 수 있다.
타입스크립트 4.1부터 이를 확장하는 방법인 템플릿 리터 럴 타입(Template Literal Types)을 지원하기 시작했다. 템플릿 리터럴 타입은 자바스크립트의 템플릿 리터럴 문법을 사용해 특정 문자열에 대한 타입을 선언할 수 있는 기능이다. 앞 예시의 HeaderTag 타입은 템플릿 리터럴 타입을 사용하여 다음과 같이 선언할 수 있다.

type HeadingNumber = 1 | 2 | 3 | 4 | 5;
type HeaderTag = `h${HeadingNuinber}`;

수평 또는 수직 방향을 표현하는 Direction 타입을 다음과 같이 표현할수 있다.

type Direction =
    | "top"
    | "topLeft"
    | "topRight"
    | "bottoni"
    | "bottomLeft"
    | "bottomRight";

이 코드의 Direction 타입은 “top”, “bottom”, “left”, “right”가 합쳐진 문자열로 선언되어 있다. 이 코드에 템플릿 리터럴 타입을 적용하면 다음과 같이 좀 더 명확하게 표시할 수 있다.

type Vertical = "top" | "bottom";
type Horizon = "Left" | "right";

type Direction = Vertical | `${Vertical}${Capitalize<Horizon>}`;

따라서 템플릿 리터럴 타입을 사용하면 더욱 읽기 쉬운 코드로 작성할 수 있게 되며. 코드를 재사용하고 수정하는 데 용이한 타입을 선언할 수 있다.

5.3 커스텀 유틸리티 타입 활용하기

타입스크립트로 프로젝트를 진행하다 보면 표현하기 힘든 타입을 마주할 때가 있다. 원하는 타입을 정확하게 설정해야만 해당 컴포넌트, 함수의 안정성과 사용성을 높일 수 있지만 타입스크립트에서 제공하는 유틸리티 타입만으로는 표현하는 데 한계를 느끼기도 한다. 이럴 때는 유틸리티 타입을 활용한 커스텀 유틸리티 타입을 제작해서 사용하면 된다. 이 절에서는 우아한형제들에서 사용하는 유틸리티 함수와 커스텀 유틸리티 타입을 소개하면서 어떻게 유틸리 티 타입을 활용하는지를 살펴본다.

5.3.1 유틸리티 함수를 활욤해 styled-components의 중복 타입 선언 피하기

리액트 컴포넌트를 구현할 때 여러 옵션을 props로 받아 유연한 컴포넌트로 만들 수 있다. 예를 들어 컴포넌트의 background-color, size 값을 props로 받아와서 상황에 맞게 스타일을 구현할 때가 많다. 이와 같은 스타일 관련 props는 styled—components에 전달되며 styled-components에도 해당 타입을 정확하게 작성해줘야 한다. styled-components로 만든 컴포넌트에 넘겨주는 타입은 props에서 받은 타입과 동일할 때가 대부분이다. 이런 경우에는 타입스크립트에서 제공하는 Pick, Omit 같은 유틸리티 타입을 잘 활용하여 코드를 간결하게 작성할 수 있다.
먼저 유틸리티 타입을 활용하지 않으면 어떤 불편함이 발생하는지 살펴보자.

Props 타입과 styled-components 타입의 중복 선언 및 문제점

아래 컴포넌트는 수평선을 그어주는 Hr 컴포넌트다.

// HrComponent.tsx
export type Props = {
    height?： string;
    color?： keyof typeof colors;
    isFull?: boolean;
    className?: string;
    ...
}

export const Hr： VFC<Props> = ({ height, color, isFull, className }) => {
    ...
    return <HrComponent height={height} color={color} isFull={isFull}
    className={class Name} />;
}；

// styles.ts
import { Props } from "...";
// Props 타입에서 'height', 'color', 'isFull' 프로퍼티만 선택하여 StyledProps 타입을 정의
type StyledProps = Pick<Props, 'height' | 'color' | 'isFull'>;
// HrComponent를 스타일링
const HrComponent = styled.hr<StyledProps>`
    height： ${({ height }) => height || "10px"};
    margin： 0;
    background-color： ${({ color }) => colors[color || "gray7"];
    border： none;
    ${({ isFull }) =>
    isFull &&
    css'
    margin: 0 -15px;
    `}
`;

StyledProps 타입 정의: Props 타입에서 height, color, isFull 프로퍼티만 선택하여 StyledProps 타입을 정의하고 있다.
HrComponent 스타일링: styled-components 라이브러리를 사용하여 hr 태그를 스타일링하고 있다.
Hr 컴포넌트 Props의 height, color, isFull 속성은 styled-components 컴포넌트인 HrComponent에 바로 연결되며 타입도 역시 같다. // style.ts 주석 아래 코드처럼 height, color, isFulll에 대한 StyledProps 타입을 새로 정의하여 HrComponent에 적용해보자.
StyledProps를 따로 정의하려면 Props와 똑같은 타입임에도 새로 작성해야 하므로 불가피하게 중복된 코드가 생긴다. 그리고 Props의 height, color, isFull 타입이 변경되면 StyledProps도 같이 변경돼야 한다. Hr 컴포넌트가 간단한 컴포넌트이기 때문에 코드를 중복해서 작성하는 게 별로 번거롭지 않을 수도 있지만. 컴포넌트가 더 커지고 styled-components로 만든 컴포넌트가 늘어날수록 중복되는 타입이 많아지며 관리해야 하는 포인트도 늘어난다.
이런 문제를 Pick, Omit 같은 유틸리티 타입으로 개선할 수 있다. 아래 그림처럼 Pick 유틸리티 타입을 사용해서 styled-components 컴포넌트 타입을 작성해보자.
직접 선언한 props 타입(before)

type Props = {
    height?： string | undefined;
    color?： "red" | "blue" | "yellow" | "green";
    isFull?: boolean | undefined;
    className?: string | undefined;
}

export type Props = {
    height?： string;
    color?： keyof typeof colors;
    isFull?: boolean;
    className?: string;
}

유틸리티 타입 Pick을 사용하여 선언한 StyledProps 타입

type styledProps = {
    height?： string | undefined;
    color?： "red" | "blue" | "yellow" | "green";
    isFull?: boolean | undefined;
}

type StyledProps = Pick<Props, 'height' | 'color' | 'isFull'>;

이처럼 Pick 유틸리티 타입을 활용해서 props에서 필요한 부분만 선택하여 styled-components 컴포넌트의 타입을 정의하면, 중복된 코드를 작성하지 않아도 되고 유지보수를 더욱 편리하게 할 수 있게 된다. 이외에도 상속받는 컴포넌트 혹은 부모 컴포넌트에서 자식 컴포넌트로 넘겨주는 props 등에도 Pick, Omit 같은유틸리티 타입을 활용할수 있다.

5.3.2 PickOne 유틸리티 함수

타입스크립트에는 서로 다른 2개 이상의 객체를 유니온 타입으로 받을 때 타입 검사가 제대로 진행되지 않는 이슈가 있다. 이런 문제를 해결하기 위해 PickOne이라는 이름의 유틸리티 함수를 구현해보자.

아래 코드와 같이 Card. Account 중 하나의 객체만 받고 싶은 상황에서 Card

Account로 타입을 작성하면 의도한 대로 타입 검사가 이뤄지지 않는다. 또한 withdraw 함수의 인자로 {card: ‘hyundai’} 또는 {account: ‘hana’} 중 하나만 받고 싶지만 실제로는 card, account 속성을 모두 받아도 타입 에러가 발생하지 않는다.

type Card = {
    card: string
}；

type Account = {
    account： string
}；
function withdraw(type： Card | Account) {
    ...
}
withdraw({ card： "hyundai", account： "hana" });

왜 타입 에러가 발생하지 않을까? 그 이유는 앞서 언급한 바와 같이 집합 관점으로 볼 때 유니온은 합집합이 되기 때문이다. 따라서 card, account 속성이 하나씩만 할당된 상태도 허용하지만 card, account 속성이 모두 포함되어도 합집합의 범주에 들어가기 때문에 타입 에러가 발생하지 않는 것이다.
이런 문제를 해결하기 위해 타입스크립트에서는 식별할 수 있는 유니온 기법을 자주 활용한다.

식별할 수 있는 유니온으로 객체 타입을 유니온으로 받기

식별할 수 있는 유니온은 각 타입에 type이라는 공통된 속성을 추가하여 구분짓는 방법이다. 식별할 수 있는 유니온을 활용하면 공통된 속성인 type을 기준으로 객체를 구분할 수 있기 때문에 withdraw 함수를 사용하는 곳에서 정확한 타입을 추론할 수 있게 된다.

type Card = {
    type： "card";
    card： string;
}；
type Account = {
    type： "account";
    account: string;
};
function withdraw(type: Card | Account) {
    ...
}
withdraw({ type： "card", card： "hyundai" });
withdraw({ type： "account", account： "hana" });

식별할 수 있는 유니온으로 문제를 해결할 수 있지만 일일이 type을 다 넣어줘야 하는 불편함이 생긴다. 처음부터 식별할 수 있는 유니온 형태로 설계했다면 불편함은 덜했을 수도 있지만, 이미 구현된 상태에서 식별할 수 있는 유니온을 적용하려면 해당 함수를 사용하는 부분을 모두 수정해야 한다. 실수로 수정하지 않은 부분이 생긴다면 또 다른 문제가 발생할 수 있다.
이러한 상황을 방지하기 위해 PickOne이라는 유틸리티 타입을 구현하여 적용해보자.

PickOne 커스텀 유틸리티 타입 구현하기

타입스크립트에서 제공하는 유틸리티 타입을 활용해서 커스텀 유틸리티 타입을 만들어보자. 앞의 여러 속성 중 하나의 속성만 받는 커스텀 유틸리티 타입을 구현하기 전에 구현해야 하는 타입이 정확히 무엇인지 생각해보자.

구현하고자 하는 타입은 account 또는 card 속성 하나만 존재하는 객체를 받는 타입이다. 처음에 작성한 것처럼 { account： string }

{ card： string }으로타입을 구현했을 때는 account와 card 속성을 모두 가진 객체도 허용되는 문제가 있었다.

account일 때는 card를 받지 못하고, card일 때는 account를 받지 못하게 하려면 하나의 속성이 들어왔을 때 다른 타입을 옵셔널한 undefined 값으로 지정하는 방법을 생각해볼 수 있다.

{ account: string; card?： undefined } | { account?: undefined; card: string }

결국 선택하고자 하는 하나의 속성을 제외한 나머지 값을 옵셔널 타입 十 undefined로 설정하면 원하고자 하는 속성만 받도록 구현할 수 있다. 이를 커스텀 유틸리티 타입으로 구현해보면 아래와같다.

type PickOne<T> = {
    [P in keyof T]： Record<P, T[P]> & Partial<Record<Exclude<keyof T, P>, undefined>>;
}[keyof T];

PickOne 살펴보기

앞의 유틸리티 타입을 하나씩 자세하게 뜯어보자. 먼저 PickOne 타입을 2가지 타입으로 분리해서 생각할 수 있다.

One</h6> ```js type One = { [P in keyof T]： Record<P, T[P]> }[keyof T]; ``` - keyof T - keyof T는 타입 T의 모든 키를 유니언 타입으로 반환한다. - 예를 들어, T가 { card: string; price: number }라면, keyof T는 'card' | 'price'가 된다. - 맵드 타입 구문 [P in keyof T] - P는 T 타입의 모든 키를 순회한다. - 예를 들어, T가 { card: string; price: number }라면, P는 순차적으로 card와 price가 된다. - Record<P, T[P]> - Record<K, T>는 TypeScript의 유틸리티 타입으로, 키 K와 값 T를 가진 객체 타입을 생성한다. - 예를 들어, P가 card라면 Record<'card', string>은 { card: string } 타입이 된다. - { [P in keyof T]: Record<P, T[P]> } - 이 구문은 타입 T의 각 키 P에 대해 Record<P, T[P]> 타입을 생성하여 새로운 객체 타입을 만든다. - 예를 들어, T가 { card: string; price: number }라면, { [P in keyof T]: Record<P, T[P]> }는 { card: Record<'card', string>; price: Record<'price', number> }가 된다. - 결국 { card: { card: string }; price: { price: number } } 타입이 된다. - [keyof T] - 앞에서 생성한 타입에서 keyof T에 해당하는 모든 키를 유니언 타입으로 추출한다. - 예를 들어, T가 { card: string; price: number }라면, keyof T는 'card' | 'price'가 되고, 최종적으로 { card: { card: string }; price: { price: number } }['card' | 'price']는 { card: string } | { price: number } 타입이 된다. - { card: { card: string }; price: { price: number } }['card']는 {card: string} 타입이고, { card: { card: string }; price: { price: number } }['price']는 { price: number } 타입이다. 따라서 인덱스 타입 조회를 각각 한 다음 유니온 타입으로 합친것과 같다. - 정리 - 1. T 타입의 모든 키를 순회한다. - 2. 각 키와 해당 값을 Record 타입으로 변환한다. - 3. 최종적으로 변환된 객체 타입에서 모든 키를 유니언 타입으로 추출한다. ```js type Card = { card： string }; const one： One = { card： "hyundai" }; ```
ExcludeOne</h6> ```js type ExcludeOne = { [P in keyof T]： Partial<Record<Exclude<keyof T, P>, undefined>> }[keyof T]; ``` - Exclude<keyof T, P> - Exclude<UnionType, ExcludedMembers>는 유니언 타입에서 특정 멤버를 제외하는 타입 유틸리티이다. - Exclude<keyof T, P>는 T 타입의 키들 중 P를 제외한 나머지 키들을 반환한다. - 예를 들어, P가 card일 때, Exclude<'card' | 'price', 'card'>는 'price'가 된다. - Record<Exclude<keyof T, P>, undefined> - Record<Exclude<keyof T, P>, undefined>는 P를 제외한 나머지 키들에 대해 값 타입이 undefined인 객체 타입을 생성한다. - 예를 들어, P가 card일 때, Record<'price', undefined>는 { price?: undefined }가 된다. - Partial - Partial는 T 타입의 모든 프로퍼티를 선택적(Optional)으로 만드는 타입 유틸리티 - Partial<Record<Exclude<keyof T, P>, undefined>>는 P를 제외한 나머지 키들에 대해 선택적 undefined 타입을 가진 객체 타입을 생성한다. - P가 card일 때, Partial<Record<'price', undefined>>는 { price?: undefined }가 된다. - { [P in keyof T]： Partial<Record<Exclude<keyof T, P>, undefined>> } - T 타입의 각 키 P에 대해 P를 제외한 나머지 키들을 undefined로 설정한 객체 타입을 생성한다. - 최종적으로, [keyof T]를 사용하여 이들 객체 타입을 유니언 타입으로 합친다. - 예를 들어, T가 { card: string; price: number }일 때, 최종 타입은 { price?: undefined } | { card?: undefined }가 된다.
PickOne</h6> ```js type PickOne = One & ExcludeOne; ``` - One & ExcludeOne는 [P in keyof T]를 공통으로 갖기 때문에 아래 같이 교차된다. ```js [P in keyof T]: Record<P, T[P]> & Partial<Record<Exclude<keyof T, P>, undefined>> ``` - ) 이 타입을 해석하면 전달된 T 타입의 1 개의 키는 값을 가지고 있으며, 나머지 키는 옵셔널한 undefined 값을 가진 객체를 의미한다. ```js type Card = { card： string }; type Account = { account： string }; const pickOnel： PickOne<Card & Account> = { card： "hyundai" }; // (0) const pickOne2： PickOne<Card & Account> = { account： "hana" }; // (0) const pickOne3： PickOne<Card & Account> = { card： "hyundai", account： undefined }; // (0) const pickOne4; PickOne<Card & Account> = { card： undefined, account： "hana" }; // (0) const pickOne5： PickOne<Card & Account> = { card： "hyundai", account; "hana" }; // (X) ``` - 지금까지 PickOne 타입을 구현하기 위해 단계별로 One 타입과 ExcludeOne 타입을 구현하는 예시를 살펴보았다. 유틸리티 타입만으로는 원하는 타입을 추출하기 어려울 때 커스텀 유틸리티 타입을 구현한다. 앞에서 본 예시에서처럼 커스텀 유틸리티 타입을 구현할 때는 정확히 어떤 타입을 구현해야 하는지를 파악하고, 필요한 타입을 작은 단위로 쪼개어 생각하여 단계적으로 구현하는 게 좋다. 이렇게 하면 용이하게 원하는 타입을 구현할 수 있을 것이다. #### 5.3.3 NonNullable 타입 검사 함수를 사용하여 간편하게 타입 가드하기 - 타입 가드는 타입스크립트에서 많이 사용된다. 특히 null을 가질 수 있는값(Nullable)의 null 처리는 자주 사용되는 타입 가드 패턴의 하나이다. - 일반적으로 if문을 사용해서 null 처리 타입 가드를 적용하지만, is 키워드와 NonNullable 타입으로 타입 검사를 위한 유틸 함수를 만들어서 사용할 수도 있다.
NonNullable 타입이란</h6> - 타입스크립트에서 제공하는 유틸리티 타입으로 제네릭으로 받는 T가 null 또는 undefined 일 때 never 또는 T를 반환하는 타입이다. NonNullable을 사용하면 null이나 undefined가 아닌 경우를 제외할 수 있다. ```js type NonNullable = T extends null | undefined ? never : T; ```
null, undefined를 검사해주는 NonNullable 함수
- NonNullable 유틸리티 타입을 사용하여 null 또는 undefined를 검사해주는 타입 가드 함수를 만들어 쓸 수 있다. - NonNullable 함수는 매개변수인 value가 null 또는 undefined라면 false를 반환한다. is 키워드가 쓰였기 때문에 NonNullable 함수를 사용하는 쪽에서 true가 반환된다면 넘겨준 인자는 null이나 undefined가 아닌 타입으로 타입 가드（타입이 좁혀진다）가 된다. ### 5.4 불변 객체 타입으로 활용하기 - 프로젝트를 진행하면서 상숫값을 관리할 때 객체를 사용한다. ```js const colors = { red： "#F45452", green： "#0C952A", blue: "#1A7CFF", }； const getColorHex = (key; string) => colors[key]; ``` - 컴포넌트나 함수에서 이런 객체를 사용할 때 열린 타입으로 설정할 수 있다. 함수 인자로 키를 받아서 value를 반환하는 함수를 보자. 키 타입을 해당 객체에 존재하는 키값으로 설정하는 것이 아니라 string으로 설정하면 getColorHex 함수의 반환 값은 any가 된다. colors에 어떤 값이 추가될지 모르기 때문이다. - 여기서 as const 키워드로 객체를 불변 객체로 선언하고, keyof 연산자를 사용하여 getColorHex 함수 인자로 실제 colors 객체에 존재하는 키값만 받도록 설정할 수 있다. keyof, as const로 객체 타입을 구체적으로 설정하면 타입에 맞지 않는 값을 전달할 경우 타입 에러가 반환되기 때문에 컴파일 단계에서 발생할 수 있는 실수를 방지할 수 있다. 즉, 이런 방법으로 객체 타입을 더 정확하고 안전하게 설정할 수 있다. #### 5.4.1 Atom 컴포넌트에서 theme style 객체 활용하기 - Atom 단위의 작은 컴포넌트(Button, Header, Input 등)는 폰트 크기, 폰트 색상, 배경 색상 등 다양한 환경에서 유연하게 사용될 수 있도록 구현되어야 하는데 이러한 설정값은 props로 넘겨주도록 설계한다. props로 직접 색상 값을 직접 넘겨줄 수도 있지만 그렇게 하면 사용자가 모든 색상 값을 인지해야 하고, 변경 사항이 생길 때 직접 값을 넣은 모든 곳을 찾아 수정해야 하는 번거로움이 생기기 때문에 변경에 취약한 상태가 된다. - 이런 문제를 해결하기 위해 대부분의 프로젝트에서는 해당 프로젝트의 스타일 값을 관리해주는 theme 객체를 두고 관리한다. Atom 컴포넌트에서는 theme 객체의 색상, 폰트 사이즈의 키값을 props로 받은 뒤 theme 객체에서 값을 받아오도록 설계한다. 컴포넌트에서 props의 color, fontsize 값의 타입을 정의할 때는 아래 예시처럼 string으로 설정할 수도 있다. ```js interface Props { fontsize?： string; backgroundcolor?： string; color?: string; onClick: (event： React.MouseEvent) => void | Promise; } const Button: FC = ({ fontSize, backgroundColor, color, children }) => { return ( <ButtonWrap fontSize={fontSize} backgroundColor={backgroundcolor} color={color} > {children} </ButtonWrap> ); }; const ButtonWrap = styled.button<Omit<Props, "onClick">>` color： ${({ color }) => theme.color[color ?? "default"]}; background-color： ${({ backgroundcolor }) => theme.bgColor[backgroundcolor ?? "default"]}; font-size： ${({ fontsize }) => theme.fontSize[fontSize ?? "default"]}; `; ``` - 앞의 코드에서 fontsize, backgroundcolor 같은 props 타입이 string이면 Button 컴포넌트의 props로 color, backgroundcolor를 넘겨줄 때 키값이 자동 완성되지 않으며 잘못된 키값을 넣어도 에러가 발생하지 않게 된다. 이러한 문제는 theme 객체로 타입을 구체화해서 해결할 수 있다. - theme 객체로 타입을 구체화하려면 keyof, typeof 연산자가 타입스크립트에서 어떻게 사용되는지 알아야한다.
타입스크립트 keyof 연산자로 객체의 키값을 타입으로 추출하기
- 타입스크립트에서 keyof 연산자는 객체 타입을 받아 해당 객체의 키값을 string 또는 number의 리터럴 유니온 타입을 반환한다. - 아래 예시로 keyof의 동작을 확인해보자. ColorType 객체 타입의 keyof ColorType을 사용하면 객체의 키값인 ‘red’, green’, ‘blue’가 유니온으로 나오게 된다. ```js interface ColorType { red; string; green： string; blue： string; } type ColorKeyType = keyof ColorType; //'red' | 'green' | 'blue' ```
타입스크립트 typeof 연산자로 값을 타입으로 다루기
- keyof 연산자는 객체 타입을 받는다. 따라서 객체의 키값을 타입으로 다루려면 값 객체를 타입으로 변환해야 한다. 이때 타입스크립트의 typeof 연산자를 활용할 수 있다. 자바스크립트에서는 typeof가 타입을 추출하기 위한 연산자로 사용된다면, 타입스크립트에서는 typeof가 변수 혹은 속성의 타입을 추론하는 역할을 한다. - 타입스크립트의 typeof 연산자는 단독으로 사용되기보다 주로 ReturnType같이 유틸리티 타입이나 keyof 연산자같이 타입을 받는 연산자와 함께 쓰인다. - typeof로 colors 객체의 타입을 추론한 결과는 아래와 같다. ```js const colors = { red: "#F45452", green: "#0C952A", blue: "#1A7CFF", }; type ColorsType = typeof colors; /** { red： string; green： string; blue： string; } */ ```
객체의 타입을 활용해서 컴포넌트 구현하기
- keyof, typeof 연산자를 사용해서 theme 객체 타입을 구체화하고, string으로 타입을 설정했던 Button 컴포넌트를 개선해보자. - color, backgroundcolor, fontsize의 타입을 theme 객체에서 추출하고 해당 타입을 Button 컴포넌트에 사용했다. ```js import { FC } from "react"; import styled from "styled-components"; const colors = { black： "#000000", gray： "#222222", white: "#FFFFFF", mint： "#2AC1BC", }; const theme = { colors: { default： colors.gray, ...colors }, backgroundcolor： { default： colors.white, gray： colors.gray, mint： colors.mint, black： colors.black. }, fontsize： { default： "16px", small： "14px", large： "18px", }, }； type ColorType = typeof keyof theme.colors; type BackgroundColorType = typeof keyof theme.backgroundcolor; type FontSizeType = typeof keyof theme.fontsize; interface Props { color?： ColorType; backgroundcolor?： BackgroundColorType; fontsize?： FontSizeType; onClick： (event： React.MouseEvent서TMLButtonElement>) => void ! Promise; } const Button: FC = ({ fontSize, backgroundColor, color, children }) => { return ( <ButtonWrap fontSize={fontSize} backgroundColor={backgroundcolor} color={color} > {children} </ButtonWrap> ); }; const ButtonWrap = styled.button<Omit<Props, "onClick">>` color： ${({ color }) => theme.color[color ?? "default"]}; background-color： ${({ backgroundcolor }) => theme.bgColor[backgroundcolor ?? "default"]}; font-size： ${({ fontsize }) => theme.fontSize[fontSize ?? "default"]}; `; ``` - Button 컴포넌트를 사용하는 곳에서 아래처럼 background의 값만 받을 수 있게 되었고 다른 값을 넣었을 때는 타입 오류가 발생한다. ### 5.5 Record 원시 타입 키 개선하기 - 객체 선언 시 키가 어떤 값인지 명확하지 않다면 Record의 키를 string이나 number 깉은 원시 타입으로 명시하곤 한다. 이때 타입스크립트는 키가 유효하지 않더라도 타입상으로는 문제 없기 때문에 오류를 표시하지 않는다. 이것은 예상치 못한 런타임 에러를 야기할 수 있다. 이 절에서는 Record를 명시적으로 사용하는 방안에 대해 다룬다. #### 5.5.1 무한한 키를 집합으로 가지는 Record - 다음처럼 음식 분류（한식, 일식）를 키로 사용하는 음식 배열이 담긴 객체를 만들었다. ```js type Category = string; interface Food { name： string; // ... } const foodByCategory： Record<Category, Food[]> = { 한식: [{ name： "제육덮밥" }, { name： "뚝배기 불고기" }], 일식: [{ name： "초밥" }, { name： "텐동" }], }； ``` - 여기에서 Category의 타입은 string이다. Category를 Record의 키로 사용하는 foodByCategory 객체는 무한한 키 집합을 가지게 된다. 이때 foodByCategory 객체에 없는 키값을 사용하더라도 타입스크립트는 오류를 표시하지 않는다. ```js foodByCategory["양식"]; // Food[]로 추론 foodByCategory["양식"].map((food) => console.log(food.name)); // 오류가 발생하지 않는다 ``` - 그러나 foodByCategory["양식"]은 런타임에서 undefined가 되어 오류를 반환한다. - 이때 자바스크립트의 옵셔널 체이닝 등을 사용해 런타임 에러를 방지할 수 있다. ```js foodByCategory["양식"]?.map((food) => console.log(food.name)); ``` - 그러나 어떤 값이 undefined인지 매번 판단해야 한다는 번거로움이 생긴다. 또한 실수로 undefined일 수 있는 값을 인지하지 못하고 코드를 작성하면 예상치 못한 런타임 에러가 발생할 수 있다. 하지만 타입스크립트의 기능을 활용하여 개발 중에 유효하지 않은 키가 사용되었는지 또는 undefined일 수 있는 값이 있는지 등을 사전에 파악할 수 있다. #### 5.5.2 유닛 타입으로 변경하기 - 키가 유한한 집합이라면 유닛 타입（다른 타입으로 쪼개지지 않고 오직 하나의 정확한 값을 가지는 타입）을사용할수 있다. ```js type Category = "한식" | "일식"; interface Food { name： string; // ... } const foodByCategory: Record<Category, Food[]> = { 한식: [{ name： "제육덮밥" }, { name： "뚝배기 불고기" }], 일식: [{ name： "초밥" }, { name： "텐동" }], }; // Property ’양식' does not exist on type 'Record<Category, Food[]>'. foodByCategory ["양식"]; ``` - 이제 Category로 한식 또는 일식만 올 수 있기 때문에 양식을 키로 사용하면 에러가 발생한다. 이처럼 유닛 타입을 활용하면 개발 중에 유효하지 않은 키가 사용되었는지를 확인할 수 있다. 그러나 키가 무한해야 하는 상황에는 적합하지 않다. #### 5.5.3 Partial을 활용하여 정확한 타입 표현하기 - 키가 무한한 상황에서는 Partial을 사용하여 해당 값이 undefined일 수 있는 상태임을 표현할 수 있다. 객체 값이 undefined일 수 있는 경우에 Partial을 사용해서 PartialRecord 타입을 선언하고 객체를 선언할 때 이것을 활용할 수 있다. ```js type PartialRecord<K extends string, T> = Partial<Record<K, T>>; type Category = string; interface Food { name; string; // ... } const foodByCategory： PartialRecord<Category, Food[]> = { 한식: [{ name： "제육덮밥" }, { name： "뚝배기 불고기" }], 일식: [{ name: "초밥" }, { name： "텐동" }], }； foodByCategory["양식"]; // Food[] 또는 undefined 타입으로 추론 foodByCategory["양식"].map((food) => console.log(food.name)); // Object is possibly 'undefined' foodByCategory["양식"]?.map((food) => console.log(food.name)); // OK ``` - Record<K, T> - Record<K, T>는 객체 타입을 생성하는 유틸리티 타입 - 예를 들어, Record<'a' | 'b', number>는 { a: number; b: number } 타입을 생성한다. - K는 문자열 유니언 타입이어야 하며(K extends string), T는 값의 타입이다. - Record<K, T>는 K에 포함된 모든 키에 대해 값이 T인 객체 타입을 생성합니다. - Partial<Record<K, T>> - Record<K, T>를 먼저 생성한 후, 이를 Partial로 감싸서 모든 프로퍼티를 선택적으로 만든다. - PartialRecord<K, T>는 Record<K, T>에서 모든 프로퍼티를 선택적으로 만든 객체 타입을 정의한다. ```js type Keys = 'a' | 'b' | 'c'; type Value = number; type Example = PartialRecord<Keys, Value>; // Example은 { a?: number; b?: number; c?: number } 타입입니다 ``` - 타입스크립트는 foodByCategory[key]를 Food[] 또는 undefined로 추론하고, 개발자에게 이 값은 undefined일 수 있으니 해당 값에 대한 처리가 필요하다고 표시해준다. 개발자는 안내를 보고 옵셔널 체이닝을 사용하거나 조건문을 사용하는 등 사전에 조치할 수 있게 되어 예상치 못한 런타임 오류를 줄일 수 있다.
끝!

4장 타입 확장하기 / 좁히기

Mon, 12 Feb 2024 00:00:00 +0900

4.1 타입 확장하기

타입 확장은 기존 타입을 사용해서 새로운 타입을 정의하는 것을 말한다. 기본적으로 타입스크립트에서는 interface와 type 키워드를 사용해서 타입을 정의하고 extends, 교차 타입, 유니온 타입을 사용하여 타입을 확장한다. 타입 확장의 장점과 더불어 extends, 교차 타입, 유니온 타입 간의 차이를 파악하고 언제 사용하면 좋을지 살펴보자.

4.1.1 타입 확장의 장점

타입 확장의 가장 큰 장점은 코드 중복을 줄일 수 있다는 것이다. 타입스크립트 코드를 작성하다 보면 필연적으로 중복되는 타입 선언이 생기기 마련이다. 이때 중복되는 타입을 반복적으로 선언하는 것보다 기존에 작성한 타입을 바탕으로 타입 확장을 함으로써 불필요한 코드 중복을 줄일 수 있다. 아래 예시를 보자.

/**
* 메뉴 요소 타입
* 메뉴 이룜, 이미지, 할인율, 재고 정보를 담고 있다
* */
interface BaseMenuItem {
    itemName: string | null;
    itemlmageUrl: string | null;
    itemDiscountAmount: number;
    stock： number | null;
}
/**
* 장바구니 요소 타입
* 메뉴 타입에 수량 정보가 추가되었다
* */
interface BaseCartltem extends BaseMenuItem {
    quantity： number；
}

이처럼 타입 확장은 중복된 코드를 줄일 수 있게 해준다. 그뿐만 아니라 BaseCartltem이 BaseMenuItem에서 확장되었다는 것을 쉽게 확인할 수 있는 것처럼 더 명시적인 코드를 작성할 수 있게 된다. interface 키워드 대신 typ은을 쓴다면 아래와 같이 코드를 작성하면 된다.

type BaseMenuItem = {
    itemName： string | null;
    itemlmageUrl： string | null;
    itemDiscountAmount: number;
    stock： number | null;
}；
type BaseCartltem = {
    quantity： number；
} & BaseMenuItem;

타입 확장은 중복 제거, 명시적인 코드 작성 외에도 확장성이란 장점을 가지고 있다. 앞에서 정의한 BaseCartltem을 활용하면 요구 사항이 늘어날 때마다 새로운 Cartitem 타입을 확장하여 정의할 수 있다. 아래 예시를 살펴보자.

/**
* 수정할 수 있는 장바구니 요소 타입
* 품절 여부, 수정할 수 있는 옵션 배열 정보가 추가되었다
* */
interface EditableCartItem extends BaseCartltem {
    isSoldOut: boolean;
    optionGroups; SelectableOptionGroup[];
}

/**
* 이벤트 장바구니 요소 타입
* 주문 가능 여부에 대한 정보가 추가되었다
* */
interface EventCartltem extends BaseCartltem {
    orderable： boolean;
}

더욱이, 기존 장바구니 요소에 대한 요구 사항이 변경되어도 BaseCartltem 타입만 수정흐!고 EditableCartItem이나 EventCartltem은 수정하지 않아도 되기 때문에 효율적이다.

4.1.2 유니온 타입

유니온 타입은 2개 이상의 타입을 조합하여 사용하는 방법이다. 집합 관점으로 보면 유니온 타입을 합집합으로 해석할 수 있다.

type MyUnion = A | B;

여기서 주의해야 할 게 있다. 유니온 타입으로 선언된 값은 유니온 타입에 포함된 모든 타입이 공통으로 갖고 있는 속성에만 접근할 수 있다.

interface CookingStep {
    orderld: string;
    price： number;
}
interface DeliveryStep {
    orderld: string;
    time: number;
    distance: string;
}
function getDeliveryDistance(step： CookingStep | DeliveryStep) {
    return step.distance;
    // Property 'distance' does not exist on type 'CookingStep | DeliveryStep’
    // Property 'distance' does not exist on type 'CookingStep'
}

distance는 Deliverystep에만 존재하는 속성이다. 인자로 받는 step의 타입이 CookingStep이라면 distance 속성을 찾을 수 없기 때문에 에러가 발생한다.
즉, step이라는 유니온 타입은 CookingStep 또는 Deliverystep 타입에 해당할 뿐이지 CookingStep이면서 DeliveryStep인 것은 아니다.

4.1.3 교차 타입

교차 타입도 기존 타입을 합쳐 필요한 모든 기능을 가진 하나의 타입을 만드는 것으로 이해할 수 있다.

/* 배달 팁 */
interface DeliveryTip {
    tip： string；
}
/* 별점 */
interface StarRating {
    rate: number;
}
/* 주문 필터 */
type Filter = DeliveryTip & StarRating;

const filter： Filter = {
    tip： "1000원 이하",
    rate： 4,
}

교차 타입을 사용할 때 타입이 서로 호환되지 않는 경우도 있다. 다음 코드를 살펴보자.

type IdType = string | number;
type Numeric = number | boolean;

type Universal = IdType & Numeric;

Universal은 IdType과 Numeric의 교차 타입이므로 두 타입을 모두 만족하는 경우에만 유지된다. 따라서 Universal의 타입은 number가 된다.

4.1.4 extends와 교차 타입

유니온 타입과 교차 타입을 사용한 새로운 타입은 오직 type 키워드로만 선언할 수 있다.
주의할 점은 extends 키워드를 사용한 타입이 교차 타입과 100% 상응하지는 않는다는 것이다. 예시를 보자.

interface DeliveryTip {
    tip: number;
}
interface Filter extends DeliveryTip {
    tip：string;
    // Interface 'Filter' incorrectly extends interface 'DeliveryTip'
    // Types of property 'tip' are incompatible
    // Type 'string' is not assignable to type 'number'
}

DeliveryTip을 extends로 확장한 Filter 타입에 string 타입의 속성 tip을 선언하면 tip의 타입이 호환되지 않는다는 에러가 발생한다.

type DeliveryTip = {
    tip: number;
}；
type Filter = DeliveryTip & {
    tip： string;
};

extends를 &로 바꿨을 뿐인데 에러가 발생하지 않는다. 이때 tip 속성의 타입은 number일까? string일까? 정답은 never다.
type 키워드는 교차 타입으로 선언되었을 때 새롭게 추가되는 속성에 대해 미리 알 수 없기 때문에 선언 시 에러가 발생하지 않는다. 하지만 tip이라는 같은 속성에 대해 서로 호환되지 않는 타입이 선언되어 결국 never 타입이 된 것이다.

4.2 타입 좁히기 - 타입 가드

타입스크립트에서 타입 좁히기는 변수 또는 표현식의 타입 범위를 더 작은 범위로 좁혀나가는 과정을 말한다. 타입 좁히기를 통해 더 정확하고 명시적인 타입 추론을 할 수 있게 되고, 복잡한 타입을 작은 범위로 축소하여 타입 안정성을 높일 수 있다.

4.2.1 타입 가드에 따라 분기 처리하기

타입스크립트에서의 분기 처리는 조건문과 타입 가드를 활용하여 변수나 표현식의 타입 범위를 좁혀 다양한 상황에 따라 다른 동작을 수행하는 것을 말한다. 타입 가드는 런타임에 조건문을 사용하여 타입을 검사하고 타입 범위를 좁혀주는 기능을 말한다. 구체적인 상황을 보면서 이해해보자.
타입스크립트로 개발하다 보면 여러 타입을 할당할 수 있는 스코프에서 특정 타입을 조건으로 만들어 분기 처리하고 싶을 때가 있다. 여러 타입을 할당할 수 있다는 것은 변수가 유니온 타입 또는 any 타입 등 여러 가지 타입을 받을 수 있다는 것을 말하는데 조건으로 검사하려는 타입보다 넓은 범위를 갖고 있다.

예를 들어 어떤 함수가 A

B 타입의 매개변수를 받는다고 가정해보자. 인자 타입이 A 또는 B 일 때를 구분해서 로직을 처리하고 싶다면 어떻게 해야 할까?

if문을 사용해서 처리하면 될 것 같지만 컴파일 시 타입 정보는 모두 제거되어 런타임에 존재하지 않기 때문에 타입을 사용하여 조건을 만들 수는 없다. 즉, 컴파일해도 타입 정보가 사라지지 않는 방법을 사용해야 한다.
특정 문맥 안에서 타입스크립트가 해당 변수를 타입 A로 추론하도록 유도하면서 런타임에서 도 유효한 방법이 필요한데, 이때 타입 가드를 사용하면 된다. 타입 가드는 크게 자바스크립트 연산자를 사용한 타입 가드와 사용자 정의 타입 가드로 구분할 수 있다.
자바스크립트 연산자를 활용한 타입 가드는 typeof, instanceof, in과 같은 연산자를 사용해서 제어문으로 특정 타입 값을 가질 수밖에 없는 상황을 유도하여 자연스럽게 타입을 좁히는 방식이다. 자바스크립트 연산자를 사용하는 이유는 런타임에 유효한 타입 가드를 만들기 위해서다. 런타임에 유효하다는 말은 타입스크립트뿐만 아니라 자바스크립트에서도 사용할 수 있는 문법이어야 한다는 의미이다.
사용자 정의 타입 가드는 사용자가 직접 어떤 타입으로 값을 좁힐지를 직접 지정하는 방식이다. 그럼 어떤 상황에서 타입 가드를 활용할 수 있을지 살펴보자.

4.2.2 원시 타입을 추론할 때: typeof 연산자 활용하기

typeof 연산자를 활용하면 원시 타입에 대해 추론할 수 있다. 다만 typeof는 자바스크립트 타입 시스템만 대응할 수 있다. 자바스크립트의 동작 방식으로 인해 null과 배열 타입 등이 object 타입으로 판별되는 등 복잡한 타입을 검증하기에는 한계가 있다. 따라서 typeof 연산자는 주로 원시 타입을 좁히는 용도로만 사용할 것을 권장한다.

4.2.3 인스턴스화된 객체 타입을 판별할 때: instanceof 연산자 활용하기

다음 예시는 selected 매개변수가 Date인지를 검사한 후에 Range 타입의 객체를 반환할 수 있도록 분기 처리하고 있다.

interface Range {
start： Date;
end： Date;
}

interface DatePickerProps {
selectedDates?: Date | Range;
}
const DatePicker = ({ selectedDates }： DatePickerProps) => {
    const [selected, setSelected] = useState(convertToRange(selectedDates));
    //...
}；
export function convertToRange(selected?： Date | Range)： Range | undefined {
    return selected instanceof Date
    ? { start： selected, end： selected }
    : selected;
}

typeof 연산자를 주로 원시 타입을 판별하는 데 사용한다면, instanceof 연산자는 인스턴스화된 객체 타입을 판별하는 타입 가드로 사용할 수 있다.

4.2.4 객체의 속성이 있는지 없는지에 따른 구분: in 연산자 활용하기

in 연산자는 객체에 속성이 있는지 확인한 다음에 true 또는 false를 반환한다. in 연산자를 사용하면 속성이 있는지 없는지에 따라 객체 타입을 구분할 수 있다.
자바스크립트의 in 연산자는 런타임의 값만을 검사하지만 타입스크립트에서는 객체 타입에 속성이 존재하는지를 검사한다. 여러 객체 타입을 유니온 타입으로 가지고 있을 때 in 연산자를 사용해서 속성의 유무에 따라 조건 분기를 할 수 있다.

4.2.5 is 연산자로 사용자 정의 타입 가드 만들어 활용하기

직접 타입 가드 함수를 만들 수도 있다. 이러한 방식의 타입 가드는 반환 타입이 타입 명제인 함수를 정의하여 사용할 수 있다. 타입 명제는 A is B 형식으로 작성하면 되는데 여기서 A는 매개변수 이름이고 B는 타입이다. 참/거짓의 진릿값을 반환하면서 반환 타입을 타입 명제로 지정하게 되면 반환 값이 참일 때 A 매개변수의 타입을 B 타입으로 취급하게 된다. 아래 예시를살펴보자.

const isDestinationCode = (x： string)： x is Destinationcode =>
    destinationCodeList.includes(x);

isDestinationCode는 string 타입의 매개변수가 destinationCodeList 배열의 원소 중 하나인지를 검사하여 boolean을 반환하는 함수이다. 함수의 반환 값을 boolean이 아닌 x is Destinationcode로 타이핑하여 타입스크립트에게 이 함수가 사용되는 곳의 타입을 추론할 때 해당 조건을 타입 가드로 사용하도록 알려준다.
만약 isDestinationCode의 반환 값 타이핑을 x is Destinationcode가 아닌 boolean으로 했다면 타입스크립트는 어떻게 추론할까? ? 개발자는 if문 내부에서 str 타입이 Destinationcode라는 것을 알 수 있다. Array. includes를 해석할수 있기 때문이다.
하지만 타입스크립트는 isDestinationCode 함수 내부에 있는 includes 함수를 해석해 타입 추론을 할 수 없다. 타입스크립트는 if문 스코프의 str 타입을 좁히지 못하고 string으로만 추론한다. destinationNames의 타입은 DestinationName[]이기 때문에 string 타입의 str을 push할 수 없다는 에러가 발생한다. 이처럼 타입스크립트에게 반환 값에 대한 타입정보를 알려주고 싶을 때 is를 사용할 수 있다. 반환 값의 타입을 X is Destinationcode로 알려줌으로써 타입스크립트는 if문 스코프의 str 타입을 Destinationcode로 추론할 수 있게 된다.

4.3 타입 좁히기 - 식별할 수 있는 유니온(Discriminated Unions)

종종 태그되 유니온 으로도 불리는 식별할 수 있는 유니온은 타입 좁히기에 널리 사용되는 방식이다. 이 절에서는 예시를 살펴보면서 식별할 수 있는 유니온을 어떨 때 사용할 수 있는지와 장점을 알아본다.

4.3.1 에러 정의하기

배달의민족의 선물하기 서비스는 선물을 보낼 때 필요한 값을 사용자가 올바르게 입력했는지 를 확인하는 유효성 검사를 진행한다. 유효성 에러가 발생하면 사용자에게 다양한 방식으로 에러를 보여 주는데 우아한형제들에서는 이 에러를 크게 텍스트 에러, 토스트 에러, 얼럿 에러 로 분류한다. 이들 모두 유효성 에러로 에러 코드(errorcode)와 에러 메시지(errorMessage)를 가지고 있으며, 에러 노출 방식에 따라 추가로 필요한 정보가 있을 수 있다. 예를 들어 토스트 에러는 토스트를 얼마 동안 띄울 것인지에 대한 정보가 필요하다.

type TextError = {
    errorCode： string;
    errorMessage: string;
}；
type ToastError = {
    errorCode: string;
    errorMessage： string;
    toastShowDuration： number; // 토스트를 띄워줄 시간
}；
type AlertError = {
    errorCode; string;
    errorMessage： string;
    onConfirm: () => void; // 얼럿 창의 확인 버튼을 누른 뒤 액션
};

이 에러 타입의 유니온 타입을 원소로 하는 배열을 정의해보면 다음과 같을 것이다.

type ErrorFeedbackType = TextError | ToastError | AlertError;
const errorArr： ErrorFeedbackType[] = [
{ errorcode: "100", errorMessage： "텍스트 에러"},
{ errorCode： "200", errorMessage： "토스트 에러", toastShowDuration： 3000 },
{ errorcode： "300", errorMessage： "얼럿 에러", onConfirm： () => {} },
]；

TextError, ToastError, AlertError의 유니온 타입인 ErrorFeedbackType의 원소를 갖는 배열 errorArr를 정의함으로써 다양한 에러 객체를 관리할 수 있게 되었다. 여기서 해당 배열에 에러 타입별로 정의한 필드를 가지는 에러 객체가 포함되길 원한다고 해보자. 즉, ToastError의 toastShowDuration 필드와 AlertError의 onConfirm 필드를 모두 가지는 객체에 대해서는 타입 에러를 뱉어야 할 것이다.

const errorArr： ErrorFeedbackType[] = [
    // ...
    {
    errorCode： "999",
    errorMessage： "잘못된 에러",
    toastShowDuration： 3000,
    onConfirm： () => {},
    }, // expected error
]；

하지만 이 코드를 작성했을 때 자바스크립트는 덕 타이핑 언어이기 때문에 별도의 타입 에러를 뱉지 않는 것을 확인할 수 있다. 이런 상황에서 타입 에러가 발생하지 않는다면 앞으로의 개발 과정에서 의미를 알 수 없는 무수한 에러 객체가 생겨날 위험성이 커진다.

4.3.2 식별할 수 있는 유니온

따라서 에러 타입을 구분할 방법이 필요하다. 각 타입이 비슷한 구조를 가지지만 서로 호환되지 않도록 만들어주기 위해서는 타입들이 서로 포함 관계를 가지지 않도록 정의해야 한다. 이때 적용할 수 있는 방식이 바로 식별할 수 있는 유니온을 활용하는 것이다. 식별할 수 있는 유니온이란 타입 간의 구조 호환을 막기 위해 타입마다 구분할 수 있는 판별자를 달아주어 포함 관계를 제거하는 것이다.
판별자의 개념으로 errorType이라는 필드를 새로 정의해보자. 각 에러 타입마다 이 필드에 대해 다른 값을 가지도록 하여 판별자를 달아주면 이들은 포함 관계를 벗어나게 된다.

type TextError = {
    errorType： "TEXT";
    errorCode： string;
    errorMessage： string;
}；
type ToastError = {
    errorType： "TOAST";
    errorCode： string;
    errorMessage: string;
    toastShowDuration: number;
}；
type AlertError = {
    errorType： "ALERT";
    errorCode： string;
    errorMessage： string;
    onConfirm： () => void;
}；

에러 객체에 대한 타입을 위와 같이 정의한 상태에서 errorArr을 새로 정의해보면, 우리가 처음에 기대했던 대로 정확하지 않은 에러 객체에 대해 타입 에러가 발생하는 것을 확인할수 있다.

4.3.3 식별할 수 있는 유니온의 판별자 선정

식별할 수 있는 유니온을 사용할 때 주의할 점이 있다. 식별할 수 있는 유니온의 판별자는 유닛 타입으로 선언되어야 정상적으로 동작한다. 유닛 타입은 다른 타입으로 쪼개지지 않고 오직 하나의 정확한 값을 가지는 타입을 말한다. null, undefined, 리터럴 타입을 비롯해 true, 1 등 정확한 값을 나타내는 타입이 유닛 타입에 해당한다. 반면에 다양한 타입을 할당할 수 있는 void, string, number와 같은 타입은 유닛 타입으로 적용되지 않는다.
공식 깃허브의 이슈 탭을 살펴보면 식별할 수 있는 유니온의 판별자로 사용할 수 있는 타입을 다음과 같이 정의하고 있다.
- 리터럴타입이어야핸다.
- 판별자로 선정한 값에 적어도 하나 이상의 유닛 타입이 포함되어야 하며, 인스턴스화할 수 있는 타입은 포함되지 않아야 한다.

4.4 Exhaustiveness Checking으로 점확한 타입 분기 유지하기

Exhaustiveness는 사전적으로 철저함, 완전함을 의미한다. 따라서 Exhaustiveness Checking은 모든 케이스에 대해 철저하게 타입을 검사하는 것을 말하며 타입 좁히기에 사용되는 패러다임 중 하나다.
타입 가드를 사용해서 타입에 대한 분기 처리를 수행하면 필요하다고 생각되는 부분만 분기 처리를 하여 요구 사항에 맞는 코드를 작성할 수 있게 된다. 하지만 때로는 모든 케이스에 대해 분기 처리를 해야만 유지보수 측면에서 안전하다고 생각되는 상황이 생긴다. 이때 Exhaustiveness Checking을 통해 모든 케이스에 대한 타입 검사를 강제할 수 있다. 예시를 보며 Exhaustiveness Checking의 의미를 이해해보자.

4.4.1 상품권

배달의민족의 선물하기 서비스에는 다양한 상품권이 있다. 상품권 가격에 따라 상품권 이름을 반환해주는 함수를 작성하면 다음과 같다.

type Productprice = "10000" | "20000"；
const getProductName = (productPrice： ProductPrice)： string => {
    if (productprice === "10000") return "배민상품권 1만 원";
    if (productPrice === "20000") return "배민상품권 2만 원";
    else {
        return "배민상품권";
    }
}；

여기까지는 각 상품권 가격에 따라 상품권 이름을 올바르게 반환하고 있어 큰 문제가 없다고 느껴질 수 있다. 하지만 새로운 상품권이 생겨서 Productprice 타입이 업데이트되어야 한다고 해보자.

type Productprice = "10000" | "20000" | "5000";
const getProductName = (productPrice： ProductPrice)： string => {
    if (productprice === "10000") return "배민상품권 1만 원";
    if (productPrice === "20000") return "배민상품권 2만 원";
    if (productprice === "5000") return "배민상품권 5천 원"; // 조건 추가 필요
    else {
        return "배민상품권";
    }
}；

이처럼 Productprice 타입이 업데이트되었을 때 getProductName 함수도 함께 업데이트되어야 한다. prod나ctPrice가 “5000”일 경우의 조건도 검사하여 의도한 대로 상품권 이름을 반환해야 한다. 그러나 getProductName 함수를 수정하지 않아도 별도 에러가 발생하는 것이 아니기 때문에 실수할 여지가 있다. 이와 같이 모든 타입에 대한 타입 검사를 강제하고 싶다면 다음과 같이 코드를 작성하면 된다.

type Productprice = "10000" | "20000" | "5000";
const getProductName = (productPrice： ProductPrice)： string => {
    if (productprice === "10000") return "배민상품권 1만 원";
    if (productPrice === "20000") return "배민상품권 2만 원";
    // if (productprice === "5000") return "배민상품권 5천 원"; // 조건 추가 필요
    else {
        exhaustiveCheck(productPrice); // Error： Argument of type 'string' is not assignable to parameter of type 'never'
        return "배민상품권";
    }
}；

const exhaustiveCheck = (param： never) => {
    throw new Error("type error!");
}；

앞의 코드에서 productPrice가 “5000”일 때의 분기 처리가 주석 처리된 것이 보일 것이다. 그리고 exhaustiveCheck(productPrice);에서 에러를 뱉고 있는데 ProductPrice 타입 중 5000이라는 값에 대한 분기 처리를 하지 않아서 (철저하게 검사하지 않았기 때문에) 발생한 것이다. 이렇게 모든 케이스에 대한 타입 분기 처리를 해주지 않았을 때, 컴파일타임 에러가 발생하게 하는 것을 Exhaustiveness Checking이라고 한다.
좀 더 자세히 살펴보면 exhaustiveCheck라는 함수가 보일 것이다. 이 함수는 매개변수를 never 타입으로 선언하고 있다. 즉, 매개변수로 그 어떤 값도 받을 수 없으며 만일 값이 들어온다면 에러를 내뱉는다. 이 함수를 타입 처리 조건문의 마지막 else문에 사용하면 앞의 조건문에서 모든 타입에 대한 분기 처리를강제할 수 있다.
이렇게 Exhaustiveness Checking을 활용하면 예상치 못한 런타임 에러를 방지하거나 요구사항이 변경되었을 때 생길 수 있는 위험성을 줄일 수 있다. 타입에 대한 철저한 분기 처리가 필요하다면 Exhaustiveness Checking 패턴을 활용해보길 바란다.

끝!

React Compound Component Pattern

Sun, 11 Feb 2024 00:00:00 +0900

React Compound Component Pattern에 대해 공부해보자.

리액트 컴파운드 컴포넌트 패턴 소개

리액트(React)를 사용하다 보면, 한 컴포넌트 내에서 특정 기능을 수행하고, 그 기능과 밀접하게 연관된 하위 요소들을 함께 구성하는 상황을 자주 맞닥뜨리게 된다.
이때 흔히 떠오르는 것은 “props drilling” 혹은 하위 컴포넌트에 일일이 필요한 값을 내려주는 패턴이다. 하지만 이런 방법은 컴포넌트 구조가 커지면서 점점 복잡해지고, 재사용성이나 가독성이 떨어질 수 있다. 이러한 문제를 해결하기 위한 한 가지 유용한 디자인 패턴이 바로 컴파운드(Compound) 컴포넌트 패턴이다.

w/o 컴파운드 컴포넌트 패턴 리액트 코드

컴파운드 컴포넌트 패턴 없이 아래와 같은 간단한 드롭다운(셀렉트 박스) UI를 만들어 보자.

우선 전체 드롭다운 로직을 관리하는 최상위 컴포넌트인 Select 컴포넌트가 있다. Select에서 상태를 모두 관리하고, 그 상태를 Trigger, Menu, Option 컴포넌트에 props로 하나하나 전달하는 형태다.
그리고 현재 선택된 값을 보여주고, 클릭 시 메뉴를 열거나 닫아주는 버튼인 Trigger 컴포넌트가 있다.
Menu 컴포넌트에서는 실제 드롭다운 목록을 보여준다.
Option 컴포넌트는 개별 옵션 항목을 나타낸다.

function App() {
    const options = [
        { value: 'apple', label: 'Apple' },
        { value: 'banana', label: 'Banana' },
        { value: 'orange', label: 'Orange' },
    ];
    return (
        <div className="App">
            <Select options={options} />
        </div>
    );
}

const Select = ({ options = [] }) => {
    // 상태를 이용해 메뉴가 열렸는지 닫혔는지 관리
    const [isOpen, setIsOpen] = useState(false);
    // 현재 어떤 옵션이 선택되었는지 저장
    const [selectedValue, setSelectedValue] = useState(null);

    // 메뉴 열림/닫힘을 제어
    const toggle = () => setIsOpen(!isOpen);
    // 옵션 선택 시 상태를 갱신하고 메뉴를 닫음
    const selectOption = (value) => {
        setSelectedValue(value);
        setIsOpen(false);
    };

    return (
        <div
            className="select-container"
        >
            <Trigger
                isOpen={isOpen}
                selectedValue={selectedValue}
                onToggle={toggle}
            />
            <Menu isOpen={isOpen}>
                {options.map((option) => (
                    <Option
                        key={option.value}
                        value={option.value}
                        onSelect={selectOption}
                    >
                        {option.label}
                    </Option>
                ))}
            </Menu>
        </div>
    );
};

export default Select;

아래는 Trigger 컴포넌트다. Select 컴포넌트로부터 isOpen, selectedValue, onToggle를 props로 받는다.
isOpen에 따라 화살표 아이콘을 위(▲)나 아래(▼)로 바꾼다.
onClick 이벤트에 onToggle 이벤트 핸들러를 등록해 isOpen 상태를 변경한다.

const Trigger = ({ isOpen, selectedValue, onToggle }) => {
    return (
        <button
            onClick={onToggle}
        >
            {selectedValue ?? 'Select an option'} {isOpen ? '▲' : '▼'}
        </button>
    );
};

그리고 아래는 Menu와 Option 컴포넌트다.

const Menu = ({ isOpen, children }) => {
    if (!isOpen) return null;
    return (
        <ul>
            {children}
        </ul>
    );
};

const Option = ({ value, onSelect, children }) => {
    return (
        <li
            onClick={() => onSelect(value)}
        >
            {children}
        </li>
    );
};

Menu 컴포넌트는 Select로부터 isOpen을 props로 받아서 true일 때만 목록을 표시해준다.

w/o 컴파운드 컴포넌트 패턴 문제점

위 구조는 Select 컴포넌트 내부에서 모든 로직과 데이터 흐름을 관리하면서 하위 컴포넌트에 props를 직접 전달하고 있는 형태다. 이로 인해 하위 컴포넌트들을 자유롭게 배치하거나 추가적인 UI 변화를 주려면 Select 컴포넌트를 계속 수정해야 되고, props 전달이 더 많아 질 수 있다.
이렇게 컴포넌트 패밀리가 명확히 정의 되지 않으면, 나중에 코드 구조를 파악하거나 수정할 때 “이 컴포넌트는 어디에 속하고 어떻게 함께 사용되는지” 한번 더 고민해야 하며, 각각의 컴포넌트를 독립적으로 이해하고 관리해야 한다.
다시 말해, 기능은 단순하지만, 확장성과 유연성, 그리고 유지 보수성이 떨어지는 구조라고 볼 수 있다.

w/ 컴파운드 컴포넌트 패턴 리액트 코드

아래는 컴파운드 컴포넌트 패턴을 적용한 App과 Select 컴포넌트다.

function App() {
    return (
        <div className="App">
            <Select>
                <Select.Trigger />
                <Select.Menu>
                    <Select.Option value="apple">Apple</Select.Option>
                    <Select.Option value="banana">Banana</Select.Option>
                    <Select.Option value="orange">Orange</Select.Option>
                </Select.Menu>
            </Select>
        </div>
    );
}

const SelectContext = createContext();

export function useSelectContext() {
    const context = useContext(SelectContext);
    if (!context) {
        throw new Error(
            'Select compound components must be used within a Select'
        );
    }
    return context;
}

const Select = ({ children }) => {
    const [isOpen, setIsOpen] = useState(false); // 메뉴 열림/닫힘 상태
    const [selectedValue, setSelectedValue] = useState(null); // 선택된 옵션 값

    const toggle = () => setIsOpen((prev) => !prev); // 메뉴 열림/닫힘 토글 함수
    const selectOption = (value) => {
        setSelectedValue(value); // 새로운 값 선택
        setIsOpen(false); // 선택 후 메뉴 닫기
    };

    const value = { isOpen, selectedValue, toggle, selectOption };

    return (
        <SelectContext.Provider value={value}>
            <div
            >
                {children}
            </div>
        </SelectContext.Provider>
    );
};

export default Select;

Select.Trigger = Trigger;
Select.Menu = Menu;
Select.Option = Option;

컴파운드 컴포넌트 패턴을 사용한 Select 컴포넌트는 하나의 상위 컴포넌트(Select)와 그 안에서만 의미있게 동작하는 하위 컴포넌트들(Select.Trigger, Select.Menu, Select.Option)을 하나의 세트로 묶는다.
App 컴포넌트를 보면 하위 컴포넌트인 Select.Trigger, Select.Menu, Select.Option을 별도로 import하지 않고, Select 하나만 import한 뒤 Select 객체 안에 있는 하위 컴포넌트들을 점(.)을 통해 바로 접근한다.
상위 컴포넌트(Select) 안에서 이미 Context를 통해 상태가 공유되고 있으므로, 하위 컴포넌트는 복잡한 props 없이 상위 상태를 활용한다.
컴포넌트를 재배치하거나 하위 컴포넌트를 추가할 때도 코드 구조가 깔끔하고 직관적이다.

const Trigger = () => {
    const { isOpen, toggle, selectedValue } = useSelectContext();
    return (
        <button
            onClick={toggle}
        >
            {selectedValue ?? 'Select an option'}{' '}
            <span>{isOpen ? '▲' : '▼'}</span>{' '}
        </button>
    );
};

const Menu = ({ children }) => {
    const { isOpen } = useSelectContext();
    return isOpen ? (
        <ul>
            {children}
        </ul>
    ) : null; // isOpen이 true일 때만 목록 표시
};

const Option = ({ value, children }) => {
    const { selectOption } = useSelectContext();
    return (
        <li
            onClick={() => selectOption(value)}
        >
            {children}
        </li>
    );
};

w/ 컴파운드 컴포넌트 패턴의 장점

App 컴포넌트를 비교해봤을때 w/o 컴파운드 컴포넌트 패턴의 경우, options를 전달하기 위해 props drilling이 필요하지만, w/ 컴파운드의 경우 하위 컴포넌트에 곧바로 props를 전달할 수 있다.
또한 Context API를 사용하면서 props drilling을 줄였다. 이를 통해 상위 컴포넌트만 한 번 import한 뒤, 그 안에 있는 하위 컴포넌트를 바로 호출해서 사용하는 구조로 자연스럽게 형성할 수 있었다.
따라서 코드적으로 상위 컴포넌트와 그와 밀접하게 관련된 하위 컴포넌트들이 한데 묶여 있으므로, 이들이 “한 세트”라는 사실이 명확해진다. “이 하위 컴포넌트들은 이 상위 컴포넌트와 함께 써야 하는구나”라는 점을 코드 구조에서 바로 느낄 수 있다.

정리

컴파운트 컴포넌트은 상위 컴포넌트가 상태와 로직을 관리하고, 하위 컴포넌트들은 이 상위 컴포넌트에서 제공하는 Context를 통해 해당 상태와 로직에 접근한다.
그리고 상위 컴포넌트만 import한 뒤, 그 내부에 배치된 하위 컴포넌트들을 자유롭게 조합하여 하나의 기능 단위(Component family)로 사용하는 패턴이다.
즉, 상위 컴포넌트와 하위 컴포넌트 사이에 명확한 관계와 하나의 패키지로서의 응집성을 강조하는 것이 컴파운트 패턴이다.

끝!

React로 스톱워치 만들기

Fri, 09 Feb 2024 00:00:00 +0900

이번에는 React JS를 이용해 스톱워치를 만들어보자.

컴포넌트 구성

컴포넌트 구성은 우선 스톱워치를 총괄하는 컴포넌트인 StoWatch 컴포넌트를 생성했다.

const { centisecond, start, pause, createLap, reset, isRunning, laps } =
        useTimer();

<section className="w-fit bg-white shadow-md rounded px-8 pt-6 pb-8 mb-4 flex flex-col justify-center m-auto mt-36 max-w-sm">
            <Timer centisecond={centisecond} />
            <div className="flex justify-between text-white pb-8 text-sm select-none">
                <Button
                    color="bg-gray-600"
                    label={isRunning === true ? '랩' : '리셋'}
                    code="L"
                    handleBtnClick={handleLapRest}
                    ref={lapResetRef}
                />
                <Button
                    color={isRunning === true ? 'bg-red-600' : 'bg-green-600'}
                    label={isRunning === true ? '중단' : '시작'}
                    code="S"
                    handleBtnClick={handleStartStop}
                    ref={startStopRef}
                />
            </div>
            <Laps laps={laps} />
        </section>

가장 위에는 실시간 타이머를 보여주는 Timer 컴포넌트, 그 밑에 Button 컴포넌트, 그 밑에 Laps 컴포넌트를 뒀다.
StopWatch 컴포넌트에서 useTimer 훅을 호출하여 상태와 로직을 관리한 뒤, 해당 로직을 하위 Button 컴포넌트에 이벤트 핸들러를 내려주는 방식으로 구현했다.
다시 말해, 타이머 모듈의 상태 관리를 단일화하여 여러 상태들을 한 곳(StopWatch)에서만 관리하고, 하위 컴포넌트들은 그 상태를 props로 전달 받아 표시하거나, 상위에서 내려준 핸들러를 통해 상태를 변경하게 된다.
이를 통해, Button 컴포넌트는 시간 측정과 관련된 로직을 전혀 알 필요 없이, 단순히 버튼 UI의 역할에만 충실할 수 있도록 했다.

시작/중단, 랩/리셋 기능 만들기

const handleStartStop = () => {
        if (isRunning === false) {
            start();
        } else {
            pause();
        }
    };
    const handleLapRest = () => {
        if (isRunning === false) {
            reset();
        } else {
            createLap();
        }
    };

<Button
    color={isRunning === true ? 'bg-red-600' : 'bg-green-600'}
    label={isRunning === true ? '중단' : '시작'}
    code="S"
    handleBtnClick={handleStartStop}
    ref={startStopRef}
/>

useTimer의 isRunning 변수를 통해 Button 컴포넌트의 color, label props를 제어했다.
StopWatch 컴포넌트에서 Button 컴포넌트에 이벤트 핸들러를 props로 전달해줬다.

랩 기능 구현

랩 버튼을 누르면 useTimer의 createLap 메서드가 수행이 되고, 결과 값으로 laps를 반환한다.
결과값인 laps는 StopWatch 컴포넌트의 state이기 때문에 StopWatch 컴포넌트 리렌더 되면서 Laps 컴포넌트에 laps를 props로 전달한다.

키보드 조작 기능 구현

keydown 이벤트는 document에 이벤트 리스너를 추가해야하기 때문에 useEffect 훅을 사용했다.

const handleKeyDown = (e) => {
        if (e.code === 'KeyL') {
            lapResetRef.current.click();
        } else if (e.code === 'KeyS') {
            startStopRef.current.click();
        }
};
useEffect(() => {
    document.addEventListener('keydown', (e) => handleKeyDown(e));
}, []);

그리고 key 이벤트는 버튼을 클릭했을때와 동일하게 처리하기 위해 버튼의 ref에대해 click 이벤트를 수행하도록 했다.

최단, 최장 기록 강조 기능 구현

최단, 최장 기록 강조 기능을 구현하기 위한 Laps 컴포넌트 로직은 아래와 같다.

const Laps = ({ laps }) => {
    const sortedLaps = [...laps].sort((lap1, lap2) => lap1[1] - lap2[1]);
    const maxLapNum = sortedLaps.length && sortedLaps[sortedLaps.length - 1][0];
    const minLapNum = sortedLaps.length && sortedLaps[0][0];

    const createMinMaxStyle = (lap) => {
        if (laps.length < 2) return;
        if (lap[0] === minLapNum) return 'text-green-600';
        else if (lap[0] === maxLapNum) return 'text-red-600';
    };

    return (
        <article className="text-gray-600 h-64 overflow-auto border-t-2">
            <ul id="laps">
                {/* 추가되는 lap은 아래의 HTML 코드 형식을 사용해 추가해주세요.  */}
                {laps.map((lap) => (
                    <li
                        className={`${createMinMaxStyle(
                            lap
                        )} flex justify-between py-2 px-3 border-b-2`}
                        key={lap[0]}
                    >
                        <span>랩 {lap[0]}</span>
                        <span>{formatTime(lap[1])}</span>
                    </li>
                ))}
            </ul>
        </article>
    );
};

우선 laps 배열을 복사해 sortedLaps로 정렬했다.
그리고 최단/ 최장 Lap 번호를 추출하고, map을 통해 렌더링시에 createMinMaxStyle 메서들를 생성해 Lap 번호가 같은 경우 스타일을 추가했다.
그리고 Lap이 한 개인 경우는 최단/ 최장 기능이 동작하지 않기때문에 createMinMaxStyle 메서드에서 early return 처리했다.

완성본

완성본 보러가기

끝!

React로 장바구니 만들기

Thu, 08 Feb 2024 00:00:00 +0900

이번에는 React JS를 이용해 장바구니를 만들어보자.

컴포넌트 구성

컴포넌트는 크게 상품 리스트를 렌더하는 ProductList 컴포넌트와 오른쪽 툴페인인 CartToolpane 컴포넌트로 구성했다.
ProductList는 productlist를 props로 받아 map을 통해 각 item들을 ProductItem 컴포넌트를 통해 렌더했다.

const ProductList = ({ productList, handleProductItemClick }) => {
    if (productList === undefined || productList.length === 0) {
        return '상품이 없습니다.';
    }
    return (
        <>
            <section id="product-list">
                <div
                    id="product-card-grid"
                    className="grid gap-4 auto-cols-fr grid-cols-2 md:grid-cols-4"
                >
                    {productList?.map((item) => (
                        <ProductItem
                            key={item.id}
                            id={item.id}
                            imgSrc={item.imgSrc}
                            name={item.name}
                            price={item.price}
                            handleProductItemClick={handleProductItemClick}
                        />
                    ))}
                </div>
            </section>
        </>
    );
};

마찬가지로 CartToolpane 컴포넌트는 props로 cartlist를 CartList 컴포넌트에 전달하고, CartList 컴포넌트에서 CartItem 컴포넌트를 렌더했다.

비동기 API 요청 모킹하기

src/api/productData.json 파일에 있는 상품 목록 데이터를 fetch API를 통해 비동기로 데이터를 받아와 렌더링했다.

useEffect(() => {
        const fetchProductData = async () => {
            const result = await getProductList();
            setProductList(result);
        };
        fetchProductData();
}, []);

const request = async (url) => {
    try {
        const response = await fetch(url);
        if (response.ok) {
            const data = await response.json();
            return data;
        }
        throw response.json();
    } catch (e) {
        console.log(e);
    }
};

const getProductList = async () => {
    const result = await request('./productData.json');
    return result;
};

respone 객체의 json 메서드를 통해 JSON 형태를 파싱하여 자바스크립트 객체로 받았다.

상품 목록 렌더링하기

fetch가 완료된 후 productList state를 초기화해 fetch된 productList를 ProductList 컴포넌트에 prpos로 전달해 초기화된 상품 목록을 렌더링하도록 했다.

장바구니 토글 기능

장바구니 아이콘을 클릭하거나 상품 목록 중 하나를 클릭하면 장바구니가 열려야한다.
장바구니 열린 상태에서 닫기 버튼을 누르거나 backdrop을 누르면 장바구니가 닫혀야 한다.

<App>
    <ProductList />
    <CartList />
</App>

위 코드와 같이 ProductList와 CartList는 서로 다른 서브 트리 이지만, ProductList를 클릭하면 CartList가 열려야한다.
따라서 공통 부모인 App 컴포넌트에서 cartToolpaneOpen state를 토글하는 이벤트 핸들러를 구현했다.
아래의 이벤트 핸들러를 장바구니 아이콘, 상품 목록, 장바구니 닫기 버튼, backdrop의 onClick 이벤트 핸들러로 등록했다.

const handleOpenCloseCartToolpane = () => {
        setCartToolpaneOpen((prev) => !prev);
};

장바구니 추가 기능

상품 카드를 클릭하면 상품이 장바구니에 추가되어야 한다.
따라서 App 컴포넌트에서 이벤트 핸들러를 만들어 ProductList 컴포넌트에 props로 전달했다.
Productlist 컴포넌트는 ProductItem 컴포넌트로 전달하고, ProductItem의 onClick 이벤트 핸들러로 등록한다.

 const handleProductItemClick = (e) => {
        // 장바구니 토글
        handleOpenCloseCartToolpane();
        const productId = e.target.dataset.productid;
        addCartItem(parseInt(productId));
};

    const addCartItem = (id) => {
        const selectedItem = productList.find((item) => item.id === id);
        const idx = cartList.findIndex((item) => item.id === id);
        if (idx === -1) {
            setCartList((prev) => [...prev, { ...selectedItem, count: 1 }]);
        } else {
            cartList[idx].count += 1;
            setCartList([...cartList]);
        }
};

fetch한 productList의 정보는 App 커뮤포넌트에 있고, product 정보를 받으려면 id 정보가 필요하다. 따라서 ProductItem 컴포넌트의 HTMLElement의 dataset의 productid를 통해 id 정보를 받았다.
그리고 id 가있는 경우는 해당 cartItem의 count를 1 증가시키고, 없는 경우는 기존 cartList state에 새롭게 추가했다.

장바구니 상품 삭제 기능

장바구니 목록에서 삭제하기 글씨를 클릭하면 해당 상품이 삭제된다.

const handleRemoveItem = () => {
        const newCratList = cartList.filter((item) => item.id !== id);
        setCartList([...newCratList]);
};

따라서 삭제하기 버튼에 handleRemoveItem 이벤트 핸들러를 구현해 등록했다.

Web Storage API를 사용한 장바구니 데이터 저장 기능

장바구니의 결제하기 버튼을 누르면 장바구니 데이터를 브라우저에 저장하도록 했다.
따라서 새로고침을 하더라도 장바구니 데이터가 localStorage에 저장되어있으면 장바구니 데이터를 보여준다.

// 장바구니 데이터 저장
const saveCartList = (e) => {
    e.preventDefault();
    localStorage.setItem('cartList', JSON.stringify(cartList));
};

// 장바구니 데이터 로드
useEffect(() => {
    setCartList(JSON.parse(localStorage.getItem('cartList')));
}, [setCartList]);

localStorage 이용해 장바구니 데이터를 저장하고 로드했다.

완성본

완성본 보러가기

끝!

VanillaJS로 스톱워치 만들기

Wed, 07 Feb 2024 00:00:00 +0900

이번에는 Vanilla JS를 이용해 스톱워치를 만들어보자.

스톱워치 모듈

상태 이름	설명
_interval	start() 시 실행되는 setInterval이 리턴하는 intervalID
_centisecond	현재 스톱워치의 시간 (단위: centisecond)
_lapCount	현재 스톱워치의 누적 Lap 갯수
_prevLap	직전 Lap 시간

모듈 메서드 (함수)

메소드 이름	기능	리턴값
centisecond	현재 centisecond 값 가져오기	_centisecond
start	스톱워치 시작하기	null
pause	스톱워치 중단(일시정지)하기	null
createLap	스톱워치 Lap 생성하기	[_lapCount, 현재 Lap 시간]
reset	스톱워치 리셋하기	null

시작, 중단 기능 만들기

시작, 중단 버튼 클릭 이벤트 핸들러는 아래와 같다.

const setTime = (time) => {
    timer.innerText = time;
};

const handleStartStop = () => {
    if (isRunning === false) {
        isRunning = true;
        stopWatch.start();
        setInterval(() => {
            setTime(convertCentiSecondtoMinSecond(stopWatch.centisecond));
        }, 10);
        startStopBtnLabel.innerText = '중단';
        lapResetBtnLabel.innerText = '랩';
    } else {
        isRunning = false;
        stopWatch.pause();
        setTime(stopWatch.centisecond);
        startStopBtnLabel.innerText = '시작';
        lapResetBtnLabel.innerText = '리셋';
    }
    startStopBtn.classList.toggle('bg-green-600');
    startStopBtn.classList.toggle('bg-red-600');

스톱워치가 멈춰있는 경우, stopWatch 객체를 start시키고, 10ms 마다 타이머의 innerText를 업데이트한다.
스톱워치가 구동중인 경우, stopWatch 객체를 pause시킨다.
버튼 클릭시 마다 버튼의 bg 색이 바껴야 하기 때문에 에를 classList의 toggle을 이용해서 구현했다.

랩/리셋 기능 구현하기

랩 L 버튼을 클릭하면 Lap Count가 함께 명시된 랩이 하나씩 기록되면서 최신 Lap이 맨 위에 추가 된다.

const handleLapReset = () => {
    if (isRunning === true) {
        appendLap();
    } else {
        stopWatch.reset();
        setTime(convertCentiSecondtoMinSecond(0));
        clearLaps();
    }
};

const appendLap = () => {
    const [lapCnt, lapTime] = stopWatch.createLap();
    const lap = document.createElement('li');
    lap.setAttribute('data-time', lapTime);
    lap.className = 'flex justify-between py-2 px-3 border-b-2';
    lap.innerHTML = `  
                        <span>랩 ${lapCnt}</span>
                        <span>${convertCentiSecondtoMinSecond(lapTime)}</span>
                    `;
    laps.prepend(lap);

}

최신 lap이 가장 위쪽에 append되어야 하기 때문에 prepend 메서드를 이용했다.

키보드 조작 기능 구현

아래는 키 조작 이벤트 핸들러인 handleKeyDown이다.

document.documentElement.addEventListener('keydown', (e) => handleKeyDown(e));

const handleKeyDown = (e) => {
    console.log(e.code);
    switch (e.code) {
        case 'KeyL':
            handleLapReset();
            break;
        case 'KeyS':
            handleStartStop();
            break;
        default:
            return;
    }
};

최단, 최장 기록 강조 기능 구현

const appendLap = () => {
    ...

    // first
    if (maxLap === undefined) {
        maxLap = lap;
        return;
    }
    // second
    if (minLap === undefined) {
        const maxTime = parseInt(maxLap.getAttribute('data-time'));
        if (lapTime > maxTime) {
            minLap = maxLap;
            maxLap = lap;
        } else {
            minLap = lap;
        }
        maxLap.classList.add('text-red-600');
        minLap.classList.add('text-green-600');
        return;
    }
    const maxTime = parseInt(maxLap.getAttribute('data-time'));
    const minTime = parseInt(minLap.getAttribute('data-time'));
    if (lapTime < minTime) {
        minLap.classList.remove('text-green-600');
        minLap = lap;
    } else if (lapTime > maxTime) {
        maxLap.classList.remove('text-red-600');
        maxLap = lap;
    }
    maxLap.classList.add('text-red-600');
    minLap.classList.add('text-green-600');
};

최단, 최장 Lap 기록은 Lap이 새롭게 추가될때 정해지기 때문에 위에서 구현한 appendLap 함수 내에서 구현했다.
최단, 최장 Lap에 해당하는 HTMLElement를 찾아서 classList로 스타일링을 해야하기 때문에, 전역변수로 minLap과 maxLap을 관리했다.
HTMLElement에는 lapTime에 대한 기록이 없기 때문에 해당 lapTime을 dataSet 객체에 저장했다.
따라서 lap이 하나 추가될때 마다 min/maxLap HTMLElement의 dataSet 객체에 있능 lapTime를 받아서 비교한 후, min/maxLap을 업데이트했다.

완성본

완성본 보러가기

끝!

3장 고급 타입

Mon, 05 Feb 2024 00:00:00 +0900

3.1 타입스크립트만의 독자적 타입 시스템

타입스크립트는 자바스크립트 자료형에서 제시되지 않은 독자적인 타입 시스템을 가지고 있다. 하지만 엄밀히 말하면 타입스크립트의 타입 시스템이 내포하고 있는 개념은 모두 자바스크립트에서 기인한 것이다. 단지 자바스크립트로 표현할 수단과 필요성이 없었을 뿐이다. 자바스크립트의 슈퍼셋으로 정적 타이핑을 할 수 있는 타입스크립트가 등장하면서 비로소 타입스크립트의 타입 시스템이 구축되었다.
이 장에서 소개하는 모든 타입 시스템은 타입스크립트에만 존재하는 키워드지만, 그 개념은 자바스크립트에 기인한 타입 시스템이라는 점을 인지하고 각 타입을 살펴 보자.

3.1.1 any 타입

any 타입은 앞서 말한 대로 자바스크립트에 존재하는 모든 값을 오류 없이 받을 수 있다. 즉, 자바스크립트에서의 기본적인 사용 방식과 같으므로 타입을 명시하지 않은 것과 동일한 효과를 나타낸다.
자연스레 any 타입의 효용성에 대해 의문을 가질 수 있다. 앞의 예시에서 볼 수 있듯이 any 타입은 타입스크립트로 달성하고자 하는 정적 타이핑을 무색하게 만들 수 있다. 타입스크립트는 동적 타이핑 특징을 가진 자바스크립트에 정적 타이핑을 적용하는 것이 주된 목적이지만 any 타입은 이러한 목적을 무시하고 자바스크립트의 동적 타이핑으로 돌아가는 것과 비슷한 결과를 가져온다.
따라서 any 타입을 변수에 할당하는 것은 지양해야 할 패턴으로 알려져 있다. 다시 말해 any 를 회피하는 것은 좋은 습관으로 간주된다. 하지만 타입스크립트에서 any 타입을 어쩔 수 없이 사용해야 할 때가 있는데 대표적으로 3가지 사례를 들 수 있다.
- 개발 단계에서 임시로 값을 지정해야 할 때
  - 매우 복잡한 구성 요소로 이루어진 개발 과정에서 추후 값이 변경될 가능성이 있거나 아직 세부 항목에 대한 타입이 확정되지 않은 경우가 생길 수 있다. 이럴 때 해당 값을 any로 지정하면 경고 없이 개발을 계속할 수 있다. 즉 타입을 세세하게 명시하는 데 소요되는 시간을 절약할 수있다. 하지만 any 타입으로 지정하고 나서 다른 타입으로 바꾸는 과정이 누락되면 문제가 발생할 수 있으므로 주의해야 한다.
- 어떤 값을 받아올지 또는 넘겨줄지 정할 수 없을 때
  - 타입스크립트의 타입을 사용하면 정적 타이핑의 효과를 얻을 수 있다. 그러나 자바스크립트 입장에서는 어떤 값의 타입을 명확하게 지정하기 어려운 상황이 발생할 수 있다. 예를 들어 API 요청 및 응답 처리, 콜백 함수 전달, 타입이 잘 정제되지 않아 파악이 힘든 외부 라이브러리 등을 사용할 때는 어떤 인자를 주고받을지 특정하기 힘들다. 이처럼 주고받을 값이 명확하지 않을 때 열린 타입 （any 타입）을 선언해야 할 수 있다.
- 값을 예측할 수 없을 때 암묵적으로 사용
  - 외부 라이브러리나 웹 API의 요청에 따라 다양한 값을 반환하는 API가 존재할 수 있다. 대표적인 예로 브라우저의 Fetch API> 들 수 있다. Fetch API의 일부 메서드는 요청 이후의 응답을 특정 포맷으로 파싱하는데 이때 반환 타입이 any로 매핑되어 있는 것 을 볼 수 있다.
any 타입은 개발자에게 편의성과 확장성을 제공하기도 하지만 해당 값을 컨트롤하려면 파악해야 할 정보도 많다. 즉 도구의 도움을 받을 수 없는 상태에서 온전히 개발자 스스로 책임을 져야함을 의미한다. 이런 맥락을 이해하지 못하면 협업 시 실수할 가능성이 커진다.

3.1.2 unknown 타입

unknown 타입은 any 타입과 유사하게 모든 타입의 값이 할당될 수 있다. 그러나 any를 제외한 다른 타입으로 선언된 변수에는 unknown 타입 값을 할당할 수 없다. 아래 표는 any와 unknown 타입의 비교 내용을 담고 있다.

let unknownvalue： unknown;
unknownValue = 100; // any 타입과 유사하게 숫자이든
unknownvalue = "hello world"; // 문자열이든
unknownvalue = () =〉console.log("this is any type"); // 함수이든 상관없이 할당이 가능하지만
let someValuel： any = unknownvalue; // (0) any 타입으로 선언된 변수를 제외한 다른 변수는
모두 할당이 불가
let someValue2： number = unknownvalue; // (X)
let someValue3： string = unknownvalue; // (X)

unknown타입은 타입스크립트 3.0이 릴리스 될 때 추가되었는데 기존 타입 시스템에서 부족한 부분을 보완하기 위해 등장했다. unknown에 대응되는 자바스크립트 자료형이 무엇인지 쉽게 떠오르지 않을 만큼 타입스크립트만의 타입 시스템이라고 볼 수 있는데, unknown 타입은 이름처럼 무엇이 할당될지 아직 모르는 상태의 타입을 말한다. 이렇게만 보면 any 타입과 비슷한데 왜 unknown 타입이 추가되었을까?
앞선 예시를 다시 보자. 재미있는 점은 분명 함수를 unknown 타입 변수에 할당할 때는 컴파일러가 아무런 경고를 주지 않지만 이를 실행하면 다음과 같은 에러가 발생한다는 것이다.

// 할당하는 시점에서는 에러가 발생하지 않음
const unknownFunction： unknown = () => console.log("this is unknown type");
// 하지만 실행 시에는 에러가 발생; Error： Object is of type 'unknown’.ts (2571)
unknownFunction();

비단 함수뿐만 아니라 객체의 속성 접근, 클래스 생성자 호출을 통한 인스턴스 생성 등 객체 내부에 접근하는 모든 시도에서 에러가 발생한다. unknown 타입은 어떤 타입이 할당되었는지 알 수 없음을 나타내기 때문에 unkonwn 타입으로 선언된 변수는 값을 가져오거나 내부 속성에 접근할 수 없다. 이는 unknown 타입으로 할당된 변수는 어떤 값이든 올 수 있음을 의미하는 동시에 개발자에게 엄격한 타입 검사를 강제하는 의도를 담고 있다.
any 타입을 사용하면 어떤 값이든 허용된다. 앞서 어떤 값이 할당될지 파악하기 어려운 상황에서 any 타입을 지정하여 임시로 문제를 회피하는 예시도 살펴보았다. 그리고 나중에 any 타입을 특정 타입으로 수정해야 하는 것을 깜빡하고 누락하면 어떤 값이든 전달될 수 있기 때문에 런타임에 예상치 못한 버그가 발생할 가능성이 높아진다는 것도 설명했다.
unknown 타입은 이러한 상황을 보완하기 위해 등장한 타입이다. any 타입과 유사하지만 타입 검사를 강제하고 타입이 식별된 후에 사용할 수 있기 때문에 any 타입보다 더 안전하다. 따라서 데이터 구조를 파악하기 힘들 때 any 타입 대신 unknown 타입으로 대체해서 사용하는 방법이 권장된다.
unknown은 어떨 때 사용할 수 있을까요?
- 강제 타입 캐스팅을 통해 타입을 전환할 때 사용합니다. const env = process.env unknown as ProcessEnv 같은 식으로요.
- 예상할 수 없는 데이터라면 unknown을 씁니다. 타입스크립트 4.4부터 try— catch 에러의 타입이 any에서 unknown으로 변경되어서 에러 핸들링할 때도 unknown을 사용합니다. 한편 as unknown as Type같이 강제 타입 캐스팅율 하기도 하는데 사실 이것도 any와 다를 바 없어서 지양해야합니다.

3.1.3 void 타입

다른 정적 타입 언어에서 void라는 타입을 이미 접해본 적이 있다면 이해하기 쉬울 것이다. 타입스크립트에서 함수가 어떤 값을 반환하지 않는 경우에는 void를 지정하여 사용한다고 생각하면 된다.

3.1.4 never 타입

never 타입도 일반적으로 함수와 관련하여 많이 사용되는 타입이다. never라는 단어가 내포하고 있는 의미처럼 never 타입은 값을 반환할 수 없는 타입을 말한다. 여기서 값을 반환하지 않는 것과 반환할 수 없는 것을 명확히 구분해야 한다. 자바스크립트에서 값을 반환할 수 없는 예는 크게 2가지로 나눌 수 있다.
- 에러를 던지는 경우
  - throw 키워드를 사용하면 에러를 발생시킬 수 있는데, 이는 값을 반환하는 것으로 간주하지 않는다. 따라서 특정 함수가 실행 중 마지막에 에러를 던지는 작업을 수행한다면 해당 함수의 반환 타입은 never이다.

function generateError(res： Response)： never {
    throw new Error(res.getMessageO);
}

- 무한히 함수가 실행되는 경우
    - 드물지만 함수 내에서 무한 루프를 실행하는 경우가 있을 수 있다. 무한 루프는 결국 함수가 종료되지 않음을 의미하기 때문에 값을 반환하지 못한다

3.1.5 Array 타입

이미 자바스크립트에서도 확인할 수 있는 자료형 인데도 왜 타입스크립트에서 다시 배열을 다루는지 의문이 들 수 있을 것이다. 타입스크립트에서 다시 Array를 언급하는 이유를 다음과 같이 제시할 수 있다.
- 엄밀히 말하면 자바스크립트에서는 배열을 객체에 속하는 타입으로 분류한다. 즉, 자바스크립트에서는 배열을 단독으로 배열이라는 자료형에 국한하지 않는다.
- 타입스크립트에서 Array라는 타입을 사용하기 위해서는 타입스크립트의 특수한 문법을 함께 다뤄야 핸다.
앞서 설명한 대로, 자바스크립트의 배열은 동적 언어의 특징에 따라 어떤 값이든 배열의 원소로 허용한다. 즉, 하나의 배열로 선언된 변수에 숫자, 문자열, 객체 등 자료형이 무엇이든 상관없이 원소를 삽입하고 관리할 수 있다.
타입스크립트에서는 일반적으로 배열의 크기까지 제한하지는 않지만 정적 타입의 특성을 살려 명시적인 타입을 선언하여 해당 타입의 원소를 관리하는 것을 강제한다.
2가지 방식으로 배열 타입을 선언할 수 있는데 두 방식 간의 차이점은 선언하는 형식 외에는 없다. 개인의 선호나 팀의 컨벤션에 따라 하나의 방식으로 통일하거나 2가지 방식을 혼용해서 사용해도 큰 문제는 없다.
기본적으로 자바스크립트의 동작은 배열 원소의 타입을 구분하지 않기 때문에 다양한 자료형의 원소를 함께 다룰 수 있는데, 만약 숫자형과 문자열 등 여러 타입을 모두 관리해야 하는 배열을 선언하려면 유니온 타입을 사용할 수 있다.

const arrayl： Array<number | string> = [1, "string"];
const array2: number[] | string[] = [1, "string"];
// 후자의 방식은 아래와 같이 선언할 수도 있다
const arrays： (number | string)[] = [1, "string"];

앞서 언급한 대로 타입스크립트에서 배열 타입을 명시하는 것만으로 배열의 길이까지는 제한할 수 없다. 그러나 튜플은 배열 타입의 하위 타입으로 기존 타입스크립트의 배열 기능에 길이 제한까지 추가한 타입 시스템이라고 볼 수 있다.
튜플은 타입스크립트의 타입 시스템과 대괄호를 사용해서 선언할 수 있다. 대괄호 안에 타입시스템을 기술하는 것이 배열 타입과 유일하게 다른 점이다. 이때 대괄호 안에 선언하는 타입의 개수가 튜플이 가질 수 있는 원소의 개수를 나타낸다. 즉, 튜플은 배열의 특정 인덱스에 정해진 타입을 선언하는 것과 같다.

let tuple： [number] = [1]；
tuple = [1, 2]; // 불가능
tuple = [1, "string"]; // 불가능
let tuple： [number, string, boolean] = [1, "string", true]; // 여러 타입과 혼합도 가능하다

기본적으로 타입스크립트에서의 배열과 튜플은 자바스크립트와 달리 제한적으로 쓰인다. 배열은 사전에 허용하지 않은 타입이 서로 섞이는 것을 방지하여 타입 안정성을 제공한다. 튜플은 길이까지 제한하여 원소 개수와 타입을 보장한다.
이처럼 타입을 제한하는 것은 자바스크립트가 갖는 동적 언어의 자유로움으로 인해 발생할 수 있는 런타임 에러와 유지보수의 어려움을 막기 위한 것이다. 특히 튜플의 경우 컨벤션을 잘 지키고 각 배열 원소의 명확한 의미와 쓰임을 보장할 때 더욱 안전하게 사용할 수 있는 타입이다.
튜플의 유용한 쓰임새를 알아보기 위해 사용자 인터페이스를 만들기 위한 자바스크립트 라이브러리인 리액트 예시를 살펴보자. 리액트는 16.8 버전부터 도입된 훅이라는 요소 중 UseState는 튜플 타입을 반환한다. 첫 번째 원소는 훅으로부터 생성 및 관리되는 상태 값을 의미하고, 두 번째 원소는 해당 상태를 조작할 수 있는 세터(setter)를 의미한다.

3.1.6 enum 타입

enum 타입은 열거형이라고도 부르는데 타입스크립트에서 지원하는 특수한 타입이다. enum이라는 키워드는 다른 언어에서도 사용하는 개념이기에 익숙할 수 있을 것이다. enum은 일종의 구조체를 만드는 타입 시스템이다.
기본적인 추론 방식은 숫자 0부터 1씩 늘려가며 값을 할당하는 것이다. 또한 각 멤버에 명시적으로 값을 할당할 수 있다. 모든 멤버에 일일이 값을 할당할 수도 있지만, 일부 멤버에 값을 직접 할당하지 않아도 타입스크립트는 누락된 멤버를 아래와 같은 방식으로 이전 멤버 값의 숫자를 기준으로 1씩 늘려가며 자동으로 할당한다.

enum ProgrammingLanguage {
Typescript = "Typescript",
Javascript = "Javascript",
Java = 300,
Python = 400,
Kotlin, // 401
Rust, // 402
Go, // 403
}
ProgrammingLanguage[300]； // "Java"

enum 타입은 주로 문자열 상수를 생성하는 데 사용된다. 이를 통해 응집력 있는 집합 구조체를 만들 수 있으며, 사용자 입장에서도 간편하게 활용할 수 있다. 또한 열거형은 그 자체로 변수 타입으로 지정할 수 있다. 이때 열거형을 타입으로 가지는 변수는 해당 열거형이 가지는 모든 멤버를 값으로 받을 수 있다. 이런 특성은 코드의 가독성을 높여준다.
다만 열거형에 사용할 때는 주의해야 할 점이 있다. 먼저 숫자로만 이루어져 있거나 타입스크립트가 자동으로 추론한 열거형은 안전하지 않은 결과를 낳을 수 있다. 맨 처음 예시를 보면 역방향으로도 접근할 수 있음을 보여준다. 여기서 할당된 값을 넘어서는 범위로 역방향으로 접근하더 라도 타입스크립트는 막지 않는다.
이러한동작을 막기 위해 const enum으로 열거형을 선언하는 방법이 있다. 이 방식은 역방향으로의 접근을 허용하지 않기 때문에 자바스크립트에서의 객체에 접근하는 것과 유사한 동작을 보장한다.

ProgrammingLanguage[200]; // undefined를 출력하지만 별다른 에러를 발생시키지 않는다
// 다음과 같이 선언하면 위와 같은 문제를 방지할 수 있다
const enum ProgrammingLanguage {
    // ...
}

그러나 const enum으로 열거형을 선언하더라도 숫자 상수로 관리되는 열거형은 선언한 값 이외의 값을 할당하거나 접근할 때 이를 방지하지 못한다. 반면 문자열 상수 방식으로 선언한 열거형은 미리 선언하지 않은 멤버로 접근을 방지한다. 따라서 문자열 상수 방식으로 열거형을 사용하는 것이 숫자 상수 방식보다 더 안전하며 의도하지 않은 값의 할당이나 접근을 방지하는 데 도움이 된다.

const enum NUMBER {
    ONE = 1,
    TWO = 2,
}
const myNumber: NUMBER = 100; // NUMBER enum에서 100을 관리하고 있지 않지만 이는 에러를 발생시키지 않는다
const enum STRING_NUMBER {
ONE = "ONE",
TWO = "TWO",
}
const myStringNumber： STRING_NUMBER = "THREE"; // Error

3.2 타입 조합

이 절에서는 앞에서 다룬 개념을 응용하거나 약간의 내용을 덧붙여 좀 더 심화한 타입 검사를 수행하는 데 필요한 지식을 살펴본다.

3.1.1 교차 타입(Intersection)

교차 타입을 사용하면 여러 가지 타입을 결합하여 하나의 단일 타입으로 만들 수 있다. 다시 말해 기존에 존재하는 다른 타입들을 합쳐서 해당 타입의 모든 멤버를 가지는 새로운 타입을 생성하는 것이다. 교차 타입은 &을 사용해서 표기한다. 결과물로 탄생한 단일 타입에는 타입 별칭(type alias)을 붙일 수도 있다.
아래처럼 ProductItemWithDiscount 타입의 변수를 선언하고 값을 할당하면 Productltem의 모든 멤버와 discountAmount까지 멤버로 가지게 된다.

type Productltem = {
    id： number;
    name: string;
    type: string;
    price： number；
    imageUrl： string；
    quantity： number;
}；

type ProductItemWithDiscount = Productitem & { discountAmount: number };

3.1.2 유니온 타입(Union)

교차 타입 (A & B)이 타입 A와 타입을 모두 만족하는 경우라면, 유니온 타입은 타입 A 또는 타입 B 중 하나가 될 수 있는 타입을 말하며 A | B 같이 표기한다. 주로 특정 변수가 가질수 있는 타입을 전부 나열하는 용도로 사용된다.
교차 타입과 마찬가지로 2개 이상의 타입을 이어 붙일 수 있고 타입 별칭을 통해 중복을 줄일 수도 있다. 아래 예시는 Productitem 혹은 Carditem이 될 수 있는 유니온 타입인 PromotionEventltem을 나타낸다. 즉, 이벤트 프로모션의 대상으로 상품이 될 수도 있고 카드가 될 수도 있다는 의미이다.

type Cardltem = {
    id： number;
    name： string；
    type: string;
    imageUrl： string;
}；
type PromotionEventltem = Productltem | Cardltem;

const printPromotionltem = (item： PromotionEventltem) => {
    console.log(itein.name); // 0
    console.log(iteni.quantity); // 컴파일 에러 발생
};

3.1.3 인덱스 시그니처(Index Signatures)

인덱스 시그니처는 특정 타입의 속성 이름은 알 수 없지만 속성값의 타입을 알고 있을 때 사용하는 문법이다. 인터페이스 내부에 [Key: K]: T 꼴로 타입을 명시해주면 되는데 이는 해당 타입의 속성 키는 모두 K 타입이어야 하고 속성값은 모두 T 타입을 가져야 한다는 의미다.

interface IndexSignatureEx {
[key： string]： number;
}

인덱스 시그니처를 선언할 때 다른 속성을 추가로 명시해줄 수 있는데 이때 추가로 명시된 속성은 인덱스 시그니처에 포함되는 타입이어야 한다.

interface IndexSignatureEx2 {
    [key： string]： number | boolean;
    length： number;
    isValid： boolean;
    name： string; // 에러 발생
}

3.1.4 인덱스드 액세스 타입(Indexed Access Types)

인덱스드 엑세스 타입은 다른 타입의 특정 속성이 가지는 타입을 조회하기 위해 사용된다. 아래 첫 번째 예시 (IndexedAccess)는 Example 타입의 a 속성이 가지는 타입을 조회하기 위한 인덱스드 엑세스 타입이다. 인덱스에 사용되는 타입 또한 그 자체로 타입이기 때문에 유니온 타입, keyof, 타입 별칭 등의 표현을 사용할수 있다.

type Example = {
    a： number；
    b： string;
    c： boolean；
};
type IndexedAccess = Example["a"];
type IndexedAccess2 = Example["a" | "b"]; // number | string
type IndexedAccessB = Example[keyof Example]; // number | string | boolean
type ExAlias = "b" | "c";
type IndexedAccess4 = Exainple[ExAlias]; // string | boolean
type IndexedAccess2 = Example["a" | "b"]; // number | string
type IndexedAccessB = Example[keyof Example]; // number | string | boolean
type ExAlias = "b" | "c";
type IndexedAccess4 = Example[ExAlias]; // string ! boolean

3.1.5 맵드 타입(Mapped Types)

보통 map이라고 하면 유사한 형태를 가진 여러 항목의 목록 A를 변환된 항목의 목록으로 바꾸는 것을 의미한다. 이와 마찬가지로 맵드 타입은 다른 타입을 기반으로 한 타입을 선언할 때 사용하는 문법인데, 인덱스 시그니처 문법을 사용해서 반복적인 타입 선언을 효과적으로줄일 수 있다.

type Example = {
    a： number;
    b: string;
    c： boolean;
};

type Subset<T> = {
[K in keyof T]?: T[K];
};
// keyof Example = a | b | c
// T[K] : 프로퍼티 'K'의 타입을 'T'에서 가져옴

const aExample： Subset<Example> = { a: 3 };
const bExample: Subset<Example> = { b： "hello" };
const acExample: Subset<Example> = { a： 4, c： true };

맵드 타입이 실제로 사용된 예시를 살펴보자. 배달의민족 선물하기 서비스에는 ‘바텀시트’ 라는 컴포넌트가 존재한다. 밑에서부터 스르륵 올라오는 모달이라고 생각하면 되는데 이 바텀시트는 선물하기 서비스의 최근 연락처 목록, 카드 선택, 상품 선택 등 여러 지면에서 사용되고 있다. 바텀시트마다 각각 resolver, isOpened 등의 상태를 관리하는 스토어가 필요한데 이 스토어의 타입 (BottomSheetStore)을 선언해줘야 한다.
이때 BottomSheetMap에 존재하는 모든 키에 대해 일일이 스토어를 만들어줄 수도 있지만 불필요한 반복이 발생하게 된다. 이럴 때는 인덱스 시그니처 문법을 사용해서 BottomSheetMap을 기반으로 각 키에 해당하는 스토어를 선언할수 있다. 이처럼 반복 작업을 효율적으로 처리할 수있다.

const BottomSheetMap = {
    RECENT_CONTACTS: RecentContactsBottomSheet,
    CARD_SELECT: CardSelectBottomSheet,
    SORT_FILTER： SortFilterBottomSheet,
    PRODUCT_SELECT: ProductSelectBottomSheet,
    REPLY_CARD_SELECT: ReplyCardSelectBottomSheet,
    RESEND： ResendBottomSheet,
    STICKER： StickerBottomSheet,
    BASE: null,
};

export type BOTTOM_SHEET_ID = keyof typeof BottomSheetMap;
// "RECENT.CONTACTS" | "CARD.SELECT" | "SORT_FILTER" | "PRODUCT.SELECT" | "REPLY_CARD_SELECT" | "RESEND" | "STICKER" | "BASE";

// 불필요한 반복이 발생한다
type BottomSheetStore = {
RECENT_CONTACTS: {
    resolver?: (payload： any) => void;
    args?： any;
    isOpened： boolean;
};
CARD_SELECT: {
    resolver?: (payload： any) => void;
    args?; any;
    isOpened： boolean;
}；
SORT_FILTER: {
    resolver?： (payload: any) => void;
    args?： any;
    isOpened: boolean;
}；
// ...
}；

// Mapped Types를 통해 효율적으로 타입을 선언할 수 있다
type Bottomsheetstore = {
    [index in BOTTOM_SHEET_ID]: {
        resolver?： (payload： any) => void;
        args?: any;
        isOpened： boolean；
    }；
}；

덧붙여 맵드 타입에서는 as 키워드를 사용하여 키를 재지정할 수 있다. 앞서 봤던 바텀시트를 다시 살펴보자. BottomSheetStore의 키 이름에 BottomSheetMap의 키 이름을 그대로 쓰고 싶은 경우가 있을 수 있고, 모든 키에 _BOTTOM_SHEET를 붙이는 식으로 공통된 처리를 적용하여 새로운 키를 지정하고 싶을 수도 있다. 이럴 때는 아래 예시처럼 as 키워드를 사용해서 효율적으로 처리할 수 있다.

type BottomSheetStore = {
    [index in BOTTOM_SHEET_ID as '${index}_BOTTOM_SHEET']: {
        resolver?: (payload： any) => void;
        args?： any;
        isOpened： boolean;
    }；
}；

3.1.6 템플릿 리터럴 타입(Template Literal Types)

템플릿 리터럴 타입은 자바스크립트의 템플릿 리터럴 문자열을 사용하여 문자열 리터럴 타입을 선언할 수 있는 문법이다.

type Stage =
| "init"
| "select-image"
| "edit-image"
| "decorateord"
| "capture-image";
type StageName = `${Stage}-stage`;
// 'init-stage' i 'select-image-stage' ! ’edit-image-stage' i 'decorate-card-stage'i
’capture-image-stage'

3.1.7 제네릭(Generic)

제네릭Generic은 C나 자바 같은 정적 언어에서 다양한 타입 간에 재사용성을 높이기 위해 사용하는 문법이다. 타입스크립트도 정적 타입을 가지는 언어이기 때문에 제네릭 문법을 지원하고 있다.
좀 더 자세히 타입스크립트 제네릭의 개념을 풀어보면 함수, 타입, 클래스 등에서 내부적으로 사용할 타입을 미리 정해두지 않고 타입 변수를 사용해서 해당 위치를 비워 둔 다음에, 실제로 그 값을 사용할 때 외부에서 타입 변수 자리에 타입을 지정하여 사용하는 방식을 말한다.
이렇게 하면 함수, 타입, 클래스 등 여러 타입에 대해 하나하나 따로 정의하지 않아도 되기 때문에 재사용성이 크게 향상된다.

type ExampleArrayType<T> = T[];
const arrayl： ExampleArrayType<string> = ["치킨", "피자", "우동"];

앞서 제네릭이 일반화된 데이터 타입을 말한다고 했는데, 이 표현만 보면 any의 쓰임과 혼동할 수도 있을 것이다. 하지만 둘은 명확히 다르다. 둘의 차이는 배열을 떠올리면 쉽게 알 수 있다.
any 타입의 배열에서는 배열 요소들의 타입이 전부 같지 않을 수 있다. 쉽게 말해 타입 정보를 잃어버린다고 생각하면 편하다. 즉, any를 사용하면 타입 검사를 하지 않고 모든 타입이 허용되는 타입으로 취급된다. 반면에 제네릭은 any처럼 아무 타입이나 무분별하게 받는 게 아니라, 배열 생성 시점에 원하는 타입으로 특정할 수 있다. 다시 말해 제네릭을 사용하면 배열 요소가 전부 동일한 타입이 라고 보장할 수 있다.
또한 특정 요소 타입을 알 수 없을 때는 제네릭 타입에 기본값을 추가할 수 있다.

interface SubmitEvent<T = HTMLElement> extends SyntheticEvent<T> { submitter： T;

}

다시 언급하지만 제네릭은 일반화된 데이터 타입을 의미한다고 했다. 따라서 함수나 클래스 등의 내부에서 제네릭을 사용할 때 어떤 타입이든 될 수 있다는 개념을 알고 있어야 한다.
특정한 타입에서만 존재하는 멤버를 참조하려고 하면 안된다. 예를 들어 배열에만 존재하는 length 속성을 제네릭에서 참조하려고 하면 당연히 에러가 발생한다. 컴파일러는 어떤 타입이 제네릭에 전달될지 알 수 없기 때문에 모든 타입이 length 속성을 사용할 수는 없다고 알려주는 것이다.

function exampleFunc2<T>(arg： T)： number {
return arg.length; // 에러 발생: Property 'length' does not exist on type 'T'
}

이럴 때는 제네릭 꺾쇠괄호 내부에 “length 속성을 가진 타입만 받는다”라는 제약을 걸어줌으로써 length 속성을 사용할 수 있게끔 만들 수 있다.

interface TypeWithLength {
    length： number;
}
function exampleFunc2<T extends TypeWithLength>(arg: T): number {
    return arg.length;
}

제네릭을 사용할 때 주의해야 할 점이 있다. 파일 확장자가 tsx일 때 화살표 함수에 제네릭을 사용하면 에러가 발생한다. tsx는 타입스크립트 + JSX이므로 제네릭의 꺾쇠괄호와 태그의 꺾쇠괄호를 혼동하여 문제가 생기는 것이다. JSX에서는 태그를 나타내는 데 꺾쇠괄호(<>)를 사용한다.
이러한 상황을 피하기 위해서는 제네릭 부분에 extends 키워드를 사용하여 컴파일러에게 특정 타입의 하위 타입만 올 수 있음을 확실히 알려주면 된다. 보통 제네릭을 사용할 때는 function 키워드로 선언하는 경우가 많다.

// 에러 발생: JSX element 'T' has no corresponding closing tag
const arrowExampleFunc = <T>(arg：T): T[] => {
    return new Array(3).fill.(arg);
};

// 에러 발생 X
const arrowExampleFunc2 = <T extends {}>(arg： T)： T[] => {
    return new Array(3).fiVL(arg);
}

3.2 제네릭 사용법

3.2.1 함수의 제네릭

어떤 함수의 매개변수나 반환 값에 다양한 타입을 넣고 싶을 때 제네릭을 사용할 수 있다. 아래 예시처럼 T 자리에 넣는 타입에 따라 ReadOnlyRepository가 적절하게 사용될 수 있다.

function ReadOnlyRepository<T>(target: ObjectType<T> | EntitySchema<T> | string)：
Repository<T> {
    return getConnection("ro").getRepository(target);
}

3.2.2 호출 시그니처의 제네릭

호출 시그니처(call signature)는 타입스크립트의 함수 타입 문법으로 함수의 매개변수와 반환 타입을 미리 선언하는 것을 말한다. 호출 시그니처를 사용할 때 제네릭 타입을 어디에 위치시키는지에 따라 타입의 범위와 제네릭 타입을 언제 구체 타입으로 한정할지를 결정할 수 있다.

interface useSelectPaginationProps<T> {
    categoryAtom： RecoilState<number>;
    filterAtom： RecoilState<string[]>; sortAtom：
    RecoilState<SortType>;
    fetcherFunc： (props： CommonListRequest) => Promise<DefaultResponse<ContentListRes
    ponse<T>>>；
}

여기서 는 useSelectPaginationProps의 타입 별칭으로 한정했다. 따라서 useSelectPaginationProps을 사용할 때 타입을 명시함으로써 제네릭 타입을 구체 타입으로 한정한다.

export type UseRequesterHookType = <RequestData = void, ResponseData = void>(
baseURL?：
string | Headers,
defaultHeader?： Headers
) => [Requeststatus, Requester<RequestData, ResponseData>];

이 예시에서 <RequestData, ResponseData>는호출 시그니처의 일부, 다시 말해 괄호 앞에 선언했기 때문에 타입스크립트는 UseRequesterHookTyp은 타입의 함수를 실제 호출할 때 제네릭 타입을 구체 타입으로 한정한다.

3.2.3 제네릭 클래스

제네릭 클래스는 외부에서 입력된 타입을 클래스 내부에 적용할 수 있는 클래스이다. 제네릭 클래스는 다음과 같은 형태로 선언된다.

class LocalDB<T> {
    // ...
    async put(table： string, row： T)： Promise<T> {
        return new Promise<T>((resolved, rejected) => { /* T 타입의 데이터를 DB에 저장 */ });
    }
    async get(table:string, key： any)： Promise<T> {
        return new Promise<T>((resolved, rejected) => { /* T 타입의 데이터를 DB에서 가져옴 */
         })；
    }
    async getTable(table： string)： Promise<T[]> {
        return new Promise<r[]>((resolved, rejected) => { /* T[] 타입의 데이터를 DB에서 가져옴*/ })
    }
}

export default class IndexedDB implements ICacheStore {
    private _DB?： LocalDB<{ key： string; value： Promise<Record<string, unknown>>;
    cacheTTL: number }>;
    private DB() {
        if (!this._DB) {
            this._DB = new LocalDB("localCache", { ver: 6, tables; [{ name: TABLE_NAME,
            keyPath： "key" }] });
        }
        return this._DB;
    }
    //...
}

클래스 이름 뒤에 타입 매개변수인 를 선언해준다. 는 메서드의 매개변수나 반환 타입으로 사용될 수 있다. LocalDB 클래스는 외부에서 { key： string; value: Promise<Record<string, unknown>>; cacheTTL： number } 타입을 받아들여 클래스 내부에 서 사용될 제네릭 타입으로 결정된다.
제네릭 클래스를 사용하면 클래스 전체에 걸쳐 타입 매개변수가 적용된다. 특정 메서드만을 대상으로 제네릭을 적용하려면 해당 메서드를 제네릭 메서드로 선언하면 된다.

3.2.4 제한된 제네릭

타입스크립트에서 제한된 제네릭은 타입 매개변수에 대한 제약 조건을 설정하는 기능을 말한다. 예를 들어 string 타입으로 제약하려면 타입 매개변수는 특정 타입을 상속(extends)해야한다.

type ErrorRecord<Key extends string> = Exclude<Key, ErrorCodeTypo extends never
? Partial<Record<Key, boolean>>
: never；

이처럼 타입 매개변수가 특정 타입으로 묶였을 때(bind) 키를 바운드 타입 매개변수(bounded type parameters)라고 부른다. 그리고 String을 키의 상한 한계(upper bound)라고 한다. 상속받을 수 있는 타입으로는 기본 타입뿐만 아니라 상황에 따라 인터페이스나 클래스도 사용할 수 있다. 또한 유니온 타입을 상속해서 선언할 수도 있다.

3.2.5. 확장된 제네릭

제네릭 타입은 여러 타입을상속받을 수 있으며 타입 매개변수를 여러 개 둘수도 있다.

 <Key extends string>

타입을 이런 식으로 제약해버리면 제네릭의 유연성을 잃어버린다. 제네릭의 유연성을 잃지 않으면서 타입을 제약해야 할 때는 타입 매개변수에 유니온 타입을 상속해서 선언하면 된다.

 <Key extends string | number>

유니온 타입으로 Key가 여러 타입을 받게 할 수는 있지만, 타입 매개변수가 여러 개일 때는 처리할 수 없다. 이럴 때는 매개변수를 하나 더 추가하여 선언한다.

3.2.6. 제네릭 예시

제네릭의 장점은 다양한 타입을 받게 함으로써 코드를 효율적 재사용할 수 있는 것이다. 그렇다면 실제 현업에서 가장 많이 제네릭이 활용할 때는 언제일까? 바로 API 응답 값의 타입을 지정할때이다.
우아한형제들에서는 API 응답 값의 타입을 지정할 때 제네릭을 활용하여 적절한 타입 추론과 코드의 재사용성을높이고 있다.

export interface MobileApiResponse<Data> {
    data： Data;
    statusCode： string；
    statusMessage?： string;
}

이 코드를 살펴보면 API 응답 값에 따라 달라지는 data를 제네릭 타입 Data로 선언하고 있다. 이렇게 만든 MobileApiResponse는 실제 API 응답 값의 타입을 지정할 때 아래와 같이 사용되고 있다.

export const fetchPriceInfo = (): Promise<MobileApiResponse<PriceInfo>> => {
    const priceUrl = "https：~~~" // url 주소
    return request({
        method： "GET",
        url： priceUrl,
    })；
}；

export const fetchOrderlnfo = ()： Promise<MobileApiResponse<Order>> => {
    const orderUrl =  "https：~~~" // url 주소
    return requests({
        method: "GET",
        url： orderUrl,
    })；
};

이처럼 다양한 API 응답 값의 타입에 MobileApiResponse을 활용해서 코드를 효율적으로 재사용할 수 있다.
이런 식으로 제네릭을 필요한 곳에 사용하면 가독성을 높이고 코드를 효율적으로 작성할 수 있다. 하지만 굳이 필요하지 않은 곳에 제네릭을 사용하면 오히려 독이 되어 코드를 복잡하게 만든다.

제네릭을 굳이 사용하지 않아도 되는 타입

제네릭이 필요하지 않을 때도 사용하면 코드 길이만 늘어나고 가독성을 해칠 수 있다. 다음은 제네릭이 굳이 필요하지 않은데도 사용한 예시다.

type GType<T> = T;
type RequirementType = "USE" | "UN_USE" | "NON_SELECT"；
interface Order {
    getRequirement()： GType<RequirementType>;
}

GType이 다른 곳에서는 사용되지 않고 getRequirement 함수의 반환 값 타입으로만 사용되고 있다고 가정해보자.
GType이라는 이름이 현재 사용되고 있는 목적의 의미를 정확히 담고 있지도 않을뿐더러 굳이 제네릭을 사용하지 않고 타입 매개변수를 그대로 선언하는 것과 같은 기능을 하고 있다. 즉, 아래처럼 사용하는 것과동일하다.

type RequirementType = "USE" | "UN_USE" | "NON_SELECT"；
interface Order {
    getRequirement()： RequirementType;
}

any 사용하기

제네릭은 코드의 재사용성을 높이고 타입 추론을 하는 데 사용된다. 그러나 any를 사용하면 제네릭의 장점과 타입 추론 및 타입 검사를 할 수 있는 이점을 누릴 수 없게 된다. any 타입은 모든 타입을 허용하기 때문에 사실상 자바스크립트와 동일한 방식으로 코드를 작성하는 것과 같다. 따라서 any를 사용하면 제네릭을 포함해 타입을 지정하는 의미가 사라지게 된다.

type ReturnType<T = any> = {
    // ...
};

가독성을 고려하지 않은 사용

제네릭이 과하게 사용되면 가독성을 해치기 때문에 코드를 읽고 타입을 이해하기가 어려워진다. 부득이한 상황을 제외하고 복잡한 제네릭은 의미 단위로 분할해서 사용하는 게 좋다.
만약에 내가 작성한 코드를 다른 개발자가 쉽게 이해하지 못하고 있다면 혹시 제네릭을 오남용하고 있는 것은 아닌지 검토해봐야 한다.

끝!

2장 타입

Mon, 05 Feb 2024 00:00:00 +0900

2.1 타입이란

2.1.1 자료형의로서의 타입

프로그래밍 언어에서 변수란 값을 저장할 수 있는 공간’이자 값을 가리키는 상징적인 이름이다. 개발자는 변수를 선언하고 그 변수에 특정한 값인 데이터를 할당한다. 데이터 타입은 여러 종류의 데이터를 식별하는 분류 체계로 컴파일러에 값의 형태를 알려준다. 메모리에 저장된 값을 데이터 타입으로 설명할 수 있으며 모든 데이터를 해석할 때 데이터 타입 체계가 사용된다.

2.1.2 자료형의로서의 타입

프로그래밍에서의 타입은 수학의 집합과 유사하다. 타입은 값이 가질 수 있는 유효한 범위의 집합을 말한다.
어떤 값이 T 타입이라면 컴파일러 (또는 개발자)는 이 값으로 어떤 일을 할 수 있고, 어떤 일을 할 수 없는지를 사전에 알 수 있다. 타입 시스템은 코드에서 사용되는 유효한 값의 범위를 제한해서 런타임에서 발생할 수 있는 유효하지 않은 값에 대한 에러를 방지해준다.

2.1.3 정적 타입과 동적 타입

만약 자바스크립트만을 사용했다면 변수와 값을 다룰 때 타입은 고려하지 않고 코드를 작성했을 수도 있다. 그러나 자바스크립트에도 분명히 타입이 존재한다. 다만 개발자가 컴파일 이전 에 타입을 직접 정의해줄 필요가 없었을 뿐이다. 타입을 결정하는 시점에 따라 타입을 정적 타입(static type)과 동적 타입(dynamic type)으로 분류할 수 있다.
정적 타입 시스템에서는 모든 변수의 타입이 컴파일타임에 결정된다. 코드 수준에서 개발자가 타입을 명시해줘야 하는 C, 자바, 타입스크립트 등이 정적 타입 언어에 속한다. 조금 번거롭게 느껴지기도 하지만 컴파일타임에 타입 에러를 발견할 수 있기 때문에 프로그램의 안정성을 보장할수 있다.
동적 타입 시스템에서는 변수 타입이 런타임에서 결정된다. 파이썬, 자바스크립트가 대표적인 동적 타입 언어로 개발자는 직접 타입을 정의해줄 필요가 없다. 프로그램을 실행할 때 타입 에러가 발견되기 때문에 개발 과정에서 에러 없이 마음껏 코드를 작성할 수 있지만 언제 프로그램에 오류가 생길지 모르는 불안감에 휩싸이게 된다.

2.1.4 강타입과 약타입

타입이 결정되는 시점은 다르지만 모든 프로그래밍 언어에는 값의 타입이 존재한다. 개발자가 의도적으로 타입을 명시하거나 바꾸지 않았는데도 컴파일러 또는 엔진 등에 의해서 런타임에 타입이 자동으로 변경되는 것을 암묵적 타입 변환(Implicit coercion conversion)이 라고 한다.
암묵적 타입 변환 여부에 따라 타입 시스템을 강타입과 약타입으로 분류할 수 있다. 강타입 특징을 가진 언어에서는 서로 다른 타입을 갖는 값끼리 연산을 시도하면 컴파일러 또는 인터프리터에서 에러가 발생한다. 이에 반해 약타입 특징을 갖는 언어에서 서로 다른 타입을 갖는 값끼리 연산할 때는 컴파일러 또는 인터프리터가 내부적으로 판단해서 특정 값의 타입을 변환하여 연산을 수행한 후 값을 도출한다.
결론적으로 C++, 자바, 자바스크립트는 약타입 언어로 파이썬, 루비, 타입스크립트는 강타입 언어로 분류할 수 있다.
암묵적 변환은 개발자가 명시적으로 타입을 변환하지 않아도 다른 데이터 타입끼리 연산을 진행할 수 있는 편리함을 제공하지만, 작성자의 의도와 다르게 동작할 수 있기 때문에 예기치 못한 오류가 발생할 가능성도 높아진다.
자바스크립트는 약타입 언어이기 때문에 런타임에서 발생할 수 있는 에러를 예측하고 방지하는 코드를 작성하는 것이 프로그램을 안전하게 만드는 데 도움이 된다. 여기서 ‘안전한’이라는 표현은 타입 안정성을 의미한다. 타입을 사용해서 프로그램이 유효하지 않은 작업을 수행하지 않도록 방지하는 것이다. 타입을 명시해서 코드를 작성한 후에는 프로그램 내에 기술된 개발자의 의도가 논리적으로 합당한지 검사하는 기준이 필요하다.
타입 검사기가 프로그램에 타입을 할당하는 데 사용하는 규칙 집합을 타입 시스템이라고 한다. 타입 시스템은 크게 두 가지로 구분한다. 어떤 타입을 사용하는지를 컴파일러에 명시적으로 알려줘야 하는 타입 시스템이 있고, 자동으로 타입을 추론하는 타입 시스템도 있다. 타입스크립트에서 사용하는 타입 시스템은 뒤에서 구체적으로 살펴볼 것이다.

2.1.5 컴파일 방식

컴파일의 일반적인 의미는 사람이 이해할 수 있는 방식으로 작성한 코드를 컴퓨터가 이해할 수 있는 기계어로 바꿔주는 과정을 말한다. 즉 개발자가 자바, C# 등의high-level 언어로 소스코드를 작성하면, 컴파일러는 컴퓨터가 해석할 수 있는 바이너리 binary 코드로 변환한다. 바이너리는 0과 1로 이루어진 이진 코드를 말한다. 언어마다 컴파일 과정과 단계에 조금씩 차이가 있지만 기본적으로 컴파일은 서로 다른 수준（고수준-저수준） 간의 코드 변환을 의미한다.
그러나 타입스크립트의 컴파일 결과물은 여전히 사람이 이해할 수 있는 방식인 자바스크립트 파일이다. 타입스크립트가 탄생한 이유는 사람이 이해하기 쉬운 방식으로 코드를 작성하기 위해서가 아니라 자바스크립트의 컴파일타임에 런타임 에러를 사전에 잡아내기 위한 것이다. 타입스크립트를 컴파일하면 타입이 모두 제거된 자바스크립트 소스코드만이 남게 된다.
자바는 그 자체로 언어지만 타입스크립트를 자바스크립트에 타입이라는 레이어를 끼얹은 일종의 템플릿 언어(Template Languages) 또는 확장(Extensions) 언어로 해석하는 의견도 있다.

2.2 타입스크립트의 타입 시스템

2.2.1 타입 애너테이션 방식

타입 애너테이션이란 변수나 상수 혹은 함수의 인자와 반환 값에 타입을 명시적으로 선언해서 어떤 타입 값이 저장될 것인지를 컴파일러에 직접 알려주는 문법이다.

let isDone： boolean = false;
let decimal： number = 6;
let color: string = "blue";

타입스크립트는 기존 자바스크립트 코드에 점진적으로 타입을 적용할 수 있는 특징을 가지고 있다. 위의 예시에서 : type 선언부를 제거해도 코드가 정상적으로 동작한다. 하지만 타입을 제거하면 타입스크립트 타입 시스템이 타입 추론을 하는 과정에서 어려움을 겪을 것이다.

2.2.2 구조적 타이핑

타입을 사용하는 여러 프로그래밍 언어에서 값이나 객체는 하나의 구체적인 타입을 가지고 있다. 타입은 이름으로 구분되며 컴파일타임 이후에도 남아있다. 이것을 명목적으로 구체화한 타입 시스템이라고 부르기도 한다.
또한 서로 다른 클래스끼리 명확한 상속 관계나 공통으로 가지고 있는 인터페이스가 없다면 타입은 서로 호환되지 않는다.
그러나 타입스크립트에서 타입을 구분하는 방식은 조금 다르다. 이름으로 타입을 구분하는 명목적인 타입 언어의 특징과 달리 타입스크립트는 구조로 타입을 구분한다. 이것을 구조적 타이핑이라고 한다.

2.2.3 구조적 서브타이핑

앞서 타입스크립트의 타입 시스템을 집합으로 이해할 수 있다고 언급했었다. 타입스크립트의 타입은 값의 집합으로 생각할 수 있다. 타입은 단지 집합에 포함되는 값이고 특정 값은 많은 집합에 포함될 수 있다. 따라서 타입스크립트에서는 특정 값이 string 또는 number 타입을 동시에 가질 수 있다.

 type stringOrNumber = string | number;

이처럼 집합으로 나타낼 수 있는 타입스크립트의 타입 시스템을 지탱하고 있는 개념이 바로 구조적 서브타이핑이다.
구조적 서브타이핑이란 객체가 가지고 있는 속성（프로퍼티)을 바탕으로 타입을 구분하는 것이다. 이름이 다른 객체라도 가진 속성이 동일하다면 타입스크립트는 서로 호환이 가능한 동일한 타입으로 여긴다.

interface Pet {
    name： string;
}
let cat = { name： "Zag", age: 2 };
function greet(pet： Pet) {
    console.log("Hello, " + pet.name);
}

greet(cat);

위와 같은 타이핑 방식이 구조적 타이핑이다. 이 절의 제목인 구조적 서브타이핑에서도 알 수 있듯이 타입스크립트의 서브타이핑, 즉 타입의 상속 역시 구조적 타이핑을 기반으로 하고 있다.
서로 다른 두 타입 간의 호환성은 오로지 타입 내부의 구조에 의해 결정된다. 타입 A가 타입 B의 서브타입이라면 A 타입의 인스턴스는 B 타입이 필요한 곳에 언제든지 위치할 수 있다. 즉, 타입이 계층구조로부터 자유롭다.

2.2.4 자바스크립트를 닮은 타입스크립트

타입스크립트의 타입 시스템은 구조적 서브타이핑을 사용한다고 했다. 이것은 명목적 타이핑과는 대조적인 타이핑 방식이다. 명목적 타이핑은 타입의 구조가 아닌 타입의 이름만을 가지고 구별하는 것으로 C++, 자바 등에서 사용한다.
명목적 타이핑은 타입의 동일성을 확인하는 과정에서 구조적 타이핑에 비해 조금 더안전하다. 개발자가 의도한 타입이 아니라면 변수에 타입을 명시하는 과정에서 에러를 내뱉기 때문이다. 즉, 객체의 속성을 다른 객체의 속성과 호환되지 않도록 하여 안전성을 추구한다.
그런데도 타입스크립트가 구조적 타이핑을 채택한 이유는 타입스크립트가 자바스크립트를 모델링한 언어이기 때문이다. 자바스크립트는 본질적으로 덕 타이핑(duck typing)을 기반으로 한다. 덕 타이핑은 어떤 함수의 매개변숫값이 올바르게 주어진다면 그 값이 어떻게 만들어졌는지 신경 쓰지 않고 사용한다는 개념이다.
타입스크립트는 이런 동작을 그대로 모델링한다. 타입스크립트는 자바스크립트의 특징을 그대로 받아들여 명시적인 이름을 가지고 타입을 구분하는 대신 객체나 함수가 가진 구조적 특징을 기반으로 타이핑하는 방식을 택했다. 구조적 타이핑 덕분에 타입스크립트는 더욱 유연한 타이핑이 가능해졌다. 쉬운 사용성과 안전성이라는 두 가지 목표 사이의 균형을 중시하는 타입스크립트에서는 객체 간 속성이 동일하다면 서로 호환되는 구조적 타입 시스템을 제공하여 더욱 편리성을높였다.
덕 타이핑과 구조적 타이핑의 차이는 타입을 검사하는 시점에 있다. 덕 타이핑은 런타임에 타입을 검사한다. 자바스크립트는 덕 타이핑 언어다. 구조적 타이핑은 컴파일타임에 타입체커가 타입을 검사한다.

2.2.5 구조적 타이핑의 결과

interface Cube {
    width: number;
    height： number;
    depth： number;
}

function addLines(c： Cube) {
    let total = 0;
    for (const axis of Object.keys(c)) {
        // * Element implicitly has an 'any' type
        // because expression of type 'string' can’t be used to index type 'Cube'
        //•No index signature with a parameter of type 'string'
        // was found on type 'Cube'
        const length = c[axis];
        total += length;
    }
}

c에 들어올 객체는 Cube의 width, height, depth 외에도 어떤 속성이든 가질 수있기 때문에 c[axis]의 타입이 string일 수도 있어 에러가 발생한다. 즉, 타입스크립트는 c[axis]가 어떤 속성을 지닐지 알 수 없으며 c[axis] 타입을 number라고 확정할 수 없어서 에러를 발생시킨다.

2.2.6 타입스크립트의 점진적 타입 확인

타입스크립트는 점진적으로 타입을 확인하는 언어다. 점진적 타입 검사란 컴파일 타임에 타입을 검사하면서 필요에 따라 타입 선언 생략을 허용하는 방식이다. 타입을 지정한 변수와 표현식은 정적으로 타입을 검사하지만 타입 선언이 생략되면 동적으로 검사를 수행한다. 타입 선언을 생략하면 암시적 타입 변환이 일어난다.
타입스크립트는 자바스크립트의 슈퍼셋 언어이기 때문에 모든 자바스크립트 코드는 타입스크립트 코드라고 봐도 무방하다. 따라서 ts 파일에 자바스크립트 문법으로 소스코드를 작성하더라도 문제가 발생하지 않는다. 특히 타입을 지정하지 않은 자바스크립트 코드를 타입스크립트로 마이그레이션할 때 타입스크립트의 점진적 타이핑이라는 특징을 유용하게 활용할 수 있다.
그러나 이러한 특징 때문에 타입스크립트의 타입 시스템은 정적 타입의 정확성을 100% 보장 해주지 않는다. 모든 변수와 표현식의 타입을 컴파일타임에 검사하지 않아도 되기 때문에 타입이 올바르게 정해지지 않으면 런타임에서 에러가 발생하기도 한다.

2.2.7 자바스크립트 슈퍼셋으로서의 타입스크립트

타입스크립트는 기존 자바스크립트 코드에 정적인 타이핑을 추가한 것으로 자바스크립트의 상위 집합이다.
모든 자바스크립트 코드는 타입스크립트라고 볼 수 있지만 반대로 모든 타입스크립트 코드가 자바스크립트 코드인 것은 아니다. 다시 말하지만 타입스크립트는 타입을 명시하는 문법을 가지고 있기 때문이다.

2.2.8 값 vs 타입

값은 프로그램이 처리하기 위해 메모리에 저장하는 모든 데이터다. 다르게 말하면 프로그램에서 조작하고 다룰 수 있는 어떤 표현이며 다양한 형태의 데이터를 포함한다. 프로그래밍 관점에서는 문자열, 숫자, 변수, 매개변수 등이 값에 해당한다.

11; // 숫자 값
"hello typescript"; // 문자열 값
let foo = "bar"; // 변숫값

객체 역시 값이다. 그리고 자바스크립트에서는 함수도 값이다. 모든 것이 객체인 언어답게 자바스크립트 함수는 런타임에 객체로 변환되기 때문이다.
앞서 언급한 대로 함수 역시 값으로 볼 수 있다. 위 예시에서 정의된 함수 goWork를 다른 방식으로 정의하면 다음과 같다.

 //함수
const goWork = function (developer) {
    console.log(`tired ${developer}`);
};

함수 역시 변수에 할당할 수 있는 값임을 알 수 있다. 자바스크립트 대신 타입스크립트를 사용하게 되면서 타입이라는 개념이 등장한다. 타입스크립트는 변수, 매개변수, 객체 속성 등에 : type 형태로 타입을 명시한다.
또는 type이나 interface 키워드로 커스텀 타입을 정의할수도 있다.

type Person = {
    name： string;
    age： number;
}；
interface Person {
    name： string;
    age： number;
}

값 공간과 타입 공간의 이름은 서로 충돌하지 않기 때문에 타입과 변수를 같은 이름으로 정의 할 수 있는데 타입스크립트가 자바스크립트의 슈퍼셋인 것과 관련이 있다. 타입스크립트 문법인 type으로 선언한 내용은 자바스크립트 런타임에서 제거되기 때문에 값 공간과 타입 공간은 서로충돌하지 않는다.
타입스크립트에는 앞서 언급한 대로 타입과 값이 혼용되는 것 말고도 값과 타입 공간에 동시에 존재하는 심볼도 있다. 대표적인 것이 클래스와 enum이다.
타입스크립트에서 헷갈리는 것 중 하나가 클래스에 관한 것이다. 자바스크립트 ES6에서 등장한 클래스는 객체 인스턴스를 더욱 쉽게 생성하기 위한 문법 기능으로 실제 동작은 함수와 같다.

class Rectangle {
    constructor(height, width) {
        this.height = height;
        this.width = width;
    }
}
const rect1 = new Rectangle(5, 4);

동시에 클래스는 타입으로도 사용된다. 즉 타입스크립트 코드에서 클래스는 값과 타입 공간 모두에 포함될 수 있다.

 class Developer {
    name： string;
    domain： string;
    constructor(name： string, domain: string) {
        this.name = name;
        this.domain = domain;
    }
}
const me： Developer = new Developer("zig", "frontend”);

변수명 me 뒤에 등장하는 : Developer에서 Developer는 타입에 해당하지만 new 키워드 뒤의 Developer는 클래스의 생성자 함수인 값으로 동작한다. 타입스크립트에서 클래스는 타입 애너테이션으로 사용할 수 있지만 런타임에서 객체로 변환되어 자바스크립트의 값으로 사용되는 특징을 가지고 있다.
타입스크립트에서 어떠한 심볼이 값으로 사용된다는 것은 컴파일러를 사용해서 타입스크립트 파일을 자바스크립트 파일로 변환해도 여전히 자바스크립트 파일에 해당 정보가 남아있음을 의미한다. 반면 타입으로만 사용되는 요소는 컴파일 이후에 자바스크립트 파일에서 해당 정보가 사라진다.

2.2.9 타입을 확인하는 방법

타입스크립트에서 typeof, instanceof 그리고 타입 단언을 사용해서 타입을 확인할 수 있다. typeof는 연산하기 전에 피연산자의 데이터 타입을 나타내는 문자열을 반환한다. typeof 연산자가 반환하는 값은 자바스크립트의 7가지 기본 데이터 타입 （Boolean, null, undefined, Number, Bigint, String. Symbol）과 Function（함수）, 호스트 객체 그리고 object 객체가 될 수 있다.

typeof 2022； // "number”
typeof "woowahan"; // "string”
typeof true; // "boolean"
typeof {}; // "object"

타입스크립트에는 값 공간과 타입 공간이 별도로 존재한다. 타입스크립트에서 typeof 연산자도 값에서 쓰일 때와 타입에서 쓰일 때의 역할이 다르다.

interface Person {
    first： string;
    last： string;
}
const person： Person = { first： "zig", last： "song" }；
function email(options: { person： Person; subject： string; body： string }) {}

값에서 사용된 typeof는 자바스크립트 런타임의 typeof 연산자가 된다.

const vl = typeof person; // 값은 'object'
const v2 = typeof email; // 값은 'function'

예시의 v1과 v2는 const 키워드로 선언된 변수로 값이 할당될 공간이다. 값 공간의 typeof는 피연산자인 person과 email의 런타임 타입을 가리키는 문자열을 반환한다. 즉, 값에서 사용된 typeof 연산자는 자바스크립트 typeof 연산자와 동일하게 동작한다.
반면 타입에서 사용된 typeof는 값을 읽고 타입스크립트 타입을 반환한다.

type T1 = typeof person; // 타입온 Person
type T2 = typeof email; // 타입은 (options： { person： Person; subject： string; body：
string; }) => void

person 변수가 interface Person 타입으로 선언되었기 때문에 타입 공간에서의 typeof person은 Person을 반환한다. email 함수는 타입 공간에서 typeof 연산자로 값을 읽을 때 함수의 매개변수 타입과 리턴 타입을 포함한 함수 시그니처 타입을 반환한다.
자바스크립트 클래스는 typeof 연산자를 쓸 때 주의해야 한다. 앞서 선언한 Developer 클래스를 다시 보자.

class Developer {
    name： string;
    sleepingTime： number;
    constructor(name： string, sleepingTime： number) {
        this.name = name;
        this.sleepingTime = sleepingTime;
    }
}
const d = typeof Developer; // 값이 'function'
type T = typeof Developer; // 타입이 typeof Developer

자바스크립트의 클래스는 결국 함수이기 때문에 값 공간에서 typeof Developer의 값은 function이 된다. 타입 공간에서 typeof Developer의 반환 값은 조금 특이한데 type T에 할당된 Developer는 인스턴스의 타입이 아니라 new 키워드를 사용할 때 볼 수 있는 생성자 함수이기 때문이다.

const zig： Developer = new Developer("zig", 7);
type ZigType = typeof zig; // 타입이 Developer

Developer 클래스로 생성한 zig 인스턴스는 Developer가 인스턴스 타입으로 생성되었기 때문에 타입 공간에서의 typeof zig 즉, type ZigType은 Developer를 반환한다.
자바스크립트에서 instanceof 연산자를 사용하면 프로토타입 체이닝 어딘가에 생성자의 프로토타입 속성이 존재하는지 판단할 수 있다. typeof 연산자처럼 instanceof 연산자의 필터링으로 타입이 보장된 상태에서 안전하게 값의 타입을 정제하여 사용할 수 있다.
타입스크립트에서는 타입 단언이라 부르는 문법을 사용해서 타입을 강제할 수도 있는데 as 키워드를 사용하면 된다. 타입 단언은 개발자가 해당 값의 타입을 더 잘 파악할 수 있을 때 사용되며 강제 형 변환과 유사한 기능을 제공한다.

2.3 원시 타입

앞서 말했듯이 타입스크립트는 자바스크립트의 슈퍼셋이기 때문에 자바스크립트와 대응되는 부분이 많지만 차이점도 있다.
자바스크립트에서 값은 타입을 가지지만 변수는 별도의 타입을 가지지 않는다. 따라서 자바스크립트의 변수에는 어떤 타입의 값이라도 자유롭게 할당할 수 있다. 타입스크립트는 이 변수에 타입을 지정할 수 있는 타입 시스템 체계를 구축한다.

2.3.2/3 undefined vs. null

type Person1 = {
    name: string;
    job?: string;
}；
type Person2 = {
    name： string；
    job： string | null;
}；

모든 사람은 이름과 직업을 가진다고 가정해보자. 사람마다 현업에 종사하고 있을 수도 있고 무직일 수도 있다. Person1은 job이라는 속성이 있을 수도 또는 없을 수도 있음을 나타낸다. 즉, job이라는 속성 유무를 통해 무직인지 아닌지를 나타낸다
Person2는 job이라는 속성을 사람마다 갖고 있지만 값이 비어있을 수도 있다는 것을 나타낸다. 따라서 명시적인 null 값을 할당해 무직 인 상태를 나타낸다고 볼 수 있다.

2.3.5 binInt

ES2020에서 새롭게 도입된 데이터 타입으로 타입스크립트 3.2 버전부터 사용할 수 있다. 이전의 자바스크립트에서는 가장 큰 수인 Number.MAX_SAFE_INTEGER(253-1)를 넘어가는 값을 처리할 수 없었는데 bigint를 사용하면 이보다 큰 수를 처리할 수 있다.

2.3.7 Symbol

ES2015에서 도입된 데이터 타입으로 Symbol () 함수를 사용하면 어떤 값과도 중복되지 않는 유일한 값을 생성할 수 있다. 타입스크립트에는 symbol 타입과 const 선언에서만 사용할수 있는 unique symbol 타입이라는 symbol의 하위 타입도 있다.
타입스크립트의 모든 타입은 기본적으로 null과 undefined를 포함하고 있다. 하지만 tsconfig의 strictNullChecks 옵션을 활성화했을 때는 사용자가 명시적으로 해당 타입에 null이나 undefined를 포함해야만 null과 undefined를 사용할 수 있다. 그렇지 않으면 null과 undefined가 될 수 있는 경우에 타입스크립트 에러가 발생하는데 보통 타입 가드로 null과 undefined가 되는 경우를 걸러낸다. ! 연산자를 사용해서 타입을 단언하는 방법도 있다. 이를 통해 사용자는 해당 참조가 null이나 undefined가 아니라고 보장할 수 있다. 일반적으로 타입 가드를 사용하는 것이 더 안전하다고 여겨져 단언문보다 타입 가드가 좀 더 선호되는 경향이 있다.

2.4 객체 타입

앞에서 언급한 7가지 원시 타입에 속하지 않는 값은 모두 객체 타입으로 분류할 수 있다. 자바스크립트에서 객체의 범주는 원시 타입에 비해 굉장히 넓다. 자바스크립트에서는 이런 값을 모두 객체라고 일컫는데 타입스크립트에서는 다양한 형태를 가지는 객체마다 개별적으로 타입을 지정할 수 있다.

2.4.1 object

자바스크립트 객체의 정의에 맞게 이에 대응하는 타입스크립트 타입 시스템은 object 타입이다. object 타입은 가급적 사용하지 말도록 권장되는데 나중에 다룰 any 타입과유사하게 객체에 해당하는 모든 타입 값을 유동적으로 할당할 수 있어 정적 타이핑의 의미가 크게 퇴색되기 때문이다.

2.4.2 {}

중괄호({})는 자바스크립트에서 객체 리터럴 방식으로 객체를 생성할 때 사용한다. 타입스크립트에서 객체를 타이핑할 때도 중괄호를 쓸 수 있는데, 중괄호 안에 객체의 속성 타입을 지정해주는 식으로 사용한다. 이것은 타이핑되는 객체가 중괄호 안에서 선언된 구조와 일치해야한다는 것을 말한다.

 // 정상
const noticePopup： { title: string; description： string } = {
    title： "IE 지원 종료 안내",
    description: "2022.07.15일부로 배민상회 IE 브라우저 치원을 종료합니다.",
}；
// SyntaxError
const noticePopup： { title： string; description： string } = {
    title： "IE 지원 종료 안내",
    description： "2022.07.15일부로 배민상회 IE 브라우저 지원을 종료합니다.",
    startAt; "2022.07.15 10:00:00", // startAt은 지정한 타입에 존재하지 않으므로 오류
}；

2.4.3 array

타입스크립트는 자바스크립트 객체를 세분화해서 타입을 지정할 수 있는 타입 시스템을 갖고 있다고 했다. 자바스크립트에서는 흔히 사용하는 객체 자료구조 외에도 배열, 함수, 정규식 등이 객체 범주에 속한다. 타입스크립트에서는 이런 각각의 객체에 타입을 지정할 수 있다
타입스크립트에서는 배열을 array라는 별도 타입으로 다룬다. 타입스크립트 배열 타입은 하나의 타입 값만 가질 수 있다는 점에서 자바스크립트 배열보다 조금 더 엄격하다. 하지만 자바스크립트와 마찬가지로 원소 개수는 타입에 영향을 주지 않는다. 타입스크립트에서 배열 타입을 선언하는 방식은 Array 키워드로 선언하거나 대괄호([])를 사용해서 선언하는 방법이 있다. 두 방식은 결과적으로 같으므로 개인 취향 혹은 팀의 컨벤션에 따라 하나를 선택해서 사용하면 된다.

2.4.4 type과 interface 키워드

앞에서 언급한 타입스크립트 object 타입은 실무에서는 잘 사용하지 않는다. 자바스크립트와 대응되는 예시를 보여주기 위해 언급했을 뿐이다. 객체를 타이핑하기 위해서는 타입스크립트에서만 독자적으로 사용할 수 있는 키워드를 사용하는 게 일반적이다.
흔히 객체를 타이핑하기 위해 자주 사용하는 키워드로 type과 interface가 있다. 중괄호를 사용한 객체 리터럴 방식으로 타입을 매번 일일이 지정하기에는 중복적인 요소가 많다. 앞에서 지정한 noticePopup 객체 타입을 type 또는 interface 키워드를 사용해 다음과 같이 선언하면 반복적으로 사용돼도 중복 없이 해당 타입을 쓸 수 있다.

type NoticePopupType = {
    title: string;
    description： string;
}；
interface INoticePopup {
    title: string;
    description： string;
}

const noticePopupl： NoticePopupType = { ... };
const noticePopup2： INoticePopup = { ... };

type과 interface률 둘 다 쓸 수 있는 상황에서 팀은 주로 어떤 것을 사용하나요?

정해진 컨벤션이 있는 건 아니지만 대부분의 상황에서 interface를 사용하고 있습니다. 하지만 간단한 용도로는 type도 사용합니다. 만약 컨벤션으로 정한다면 공식 문서에 쓰인 내용을 바탕으로 전역적(global)으로 사용할 때는 interface를, 작은 범위 내에서 한정적으로 사용한다면 type을 써도 되지 않을까 하는 생각이 드네요.
type과 interface 둘 다 사용하고 있어요. type은 어떤 값에 대한 정의같이 정적으로 결정되어 있는 것을, interface는 확장될 수 있는 basis를 정의하거나 어떤 object 구성을 설명하는 요소라고 생각해요.
객체 지향적으로 코드를 짤 때. 특히 상속하는 경우에 interface를 사용했던 것 같습니다. 예를 들어 extends나 implements를 사용할 때요.

2.4.5 function

자바스크립트에서는 함수도 일종의 객체로 간주하지만 typeof 연산자로 함수 타입을 출력해보면 자바스크립트는 함수를 function이라는 별도 타입으로 분류한다는 것을 확인할 수 있다.

function add(a, b) {
    return a + b;
}
console.log(typeof add); // 'function'

마찬가지로 타입스크립트에서도 함수를 별도 함수 타입으로 지정할 수 있다. 다만 앞서 살펴본객체의 타이핑과 달리 주의해야 할 점이 있다. 첫째, 자바스크립트에서 typeof 연산자로 확인한 function이라는 키워드 자체를 타입으로 사용하지는 않는다는 것이다. 둘째, 함수는 매개변수 목록을 받을 수 있는데 타입스크립트에서는 매개변수도 별도 타입으로 지정해야 한다.
다음은 이러한 주의 사항을 모두 적용한 함수의 타입 예시다. 마지막으로 함수가 반환하는 값이 있다면 반환 값에 대한 타이핑도 필요하다.

function add (a： number, b： number)： number {
    return a + b;
}

그런데 함수 자체의 타입은 어떻게 지정할 수 있을까? 호출 시그니처를 정의하는 방식을 사용하면 된다.
호출 시그니처?
- 타입스크립트에서 함수 타입을 정의할때 사용하는 문법이다. 함수 타입은 해당 함수가 받는 매개변수와 반환하는 값의 타입으로 결정된다. 호출 시그니처는 이러한 함수의 매개변수와 반환 값의 타입올 명시하는역할을한다.

type add = (a: number, b： number) => number;

호출 시그니처를 들여다보면 자바스크립트의 화살표 함수와 맥락이 유사한 것을 알 수 있다. 일반적으로 자바스크립트에서는 함수를 작성할 때 function 키워드를 사용해서 작성하거나 화살표 함수 방식으로 작성한다. 반면 타입스크립트에서 함수 자체의 타입을 명시할 때는 화살표 함수 방식으로만 호출 시그니처를 정의한다.

끝!

Puppetter와 Cucumber

Sat, 03 Feb 2024 00:00:00 +0900

이번에 UI 테스트를 진행하게 되면서 공부하게된 내용을 정리해본다.

UI 테스트

개발을 할때 테스트에는 여러 유형들이 있다. 테스트 가능한 가장 작은 단위인 함수 하나를 테스트하는 유닛 테스트가 있고, 그 보다 큰 여러 모듈들을 모아 이들이 의도대로 동작하는지 확인하는 통합 테스트가 있다.
UI 테스트란 통합 테스트보다 큰 단위이고, 사용자와 어플리케이션의 상호작용이 원활하게 이루어지는지 테스트를 하는 것이다.(전체 애플리케이션의 흐름 테스트)
사용자 흐름 테스트
- 실제 애플리케이션 사용자가 사용하는 것과 같은 방식으로 일련의 동작을 수행해 보는 테스트다.
사용자 시나이로 검증
- 그래서 UI 테스트는 사용자가 애플리케이션을 사용할 때 겪을 수 있는 다양한 시나리오를 검증한다. 버튼 클릭, 폼 제출, 화면 전환, 텍스트 입력 등의 인터페이스 요소들이 기대한 대로 작동하는지 확인할수 있다.

Puppeteer

Puppeteer는 Google에서 개발한 Node.js 라이브러리로 Headless Chrome 또는 Chromium을 제어할 수 있다.
- Headless Chrome??
  - Headless Chrome은 사용자 인터페이스 없이 백그라운드에서 실행되는 구글 크롬 브라우저를 말한다. 즉, 화면에 아무것도 표시되지 않지만, 일반 Chrome 브라우저와 동일한 기능을 수행할 수 있다.
  - 주로 웹 스크래핑, 자동화된 테스트, 성능 모니터링, CI/CD 파이프라인 등에서 사용됩니다.
따라서 Puppeteer는 브라우저를 프로그래밍 방식으로 제어할 수 있게 하여, 다음과 같은 다양한 작업을 자동화할 수 있다.
- 웹 페이지 탐색 및 상호작용
- 스크린샷 및 PDF 생성
- 웹 페이지 콘텐츠 스크랩
- 퍼포먼스 테스트 및 트러블슈팅
Puppeteer의 주요 기능
- Headless 브라우저 제어: UI 없이 백그라운드에서 브라우저를 실행할 수 있으며, 필요에 따라 UI를 활성화할 수도 있다.
- DOM 조작: JavaScript를 사용하여 웹 페이지의 DOM 요소를 탐색하고 조작할 수 있다.
- 네트워크 요청 조작: 요청을 가로채고, 수정하고, 응답을 시뮬레이트할 수 있다.

Cucumber(오이)

참고 : https://cucumber.io/docs/guides/overview/
오이처럼 시원하게 BDD를 지원한다하여 Cucumber라고 한다.(?ㅋㅋ)
Cucumber는 BDD(Behavior Driven Development) 프레임워크로, 비즈니스 이해 관계자와 개발자 간의 소통을 원활하게 하기 위해 자연어 형식의 시나리오를 테스트 코드로 변환한다.
- BDD(Behavior Driven Development)??
  - TDD(Test Drviven Development)는 테스트를 먼저 작성하고 그 테스트를 통과시키는 코드를 작성하는 흐름을 기본으로 한다. 게다가 테스트 단위도 함수 단위로 매우 작아서 작성하는 거의 모든 함수가 테스트 대상에 포함된다. 이상적으로 보일 수 있지만 그만큼 현업에서 사용하기에는 괴리감이 있다.
  - 프로젝트 초기에 야심 차게 TDD를 도입하여 거의 모든 함수에 대한 테스트 케이스를 준비했더라도 개발 중후반에 수정되는 내용에 대해서 깨지는 테스트 케이스를 계속 유지하면서 가져가기란 쉽지 않다.
- BDD는 시나리오를 기반으로 테스트 케이스를 작성하며 함수 단위 테스트를 권장하지 않는다. 이 시나리오는 개발자가 아닌 사람이 봐도 이해할 수 있을 정도의 레벨을 권장한다. 하나의 시나리오는 Given, When, Then 구조를 가지는 것을 기본 패턴으로 권장하며 각 절의 의미는 다음과 같다.

Feature : 테스트에 대상의 기능/책임을 명시한다.

Scenario : 테스트 목적에 대한 상황을 설명한다.

Given : 시나리오 진행에 필요한 값을 설정한다.

When : 시나리오를 진행하는데 필요한 조건을 명시한다.

Then : 시나리오를 완료했을 때 보장해야 하는 결과를 명시한다

그럼 실제 Scenario를 보자.

Scenario: Breaker guesses a word
  Given the Maker has chosen a word
  When the Breaker makes a guess
  Then the Maker is asked to score

각 시나리오는 Cucumber가 수행해야 할 단계 목록이다. Cucumber가 시나리오를 이해하려면 Gherkin 이라는 몇 가지 기본 구문 규칙을 따라야 합니다.

Gherkin

- Gherkin은 Cucumber가 이해할 수 있을 만큼 구조화된 일반 텍스트를 만드는 문법 규칙 집합이다. - **Gherkin 문서는 .feature 형태의 텍스트 파일로 저장**되며 일반적으로 소프트웨어와 함께 소스 제어에서 버전이 관리된다. 

Step Definition

feature(Gherkin step)에서 정의한 시나리오를 StepDefinition이라는 클래스 파일을 통해 프로그래밍 코드로 구현된다.
각 단계는 실제로 테스트 코드들을 포함하고 있으며, Gherkin 언어로 작성된 시나리오와 매핑된다.

끝!

1장 들어가며

Sat, 03 Feb 2024 00:00:00 +0900

1.1 웹 개발의 역사

1.1.2 자바스크립트 표준, ECMA Script의 탄생

그러면 어떻게 자바스크립트가 브라우저에서 널리 사용되기 시작했을까? 경쟁 관계이던 넷스케이프와 마이크로소프트는 자신들의 브라우저에 새로운 기능을 빠르게 늘리기 시작했는데 이렇게 추가된 기능은 각자의 브라우저에서만 동작했다. 특히 인터넷 익스플로러와 내비게이터의 DOM 구조는 완전히 다르기 때문에 브라우저마다 웹 페이지가 다르게 동작하거나 제대로 동작하지 않는 크로스 브라우징Cross Browsing 이슈가 발생했다. 따라서 개발자는 어 떤 기능을 추가하기 위해서는 두 개의 스크립트를 따로 개발해야 하는 어려움을 겪어야만 했다.
또한 초기의 자바스크립트는 브라우저 생태계를 고려해서 작성된 것이 아니었고 단지 새로운 기능이 추가되는 형태로 발전했다. 이에 따라 자바스크립트와 브라우저의 발전 속도 간의 차이가 나기 시작했고 결국 브라우저는 자바스크립트의 변화를 따라가지 못했다. 자바스크립트 에 어떤 기능이 추가된다면 런타임 환경인 브라우저도 이 기능을 지원할 수 있어야 한다.
새로운 버전의 브라우저가 출시되어 자바스크립트의 새로운 기능을 지원하더라도 사용자가 예전 버전의 브라우저를 사용한다면 이 기능은 무용지물이 된다. 이런 문제를 해결하기 위해 자바스크립트에 폴리필(Polyfill)과 트랜스파일(transpile) 같은 개념이 등장하기도 했다.
- 풀리필（Polyfill） 과 트랜스파일（transpile）
  - 폴리필은 브라우저가 지원하지 않는 코드를 브라우저에서 사용할 수 있도록 변환한 코드 조각이나，플러그인울 말한다. 트랜스파일은 최신 버전의 코드를 예전 버전의 코드로 변환하는 과정을 말한다. 둘 다 최신 기능을 구버전의 실행 환경에서 동작할 수 있게 바꿔주는 역할을 한다.
하지만 언제까지나 이런 라이브러리에 기대어 크로스 브라우징 이슈를 해결할 수는 없었고 모든 브라우저에서 동일하게 동작하는 표준화된 자바스크립트의 필요성이 제기되었다.
넷스케이프는 컴퓨터 시스템의 표준을 관리하는 Ecma 인터내셔널 （국제 표준화 기구）에 자바스크립트의 표준화를 위한 자바스크립트 기술 규격을 제출했고, Ecma 인터내셔널은 ECMAScript라는 이름으로 자바스크립트 표준화를 공식화했다. 자바스크립트가 표준화되자 정적이던 웹사이트에서 동적인 웹 애플리케이션으로의 전환이 가속화되었다.

1.1.3 웹사이트에서 웹 애플리케이션으로의 전환

웹사이트

중요한 것은 웹사이트는 수집된 데이터 및 정보를 특정 페이지에 표시하기 위한 정적인 웹이라는 것이다. 단방향으로 정보를 제공하기 때문에 사용자와 상호 작용하지 않으며, HTML에 링크가 연결된 웹 페이지 모음으로 콘텐츠가 동적으로 업데이트되지 않는다.

웹 애플리케이션

웹 애플리케이션은 사용자와 상호작용하는 쌍방향 소통의 웹을 말한다. 현재 우리가 접하는 대부분의 웹사이트는 웹 애플리케이션이지만, 본격적으로 웹 애플리케이션 시대의 서막을 연 서비스 중 하나가 구글 지도(Google Maps)였다. 기존의 지도 서비스는 이미 만들어져 있는 지도를 브라우저가 다운로드해서 보여주는 형태였는데, 구글 지도는 길을 찾기 위해 사용자가 직접 출발지와 도착지를 입력할 수 있다는 점에서 쌍방향 소통이 가능한 웹 애플리케이션이다.
이러한 웹의 성장은 개발자가 구현해야 하는 결과물 규모도 이전에 비해 커졌다는 의미이기 도 하다. 하지만 기존의 웹 개발 환경은 단순 정보 모음집 수준의 웹사이트 개발에 맞춰져 있 어서, 수많은 애플리케이션이 동작하는 대규모 웹 애플리케이션을 만드는 데는 적합하지 않았다. 개발 규모가 커진 만큼 개발 생태계도 이런 흐름에 맞춘 변화가 필요했다.

1.1.4 개발 생태계의 발전

거대한 웹 애플리케이션이 등장하면서 개발 환경은 어떻게 변화했을까? 대규모 웹 서비스 개발의 필요성이 커지면서 하나의 웹 페이지를 통으로 개발하는 것이 아니라, 컴포넌트 단위로 개발하는 방식이 생겨났다.
웹 서비스는 점차 페이지에서 애플리케이션의 특성을 가지게 되었다. 서비스 규모가 커짐에 따라 다뤄야 하는 데이터가 폭발적으로 늘어났고, 표현해야 하는 화면도 다양하고 복잡해졌다. 요즘은 수많은 디바이스가 웹과 연결되어 있으며, 웹을 표현하는 디스플레이도 모바일, 패드, 노트북, 랩톱 PC 모니터 등 매우 다양하다. 사용자는 저마다의 디바이스에 최적화된 UX/UI를 기대한다.
이런 상황과 맞물려 앞서 언급한 컴포넌트 베이스 개발Component Based Development（CBD）방법론이 등장했다. CBD는 서비스에서 다루는 데이터를 구분하고 그에 맞는 UI를 표현할 수 있게 컴포넌트 단위로 개발하는 접근 방식이다. 요즘은 작은 컴포넌트를 조합해서 좀 더 큰 컴포넌트를 만들어가는 방식이 주류가 되었다.
컴포넌트는 모듈과 유사하게 하나의 독립된 기능을 재사용하기 위한 묶음이다. 다만 모듈과는 달리 런타임 환경에서 독립적으로 배포 - 실행될 수 있는 단위이다.
작은 기능을 가진 컴포넌트일수록 다른 컴포넌트에 의존하지 않고 독립적으로 존재할 수 있지만, 조합 과정에서 필연적으로 의존성이 생긴다. 따라서 개발자는 컴포넌트 간의 의존성을 파악해야 제대로 컴포넌트를 사용하고 변화에 대응할수 있게 된다.
이런 개발 생태계의 발전과 거대한 동적 웹 서비스의 수요 증가는 자연스럽게 자바스크립트 개발자의 증가로 이어졌다

1.1.5 개발자 협업믜 필요섬 증가

결과물이 커졌기 때문에 서비스를 개발하고 나서 유지보수를 하는 데 협업의 중요성도 높아졌다. 개발에 투입된 인원이 많아질수록 코드를 파악하기 어려워지는 것은 당연지사다. 따라서 거대한 프로덕트를 개발할 때 효과적인 유지보수를 위한 협업 보완책이 필요하게 되었다. 대규모 프로덕트를 개발하고 나서 자바스크립트는 과연 유지보수에 적합한 언어 였을까?

1.2 자바스크립트의 한계

1.2.1 동적 타입 언어

자바스크립트 특징 중 하나가 동적 타입 언어라는 것이다. 이 말은 변수에 타입을 명시적으로 지정하지 않고 코드가 실행되는 런타임에 변숫값이 할당될 때 해당 값의 타입에 따라 변수 타입이 결정된다는 것을 의미한다.

1.2.2 동적 타이핑 시스템의 한계

앞에서 설명한 내용은 자바스크립트를 사용하는 개발자, 즉 사람의 한계라고 바꿔 말할 수 있다.

// 이 함수는 숫자 a, b의 합을 반환한다
const sumNumber = (a, b) => {
    return a + b;
}；
sumNumber(100); // NaN
sumNumberC("a", "b") // ab

어떤 에러도 발생하지 않고 정상적으로 동작한다. 따라서 여전히 정상적인 코드다. 동의하는가? 아마도 주석과 함수 이름 때문에 고개를 갸웃거리게 될 것이다.
자바스크립트 엔진은 이 코드를 문제 없이 실행한다. 왜나하면 자바스크립트는 동적 타입 언어 이자 상당히 관대한 언어이기 때문이다. 동적 타입 언어라는 특성 때문에 sumNumber 함수를 호출할 때 사용되는 인수 값에 따라 a와 b의 타입이 결정된다.
자바스크립트의 관대함은 이뿐만이 아니다. b가 undefined이기 때문에 + 연산자의 피연산 자가 될 수 없지만 오류를 발생시키지 않고, b를 적절한 타입인 NaN으로 형변환한 다음 실행 을 이어 나간다. 따라서 이 코드는 기계 입장에서는 정상적이지만 사람 입장에서는 정상적이지 않은 코드이다. 자바스크립트는 이 문제를 어떻게 해결하려 했을까?

1.2.3 한계 극복을뮈한 해결밤안

거대한 웹 서비스를 개발하는 데 수많은 개발자의 협업이 필요한 상황에서 위와 같은 동적 타이핑 시스템의 한계는 상당한 어려움을 야기했다. 따라서 개발자들은 자바스크립트 인터페이스의 필요성을 느끼게 되었고 JSDoc, propTypes, 다트 같은 해결 방안이 등장했다.

JSDoc

JSDoc은 모듈, 네임스페이스, 클래스, 메서드, 매개변수 등에 대한 API 문서 생성 도구다. 주석에 @ts- check를 추가하면 타입 및 에러 확인이 가능하며 자바스크립트 소스코드에 타입 힌트를 제공하는 HTML 문서를 생성할 수 있다. 하지만 어디까지나 주석의 성격을 지니고 있기 때문에 강제성을 부여해 사용하기 어렵다는 단점이 있다.

propTypes

propTypes는 리액트에서 컴포넌트 props의 타입을 검사하기 위해 사용하는 속성이다. prop에 유효한 값이 전달되었는지 확인할 수 있지만, 전체 애플리케이션의 타입 검사를 하는데는 사용할 수 없다. 또한 리액트라는 특정 라이브러리에서만 사용할 수 있다는 점에서 한계가 있다.

1.2.4 타입스크립트의 등장

시간이 지나 마이크로소프트는 자바스크립트의 슈퍼셋 언어인 타입스크립트를 공개했다. 다트와 달리 자바스크립트 코드를 그대로 사용할 수 있었고, 아래와 같은 단점을 극복할 수 있었기 때문에 많은 환영을 받았다.

안정성 보장

타입스크립트는 정적 타이핑을 제공한다. 컴파일 단계에서 타입 검사를 해주기 때문에 자바스크립트를 사용했을 때 빈번하게 발생하는 타입 에러를 줄일 수 있고, 런타임 에러를 사전에 방지할수 있어 안정성이 크게 높아진다.

개발 생산성 향상

VSCode 등의 IDE에서 타입 자동 완성 기능을 제공한다. 이 기능으로 변수와 함수 타입을 추론할 수 있고, 리액트를 사용할 때 어떤 prop을 넘겨야 하는지 매번 확인하지 않아도 사용부에서 바로 볼 수 있기 때문에 개발 생산성이 크게 향상된다.

협업에 유리

타입스크립트를 사용하면 복잡한 애플리케이션 개발 협업에 유리하다. 타입스크립트는 인터페이스interface, 제네릭Generic 등을 지원흐）는데 인터페이스가 기술되면 코드를 더 쉽게 이해할수 있게 도와준다. 또한 복잡한 애플리케이션일수록 협업하는 개발자 수도 증가하는데 자동 완성 기능이나 기술된 인터페이스로 코드를 쉽게 파악할 수 있다.

자바스크립트에 점진적으로 적용 가능

타입스크립트는 자바스크립트의 슈퍼셋이기 때문에 일괄 전환이 아닌 점진적 도입이 가능하다. 전체 프로젝트가 아닌 일부 프로젝트, 그중에서도 일부 기능부터 점진적으로 도입해볼 수 있다.

끝!

8장 좋은 리액트 코드 작성을 위한 환경 구축하기

Mon, 29 Jan 2024 00:00:00 +0900

8.2 리액트 팀이 권장하는 리액트 테스트 라이브러리

테스트란 개발자가 만든 프로그램이 코딩을 한 의도대로 작동하는지 확인하는 일련의 작업을 의미한다. 테스트를 통해 개발자들은 처음에 설계한 대로 프로그램이 작동하는지 확인할 수 있고, 버그를 사전에 방지할 수 도 있으며, 이후에 잘못된 작동으로 인해 발생하는 비용을 줄일 수도 있다. 그리고 이러한 일련의 테스트를 거친 프로그램은 사용자에게 버그가 최소화된 안정적인 서비스를 제공할 수 있는 원동력이 된다.
프런트엔드와 백엔드 모두 테스팅이 중요하지만 테스트하는 방법과 방법론은 사뭇 다르다. 백엔드의 테스트는 일반적으로 서버나 데이터베이스에서 원하는 데이터를 올바르게 가져올 수 있는지, 데이터 수정 간 교착 상태나 경쟁 상태가 발생하지는 않는지, 데이터 손실은 없는지, 특정 상황에서 장애가 발생하지 않는지 등을 확인하는 과정이 주를 이룬다. 이러한 백엔드 테스트는 일반적으로 화이트박스 테스트로, 작성한 코드가 의도대로 작동하는지 확인해야 하며, 이는 GUI가 아닌 AUI（Application User Interface； 응용 프로그램 사용자 인터페이스）에서 주로 수행해야 하기 때문에 어느 정도 백엔드에 대한 이해가 있는 사람만 가능하다.
반면 프런트엔드는 일반적인 사용자와 동일하거나 유사한 환경에서 수행된다. 사용자가 프로그램에서 수행할 주요 비즈니스 로직이나 모든 경우의 수를 고려해야 하며, 이 과정에서 사용자는 굳이 프런트엔드 코드를 알 필요는 없다. 즉, 블랙박스 형태로 테스트가 이뤄지며, 코드가 어떻게 됐든 상관없이 의도한 대로 작동하는지를 확인하는 데 좀 더 초점이 맞춰져 있다. 그리고 시나리오가 어느 정도 정해져 있는 백엔드와는 다르게, 프런트엔드는 사용자에게 완전히 노출된 영역이므로 어떻게 작동할지 최대한 예측해서 확인해야 한다. 사용자는 개발자의 의도대로만 사용하지 않기 때문이다.
프런트엔드 개발은 HTML, CSS와 같이 디자인 요소뿐만 아니라 사용자의 인터랙션, 의도치 않은 작동 등 브라우저에서 발생할 수 있는 다양한 시나리오를 고려해야 하기 때문에 일반적으로 테스팅하기가 매우 번거롭고 손이 많이 가는 작업이다. 그리고 이러한 특징 때문에 제공되는 테스팅 라이브러리도 상당히 다양한 편이다. 단순히 함수나 컴포넌트 수준에서 유닛 테스트를 할 수도 있고, 사용자가 하는 작동을 모두 흉내 내서 테스트할 수도 있다.
이번 절에서는 리액트로 개발된 애플리케이션을 테스팅하는 방법, 특히 가장 널리 사용되는 React Testing Library 위주로 살펴본다. 리액트 개발 환경에서 테스트를 수행하는 방법을 살펴보고, 어떤 도움을 얻을 수 있는지 알아보자.

8.2.1 React Testing Library란?

React Testing Library（이하 리액트 테스팅 라이브러리）란 DOM Testing Librar를 기반으로 만들어진 테스팅 라이브러리로, 리액트를 기반으로 한 테스트를 수행하기 위해 만들어졌다. 리액트 테스팅 라이브러리를 이해하려면 먼저 리액트 테스팅 라이브러리가 기반으로 하는 DOM Testing Library에 대해 먼저 알아둬야 한다. DOM Testing Library는 jsdom을 기반으로 하고 있다. jsdom이란 순수하게 자바스크립트로 작성된 라이브러리로, HTML이 없는 자바스크립트만 존재하는 환경, 예를 들어 Node.js 같은 환경에서 HTML과 DOM을 사용할 수 있도록 해주는 라이브러리다. jsdom을 사용하면 자바스크립트환경에서도 HTML을 사용할 수 있으므로 이를 기반으로 DOM Testing Library에서 제공하는 API를 사용해 테스트를 수행할 수 있다. 다음 예제 코드를 보자.

const jsdom = require('jsdom')
const { JSDOM } = jsdom
const dom = new JSDOM('<!DOCTYPE html><p>Hello world</p>')
console.log(dom.window.docuinent.querySelector('p').textcontent) // "Hello world"

이처럼 jsdom을 사용하면 마치 HTML이 있는 것처럼 DOM을 불러오고 조작할 수 있다.
jsdom을 사용해 자바스크립트 환경에서 HTML을 사용할 수 있는 DOM Testing Library를 기반으로, 동일한 원리로 리액트 기반 환경에서 리액트 컴포넌트를 테스팅할 수 있는 라이브러리가 바로 리액트 테스팅 라이브러리다. 리액트 테스팅 라이브러리를 활용하면 실제로 리액트 컴포넌트를 렌더링하지 않고도, 즉 브라우저를 직접 실행해 눈으로 확인하지 않아도 리액트 컴포넌트가 원하는 대로 렌더링되고 있는지 확인할 수 있다.

8.2.2 자바스크립트테스트의기초

본격적으로 리액트 테스트 코드를 작성하기에 앞서, 먼저 자바스크립트에서 테스트 코드는 어떻게 작성하는지에 대해 먼저 알아보자. 만약 인수 두 개의 합을 더하는 함수를 만들었다고 가정해 보자.

function sum(a, b) {
    return a + b
}

이 함수에 대한 테스트 코드를 작성한다면 어떻게 작성해야 할까? 테스트 코드를 작성하기에 잎•서 테스트 코드가 무엇인지 상기하자. 테스트 코드란 내가 작성한 코드가 내가 코드를 작성했던 당시의 의도와 목적에 맞는지 확인하는 코드를 의미한다. 그런 의미에서 sum 함수에 대해서는 다음과 같은 테스트 코드를 작성해 볼 수 있을 것이다.

// 테스트 1
// 함수를 실행했을 때의 실제 결과
let actual = suin(l, 2)
// 함수를 실행했을 때 기대하는 결과
let expected = 3
if (expected != actual) {
    throw new Error('${expected} is not equal to ${actual}')
}
// 테스트 2
actual = sum(2, 2)
expected = 4
if (expected !== actual) {
    throw new Error('${expected} is not equal to ${actual}')
}

테스트 코드를 작성하는 방식, 테스트 코드에 사용되는 인수 등 코드의 세세한 부분에는 조금씩 차이가 있겠지만 기본적인 테스트 코드를 작성하는 방식은 다음과 같은 과정을 거친다는 점에서 비슷할 것이다.
- 1) 테스트할 함수나 모듈을 선정한다.
- 2) 함수나 모듈이 반환하길기대하는 값을 적는다.
- 3) 함수나 모듈의실제반환 값을 적는다.
- 4) 3번의 기대에 따라 2 번의 결과가 일치하는지 확인한다.
- 5) 기대하는 결과를 반환한다면 테스트는 성공이며. 만약 기대와 다른 결과를 반환하면 에러를 던친다.
이를 위해 가장 먼저 필요한 것이 “작성한 코드가 예상대로 작동한다면 성공했다는 메시지가 출력되고, 실패하면 에러를 던진다”라는 작동을 대신해 주는 라이브러리다. 다행히도 Node.js는 assert라는 모듈을 기본적으로 제공하며, 이 모듈을 사용하면 위와 같이 작동하도록 만들 수 있다.

const assert = require('assert')
function suni(a, b) {
    return a + b
}
assert.equal(sum(l, 2), 3)
assert.equal(sum(2, 2), 4)
assert.equal(sum(l, 2), 4) // AssertionError [ERR_ASSERTION] [ERR_ASSERTION]: 3

일반적으로 테스트 코드와 실제 코드는 분리해 작성한다. 테스트 결과를 확인할 수 있도록 도와주는 라이브러리를 어설션(assertion) 라이브러리라고 한다. 이러한 어설션 라이브러리에는 Node.js가 제공하는 assert 외에도 should, js, expect, js, chai 등 다양하다. 테스트 코드를 작성하는 개발자들은 이러한 어설션을 활용해 다양한 시나리오를 작성하고, 이 시나리오상에서 코드가 올바르게 작동하는지 확인할 수 있다.
그렇다면 이 어설션 라이브러리만 존재한다면 테스트 코드를 작성할 준비가 다 끝난 것일까? 그렇지 않다. 테스트 코드는 가능한 한 사람이 읽기 쉽게, 그리고 테스트의 목적이 분명하게 작성되는 것이 중요하다. 앞에서 직성한 sum을 테스트하는 assert 모듈과 assert.equal 함수만으로도 어느 정도 테스트 코드의 목적을 달성했다고 볼 수도 있다. 그러나 테스트 코드가 실행되는 것을 지켜보는 입장에서는 다르다. 예를 들어, 앞의 테스트 코드가 CI 환경에서 자동으로 실행되게 만들었다고 가정해 보자. 테스트 코드가 정상적으로 작동하고, 테스트도 모두 통과하겠지만 무엇을 테스트했는지, 무슨 테스트를 어떻게 수행했는지 등 테스트에 관한 실제 정보를 알 수는 없다. 즉, 좋은 테스트 코드는 다양한 테스트 코드가 작성되고 통과하는 것뿐만 아니라 어떤 테스트가 무엇을 테스트하는지 일목요연하게 보여주는 것도 중요하다.
이러한 테스트의 기승전결을 완성해 주는 것이 바로 테스팅 프레임워크다. 테스팅 프레임워크들은 어설션을 기반으로 테스트를 수행하며, 여기에 추가로 테스트 코드 작성자에게 도움이 될 만한 정보를 알려주는 역할도 함께 수행한다. 자바스크립트에서 유명한 테스팅 프레임워크로는 Jest, Mocha, Karma, Jasmine 등이 있다. 그리고 리액트 진영에서는 리액트와 마찬가지로 메타에서 작성한 오픈소스 라이브러리인 Jest”가 널리 쓰이고 있다. Jest의 경우 자체적으로 제작한 expect 패키지를 사용해 어설션을 수행한다.
Node.js의 assert만 사용했을 때는 단순히 실패에 대해서만 단편적인 정보로 알 수 있었지만Jest를 비롯한 테스트 프레임워크를 사용하면 무엇을 테스트했는지. 소요된 시간은 어느 정도 인지, 무엇이 성공하고 실패했는지, 전체 결과는 어떤지에 대한 자세한 정보를 확인할 수 있다. 어설션 라이브러리를 내장한 테스트 프레임워크를 사용하면 테스트 코드를 작성하는 것뿐만 아니라 테스트에 대한 결과와 관련 정보를 일목요연하게 확인할 수 있다.

const { sum } = require('./math')

test('두 인수가 덧셈이 되어야 한다.', () => {
    expect(sum(l, 2)).toBe(3)
})
test('두 인수가 덧셈이 되어야 한다.', () => {
    expect(sum(2, 2)).toBe(3) // 에러
})

앞의 테스트 코드에서 볼 수 있는 특별한 점은 test, expect 등의 메서드를 import나 require 같은 모듈을 불러오기 위해 사용하는 구문 없이 바로 사용했다는 것, 그리고 node가 아닌 jest(nptii run test)로 실행했다는 것이다. 만약 해당 코드를 jest가 아닌 node로 바로 실행했다면 에러가 발생했을 것이다. 그 이유는 test와 expect 모두 Node.js 환경의 global, 즉 전역 스코프에 존재하지 않는 메서드이기 때문이다. 이러한 메서드가 실행될 수 있는 비밀은 Jest CLI에 있다. Jest를 비롯한 테스팅 프레임워크에는 이른바 글로벌(global） 이라 해서 실행 시에 전역 스코프에 기본적으로 넣어주는 값들이 있다. 그리고 Jest는 이 값을 실제 테스트 직전에 미리 전역 스코프에 넣어준다. 이렇게 하면 일일이 테스트에 관련한 정보를 임포트하지 않고도 사용할 수 있게 되는 것이다. 이는 간결하고 빠른 테스트 코드 작성에 도움을 준다. 이 전역 스코프에 삽입되는 값은 Jest 공식 문서에서 확인할 수 있다.

8.2.3 리액트컴포넌트테스트 코드 작성하기

자바스크립트에서 이뤄지는 테스트 코드에 대해 어느 정도 살펴봤으니 이제 본격적으로 리액트 컴포넌트를 테스트하는 방법을 알아보자. 기본적으로 리액트에서 컴포넌트 테스트는 다음과 같은 순서로 진행된다.
- 1) 컴포넌트를렌더링한다
- 2) 필요하다면컴포넌트에서특정액션을 수행한다.
- 3) 컴포넌트 렌더링과 2번의 액션을 통해 기대하는 결과와 실제 결과를 비교한다.

프로젝트 생성

테스트 코드를 작성하기에 앞서, 먼저 create-react-app으로 예제 프로젝트를 생성한다. create-react-app에는 이미 react-testing-library가 포함돼 있으므로 별도로 설치할 필요가 없다.

npx create-react-app react-test --template typescript

이렇게 생성된 프로젝트를 살펴보면 App.test.tsx 파일이 생성돼 있는 것을 확인할 수 있다.

import React from 'react'
import { render, screen } from '©testing-library/react'
import App from './App'
test('renders learn react link', () => {
    render(<App />)
    const linkElement = screen.getByText(/learn react/i)
    expect(linkElement).toBeInTheDocument()
})

이 App.test.tsx가 테스트하는 App 컴포넌트는 다음과 같이 구성돼 있다.

import React from 'react'
import logo from './logo.svg'
import './App.css'
function App() {
    return (
        <div className="App">
            <header className= "App-header">
                <img src={logo} className="App-logo" alt="logo" />
                <p>
                    Edit <code>src/App.tsx</code> and save to reload.
                </p>
                <a
                    className="App-link"
                    href="https://react]s.org"
                    target="_blank"
                    rel="noopener noreferrer"
                    >
                    Learn React
                </a>
            </header>
        </div>
    )
}
export default App

코드 내용을 종합하면 App.test.tsx가 App.tsx에서 테스트하는 내용은 다음과 같이 요약할 수 있다.
- 1) 을 렌더링한다.
- 2) 렌더링하는 컴포넌트 내부에서 “learn react”라는 문자열을 가진 DOM 요소를 찾는다.
- 3) expect(linkElement).toBeInTheDocument()라는 어설션을 활용해 2번에서 찾은 요소가 document 내부에 있는지 확인한다.
위와 같이 리액트 컴포넌트에서 테스트하는 일반적인 시나리오는 특정한 무언가를 지닌 HTML 요소가 있는지 여부다. 이를 확인하는 방법은 크게 3가지가 있다.
- getBy…: 인수의 조건에 맟는 요소를 반환하며. 해당 요소가 없거나 두 개 이상이면 에러를 발생시킨다. 복수 개를 찾고 싶다면 getAllBy.. .를 사용하면 된다.
- findBy…: getBy와 거의 유사하나 한 가지 큰 차이점은 Promise를 반환한다는 것이다. 즉, 비동기로 찾는다는 것을 의미하며. 기본값으로 1000ms의 타임아웃을 가지고 있다. 마찬가지로 두 개 이상이면 에러를 발생시키지만 복수 개를 찾고 싶다면 findAUBy.. .를 사용하면 된다. 이러한특징 때문에 findBy는 비동기 액션 이후에 요소를 찾을 때 사용한다.
- queryBy…: 인수의 조건에 맞는 요소를 반환하는 대신. 찾지 못한다면 null을 반환한다. getBy.. .와 findBy.. .는 찾지 못하면 에러를 발생시키기 때문에 찾지 못해도 에러를 발생시키지 않고 싶다면 queryBy., .를 사용하면 된다. 마찬가지로 복수 개를 찾았을 때는 에러를 발생시키며. 복수 개를 찾고 싶다면 queryAllBy.. .를 사용하면 된다.

그리고 컴포넌트를 테스트하는 파일은 App.tsx, App.test.tsx의 경우와 마찬가지로 같은 디렉터리상에 위치하는 것이 일반적이다. 이름 규칙인 *.test.{t

s}jsx만 준수한다면 디렉터리 내부에서 명확하게 구별되고, 대부분의 프레임워크가 이러한 이름으로 된 파일은 번들링에서 제외하므로 유용하게 사용할 수 있다.

테스트를 위해 사용할 수 있는 기본적인 메서드에 대해 알아봤으니 이제 본격적으로 컴포넌트를 테스트하는 방법을 살펴보자.

정적 컴포넌트

정적 컴포넌트, 즉 별도의 상태가 존재하지 않아 항상 같은 결과를 반환하는 컴포넌트를 테스트하는 방법은 크게 어렵지 않다. 테스트를 원하는 컴포넌트를 렌더링한 다음, 테스트를 원하는 요소를 찾아 원하는 테스트를 수행하면 된다. 먼저 다음과 같은 컴포넌트가 있다고 가정해 보자.
- beforeEach； 각 테스트(it)를 수행하기 전에 실행하는 함수다.
- describe： 비슷한 속성을 가진 테스트를 하나의 그룹으로 묶는 역할을 한다. 정의에서도 알 수 있듯, 이 describe는 꼭 필요한 메서드는 아니다. 그러나 테스트 코드가 많아지고 관리가 어려워진다면 describe로 묶어서 관리하는 것이 편리하다. describe 내부에 describe를 또 사용할 수 있다.
- it: test와 완전히 동일하며. test의 축약어(alias) 다. it이라는 축약어를 제공하는 이유는 테스트 코드를 좀 더 사람이 읽기 쉽게 하기 위해서다. describe … it (something)과 같은 형태로 작성해두면 테스트 코드가 한결 더 문어체 같이 표현되어 읽기 쉬워진다.
- testid: testid는 리액트 테스팅 라이브러리의 예약어로, get 등의 선택자로 선택하기 어렵거나 곤란한 요쇼를 선택하기 위해 사용할 수 있다. HTML의 DOM 요소에 testid 데이터셋을 선언해 두면 이후 테스트 시에 getByTestId, findByTestId 등으로 선택할 수 있다. 웹에서 사용하는 querySelector([data-testid=”${yourIdr’])와 동일한 역할을 한다.
요약하자면 각 테스트를 수행하기 전에 StaticComponent를 렌더링하고, describe로 연관된 테스트를 묶어서 it으로 it 함수 내부에 정의된 테스트를 수행하는 테스트 파일이라고 정의할 수 있다.

동적 컴포넌트

아무런 상태값이 없는 완전히 순수한 무상태(stateless) 컴포넌트는 테스트하기가 매우 간편하다. 하지만 상태값이 있는 컴포넌트, 예를 들어 usestate를 사용해 상태값을 관리하는 컴포넌트는 어떨까? 사용자의 액션에 따라 state 값이 변경된다면? 이러한 변경에 따라 컴포넌트가 다르게 렌더링돼야 한다면? 일반적으로 테스트해야 하는 컴포넌트는 정적인 경우보다 이렇게 동적인 경우가 훨씬 더 많을 것이다.

사용자가 usestate를 통해 입력을 변경하는 컴포넌트

리액트로 작성하는 컴포넌트 중 가장 흔히 볼 수 있는 것은 사용자의 입력을 usestate로 받아서 처리하는 컴포넌트일 것이다.

const setup =()=>{
    const screen = render(<InputComponent />)
    const input = screen.getByLabelText('input') as HTMLInputElement
    const button = screen.getByText(/제출하기/i) as HTMLButtonElement
    return {
        input,
        button.
        ...screen.
    }
}

setup 함수: setup 함수는 내부에서 컴포넌트를 렌더링하고, 또 테스트에 필요한 button과 input을 반환한다. 이 파일에서 수행하는 모든 테스트는 렌더링과 button, input을 필요로 하므로 이를 하나의 함수로 묶어 두었다.
userEvent.type: userEvent.type은 사용자가 타이핑하는 것을 흉내 내는 메서드다. userEvent.type을 사용하면 사용자가 키보드루 타이핑하는 것과 동일한 작동을 만들 수 있다. 니serEvent는 @testing-library/react에서 제공하는 fireEvent와 차이가 있다. 기본적으로 userEvent는 fireEvent의 여러 이벤트를 순차적으로 실행해 좀 더 자세하게 사용자의 작동을 흉내 낸다. 예를 들어, userEvent.click을 수행하면 내부적으로 다음과 같은 fireEvent가 실행된다.
- fireEvent.mouseOver
- fireEvent.mouseMove
- fireEvent.mouseDown
- fireEvent.mouseUp
- fireEvent.click
요약하자면. 대부분의 이벤트를 테스트할 때는 fireEvent로 충분하고 훨씬 더 빠르다. 단, 특별히 사용자의 이벤트를 흉내 내야 할 때만 userEvent를 사용하면 된다.
jest.spyOn： Jest가 제공하는 spyOn은 어떠한 특정 메서드를 오염시키지 않고 실행이 됐는지, 또 어떤 인수로 실행됐는지 등 실행과 관련된 정보만 얻고 싶을 때 사용한다. 여기서는 (window, ‘alert’)라는 인수와 함께 사용됐는데. 이는 window 객체의 메서드 alert를 구현하지 않고 해당 메서드가 실행됐는지만 관찰하겠다는 뜻이다.

const calc = {
    add: (a, b) => a + b,
}
const spyFn = jest.spyOn(calc, 'add')
const result = calc.add(l, 2)
expect(spyFn).toBeCalledTimes(l)
expect(spyFn).toBeCalledWith(l, 2)
expect(result).toBe(3)

위 코드에서는 jest.spyOn으로 calc 객체의 add 메서드를 관찰하는 것을 볼 수 있다. spyOn으로 관찰한 덕분에 한번 호출됐는지(toBeCaUedTimes(l)), 원하는 인수와 함께 호출됐는지(toBeCalledWith(l, 2))를 확인할 수 있다. 그리고 spyOn으로 관찰은 했지만 calc.add의 작동 자체에는 영향을 미치지 않은 것을 확인할수 있다.
mockimplementation： 해당 메서드에 대한 모킹(mocking) 구현을 도와준다. 현재 Jest를 실행하는 Node.js 환경에서는 window.alert가 존재하지 않으므로 해당 메서드를 모의 함수(mock)로 구현해야 하는데, 이것이 바로 mockimplementation의 역할이다.

8.2.5 테스트를 작성하기에앞서고려해야 할 점

소프트웨어의 테스트에 대해 논할 때 테스트 커버리지라고 해서 해당 소프트웨어가 얼마나 테스트됐는지를 나타내는 지표에 대해 들어본 적이 있을 것이다. 흔히들 알고 있는 사실 중 하나는 테스트 커버리지가 높을수록 좋고 꾸준히 테스트 코드를 작성하라는 것이다. 그러나 테스트 커버리지가 만능은 아니다. 먼저 테스트 커버리지는 단순히 얼마나 많은 코드가 테스트되고 있는지를 나타내는 지표일 뿐, 테스트가 잘되고 있는지를 나타내는 것은 아니다. 그러므로 절대 테스트 커버리지를 맹신해서는 안 된다.
또 한 가지 알아둬야 할 점은 테스트 커버리지를 100%까지 끌어올릴 수 있는 상황은 생각보다 드물다는 것이다. 이른바 TDD(Test Driven Development： 테스트 주도 개발)라고 하는 개발 방법론을 차용해서 테스트를 우선시하더라도 서버 코드와는 다르게 프런트엔드 코드는 사용자의 입력이 매우 자유롭기 때문에 이러한 모든 상황을 커버해 테스트를 작성하기란 불가능하다. 그리고 실무에서는 테스트 코드를 작성하고 운영할만큼 여유로운 상황이 별로 없다. 때로는 테스트를 QA(Quality Assurance) 에 의존해 개발을 빠르게 진행해야 할 수도 있고, 이후에 또 개발해야 할 기능이 산적해 있을 수도 있다.
따라서 테스트 코드를 작성하기 전에 생각해 봐야 할 최우선 과제는 애플리케이션에서 가장 취약하거나 중요한 부분을 파악하는 것이다. 예를 들어, 전자상거래 애플리케이션을 만든다고 가정해 보자. 애플리케이션의 모든 부분이 우선순위를 가릴 수 없이 중요하겠지만 가장 신경 써야 할 것은 바로 결제일 것이다. 결제에 대해 테스트하기로 마음먹었다면 해당 결제와 연관되어 테스트가 필요한 코드를 파악해야 할 것이다. 그리고 해당 코드들이 어떻게 순차적으로 실행되는지 확인한 다음, 그 순차적인 프로세스에 맞춰 테스트 코드를 작성하면 된다.
이처럼 애플리케이션에서 가장 핵심이 되는 부분부터 먼저 테스트 코드를 하나씩 작성해 나가는 것이 중요하다. 테스트 코드는 소프트웨어의 코드를 100% 커버하기 위해, 혹은 테스트 코드가 모두 그린 사인(테스트가모두 통과했다)을 보기 위해 작성하는 것이 아니다. 테스트 코드는 개발자가 단순 코드 작성만으로는 쉽게 이룰 수 없는 목표인 소프트웨어 품질에 대한 확신을 얻기 위해 작성하는 것이다. 무작정 테스트 코드를 작성하기보다는 반드시 이 점을 명심하고 테스트 코드를 작성해야 한다.

8.2.6 그 밖에 해볼 만한 여러 가지 테스트

이번 절의 내용은 create-react-app과 함께 제공되는 리액트 테스팅 라이브러리를 위주로 작성됐지만 프런트엔드 개발에 있어 테스트를 수행할 수 있는 방법은 굉장히 다양하다. 사용자도 한정적이고, 사용할 수 있는 케이스도 어느 정도 제한적인 백엔드에 비해 프런트엔드는 무작위 사용자가 애플리케이션에서 갖가지 작업을 할 수 있으므로 이를 테스트하기 위한 여러 가지 방법이 있다.
- 유닛 테스트(Unit Test): 각각의 코드나 컴포넌트가 독립적으로 분리된 환경에서 의도된 대로 정확히 작동하는지 검증하는 테스트
- 통합 테스트(Integration Test): 유닛 테스트를 통과한 여러 컴포넌트가 묶여서 하나의 기능으로 정상적으로 작동하는지 확인하는 테스트
- 엔드 투 엔드(End to End Test): 흔히 E2E 테스트라 하며, 실제 사용자처럼 작동하는 로봇을 활용해 애플리케이션의 전체적인 기능을 확인하는 테스트
리액트 테스팅 라이브러리는 유닛 테스트 내지는 통합 테스트를 도와주는 도구이며, E2E 테스트를 수행하려면 Cypress 같은 다른 라이브러리의 힘을 빌려야 한다. 각 테스트 설명에서도 알 수 있지만 유닛 테스트에서 통합 테스트, 엔드 투 엔드 테스트.루 갈수록 테스트가 실패할 지점이 많아지고, 테스트 코드도 복잡해지며. 테스트해야 할 경우의 수도 많아지고, 테스트 자체를 구축하는 것도 어려워진다. 그러나 유닛 테스트에서 통합 테스트, 엔드 투 엔드 테스트로 갈수록 개발자에게 있어 코드에 대한 자신감을 심어줄 수 있는 가능성 또한 커진다.

8.2.7 정리

지금까지 create-react-app에서 함께 제공되는 리액트 애플리케이션에서 가장 쉽게 접할 수 있는 테스팅 라이브러리인 리액트 테스트 라이브러리에 대해 알아봤다. . 테스트할 수 있는 방법은 여러 가지가 있지만 테스트가 이뤄야 할 목표는 애플리케이션이 비즈니스 요구사항을 충족하는지 확인하는 것 한 가지뿐이다. 의존해야 할 QA 여건이 부족하거나, 애플리케이션의 취약한 부분이 걱정된다면 조금씩 테스트 코드를 추가해보자. 한 번에 E2E 테스팅 라이브러리를 설치해 사용자의 작동을 흉내 내서 완벽한 자신감을 얻는 것도 좋은 방법이 될 수 있지만, 처음부터 너무 많은 준비가 필요한 E2E 테스트를 시작하려다 보면 테스트 코드를 작성하기도 전에 지치거나 혹은 다른 급한 일에 테스트 코드작성의 우선순위가 밀려날지도 모른다. 조금씩, 그러나 핵심적인 부분부터 테스트 코드를 작성하다 보면 소프트웨어의 품질에 확신을 갖게 될 것이다.

끝!

5장 리액트와 상태 관리 라이브러리

Mon, 29 Jan 2024 00:00:00 +0900

이번 장에서는 리액트 애플리케이션을 개발할 때 빠지지 않고 언급되는 상태 관리 라이브러리에 대해 알아본다. 많은 개발자들이 리액트 애플리케이션에 자신이 익숙한 상태 관리 라이브러리를 설치하는 것을 익숙해하지만 정작 왜 상태 관리가 필요한지, 또 이 상태 관리가 어떻게 리액트와 함께 작동하는지는 간과하는 경우가 많다. 이번 장에서는 상태 관리 라이브러리의 필요성부터 최근 많이 주목받고 있는 상태 관리 라이브러리가 어떻게 작동하는지 살펴본다.

5.1 상태 관리는 왜 필요 한가?

상태 관리에 대해 이야기하기에 앞서 이제 앞으로 계속해서 이야기할 ‘상태’가 무엇인지 정의할 필요가 있다. 흔히 웹 애플리케이션을 개발할 때 이야기하는 상태는 어떠한 의미를 지닌 값이며 애플리케이션의 시나리오 에 따라 지속적으로 변경될 수 있는 값을 의미한다. 웹 애플리케이션에서 상태로 분류될 수 있는 것들은 대표적으로 다음과 같은 것이 있다.

UI： 기본적으로 웹 애플리케이션에서 상태라 함은 상호 작용이 가능한 모든 요소의 현재 값을 의미한다. 다크/라이트 모드, 라디오를 비롯한 각종 input, 알림창의 노출 여부 등 많은 종류의 상태가 존재한다.
URL： 브라우저에서 관리되고 있는 상태값으로, 여기에도 우리가 참고할 만한 상태가 존재할 수 있다. https://www.airbnb.co.kr7rooins/34：L13796?adults=2와 같은 주소가 있다고 가정해 보자. 이 주소에는 rooinld=34113796과 adults=2라고 하는 상태가 존재하며 이 상태는 사용자의 라우팅에 따라 변경된다.

폼(form): 폼에도 상태가 존재한다. 로딩 중인지(loading), 현재 저g됐는지(submit). 접근이 불7

능한지(disabled), 값이 유효한지(validation) 등 모두가 상태로 관리된다.

서버에서 가져온 값 클라이언트에서 서버로 요청을 통해 가져온 값도 상태로 볼 수 있다. 대표적으로 API 요청이 있다.

애플리케이션 전체적으로 관리해야 할 상태가 있다고 가정해 보자. 그리고 그 상태에 따라 다양한 요소들이 각 상태에 맞는 UI를 보여줘야 한다. 상태를 어디에 둘 것인가? 전역 변수에 둘 것인가? 별도의 클로저를 만들 것인가? 그렇다면 그 상태가 유효한 범위는 어떻게 제한할 수 있을까? 상태의 변화에 따라 변경돼야 하는 자식 요소들은 어떻게 이 상태의 변화를 감지할 것인가? 이러한 상태 변화가 일어남에 따라 즉각적으로 모든 요소들이 변경되어 애플리케이션이 찢어지는 현상(이를 tearing이라고 하며, 하나의 상태에 따라 서로 다른 결과물을 사용자에게 보여주는 현상을 말한다)을 어떻게 방지할 것인가?
이처럼 현대 웹 애플리케이션에서 상태 관리란 어렵다고 흐fl서 외면할 수 없는 주제가 됐다. 이러한 상태를 효율적으로 관리하고, 상태가 필요한 쪽에서는 빠르게 반응할 수 있는 모델에 대한 고민이 본격적으로 시작된 것이다.

5.1.1 리액트 상태관리의역사

다른 웹 개발 환경과 마찬가지로 리액트도 상태 관리에 대한 필요성이 존재했다. 애플리케이션 개발에 모든 것을 제공하는, 이른바 프레임워크를 지향하는 Angular와는 다르게 리액트는 단순히 사용자 인터페이스를 만들기 위한 라이브러리일 뿐이고, 그 이상의 기능을 제공하지 않고 있다.. 따라서 상태를 관리하는 방법도 개발자에 따라, 시간에 따라 많은 차이가 있다. 리액트 생태계에서 개발자들이 상태 관리를 하기 위해 어떠한 방법을 활용했는지 그 역사를 살펴보자.

Flux 패턴의 등장

리액트에서는 상태 관리, 특히 전역 상태 관리를 어떻게 했을까? 리덕스가 나타나기 전까지 리액트 애플리케이션에서 딱히 이름을 널리 알린 상태 관리 라이브러리는 없었다.
그러던 중 2014년경, 리액트의 등장과 비슷한 시기에 Flux 패턴과 함께 이를 기반으로 한 라이브러인 Flux를 소개하게 된다. Flux에 대해 소개하기에 앞서 먼저 이 당시 웹 개발상황을 짚고 넘어가자. 웹 애플리케이션이 비대해지고 상태（데이터）도 많아짐에 따라 어디서 어떤 일이 일어나서 이 상태가 변했는지 등을 추적하고 이해하기가 매우 어려운 상황이었다.
페이스북 팀은 이러한 문제의 원인을 양방향 데이터 바인딩으로 봤다. 뷰（HTML）가 모델（자바스크립트）을 변경할 수 있으며, 반대의 경우 모델도 뷰를 변경할 수 있다. 이는 코드를 작성하는 입장에서는 간단할 수 있지만 코드의 양이 많아지고 변경 시나리오가 복잡해질수록 관리가 어려워진다. 페이스북 팀은 양방향이 아닌 단방향으로 데이터 흐름을 변경하는 것을 제안하는데 이것이 바로 Flux 패턴의 시작이다.

각 용어의 정의를 살펴보자.
- 액션(action): 어떠한 작업을 처리할 액션과 그 액션 발생 시 함께 포함시킬 데이터룰 의미한다. 액션 타입과 데이터를 각각 정의해 이를 디스패처로 보낸다.
- 디스패처(dispatcher): 액션을 스토어에 보내는 역할을 한다. 콜백 함수 형태로 앞서 액션이 정의한 타입과 데이터를 모두 스토어에 보낸다.
- 스토어(store): 여기에서 실제 상태에 따른 값과 상태를 변경할 수 있는 메서드를 가지고 있다. 액션의 타입에 따라 어떻게 이를 변경할지가 정의돼 있다.
- 뷰(view)： 리액트의 컴포넌트에 해당하는 부분으로. 스토어에서 만들어진 데이터를 가져와 화면을 렌더링하는 역할을 한다. 또한 뷰에서도 사용자의 입력이나 행위에 따라 상태를 업데이트하고자 할 수 있을 것이다. 이 경우에는 다음 그림처럼 뷰에서 액션을 호출하는 구조로 구성된다.

간단하게 리액트 코드로 살펴보자.

type storestate = {
count: number
}

type Action = { type: 'add'; payload: number }

function reducer(prevState: StoreState, action; Action) {
    const { type: ActionType } = action
    if (ActionType === 'add') {
        return {
            count: prevState.count + action.payload,
        }
    }
    throw new Error('Unexpected Action [${ActionType}]')
}

export default function App() {
    const [state, dispatcher] = useReducer(rediicer, { count： 0 })
    function handleClick() {
        dispatcher({ type: 'add', payload： 1 })
    }
    return (
        <div>
            <hl>{state.count}</hl>
            <button onClick={handleClick}>+</button>
        </div>
    )
}

먼저 type Action으로 액션이 어떤 종류가 있고 어떤 데이터를 필요로 하는지 정의해 뒀다. 그리고 스토어의 역할을 하는 것이 useReducer와 reducer인데, 각각 현재 상태와 상태에 따른 값이 어떻게 변경되는지를 정의했다. 그리고 dispatcher로 이 액션을 실행했고, 이를 뷰인 App에서 보여준다.
이러한 단방향 데이터 흐름 방식은 당연히 불편함도 존재한다. 사용자의 입력에 따라＜여기에서는 사용자의 클릭에 따라） 데이터를 갱신하고 화면을 어떻게 업데이트해야 하는지도 코드로 작성해야 하므로 코드의 양이 많아지고 개발자도 수고로워진다. 그러나 데이터의 흐름은 모두 액션이라는 한 방향（단방향）으로 줄어들므로 데이터의 흐름을 추적하기 쉽고 코드를 이해하기가 한결 수월해진다.
상태와 그 상태의 변경에 대한 흐름과 방식을 단방향으로 채택한 것이 바로 리액트 기반 Flux의 특징이라고 볼 수 있다.

Context API와 useContext

리액트가 처음 세상에 나온 뒤에도 상태를 어떻게 적절하게 주입해야 하는지에 대한 고민은 계속 이어져왔다. 부모에 있는 상태를 자식 컴포넌트에서 쓰기 위해서는 이른바 prop 내려주기 라 불리는 방식. 즉 props를 가지고 있는 부모에서 필요한 자식 컴포넌트까지 끊임없이 컴포넌트의 인수로 넘겨야 하는 불편함이 있었다.
리액트 팀은 리액트 16.3에서 전역 상태를 하위 컴포넌트에 주입할 수 있는 새로운 Context API를 출시했다. props로 상태를 넘겨주지 않더라도 Context API를 사용하면 원하는 곳에서 Context Provider가 주입하는 상태를 사용할 수 있게 된 것이다.
그러나 3.1 절 ‘리액트의 모든 훅 파헤치기’에서 이야기한 것처럼 Context API는 상태 관리가 아닌 주입을 도와주는 기능이며, 렌더링을 막아주는 기능 또한 존재하지 않으니 사용할 때 주의가 필요하다.

5.2 리액트 훅으로 시작하는 상태 관리

5.2.1 가장 기본적인 방법: useState와 useReducer

usestate의 등장으로 리액트에서는 여러 컴포넌트에 걸쳐 손쉽게 동일한 인터페이스의 상태를 생성하고 관리할 수 있게 됐다. 다음 예제 훅을 살펴보자.

function useCounter(initCount: number = 0) {
    const [counter, setCounter] = useState(initCount)
    function inc() {
        setCounter((prev) => prev + 1)
    }

    return { counter, inc }
}

이 예제는 usecounter라는 훅을 만들어서 함수형 컴포넌트 어디에서든 사용할 수 있게 구현한 사례다. 이 훅은 외부에서 받은 숫자 혹은 0을 초깃값으로 상태를 관리하며, inc라는 함수를 선언해 이 숫자를 1씩 증가시킬 수 있게 구현했다. 그리고 상태값인 counter와 inc 함수를 객체로 반환한다.
다음 코드와 같이 usecounter를 사용하는 함수형 컴포넌트는 이 훅을 사용해 각자의 counter 변수를 관리하며, 중복되는 로직 없이 숫자를 1 씩 증가시키는 기능을 손쉽게 이용할 수 있다.

function useCounter(initCount: number = 0) {
    const [counter, setCounter] = useState(initCount)
    function inc() {
        setCounter((prev) => prev + 1)
    }
    return { counter, inc }
}
function Counter1() {
    const { counter, inc } = useCounter()
    return (
        <>
            <h3>Counter1: {counter}</h3>
            <button onClick={inc}>+</button>
        </>
    )
}
function Counter2() {
    const { counter, inc } = useCounter()
    return (
        <>
            <h3>Counter2: {counter}</h3>
            <button onClick={inc}>+</button>
        </>
    )
}

usecounter라는 훅이 없었다면 이러한 기능이 필요한 각각의 컴포넌트에서 모두 위와 같은 내용을 구현해야만 했을 것이다. 더 나아가 훅 내부에서 관리해야 하는 상태가 복잡하거나 상태를 변경할 수 있는 시나리오가 다양해진다면 훅으로 코드를 격리해 제공할 수 있다는 장점이 더욱 크게 드러날 것이다. 이처럼 리액트의 훅을 기반으로 만든 사용자 정의 훅은 함수형 컴포넌트라면 어디서든 손쉽게 재사용 가능하다는 장점이 있다.
지금까지 일반적으로 사용되는 usestate와 useReducer로 컴포넌트 내부의 상태를 관리하는 방법에 대해 알아봤다. 그러나 실제 애플리케이션을 작성해 보면 알겠지만 usestate와 useReducer가 상태 관리의 모든 필요성과 문제를 해결해 주지는 않는다. usestate와 useReducer를 기반으로 하는 사용자 지정 훅의 한계는 명확하다. 훅을 사용할 때마다 컴포넌트별로 초기화되므로 컴포넌트에 따라 서로 다른 상태를 가질 수밖에 없다. 위 예제의 경우 counter는 useCounter가 선언될 때마다 새롭게 초기화되어, 결론적으로 컴포넌트별로 상태의 파편화를 만들어 버린다. 이렇게 기본적인 usestate를 기반으로 한 상태를 지역 상태(local state)라고 하며, 이 지역 상태는 해당 컴포넌트 내에서만 유효하다는 한계가 있다.
만약 usecounter에서 제공하는 counter를 올리는 함수는 지금처럼 동일하게 사용하되, 두 컴포넌트가 동일한 counter 상태를 바라보게 하기 위해서는 어떻게 해야 할까? 즉, 현재 지역 상태인 counter를 여러 컴포넌트가 동시에 사용할 수 있는 전역 상태(global state)로 만들어 컴포넌트가 사용하는 모든 훅이 동일한 값을 참조할 수 있게 하려면 어떻게 해야 할까? 가장 먼저 떠오르는 방법은 상태를 컴포넌트 밖으로 한 단계 끌어올리는 것이다. 다음 예제를 보자.

function Counter1({ counter, inc }: { counter: number; inc: () => void }) {
    return (
        <>
            <h3>Counterl: {counter}</h3>
            <button onClick={inc}>+</button>
        </>
    )
}
function Counter2({ counter, inc }: { counter: number; inc: () => void }) {
    return (
        <>
            <h3>Counter2: {counter}</h3>
            <button onClick={inc}>+</button>
        </>
    )
}

function Parent() {
    const { counter, inc } = useCounter()
    return (
        <>
            <Counter1 counter={counter} inc={inc} />
            <Counter2 counter={counter} inc={inc} />
        </>
    )
}

예제에서는 useCounter를 각 컴포넌트에서 사용하는 대신, Parent라고 불리는 상위 컴포넌트에서만 useCounter를 사용하고, 이 훅의 반환값을 하위 컴포넌트의 props로 제공했다. 즉, 지역 상태인 useCounter를 부모 컴포넌트로 한 단계 끌어올린 다음, 이 값을 하위 컴포넌트에서 참조해 재사용하게끔 만들었다. 이제 적어도 Parent 내부에서는 위의 props 규칙만 잘 지킨다면 하나의 counter 값과 하나의 inc 함수로 상태를 관리할 수 있게 된다.
여러 컴포넌트가 동일한 상태를 사용할 수 있게 됐다는 점은 주목할 만하지만 props 형태로 필요한 컴포넌트에 제공해야 한다는 점은 여전히 조금은 불편해 보인다. 이후에 이러한 점을 어떻게 개선할 수 있을지 살펴보자.
지금까지 usestate와 useReducer, 그리고 사용자 지정 훅을 활용한 지역 상태 관리를 살펴봤다. 이 두 훅은 만들기에 따라 재사용할 수 있는 지역 상태를 만들어 주지만 이는 지역 상태라는 한계 때문에 여러 컴포넌트에 걸쳐 공유하기 위해서는 컴포넌트 트리를 재설계하는 등의 수고로움이 필요하다.

5.2.2 지역 상태의 한계를 벗어나보자: useState의 상태를 바깥으로 분리하기

리액트 코드의 작동 여부를 떠나서 조금 더 과감하게 상상해 보자. usestate의 한계는 명확하다. 현재 리액트의 usestate는 리액트가 만든 클로저 내부에서 관리되어 지역 상태로 생성되기 때문에 해당 컴포넌트에서만 사용할 수 있다는 단점이 있다. 만약 usestate가 이 리액트 클로저가 아닌 다른 자바스크립트 실행 문맥 어디에선가, 즉 완전히 다른 곳에서 초기화돼서 관리되면 어떨까? 즉, 어딘가에서 해당 값을 업데이트하면 그 값을 참조하고 있는 컴포넌트나 훅에서도 그 업데이트된 값을 사용할 수도 있지 않을까? 이를테면 다음과 같이 관리하는 상상을 해보자. 먼저 counter.ts라는 별개의 파일을 생성해서 다음과 같이 코드를 작성해 보자.

// counter.ts
export type State = { counter: number }
// 상태를 아예 컴포넌트 밖에 선언했다. 각 컴포넌트가 이 상태를 바라보게 할 것이다.
let state: State = {
    counter: 0,
}
// getter
export function get(): State {
    return state
}
// usestate와 동일하게 구현하기 위해 게으른 초기화 함수나 값을 받을 수 있게 했다.
type Initializer<T> = T extends any ? T | ((prev: T) => T) : never

// setter
export function set<T>(nextState: Initializer<T>) {
    state = typeof nextState ==='function' ? nextState(state) : nextState
}

// Counter
function Counter() {
    const state = get()

    function handleClick() {
        set((prev: State) => ({ counter: prev.counter + 1 }))
    }
    return (
        <>
            <h3>{state.counter}</h3>
            <button onClick={handleClick}>+</button>
        </>
    )
}

언뜻 보면 이러한 방식은 작동할 것 같지만 아쉽게도 위 방식은 리액트 환경에서 작동하지 않는다. setter나 getter 등의 코드가 잘못돼서가 아니다. 그러나 가장 큰 문제는 컴포넌트가 리렌더링되지 않는다는 것이다. 원인은 바로 리액트의 렌더링 방식 때문이다. 새로운 상태를 사용자의 UI에 보여주기 위해서는 반드시 리렌더링이 필요하다. 이 리렌더링은 함수형 컴포넌트의 재실행(호출), usestate의 두 번째 인수 호출 등 다양한 방식으로 일어나지만 위 코드에서는 리렌더링을 일으키는 장치가 어디에도 존재하지 않는다.
즉, 업데이트되는 값을 가져오려면 상태를 업데이트하는 것뿐만 아니라 상태가 업데이트됐을 때 이를 컴포넌트에 반영시키기 위한 리렌더링이 필요하며, 함수형 컴포넌트에서 리렌더링을 하려면 다음과 같은 작업 중 하나가 일어나야 한다.
- usestate, useReducer의 반환값 중 두 번째 인수가 어떻게든 호출된다. 설령 그것이 컴포넌트 렌더링과 관계없는 직접적인 상태를 관리하지 않아도 상관없다. 어떠한 방식으로든 두 번째 인수가 호출되면 리액트는 다시 컴포넌트를 렌더링 한다.
- 부모 함수(부모 컴포넌트)가 리렌더링되거나 해당 함수(함수형 컴포넌트)가 다시 실행돼야 한다. 그러나 위 경우 부모 컴포넌트가 없으며, props도 없기 때문에 일일이 Counter()를 재실행시켜야 하지만 그것은 매우 비효율적이다.
여기서 우리가 시도해 볼 수 있는 것은 usestate와 useReducer뿐으로 보인다. 그렇다면 useState의 인수로 컴포넌트 밖에서 선언한 state를 넘겨주는 방식으로 코드를 변경해 보자.

function Counter1() {
    const [count, setCount] = useState(state)
    function handleClick() {
        // 외부에서 선언한 set 함수 내부에서 다음 상태값을 연산한 다음,
        // 그 값을 로컬 상태값에도 넣었다.
        set((prev： State) => {
            const newState = { counter: prev.counter + 1 }
            // setcount가 호출되면서 컴포넌트 리렌더링을 야기한다.
            setCount(newState)
            return newState
        })
    }
    return (
        <>
            <h3>{count.counter}</h3>
            <button onClick={handleClick}>+</button>
        </>
    )
}

function Counter2() {
    const [count, setCount] = useState(state)
    // 위 컴포넌트와 동일한 작동올 추가했다.
    function handleClick() {
        set((prev: State) => {
            const newState = { counter: prev.counter + 1 }
            setcount(newState)
            return newState
        })
    }
    return (
        <>
            <h3>{count. coiinter}</h3>
            <button onClick={handleClick}>+</button>
        </>
    )
}

예제 코드에서는 억지로 전역에 있는 상태를 참조하게 만들었다. usestate의 초깃값으로 컴포넌트 외부에 있는 값을 사용하는 위와 같은 방식은 일반적인 리액트 코드 작성 방식과 동일하다.
여기서 독특한 것은 바로 handleclick으로 state를 업데이트하는 방식이다. 기본적으로 useState의 두 번째 인수로 업데이트하는 것은 해당 지역 상태에만 영향을 미치기 때문에 여기서는 외부에 선언한 set을 실행해 외부의 상태값 또한 업데이트하도록 수정했다. 이렇게 외부의 상태를수정하고 usestate의 두 번째 인수도 실행한다면 리액트 컴포넌트는 렌더링될 것이고 우리는 계속해서 외부의 값을 안정적으로 참조할 수 있게 된다.
그러나 이 방법은 굉장히 비효율적이고 문제점도 가지고 있다. 외부에 상태가 있음에도 불구하고, 함수형 컴포넌트의 렌더링을 위해 함수의 내부에 동일한 상태를 관리하는 usestate가 존재하는 구조다. 이는 상태를 중복해서 관리하므로 비효율적인 방식이라고 볼 수 있다.
여기에는 또 한 가지 문제점이 있는데, 실제로 각 컴포넌트의 버튼을 누르면 이상하게 작동하는 것을 확인할 수 있다. 버튼을 누르면 해당 컴포넌트가 렌더링되면서 원하는 값을 안정적으로 렌더링하지만 같은 상태를 바라봐야 하는 반대쪽 컴포넌트에서는 렌더링되지 않는다. 반대쪽 컴포넌트는 버튼을 눌러야 그제서야 렌더링되어 최신값을 불러온다. 그러나 여전히 반대쪽은 렌더링되지 않는 것을 볼 수 있다. 왜 같은 상태를 공유하지만동시에 렌더링되지 않는 것일까?
usestate로 컴포넌트의 리렌더링을 실행해 최신값을 가져오는 방법은 어디까지나 해당 컴포넌트 자체에서만 유효한 전략이다. 즉, 반대쪽의 다른 컴포넌트에서는 여전히 상태의 변화에 따른 리렌더링을 일으킬 무언가가 없기 때문에 클릭 이벤트가 발생하지 않는 다른 쪽은 여전히 렌더링이 되지 않는다.
이러한 한계를 종합해 본 내용을 살펴보면 함수 외부에서 상태를 참조하고 이를 통해 렌더링까지 자연스럽게 일어나려면 다음과 같은 조건을 만족해야 한다는 결론에 도달한다.
- 1) 꼭 window나 global에 있어야 할 필요는 없지만 컴포넌트 외부 어딘가에 상태를 두고 여러 컴포넌트가 같이 쓸 수 있어야한다.
- 2) 이 외부에 있는 상태를 사용하는 컴포넌트는 상태의 변화를 알아챌 수 있어야 하고 상태가 변화될 때마다 리렌더링이 일어나서 컴포넌트를 최신 상태값 기준으로 렌더링해야 한다. 이 상태 감지는 상태를 변경시키는 컴포넌트뿐만 아니라 이 상태를 참조하는 모든 컴포넌트에서 동일하게 작동해야 한다. 3) 상태가 원시값이 아닌 객체인 경우에 그 객체에 내가 감지하지 않는 값이 변한다 하더라도 리렌더링이 발생해서는 안된다.
위와 같은 조건을 만족할 수 있는, 컴포넌트 레벨의 지역 상태를 벗어나는 새로운 상태 관리 코드를 만들어보자. 먼저 이 상태는 객체일 수도, 원시값일 수도 있으므로 좀 더 범용적인 이름인 store로 정의한다. 그리고 2번의 조건을 만족하기 위해서는 store의 값이 변경될 때마다 변경됐음을 알리는 callback 함수를 실행해야 하고, 이 callback을 등록할 수 있는 subscribe 함수가 필요하다.
먼저 위 조건을 만족하는 store의 뼈대를 만들어보자. 타입스크립트의 타입을 선언해 두면 직접 코드를 작성하기에 앞서 만들어야 할 함수의 기본적인 타입을 정의해 두고 이야기할 수 있으므로 유용하다.

type Initializer<T> = T extends any ? T | ((prev: T) => T) : never
type Store<State> = {
    get: 0 => State
    set： (action: Initializer<State>) => State
    subscribe: (callback： () => void) => () => void
}

get은 항상 최신값을 가져와야 하므로 함수로 구현했다. 그리고 set의 형태는 기존에 리액트 개발자가 널리 사용하고 있는 usestate와 동일하게 값 또는 함수를 받을 수 있도록 만들었다. 마지막으로 subscribe는 이 store의 변경을 감지하고 싶은 컴포넌트들이 자신의 callback 함수를 등록해 두는 곳이다. callback을 인수로 받으며, store는 값이 변경될 때마다 자신에게 등록된 모든 callback을 실행하게 할 것이다. 그리고 이 스토어를 참조하는 컴포넌트는 subscribe에 컴포넌트 자기 자신을 렌더링하는 코드를 추가해서 컴포넌트가 리렌더링을 실행할수 있게 만들 것이다.
뼈대를 만들었으니 이 Store 함수를 실제로 작성해 보자.

export const createStore = <State extends unknown>(
initialstate: Initializer<State>,
)： Store<State> => {
    // usestate와 마찬가지로 초깃값을 게으른 초기화를 위한 함수 또한
    // 그냥 값올 받을 수 았도록 한다.
    // state의 값은 스토어 내부에서 보관해야 하므로 변수로 선언한다.
    let state = typeof initialstate !== 'function' ? initialstate : initialState()
    // callbacks는 자료형에 관계없이 유일한 값을 저장할 수 있는 Set을 사용한다.
    const callbacks = new Set<() => void>()
    // 언제든 get이 호출되면 최신값을 가져올 수 있도록 함수로 만든다.
    const get = () => state
    const set = (nextState: State | ((prev: State) => State)) => {
        // 인수가 함수라면 함수를 실행해 새로운 값을 받고,
        // 아니라면 새로운 값을 그대로 사용한다.
        state =
            typeof nextstate === 'function'
            ? (nextstate as (prev: State) => State)(state)
            : nextstate
        // 값의 설정이 발생하면 콜백 목록올 순회하면서 모든 콜백을 실행한다.
        callbacks.forEach((callback) => callback())

        return state
    }
    // subscribe는 콜백을 인수로 받는다.
    const subscribe = (callback: () => void) => {
        // 받은 함수를 콜백 목록에 추가한다.
        callbacks.add(callback)
        // 클린업 실행 시 이를 삭제해서 반복적으로 추가되는 것을 막는다.
        return () => {
            callbacks.delete(callback)
        }
    }
    return { get, set, subscribe }
}

위 코드는 store를 만드는 createStore를 구현한 코드다. 하나씩 단계별로 살펴보자.
- 1) 먼저 store의 초깃값을 state 또는 게으른 초기화 함수를 받아 store의 기본값을 초기화할 수 있게 해뒀다.
- 2) 1)에서 받은 인수를 바탕으로 함수를 실행하거나 초깃값 그 자체를 할당해 state 초깃값을 할당한다.
- 3) 3. 컴포넌트로 넘겨받는 콜백 함수를 저장하기 위해 callbacks를 Set으로 선언한다. Set은 원시값이나 객체에 관계없이 유일한 값을 저장할 수 있어 중복 없이 콜백 함수를 저장하는 용도로 유용하다.
- 4) get을 함수로 만들어 매번 최신값을 가져올 수 있게 만든다.
- 5) . set을 만들어 새로운 값을 넣을 수 있도록 만든다. usestate의 두 번째 인수와 마찬가지로 함수일 수도. 단순히 값을 받을 수도 있다. 그리고 값을 설정한 이후에 callbacks를 순회해 등록된 모든 콜백을 실행한다. set으로 값을 설정하는 순간 콜백을 모두 실행해 컴포넌트의 렌더링을 유도할 것이다.
- 6) subscribe는 callbacks Set에 callback을 등록할 수 있는 함수다. callbacks.add와 더불어. 반환값으로는 등록된 callback을 삭제하는 함수를 반환한다. 이는 callbacks에 callback이 무한히 추가되는 것을 방지하게 만들어져 있으며, useEffeet의 클린업 함수와 동일한 역할을 한다.
- 7) 마지막으로 get, set, subscribe를 하나의 객체로 반환해 외부에서 사용할 수 있도록 한다.
요약하자면 createStore는 자신이 관리해야 하는 상태를 내부 변수로 가진 다음, get 함수로 해당 변수의 최신값을 제공하며, set 함수로 내부 변수를 최신화하며, 이 과정에서 등록된 콜백을 모조리 실행하는 구조를 띠고 있다.
마지막으로 createStore로 만들어진 store의 값을 참조하고, 그리고 이 값의 변화에 따라 컴포넌트 렌더링을 유도할 사용자 정의 훅이 필요하다. usestore라는 훅을 만들어 이 store의 변화를 감지할 수 있게 코드를 작성해 보자.

export const useStore = <State extends unknown>(store： Store<State>) => {
    const [state, setState] = useState<State>(() => store.get())
    useEffect(() => {
        const unsubscribe = store.subscribe(() => {
            setState(store.get())
        })
        return unsubscribe
    }, [store])
    return [state, store.set] as const
}

이 훅이 어떻게 구성돼 있는지 살펴보자.
- 1) 먼저 훅의인수로 사용할 store를받는다.
- 2) 이 스토어의 값을 초깃값으로 하는 usestate를 만든다. 이제 이 useState가 컴포넌트의 렌더링을 유도한다.
- 3) useEffect는 store의 현재 값을 가져와 setState를 수행하는 함수를 store의 subscribe로 등록해 두었다. createStore 내부에서 값이 변경될 때마다 subscribe에 등록된 함수를 실행하므로 useStore 내부에서는 store의 값이 변경될 때마다 state의 값이 변경되는 것을 보장받을 수 있다.
- 4) 마지막으로 useEffect의 클린업 함수로 unsubscribe를 등록해 둔다. useEffect의 작동이 끝난 이후에는 callback에서 해당 함수를 제거해 callbackOl 계속해서 쌓이는 현상을 방지했다.
이제 우리가 원하는 상태 관리에 필요한 모든 코드를 작성했다. 이 상태 관리 방식이 잘 작동하는지 확인해보자.

const store = createStore({ count: 0 })
function Counter1() {
    const [state, setState] = useStore(store)
    function handleClick() {
        setState((prev) => ({ count: prev.count + 1 }))
    }
    return (
        <>
            <h3>Counterl: {state.count}</h3>
            <button onClick={handleClick}>+</button>
        </>
    )
}

function Counter2() {
    const [state, setState] = useStore(store)
    function handleClick() {
        setState((prev) => ({ count: prev.count + 1 }))
    }
    return (
        <>
            <h3>Counter2: {state.count}</h3>
            <button onClick={handleClick}>+</button>
        </>
    )
}

export default function App() {
    return (
        <div className="App">
            <Counter1 />
            <Counter2 />
        </div>
    )
}

Counterl과 Counter?의 버튼을 각각 클릭하면 store의 상태가 변경됨과 동시에 두 컴포넌트가 모두 정상적으로 리렌더링되는 것을 확인할 수 있다. 마침내 우리가 일반적으로 사용하는 상태 관리 라이브러리를 손수 구현했다.
그러나 이 usestore도 완벽한 것은 아니다. 만드는 스토어의 구조가 원시값이라면 상관없지만 객체인 경우를 가정해 보자. 만약 해당 객체에서 일부값만 변경한다면 어떻게 될까? 현재는 store의 값이 바뀌면 무조건 usestate를 실행하므로 스토어에 어떤 값이 바뀌든지 간에 리렌더링이 일어날 것이다. useStore에서 한 발짝 더 나아가서 원하는 값이 변했을 때만 리렌더링되도록 훅을 다시 구성해 보자.
여기서 수정이 필요한 것은 usestore 훅이다. subscribe는 위 예제와 동일하게 수행하되, 변경 감지가 필요한 값만 setstate를 호출해 객체 상태에 대한 불필요한 리렌더링을 막을 수 있을 것이다. 다음 예제를 보자.

export const useStoreSelector = <State extends unknown, Value extends unknown>(
store： Store<State>,
selector： (state： State) => Value,
) {
    const [state, setState] = useState(() => selector(store.get()))

    useEffect(() => {
        const unsubscribe = store.subscribe(() => {
            const value = selector(store.get())
            setState(value)
        })

        return unsubscribe
    }, [store, selector])

    return state
}

useStoreSelector는 useStore를 기반으로 만들어졌지만 한 가지 차이점이 있다. 두 번째 인수로 selector라고 하는 함수를 받는다는 것이다. 이 함수는 store의 상태에서 어떤 값을 가져올지 정의하는 함수로, 이 함수를 활용해 store.get()을 수행한다. useState는 값이 변경되지 않으면 리렌더링을 수행하지 않으므로 store의 값이 변경됐다 하더라도 selector(store.get())이 변경되지 않는다면 리렌더링이 일어나지 않는다. 이 useStoreSelector 훅을 사용하는 예제를 살펴보자.

const store = createStore({ count: 0, text: 'hi' })

function Counter() {
    const counter = useStoreSelector(
    store,
    useCallback((state) => state.count, []),
    )

    function handleClick() {
        store.set((prev) => ({ ...prev, count; prev.count + 1 }))
    }

    useEffect(() => {
        console.log('Counter Rendered')
    })
    return (
        <>
            <h3>{counter}</h3>
            <button onClick={handleClick}>+</button>
        </>
    )
}

const textselector = (state: ReturnType<typeof store.get>) => state.text

function TextEditor() {
    const text = useStoreSelector(store, textselector)
    useEffect(() => {
        console.log('Counter Rendered')
    })

    function handleChange(e: ChangeEvent<HTMLInputElement>) {
        store.set((prev) => ({ ...prev, text： e.target.value }))
    }

    return (
        <>
            <h3>{text}</h3>
            <input value={text} onChange={handleChange} />
        </>
    )
}

이제 useStoreSelector를 사용하면 store가 객체로 구성돼 있다 하더라도 컴포넌트에서 필요한 값만 말 그대로 select해서 사용할 수 있고, 이 select 또한 실제로 객체에서 변경된 값에 대해서만 수행할 것이다.
한 가지 주의할 점은 useStoreSelector에 제공하는 두 번째 인수인 selector를 컴포넌트 밖에 선언하거나, 이것이 불가능하다면 usecallback을 사용해 참조를 고정시켜야 한다는 것이다. 만약 컴포넌트 내에 이 selector 함수를 생성하고 useCallback으로 감싸두지 않는다면 컴포넌트가 리렌더링될 때마다 함수가 계속 재생성되어 store의 subscribe를 반복적으로 수행할 것이다.
지금까지 리액트 외부에서 관리되는 값에 대한 변경을 추적하고, 이를 리렌더링까지 할 수 있는 useStoreSelector 훅을 만들어서 설치해 봤다. 사실 이러한 방식으로 구현된 훅은 이미 존재한다. 바로 페이스북 팀에서 만든 usesubscription이다. useSubscription을 사용하면 방금 했던 내용을 동일하게 구현할 수 있다.

function NewCounter() {
    const subscription = useMemo(
    () => ({
        // 스토어의 모든 값으로 설정해 뒀지만 selector 예제와 마찬가지로
        // 특정한 값에서만 가져오는 것도 가능하다.
        getCurrentValue: () => store.get(),
        subscribe: (callback: ()) => void) => {
        const unsubscribe = store.subscribe(callback)
        return () => unsubscribe()
        },
    }),
    [],
    )

    const value = useSubscription(subscription)
    return <>{JSON.stringify(value)}</>
}

5.2.3 useState와 Context# 동시에 사용해 보기

앞서 useStore 내지는 useStoreSelector 훅을 활용해 useState로 관리하지 않는 외부 상태값을 읽어오고 리렌더링까지 일으켜서 마치 상태 관리 라이브러리처럼 사용하는 예제를 만들었다. 그러나 이 두 가지 훅에도 한 가지 단점이 있다.
이 훅과 스토어를 사용하는 구조는 반드시 하나의 스토어만 가지게 된다는 것이다. 하나의 스토어를 가지면 이 스토어는 마치 전역 변수처럼 작동하게 되어 동일한 형태의 여러 개의 스토어를 가질 수 없게 된다. 만약 훅을 사용하는 서로 다른 스코프에서 스토어의 구조는 동일하되, 여러 개의 서로 다른 데이터를 공유해 사용하고 싶다면 어떻게 해야 할까?
가장 먼저 떠오르는 방법은 createStore를 이용해 동일한 타입으로 스토어를 여러 개 만드는 것이다.

const store1 = createStore({ count: 0 })
const store2 = createStore({ count: 0 })
const Store3 = createStore({ count: 0 })

그러나 이 방법은 완벽하지도 않고 매우 번거롭다. 먼저 해당 스토어가 필요할 때마다 반복적으로 스토어를 생성해야 한다. 또한 훅은 스토어에 의존적인 1:1 관계를 맺고 있으므로 스토어를 만들 때마다 해당 스토어에 의존적인 usestore와 같은 훅을 동일한 개수로 생성해야 한다. 마지막으로 이러한 수고로움을 견디고 훅을 하나씩 만들었다고 하더라도 이 훅이 어느 스토어에서 사용 가능한지를 가늠하려면 오직 훅의 이름이나 스토어의 이름에 의지해야 한다는 어려움이 있다. 이 문제를 해결하는 좋은 방법은 바로 리액트의 Context다. Context를 활용해 해당 스토어를 하위 컴포넌트에 주입한다면 컴포넌트에서는 자신이 주입된 스토어에 대해서만 접근할 수 있게 될 것이다.

끝!

3장 리액트 훅 깊게 살펴보기

Wed, 24 Jan 2024 00:00:00 +0900

3.1 리액트의 모든 훅 파헤치기

3.1.1 useState

useState는 함수형 컴포넌트 내부에서 상태를 정의하고, 이 상태를 관리할 수 있게 해주는 훅
함수형 컴포넌트는 매번 함수를 실행해 렌더링이 일어나고, 함수 내부의 값은 함수가 실행될 때마다 다시 초기화
usestate 훅의 결괏값은 어떻게 함수가 실행돼도 그 값을 유지하고 있을까?
- 리액트는 클로저를 이용
- 클로저는 어떤 함수(usestate) 내부에 선언된 함수(setstate)가 함수의 실행이 종료된 이후에도(useState가 호출된 이후에도) 지역변수인 state를 계속 참조할 수 있다는 것을 의미
useState에 변수 대신 함수를 넘기는 것을 게으른 초기화(lazy initialization)
- 게으른 초기 함수는 오로지 state가 처음 만들어질 때만 사용

3.1.2 useEffect

useEffect의 정의를 정확하게 내리자면 useEffect는 애플리케이션 내 컴포넌트의 여러 값들을 활용해 동기적으로 부수 효과를 만드는 메커니즘

클린없 함수의 목적

클린업 함수는 비록 새로운 값을 기반으로 렌더링 뒤에 실행되지만 이 변경된 값을 읽는 것이 아니라 함수가 정의됐을 당시에 선언됐던 이전 값을 보고 실행됨
클린업 함수는 언마운트라기보다는 함수형 컴포넌트가 리렌더링됐을 때 의존성 변화가 있었을 당시 이전의 값을 기준으로 실행되는, 말 그대로 이전 상태를 청소해 주는 개념으로 보는 것

3.1.3 useMemo

useMemo는 비용이 큰 연산에 대한 결과를 저장(메모이제이션)해 두고, 이 저장된 값을 반환하는 훅

3.1.4 useCallback

useCallback은 인수로 넘겨받은 콜백 자체를 기억

3.1.5 useRef

useRef는 반환값인 객체 내부에 있는 current로 값에 접근 또는 변경할 수 있음
useRef는 그 값이 변하더라도 렌더링을 발생시키지 않음

3.1.6 useContext

usecontext는 상위 컴포넌트에서 만들어진 Context를 하위 함수형 컴포넌트에서 사용할 수 있도록 만들어진 훅

3.1.8 useImperativeHandle

forwardRef 살펴보기

ref를 상위 컴포넌트에서 하위 컴포넌트로 전달하고 싶을때 사용

useImperativeHandle란?

useImperativeHandle은 부모에게서 넘겨받은 ref를 원하는 대로 수정할 수 있는 훅
useImperativeHandle을 사용하면 이 ref의 값에 원하는 값이나 액션을 정의할수 있음

3.1.9 useLayoutEffect

이 함수의 시그니처는 useEffect와 동일하나, 모든 DOM의 변경 후에 동기적으로 발생
여기서 말하는 DOM 변경이란 렌더링이지, 브라우저에 실제로 해당 변경 사항이 반영되는 시점을 의미하는 것은 아님
동기적으로 발생한다는 것은 리액트는 useLayoutEffect의 실행이 종료될 때까지 기다린 다음에 화면을 그린다는 것을 의미

3.2 사용자 정의 혹과 고차 컴포넌트 중 무엇을 써야 할까?

리액트에서는 재사용할 수 있는 로직을 관리할 수 있는 두 가지 방법
바로 사용자 정의 훅(custom hook)과 고차 컴포넌트(higher order component)

3.2.1 사용자 정의 혹

서로 다른 컴포넌트 내부에서 같은 로직을 공유하고자 할 때 주로 사용되는 것이 바로 사용자 정의 훅
사용자 정의 훅은 내부에 usestate와 useEffect 등을 가지고 자신만의 원하는 훅을 만드는 기법

3.2.2 고차 컴포넌트

고차 컴포넌트(HOC, Higher Order Component)는 컴포넌트 자체의 로직을 재사용하기 위한 방법

고차 함수 만들어보기

고차 함수의 사전적인 정의를 살펴보면 ‘함수를 인수로 받거나 결과로 반환하는 함수’라고 정의(예: Array.prototype.map)
단순히 값을 반환하거나 부수 효과를 실행하는 사용자 정의 훅과는 다르게, 고차 컴포넌트는 컴포넌트의 결과물에 영향을 미칠 수 있는 다른 공통된 작업을 처리할 수 있음

3.2.3 사용자 정의훅과 고차 컴포넌트 중 무엇을 써야 할까?

사용자 정의 훅과 고차 컴포넌트 모두 리액트 코드에서 어떠한 로직을 공통화해 별도로 관리할 수 있다는 특징

사용자 정의 훅이 필요한 경우

단순히 useEffect, usestate와 같이 리액트에서 제공하는 훅으로만 공통 로직을 격리할 수 있다면 사용자 정의 훅을 사용

고차 컴포넌트를 사용해야 하는 경우

함수형 컴포넌트의 반환값, 즉 렌더링의 결과물에도 영향을 미치는 공통 로직이라면 고차 컴포넌트를 사용

끝!

3장 리액트 훅 깊게 살펴보기

Tue, 23 Jan 2024 00:00:00 +0900

함수형 컴포넌트가 상태를 사용하거나 클래스형 컴포넌트의 생명주기 메서드를 대체하는 등의 다양한 작업을 하기 위해 훅(hook)이라는 것이 추가됐다. 훅을 활용하면 클래스형 컴포넌트가 아니더라도 리액트의 다 양한 기능을 활용할 수 있다. 리액트에서 현재 사용 가능한 훅이 무엇이고, 어떻게 쓰이는지, 그리고 훅을 사용할 때 주의할 점은 무엇인지 확인해 보자.

3.1 리액트의 모든 훅 파헤치기

리액트 함수형 컴포넌트에서 가장 중요한 개념은 바로 훅이다. 훅은 클래스형 컴포넌트에서만 가능했던 state, ref 등 리액트의 핵심적인 기능을 함수에서도 가능하게 만들었고, 무엇보다 클래스형 컴포넌트보다 간결하게 작성할 수 있어 훅이 등장한 이래로 대부분의 리액트 컴포넌트는 함수형으로 작성되고 있을 정도로 많은 사랑을 받고 있다.

3.1.1 useState

useState는 함수형 컴포넌트 내부에서 상태를 정의하고, 이 상태를 관리할 수 있게 해주는 훅이다.
간단한 예제를 살펴보자.

function Component() {
    const [, triggerRender] = useState()
    let state = 'hello'
    function handleButtonClickO {
        state = 'hi'
        triggerRender()
    }
    return (
        <>
        <hl>{state}</hl>
        <button onClick={handleButtonClick}>hi</button>
        </>
    )
}

usestate 반환값의 두 번째 원소를 실행해 리액트에서 렌더링이 일어나게끔 변경했다. 그럼에도 여전히 버튼 클릭 시 state의 변경된 값이 렌더링되고 있지 않다. state가 업데이트되고 있는데 왜 렌더링이 되지 않을까?
그 이유는 리액트의 렌더링은 함수형 컴포넌트에서 반환한 결과물인 return의 값을 비교해 실행되기 때문이다. 즉, 매번 렌더링이 발생될 때마다 함수는 다시 새롭게 실행되고, 새롭게 실행되는 함수에서 state는 매번 hello로 초기화되므로 아무리 state를 변경해도 다시 hello로 초기화되는 것이다.
지금까지는 이해할 수 있는 과정으로 보인다. 함수형 컴포넌트는 매번 함수를 실행해 렌더링이 일어나고, 함수 내부의 값은 함수가 실행될 때마다 다시 초기화된다. 그렇다면 usestate 훅의 결괏값은 어떻게 함수가 실행돼도 그 값을 유지하고 있을까?
리액트의 내부 구현을 하나도 모른다고 가정하고 usestate가 어떤 구조를 가지고 있을지 상상해 보자.

function useState(initialValue) {
    let internalstate = initialVaTue
    function setState(newValue) {
        internalstate = newValue
    }
    return [internalstate, setState]
}

그러나 이는 우리가 원하는 대로 작동하지 않는다.

const [value, setValue] = useState(0)
setValue(l)
console.log(value) // 0

이러한 결과가 발생하는 이유는 setvalue로 값을 변경했음에도 이미 구조 분해 할당으로 state의 값, 즉 value를 이미 할당해 놓은 상태이기 때문에 훅 내부의 setstate를 호출하더라도 변경된 새로운 값을 반환하지는 못한 것이다.
이를 해결하려면 먼저 state를 함수로 바꿔서 state의 값을 호출할 때마다 현재 state를 반환하게 하면 된다.

function useState(initialValue) {
    let internalstate = initialvalue
    function state() {
        return internalstate
    }
    function setState(newValue) {
        internalstate = newValue
    }
    return [state, setState]
}

const [value, setValue] = useState(0)
setValue(l)
console.log(value()) // 1

물론 이것은 우리가 사용하는 usestate 훅의 모습과는 많이 동떨어져 있다. 우리는 state를 함수가 아닌 상수처럼 사용하고 있기 때문이다.
이를 해결하기 위해 리액트는 클로저를 이용했다. 여기서 클로저는 어떤 함수(usestate) 내부에 선언된 함수(setstate)가 함수의 실행이 종료된 이후에도(useState가 호출된 이후에도) 지역변수인 state를 계속 참조할 수 있다는 것을 의미한다.

게으른 초기화

일반적으로 usestate에서 기본값을 선언하기 위해 useState() 인수로 원시값을 넣는 경우가 대부분일 것이다. useState에 변수 대신 함수를 넘기는 것을 게으른 초기화(lazy initialization）라고 한다. 이 게으른 초기화가 무엇인지 살펴보자.

// 일반적인 useState 사용
// 바로 값을 집어넣는다.
const [count, setCount] = useState(
    Number.parselnt(window.localstorage.getltem(cacheKey)),
)
// 게으른 초기화
// 위 코드와의 차이점은 함수를 실행해 값을 반환한다는 것이다.
const [count, setCount] = useState(() =>
    Number.parselnt(window.localstorage.getltem(cacheKey)),
)

리액트 공식 문서에서 이러한 게으른 초기화는 usestate의 초깃값이 복잡하거나 무거운 연산을 포함하고 있을 때 사용하라고 돼 있다. 이 게으른 초기 함수는 오로지 state가 처음 만들어질 때만 사용된다. 만약 이후에 리렌더링이 발생된다면 이 함수의 실행은 무시된다. 다음 예제를 보자.
리액트에서는 렌더링이 실행될 때마다 함수형 컴포넌트의 함수가 다시 실행된다는 점을 명심하자. 함수형 컴포넌트의 usestate의 값도 재실행된다. 물론 우리는 앞서 구현 예제를 통해 내부에는 클로저가 존재하며, 클로저를 통해 값을 가져오며 초깃값은 최초에만 사용된다는 것을 알고 있다. 만약 usestate 인수로 자바스크립트에 많은 비용을 요구하는 작업이 들어가 있다면 이는 계속해서 실행될 위험이 존재할 것이다. 그러나 우려와는 다르게 usestate 내부에 함수를 넣으면 이는 최초 렌더링 이후에는 실행되지 않고 최초의 state 값을 넣을 때만 실행된다.
만약 Number.parselnt(window.localstorage.getltem(cacheKey))와 같이 한 번 실행되는 데 어느 정도 비용이 드는 값이 있다고 가정해 보자. usestate의 인수로 이 값 자체를 사용한다면 초깃값이 필요한 최초 렌더링과, 초깃값이 있어 더 이상 필요 없는 리렌더링 시에도 동일하게 계속 해당 값에 접근해서 낭비가 발생한다. 따라서 이런 경우에는 함수 형태로 인수에 넘겨주는 편이 훨씬 경제적일 것이다.
그렇다면 게으른 최적화는 언제 쓰는 것이 좋을까? 리액트에서는 무거운 연산이 요구될 때 사용하라고 한다. 즉, localStorage나 sessionstorage에 대한 접근. map, filter, find 같은 배열에 대한 접근, 혹은 초깃값 계산을 위해 함수 호출이 필요할 때와 같이 무거운 연산을 포함해 실행 비용이 많이 드는 경우에 게으른 초기화를 사용하는 것이 좋다.

3.1.2 useEffect

useEffect는 자주 쓰지만 생각보다 사용하기 쉬운 훅이 아니다. 그리고 알려진 것처럼 생명주기 메서드를 대체하기 위해 만들어진 훅도 아니다.
useEffect의 정의를 정확하게 내리자면 useEffect는 애플리케이션 내 컴포넌트의 여러 값들을 활용해 동기적으로 부수 효과를 만드는 메커니즘이다. 그리고 이 부수 효과가 ‘언제’ 일어나는지보다 어떤 상태값과 함께 실행되는지 살펴보는 것이 중요하다.
의존성 배열이 변경될 때마다 useEffect의 첫 번째 인수인 콜백을 실행한다는 것은 널리 알려진 사실이다. 하지만 useEffect는 어떻게 의존성 배열이 변경된 것을 알고 실행될까? 여기서 한 가지 기억해야 사실은 바로 함수형 컴포넌트는 매번 함수를 실행해 렌더링을 수행한다는 것이다. 다음 예제 코드를 살펴보자.
함수형 컴포넌트는 렌더링 시마다 고유의 state와 props 값을 갖고 있다. useEffect는 자바스크립트의 proxy나 데이터 바인딩, 옵저버 같은 특별한 기능을 통해 값의 변화를 관찰하는 것이 아니고 렌더링할 때마다 의존성에 있는 값을 보면서 이 의존성의 값이 이전과 다른 게 하나라도 있으면 부수 효과를 실행하는 평범한 함수라 볼 수 있다. 따라서 useEffect는 state와 props의 변화 속에서 일어나는 렌더링 과정에서 실행되는 부수 효과 함수라고 볼 수 있다.

클린업 함수의 목적

그렇다면 이른바 클린업 함수라 불리는 useEffect 내에서 반환되는 함수는 정확히 무엇이고 어떤 일을 할까? 일반적으로 이 클린업 함수는 이벤트를 등록하고 지울 때 사용해야 한다고 알려져 있다.

useEffect(() => {
function addMouseEvent() {
    console.log(counter)
}
window.addEventListener('click', addMouseEvent)
// 클린업 함수
return () => {
    console.log('클린업 함수 실행!', counter)
    window. removeEventListerier('click', addMouseEvent)
}
}, [counter])

위 useEffeet가 포함된 컴포넌트를 실행해 보면 다음과 같은 결과를 얻을 수 있다.

클린업 함수 실행! 0
1

클린업 함수 실행! 1
2

클린업 함수 실행! 2
3

클린업 함수 실행! 3
4

// ...

위 로그를 살펴보면 클린업 함수는 이전 counter 값, 즉 이전 state를 참조해 실행된다는 것을 알 수 있다. 클린업 함수는 새로운 값과 함께 렌더링된 뒤에 실행되기 때문에 위와 같은 메시지가 나타난다.
여기서 중요한 것은 클린업 함수는 비록 새로운 값을 기반으로 렌더링 뒤에 실행되지만 이 변경된 값을 읽는 것이 아니라 함수가 정의됐을 당시에 선언됐던 이전 값을 보고 실행된다는 것이다.
이 사실을 종합해 보면 왜 useEffeet에 이벤트를 추가했을 때 클린업 함수에서 지워야 하는지 알 수 있다. 함수형 컴포넌트의 useEffect는 그 콜백이 실행될 때마다 이전의 클린업 함수가 존재한다면 그 클린업 함수를 실행한 뒤에 콜백을 실행한다. 따라서 이벤트를 추가하기 전에 이전에 등록했던 이벤트 핸들러를 삭제하는 코드를 클린업 함수에 추가하는 것이다. 이렇게 함으로써 특정 이벤트의 핸들러가 무한히 추가되는 것을 방지할 수 있다.
클린업 함수는 언마운트라기보다는 함수형 컴포넌트가 리렌더링됐을 때 의존성 변화가 있었을 당시 이전의 값을 기준으로 실행되는, 말 그대로 이전 상태를 청소해 주는 개념으로 보는 것이 옳다.

의존성 배열

의존성 배열이 없는 useEffect가 매 렌더링마다 실행된다면 그냥 useEffect 없이 써도 되는 게 아닐까?

// 1
function Component() {
    console.log('렌더링됨')
}
// 2
function Component() {
    useEffect(() => {
        console.log('렌더링됨')
    })
}

두 코드는 명백히 리액트에서 차이점을 지니고 있다. 차이점은 다음과 같다.
- 1) 이후에 소개할 서버 사이드 렌더링 관점에서 useEffect는 클라이언트 사이드에서 실행되는 것을 보장해 준다. useEffect 내부에서는 window 객체의 접근에 의존하는 코드를 사용해도 된다.
- 2) useEffect는 컴포넌트 렌더링의 부수 효과, 즉 컴포넌트의 렌더링이 완료된 이후에 실행된다. 반면 직접 실행은 컴포넌트가 렌더링되는 도중에 실행된다. 따라서 1번과는 달리 서버 사이드 렌더링의 경우에 서버에서도 실행된다. 그리고 이 작업은 함수형 컴포넌트의 반환을 지연시키는 행위다. 즉, 무거운 작업일 경우 렌더링을 방해하므로 성능에 악영향을 미칠 수있다.
useEffect의 effect는 컴포넌트의 사이드 이펙트, 즉 부수 효과를 의미한다는 것을 명심하자. useEffect는 컴포넌트가 렌더링된 후에 어떠한 부수 효과를 일으키고 싶을 때 사용하는 훅이다.

useEffect를 사용할 때 주의할 점

useEffect는 리액트 코드를 작성할 때 가장 많이 사용하는 훅이면서 가장 주의해야 할 훅이기도 하다.
eslint-disable-line react-hooks/exhaustive-deps 주석은 최대한 자제하라. 이 ESLint 룰은 useEffect 인수 내부에서 사용하는 값 중 의존성 배열에 포함돼 있지 않은 값이 있을 때 경고를 발생시킨다. 이 코드를 사용하는 대부분의 예제가 빈 배열 []을 의존성으로 할 때, 즉 컴포넌트를 마운트하는 시점에만 무언가를 하고 싶다라는 의도로 작성하곤 한다. 그러나 이는 클래스형 컴포넌트의 생명주기 메서드인 componentDidMount에 기반한 접근법으로, 가급적이면 사용해선 안 된다.
useEffect는 반드시 의존성 배열로 전달한 값의 변경에 의해 실행돼야 하는 훅이다. 그러나 의존성 배열을 넘기지 않은 채 콜백 함수 내부에서 특정 값을 사용한다는 것은, 이 부수 효과가 실제로 관찰해서 실행돼야 하는 값과는 별개로 작동한다는 것을 의미한다. 즉, 컴포넌트의 state, props와 같은 어떤 값의 변경과 useEffect의 부수 효과가 별개로 작동하게 된다는 것이다. useEffect에서 사용한 콜백 함수의 실행과 내부에서 사용한 값의 실제 변경 사이에 연결 고리가 끊어져 있는 것이다.
따라서 정말로 의존성으로 []가 필요하다면 최초에 함수형 컴포넌트가 마운트됐을 시점에만 콜백 함수 실행이 필요한지를 다시 한번 되물어봐야 한다. 만약 정말 ‘그렇다’라고 하면 useEffect 내 부수 효과가 실행될 위 치가 잘못됐을 가능성이 크다. 다음 예제를 보자.

function Component({ log }: { log: string }) {
    useEffect(() => {
        logging(log)
    }, []) // eslint-disable-line react-hooks/exhaustive-deps
}

위 코드는 log가 최초로 props로 넘어와서 컴포넌트가 최초로 렌더링된 시점에만 실행된다. 그러나 위 코드는 당장은 문제가 없을지라도 버그의 위험성을 안고 있다. log가 아무리 변하더라도 useEffect의 부수 효과는 실행되지 않고, useEffect의 흐름과 컴포넌트의 props.log의 흐름이 맞지 않게 된다.
따라서 앞에서 logging이라는 작업은 log를 props로 전달하는 부모 컴포넌트에서 실행되는 것이 옳을지도 모른다. 부모 컴포넌트에서 Component가 렌더링되는 시점을 결정하고 이에 맞게 log 값을 넘겨준다면 useEffect의 해당 주석을 제거해도 위 예제 코드와 동일한 결과를 만들 수 있고 Component의 부수 효과 흐름을 거스르지 않을 수 있다.
useEffect에 빈 배열을 넘기기 전에는 정말로 useEffect의 부수 효과가 컴포넌트의 상태와 별개로 작동해야만 하는지, 혹은 여기서 호출하는 게 최선인지 한 번 더 검토해 봐아 한다.
빈 배열이 아닐 때도 마찬가지다. 만약 특정 값을 사용하지만 해당 값의 변경 시점을 피할 목적이라면 메모이제이션을 적절히 활용해 해당 값의 변화를 막거나 적당한 실행 위치를 다시 한번 고민해 보는 것이 좋다.

useEffect의 첫 번째 인수에 함수명을 부여하라

useEffect를 사용하는 많은 코드에서 useEffect의 첫 번째 인수로 익명 함수를 넘겨준다. 이는 리액트 공식문서도 마찬가지다.

useEffect(() => {
    logging(user.id)
}, [user.id])

useEffect의 코드가 복잡하고 많아질수록 무슨 일을 하는 useEffect 코드인지 파악하기 어려워진다. 이때 이 useEffect의 인수를 익명 함수가 아닌 적절한 이름을 사용한 기명 함수로 바꾸는 것이 좋다. 우리가 변수에 적절한 이름을 붙이는 이유는 해당 변수가 왜 만들어졌는지 파악하기 위함이다. useEffect도 마찬가지로 적절한 이름을 붙이면 해당 useEffect의 목적을 파악하기 쉬워진다.

useEffect(
    function logActiveUser() {
        logging(user.id)
    },
    [user.id],
)

거대한 useEffect를 만들지 마라

useEffect는 의존성 배열을 바탕으로 렌더링 시 의존성이 변경될 때마다 부수 효과를 실행한다. 이 부수 효과의 크기가 커질수록 애플리케이션 성능에 악영향을 미친다. 비록 useEffect가 컴포넌트의 렌더링 이후에 실행되기 때문에 렌더링 작업에는 영향을 적게 미칠 수 있지만 여전히 자바스크립트 실행 성능에 영향을 미친다는 것은 변함없다.
가능한 한 useEffect는 간결하고 가볍게 유지하는 것이 좋다. 만약 부득이하게 큰 useEffect를 만들어야 한다면 적은 의존성 배열을 사용하는 여러 개의 useEffect로 분리하는 것이 좋다. 만약 의존성 배열이 너무 거대하고 관리하기 어려운 수준까지 이른다면 정확히 이 useEffeet가 언제 발생하는지 알 수 없게 된다.

불필요한 외부 함수를 만들지 마라

useEffect의 크기가 작은 것과 같은 맥락에서 useEffect가 실행하는 콜백 또한 불필요하게 존재해서는 안된다.

useEffect(() => {
    fetchlnfonnation(id)
    return () => controUerRef.current?.abort()
}, [id, fetchinformation])

이 컴포넌트는 props를 받아서 그 정보를 바탕으로 API 호출을 하는 useEffect를 가지고 있다. 그러나 useEffect 밖에서 함수를 선언하다 보니 불필요한 코드가 많아지고 가독성이 떨어졌다.

useEffect(() => {
    const controller = new AbortController()
    ;(async () => {
        const result = await fetchlnfo(id, { signal: controller.signal })
        setlnfo(await result.json())
    })()
    return () => controller.abort()
}, [id])

useEffect 외부에 있던 관련 함수를 내부로 가져왔더니 훨씬 간결한 모습이다. useEffect 내에서 사용할 부수 효과라면 내부에서 만들어서 정의해서 사용하는 편이 훨씬 도움이 된다.

3.1.3 useMemo

useMemo는 비용이 큰 연산에 대한 결과를 저장(메모이제이션)해 두고, 이 저장된 값을 반환하는 훅이다. 흔히 리액트에서 최적화를 떠올릴 때 가장 먼저 언급되는 훅이 바로 useMemo다.

import { useMemo } from 'react'
const memoizedValue = useMemo(() => expensiveComputation(a, b), [a, b])

첫 번째 인수로는 어떠한 값을 반환하는 생성 함수를, 두 번째 인수로는 해당 함수가 의존하는 값의 배열을 전달한다. useMemo는 렌더링 발생 시 의존성 배열의 값이 변경되지 않았으면 함수를 재실행하지 않고 이전에 기억해 둔 해당 값을 반환하고, 의존성 배열의 값이 변경됐다면 첫 번째 인수의 함수를 실행한 후에 그 값을 반환하고 그 값을 다시 기억해 둘 것이다.

3.1.4 useCallback

useMemo가 값을 기억했다면, useCallback은 인수로 넘겨받은 콜백 자체를 기억한다. 쉽게 말해 useCallback은 특정 함수를 새로 만들지 않고 다시 재사용한다는 의미다.

const Childcomponent = memo(({ name, value, onChange }) => {
    // 렌더링이 수행되는지 확인하기 위해 넣었다.
    useEffect(() => {
        console.log('rendering!', name)
    })
    return (
        <>
            <hl>
                {name} {value ? '켜짐' : '꺼짐'}
            </hl>
            <button onClick={onChange}>toggle</button>
        </>
    )
})

function App() {
    const [status1, setStatus1] = useState(false)
    const [status2, setStatus2] = useState(false)

    const togglel =()=>{
        setStatusl(!status1)
    }
    const toggle2 =()=>{
        setStatus2(!status2)
    }
    return (
        <>
        <ChildComponent name="l" value={status1} onChange={togglel} />
        <ChildConiponent name="2" value={status2} onChange={toggle2} />
        </>
    )
}

memo를 사용해서 컴포넌트를 메모이제이션했지만 App의 자식 컴포넌트 전체가 렌더링되고 있다.
위 코드는 Childcomponent에 memo를 사용해 name, value, onChange의 값을 모두 기억하고, 이 값이 변경되지 않았을 때는 렌더링되지 않도록 작성된 코드다. 정상적인 흐름이라면 하나의 value 변경이 다른 컴포넌트에 영향을 미쳐서는 안 되고, 클릭할 때마다 하나의 컴포넌트만 렌더링되어야 한다. 그러나 어느 한 버튼을 클릭하면 클릭한 컴포넌트 외에도 클릭하지 않은 컴포넌트도 렌더링되는 것을 알 수 있다.
그 이유는 state 값이 바뀌면서 App 컴포넌트가 리렌더링되고, 그때마다 매번 onChange로 넘기는 함수가 재생성되고 있기 때문이다.

const toggle1 = useCallback(
    function toggle1() {
        setStatusl(!status1)
    },
    [status1],
)
const toggle2 = useCallback(
    function toggle2() {
        setStatus2(!status2)
    },
    [status2],
)

값의 메모이제이션을 위해 useMemo를 사용했다면, 함수의 메모이제이션을 위해 사용하는 것이 useCallback이다. useMemo와 마찬가지로 의존성 배열이 변경되지 않는 한 함수를 재생성하지 않는다. useCallback을 추가하면 해당 의존성이 변경됐을 때만 함수가 재생성된다.

3.1.5 useRef

useRef는 usestate와 동일하게 컴포넌트 내부에서 렌더링이 일어나도 변경 가능한 상태값을 저장한다는 공통점이 있다. 그러나 usestate와구별되는 큰 차이점 두 가지를 가지고 있다.
- useRef는 반환값인 객체 내부에 있는 current로 값에 접근 또는 변경할 수 있다.
- useRef는 그 값이 변하더라도 렌더링을 발생시키지 않는다.
useRef에 대해 본격적으로 알아보기 전에 useRef가 왜 필요한지 먼저 고민해보자. 렌더링에 영향을 미치지않는 고정된 값을 관리하기 위해서 useRef를 사용한다면 useRef를 사용하지 않고 그냥 함수 외부에서 값을 선언해서 관리하는 것도 동일한 기능을 수행할 수도 있지 않을까? 다음 예제를 보자.

let value = 0
function Component() {
    function handleClick() {
        value += 1
    }

    // ...
}

결론부터 이야기하자면 이 방식은 몇 가지 단점이 있다.
먼저 컴포넌트가 실행되어 렌더링되지 않았음에도 value라는 값이 기본적으로 존재하게 된다. 이는 메모리에 불필요한 값을 갖게 하는 악영향을 미친다. 그리고 만약 Component, 즉 컴포넌트가 여러 번 생성된다면 각 컴포넌트에서 가리키는 값이 모두 value로 동일하다. 컴포넌트가 초기화되는 지점이 다르더라도 하나의 값을 봐야 하는 경우라면 유효할 수도 있지만 대부분의 경우에는 컴포넌트 인스턴스 하나당 하나의 값을 필요로 하는 것이 일반적이다.
useRef의 가장 일반적인 사용 예는 바로 DOM에 접근하고 싶을 때 일 것이다.
useRef는 최초에 넘겨받은 기본값을 가지고 있다. 한 가지 명심할 것은 useRef의 최초 기본값은 return 문에 정의해 둔 DOM이 아니고 useRef()로 넘겨받은 인수라는 것이다. useRef가 선언된 당시에는 아직 컴포넌트가 렌더링되기 전이라 return으로 컴포넌트의 DOM이 반환되기 전이므로 undefined다.

3.1.6 useContext

usecontext에 대해 이해하려면 먼저 리액트의 Context에 대해 알아야 한다.

Context란?

리액트 애플리케이션은 기본적으로 부모 컴포넌트와 자식 컴포넌트로 이뤄진 트리 구조를 갖고 있기 때문에 부모가 가지고 있는 데이터를 자식에서도 사용하고 싶다면 props로 데이터를 넘겨주는 것이 일반적이다. 그러나 전달해야 하는 데이터가 있는 컴포넌트와 전달받아야 하는 컴포넌트의 거리가 멀어질수록 코드는 복잡해진다.
prop 내려주기는 해당 데이터를 제공하는 쪽이나 사용하는 쪽 모두에게 불편하다. 해당 값을 사용하지 않는 컴포넌트에서도 단순히 값을 전달하기 위해 props가 열려 있어야 하고, 사용하는 쪽도 이렇게 prop 내려주기가 적용돼 있는지 확인해야 하는 등 매우 번거로운 작업이다.
prop 내려주기를 극복하기 위해 등장한 개념이 바로 콘텍스트(Context)다. 콘텍스트를 사용하면, 이러한 명시적인 props 전달 없이도 선언한 하위 컴포넌트 모두에서 자유롭게 원하는 값을 사용할 수 있다.

Context를 함수형 컴포넌트에서 사용할 수 있게 해주는 useContext 혹

const Context = createContext<{ hello: string } | undefined>()
function ParentComponent() {
    return (
        <>
            <Context.Provider value=>
                <Context.Provider value=>
                    <ChiIdComponent />
                </Context.Provider〉
            </Context.Provider〉
        </>
    )
}

function ChildComponent() {
    const value = useContext(Context)
    // react가 아닌 javascript가 반환된다.
    return <>{value ? value.hello : ''}</>
}

usecontext는 상위 컴포넌트에서 만들어진 Context를 함수형 컴포넌트에서 사용할 수 있도록 만들어진 훅이다. useContext를 사용하면 상위 컴포넌트 어딘가에서 선언된 에서 제공한 값을 사용할 수 있게 된다. 만약 여러 개의 Provider가 있다면 가장 가까운 Provider의 값을 가져오게 된다.

function useMyContext() {
    const context = useContext(MyContext)
    if (context === undefined) {
        throw new Error(
        'useMyContext는 Contextprovider 내부에서만 사용할 수 있습니다.',
        )
    }
    return context
}

다수의 Provider와 useContext를 사용할 때. 특히 타입스크립트를 사용하고 있다면 위와 같이 별도 함수로 감싸서 사용하는 것이 좋다. 타입 추론에도 유용하고, 상위에 Provider가 없는 경우에도 사전에 쉽게 에러를 찾을 수 있다.

useContext를 사용할 때 주의할 점

usecontext를 함수형 컴포넌트 내부에서 사용할 때는 항상 컴포넌트 재활용이 어려워진다는 점을 염두에 둬야 한다. usecontext가 선언돼 있으면 Provider에 의존성을 가지고 있는 셈이 되므로 아무데서나 재활용하기에는 어려운 컴포넌트가 된다. 해당 함수형 컴포넌트가 Provider 하위에 있지 않은 상태로 useContext를 사용한다면 예기치 못한 작동 방식이 만들어진다. 즉, usecontext가 있는 컴포넌트는 그 순간부터 눈으로는 직접 보이지도 않을 수 있는 Provider와의 의존성을 갖게 되는 셈이다.
이러한 상황을 방지하려면 usecontext를 사용하는 컴포넌트를 최대한 작게 하거나 혹은 재사용되지 않을 만한 컴포넌트에서 사용해야 한다. 이러한 문제를 방지하기 위해 모든 콘텍스트를 최상위 루트 컴포넌트에 넣는 것은 어떨까?
앞서 언급한 에러는 줄어들 수 있지만 리액트 애플리케이션 관점에서는 그다지 현명한 접 근법이 아니다. 콘텍스트가 많아질수록 루트 컴포넌트는 더 많은 콘텍스트로 둘러싸일 것이고 해당 props를 다수의 컴포넌트에서 사용할 수 있게끔 해야 하므로 불필요하게 리소스가 낭비된다. 따라서 컨택스트가 미치는 범위는 필요한 환경에서 최대한 좁게 만들어야 한다.
마지막으로 일부 리액트 개발자들이 콘텍스트와 useContext를 상태 관리를 위한 리액트의 API로 오해하고 있다는 것이다. 엄밀히 따지면 콘텍스트는 상태를 주입해 주는 API다. 상태 관리 라이브러리가 되기 위해서 는 최소한 다음 두 가지 조건을 만족해야 한다.
- 1) 어떠한 상태를 기반으로 다른 상태를 만들어 낼 수 있어야 한다.
- 2) 필요에 따라 이러한 상태 변화를 최적화할 수 있어야 한다.
그러나 콘텍스트는 둘 중 어느 것도 하지 못한다. 단순히 props 값을 하위로 전달해 줄 뿐, usecontext를 사용한다고 해서 렌더링이 최적화되지는 않는다.

const MyContext = createContext<{ hello: string } | undefined>(undefined)
function ContextProvider({
    children,
    text,
}: PropsWithChildren<{ text: string }>) {
    return (
        <MyContext.Provider value=>{children}</MyContext.Provider>
    )
}
function useMyContext() {
    const context = useContext(MyContext)
    if (context === undefined) {
        throw new Error(
        'useMyContext는 Contextprovider 내부에서만 사용할 수 있습니다.',
        )
    }
    return context
}

function GrandChildComponent() {
    const { hello } = useMyContext()
    useEffect(() => {
        console.log('렌더링 GrandChildComponent')
    })
    return <h3>{hello}</h3>
}

function ChildComponent() {
    useEffect(() => {
        console.log('렌더링 Childcomponent')
    })
    return <GrandChildConiponent />
}

function ParentComponent() {
    const [text, setText] = useStateC('')
    function handleChange(e: ChangeEvent<HTMLInpiitElement>) {
        setText(e.target.value)
    }
    useEffect(() => {
        console.log('렌더링 Parentcomponent‘)
    })

    return (
        <>
            <ContextProvider text="react">
                <input value={text} onChange={handleChange} />
                <ChildComponent />
            </ContextProvider>
        </>
    )
}

ParentComponent에서 Provider의 값을 내려주고, 이를 useContext로 GrandChild Component에서 사용 중이다. 언뜻 보기에는 text가 변경되는 Parentcomponent와 이를 사용하는 GrandClildComponent만 렌더링될 것 같지만 그렇지 않다. 사실은 컴포넌트 트리 전체가 리렌더링되고 있다.
부모 컴포넌트가 렌더링되면 하위 컴포넌트는 모두 리렌더링되기 때문이다. usecontext는 상태를 관리하는 마법이 아니라는 사실을 반드시 기억해야 한다. 거듭 이야기하지만 콘텍스트는 단순히 상태를 주입할 뿐 그 이상의 기능도, 그 이하의 기능도 하지 않는다.
그렇다면 아래의 예제를 최적화하려면 어떻게 해야 할까? 예제에서 Childcomponent가 렌더링되지 않게 막으려면 React.memo를 써야 한다. memo는 props 변화가 없으면 리렌더링되지 않고 계속해서 같은 결과물을 반환할 것이다.

3.1.7 useReducer

useReducer는 useState의 심화 버전으로 볼 수 있다. useState와 비슷한 형태를 띠지만 좀 더 복잡한 상태값을 미리 정의해 놓은 시나리오에 따라 관리할 수 있다. useReducer에서 사용되는 용어를 먼저 살펴보자.
- 반환값은 usestate와 동일하게 길이가 2인 배열이다.
  - state: 현재 useReducer가 가지고 있는 값을 의미한다. useState와 마찬가지로 배열을 반환하는데. 동일하게 첫 번째 요소가 이 값이다.
  - dispatcher: state를 업데이트하는 함수. useReducer가 반환하는 배열의 두 번째 요소다. setState는 단순히 값을 넘겨주지만 여기서는 action을 넘겨준다는 점이 다르다. 이 action은 state를 변경할 수 있는 액션을 의미한다.
- usestate의 인수와 달리 2개에서 3개의 인수를 필요로 한다
  - reducer： useReducer의 기본 action을 정의하는 함수다. 이 reducer는 useReducer의 첫 번째 인수로 넘겨주어야한다.
  - initialstate： 두 번째 인수로, useReducer의 초깃값을 의미한다.
  - init： usestate의 인수로 함수를 넘겨줄 때처럼 초깃값을 지연해서 생성시키고 싶을 때 사용하는 함수다. 이 함수는 필수값이 아니며, 만약 여기에 인수로 넘겨주는 함수가 존재한다면 usestate와 동일하게 게으른 초기화가 일어나며 initialstate를 인수로 init 함수가 실행된다.

// useReducer가 사용할 state를 정의
type State = {
    count: number
}

// state의 변화를 발생시킬 action의 타입과 넘겨줄 값(payload)을 정의
// 꼭 type과 payload라는 네이밍을 지킬 필요도 없으며, 굳이 객체일 필요도 없다.
// 다만 이러한 네이밍이 가장 널리 쓰인다.
type Action = { type： 'up' | 'down' | 'reset'; payload?: State }

// 무거운 연산이 포함된 게으른 초기화 함수
function init(count： State)： State {
    // count: State를 받아서 초깃값을 어떻게 정의할지 연산하면 된다.
    return count
}

// 초깃값
const initialstate: State = { count: 0 }

// 앞서 선언한 state와 action을 기반으로 state가 어떻게 변경될지 정의
function reducer(state: State, action: Action): State {
    switch (action.type) {
    case 'up':
        return { count: state.count + 1 }
    case 'down':
        return { count: state.count - 1 > 0 ? state.count - 1 : 0 }
    case 'reset':
        return init(action.payload || { count: 0 })
    default:
        throw new Error('Unexpected action type ${action.type}')
    }
}

export default function App() {
const [state, dispatcher] = useReducer(reducer, initialState, init)
    function handleUpButtonClick() {
        dispatcher({ type: 'up' })
    }
    function handleDownButtonClick() {
        dispatcher({ type: 'down' })
    }
    function handleResetButtonClick() {
        dispatcher({ type: 'reset', payload： { count: 1 } })
    }

    return (
        <div className="App">
            <h1>>{state.count}</h1>
            <button onClick={handleUpButtonClick}>+</button>
            <button onClick={handleDownButtonClick}>-</button>
            <button onClick={handleResetButtonClick}>reset</button>
        </div>
    )
}

복잡한 형태의 state를 사전에 정의된 dispatcher로만 수정할 수 있게 만들어 줌으로써 state 값에 대한 접근은 컴포넌트에서만 가능하게 하고, 이를 업데이트하는 방법에 대한 상세 정의는 컴포넌트 밖에다 둔 다음, state의 업데이트를 미리 정의해 둔 dispatcher로만 제한하는 것이다.
state 값을 변경하는 시나리오를 제한적으로 두고 이에 대한 변경을 빠르게 확인할 수 있게끔 하는 것이 useReducer의 목적이다.
일반적으로 단순히 number나 boolean과 같이 간단한 값을 관리하는 것은 useState로 충분하지만 state 하나가 가져야 할 값이 복잡하고 이를 수정하는 경우의 수가 많아진다면 state를 관리하는 것이 어려워진다. 또 여러 개의 state를 관리하는 것보다 때로는 성격이 비슷한 여러 개의 state를 묶어 useReducer로 관리하는 편이 더 효율적일 수도 있다. 이렇게 useReducer를 사용해 state를 관리하면 state를 사용하는 로직과 이를 관리하는 비즈니스 로직을 분리할 수 있어 state를 관리하기가 한결 쉬워진다.

3.1.8 useImperativeHandle

useImperativeHandle은 실제 개발 과정에서는 자주 볼 수 없는 훅으로 널리 사용되지 않는다. 그럼에도 useImperativeHandle은 일부 사용 사례에서 유용하게 활용될 수 있다. useImperativeHandle을 이해하기 위해서는 먼저 React.forwardRef에 대해 일아야 한다.

forwardRef 살펴보기

ref는 useRef에서 반환한 객체로, 리액트 컴포넌트의 props인 ref에 넣어 HTMLElement에 접근하는 용도로 흔히 사용된다. key와 마찬가지로 ref도 리액트에서 컴포넌트의 props로 사용할 수 있는 예약어로서 별도로 선언돼 있지 않아도 사용할 수다.
만약 이러한 ref를 상위 컴포넌트에서 하위 컴포넌트로 전달하고 싶다면 어떻게 해야 할까? 즉, 상위 컴포넌트에서는 접근하고 싶은 ref가 있지만 이를 직접 props로 넣어 사용할 수 없을 때는 어떻게 해야 할까? 우리가 알고 있는 단순한 ref와 props에 대한 상식으로 이 문제를 해결한다면 다음 코드와 같은 결과물이 나올 것이다.

function ChildComponent({ ref }) {
    useEffect(() => {
        // undefined
        console.log(ref)
    }, [ref])
    return <div>안녕!</div>
}

function ParentComponent() {
    const inputRef = useRef()
    return (
        <>
        <input ref={inputRef} />
        {/* 'ref' is not a prop. Trying to access it will result in 'undefined' being returned. If you
        need to access the same value within the child component, you should pass it as a different prop */}
        〈ChildComponent ref={inputRef} />
        </>
    )
}

리액트에서 ref는 props로 쓸 수 없다는 경고문과 함께 접근을 시도할 경우 undefined를 반환한다고 돼 있다. 그렇다면 예약어로 지정된 ref 대신 다른 props로 받으면 어떨까?

function ChildComponent({ parentRef }) {
    useEffect(() => {
        // {current; undefined}
        // {current: HTMLInputElement}
        console.log(parentRef)
    }, [parentRef])
    return <div>안녕! </div>
}

function ParentComponent() {
    const inputRef = useRef()
        return (
            <>
            <input ref={inputRef} />
            <ChildComponent parentRef={inputRef} />
            </>
        )
}

이러한 방식은 앞선 예제와 다르게 잘 작동하는 것으로 보인다. 그리고 이는 클래스형 컴포넌트나 함수형 컴포넌트에서도 동일하게 작동한다. forwardRef는 방금 작성한 코드와 동일한 작업을 하는 리액트 API다. 그런데 단순히 이렇게 props로 구현할 수 있는 것을 왜 만든 것일까?
그럼에도 forwardRef가 탄생한 배경은 ref를 전달하는 데 있어서 일관성을 제공하기 위해서다. 어떤 props 명으로 전달할지 모르고, 이에 대한 완전한 네이밍의 자유가 주어진 props보다는 forwardRef를 사용하면 좀 더 확실하게 ref를 전달할 것임을 예측할 수 있고, 또 사용하는 쪽에서도 확실히 안정적으로 받아서 사용할수 있다. forwardRef를 사용하는 다음 예제를 보자.

const Childcomponent = forwardRef((props, ref) => {
    useEffect(() => {
        // {current: undefined}
        // {current: HTMLInputElement}
        console.log(ref)
    }, [ref])
return <div>안녕!</div>
})

function ParentComponent() {
    const inputRef = useRef()
    return (
        <>
        <input ref={inputRef} />
        <ChildComponent ref={inputRef} />
        </>
    )
}

먼저 ref를 받고자 하는 컴포넌트를 forwardRef로 감싸고, 두 번째 인수로 ref를 전달받는다. 그리고 부모컴포넌트에서는 동일하게 props, ref를 통해 ref를 넘겨주면 된다. 이렇게 forwardRef를 사용하는 코드로 수정하면 ref를 props로 전달할 수 있고, 전달받은 컴포넌트에서도 ref라는 이름을 그대로 사용할 수 있다.

useImperativeHandle이란?

forwardRef에 대해 알아봤으니 useImperativeHandle에 대해 살펴보자. useImperativeHandle은 부모에게서 넘겨받은 ref를 원하는 대로 수정할 수 있는 훅이다. 다음 코드를 보자.

const Input = forwardRef((props, ref) => {
    // useImperativeHandle을 사용하면 ref의 동작을 추가로 정의할 수 있다.
    useImperativeHandle(
        ref,
        () => ({
            alert： () => alert(props.value),
        }),
        // useEffect의 deps와 같다.
        [props.value].
    )
    return <input ref={ref} {...props} />
})

useImperativeHandle을 사용하면 부모 컴포넌트에서 노출되는 값을 원하는 대로 바꿀 수 있다’라는 말의 뜻이 명확해졌다. 원래 ref는 {current: HTMLElement>}와 같은 형태로 HTMLElement만 주입할 수 있는 객체였다. 그러나 여기서는 전달받은 ref에다 useImperativeHandle 훅을 사용해 추가적인 동작을 정의했다. 이로써 부모는 단순히 HTMLElement뿐만 아니라 자식 컴포넌트에서 새롭게 설정한 객체의 키와 값에 대해서도 접근할 수 있게 됐다. useImperativeHandle을 사용하면 이 ref의 값에 원하는 값이나 액션을 정의할 수 있다.

3.1.9 useLayoutEffect

공식 문서에 따르면 useLayoutEffect를 다음과 같이 정의하고 있다.
- 이 함수의 시그니처는 useEffect와 동일하나, 모든 DOM의 변경 후에 동기적으로 발생핸다.
여기서 useLayoutEffect를 이해하기 위한 중요한 사실은 ‘모든 DOM의 변경 후에 useLayoutEffect의 콜백 함수 실행이 동기적으로 발생’한다는 점이다. 여기서 말하는 DOM 변경이란 렌더링이지, 브라우저에 실제로 해당 변경 사항이 반영되는 시점을 의미하는 것은 아니다. 즉, 실행 순서는 다음과 같다.
- 1) 리액트가 DOM을업데이트
- 2) useLayoutEffect를실행
- 3) 브라우저에 변경 사항을 반영
- 4) useEffect를실행
그리고 동기적으로 발생한다는 것은 리액트는 useLayoutEffect의 실행이 종료될 때까지 기다린 다음에 화면을 그린다는 것을 의미한다. 즉, 리액트 컴포넌트는 useLayoutEffect가 완료될 때까지 기다리기 때문에 컴포넌트가 잠시 동안 일시 중지되는 것과 같은 일이 발생하게 된다. 따라서 이러한 작동 방식으로 인해 웹 애플리케이션 성능에 문제가 발생할 수 있다.
그럼 언제 useLayoutEffect를 사용하는 것이 좋을까? useLayoutEffect의 특징상 DOM은 계산됐지만 이것이 화면에 반영되기 전에 하고 싶은 작업이 있을 때와 같이 반드시 필요할 때만 사용하는 것이 좋다.

3.1.11 훅의 규칙

리액트에서 제공하는 훅은 사용하는 데 몇 가지 규칙이 존재한다. 이러한 규칙을 rules-of-hooks라고 하며 이와 관련된 ESLint 규칙인 react-hooks/rules-of-hooks도 존재한다.
- 1) 최상위에서만 훅을 호출해야 한다. 반복문이나 조건문, 중첩된 함수 내에서 훅을 실행할수 없다. 이규칙을 따라야만 컴포넌트가 렌더링될 때마다 항상 동일한 순서로 훅이 호출되는 것을 보장할 수 있다.
- 훅을 호출할 수 있는 것은 리액트 함수형 컴포넌트. 혹은 사용자 정의 훅의 두 가지 경우뿐이다. 일반 자바스크립트 함수에 서는 훅을 사용할 수 없다.

3.2 사용자 정의 혹과 고차 컴포넌트 중 무엇을 써야 할까?

개발자라면 누구나 중복 코드를 피해야 한다는 말에 대해 십분 공감할 것이다. 같은 작업을 하는 같은 내용의 코드가 있다는 사실은 코드의 존재만으로도 비효율이며 유지보수도 어렵게 만든다. 일반적인 자바스크립트에서 재사용 로직을 작성하는 방식 외에도 리액트에서는 재사용할 수 있는 로직을 관리할 수 있는 두 가지 방법이 있다.
바로 사용자 정의 훅(custom hook)과 고차 컴포넌트(higher order component)다. 사용자 정의 훅과 고차 컴포넌트가 무엇이며 어떻게 쓰는지, 공통된 코드를 하나로 만들고자 할 때 어떤 것을 선택해야 하는지를 살펴보자.

3.2.1 사용자 정의 훅

서로 다른 컴포넌트 내부에서 같은 로직을 공유하고자 할 때 주로 사용되는 것이 바로 사용자 정의 훅이다. 뒤이어 사용할 고차 컴포넌트는 굳이 리액트가 아니더라도 사용할 수 있는 기법이지만 사용자 정의 훅은 리액트에서만 사용할 수 있는 방식이다. 이 사용자 정의 훅은 3.1 절 ‘리액트의 모든 훅 파헤치기’에서 소개한 훅을 기반으로 개발자가 필요한 훅을 만드는 기법이다. 이 사용자 정의 훅의 규칙 중 하나는 이름이 반드시 use로 시작하는 함수를 만들어야 한다는 것이다. 리액트 훅의 이름은 use로 시작한다는 규칙이 있으며, 사용자 정의 훅도 이러한 규칙을 준수함으로써 개발 시 해당 함수가 리액트 훅이라는 것을 바로 인식할 수 있다는 장점도 있다.

import { useEffect, useState } from 'react'
// HTTP 요청을 하는 사용자 정의 훅
function useFetch<T>(
url: string,
{ method, body }: { method: string; body?: XHLHttpRequestBodylnit },
( {
    // 응답 결과
    const [result, setResult] = useState<T | undefined>()
    // 요청 중 여부
    const [isLoading, setlsLoading] = useState<boolean>(false)
    // 2xx 3xx로 정상 응답인지 여부
    const [ok, setOk] = useState<boolean | undefined>()
    // HTTP status
    const [status, setStatus] = useState<number | undefined>()
    useEffect(() => {
        const abortControUer = new AbortControUer()
        ;(async () => {
            setlsLoading(true)
            const response = await fetch(url, {
                methodj
                body,
                signal: abortcontroller.signal,
            })
            setOk(response.ok)
            setStatus(response.status)
            if (response.ok) {
                const apiResult = await response.json()
                setResult(apiRes냐It)
            }
            setlsLoading(false)
        })()
        return () => {
        abortcontroller.abort()
        }
    }, [url, method, body])
    return { ok, result, isLoading, status }
}

이 코드는 fetch를 이용해 API를 호출하는 로직을 사용자 정의 훅으로 분리한 예제다. 만약 훅으로 분리하지 않았다면 fetch로 API 호출을 해야 하는 모든 컴포넌트 내에서 공통적으로 관리되지 않는 최소 4개의 state를 선언해서 각각 구현했어야 할 것이다.
이렇게 복잡하고 반복되는 로직은 사용자 정의 훅으로 간단하게 만들 수 있다. 훅에서 필요한 usestate와 useEffect 로직을 사용자 정의 훅인 useFetch 내부에 두면 사용하는 쪽에서는 useFetch 훅만 사용해도 손쉽게 중복되는 로직을 관리할 수 있다.
이 코드를 통해 왜 use라는 이름을 지켜야 하는지 알 수 있게 됐다. 사용자 정의 훅은 내부에 usestate와 useEffect 등을 가지고 자신만의 원하는 훅을 만드는 기법으로, 내부에서 useState와 같은 리액트 훅을 사용하고 있기 때문에 당연히 앞서 언급한 리액트 훅의 규칙을 따라야 한다. 그리고 이 리액트 훅의 규칙을 따르고 react-hooks/rules-of-hooks의 도움을 받기 위해서는 use로 시작하는 이름을 가져야 한다. 만약 그렇지 않으면 에러가 발생한다.

3.2.2 고차 컴포넌트

고차 컴포넌트(HOC, Higher Order Component)는 컴포넌트 자체의 로직을 재사용하기 위한 방법이다. 사용자 정의 훅은 리액트 훅을 기반으로 하므로 리액트에서만 사용할 수 있는 기술이지만 고차 컴포넌트는 고차 함수(Higher Order Function)의 일종으로, 자바스크립트의 일급 객체, 함수의 특징을 이용하므로 굳이 리액트가 아니더라도 자바스크립트 환경에서 널리 쓰일 수 있다.
리액트에서는 이러한 고차 컴포넌트 기법으로 다양한 최적화나 중복 로직 관리를 할 수 있다. 리액트에서 가장 유명한 고차 컴포넌트는 리액트에서 제공하는 API 중 하나인 React.memo다.

React.memo란?

React.memo를 이해하려면 먼저 앞서 살펴본 렌더링에 대해 다시금 떠올릴 필요가 있다. 리액트 컴포넌트가 렌더링하는 조건에는 여러 가지가 있지만 그중 하나는 바로 부모 컴포넌트가 새롭게 렌더링될 때다. 이는 자 식 컴포넌트의 props 변경 여부와 관계없이 발생한다. 다음 코드를 보자.

const Childcomponent = ({ value }: { value: string }) => {
    useEffect(() => {
        console.log(' 렌더링 !')
    })
    return <>안녕하세요! {value}</>
}

function ParentComponent() {
    const [state, setState] = useState(l)
    function handleChange(e: ChangeEvent<HTMLInputEleinent>) {
        setState(Number(e.target.value))
    }
    return (
    <>
        <input type="number" value={state} onChange={handleChange} />
        <ChildComponent value="hello" />
    </>
    )
}

예제에서 Childcomponent는 props인 value=”hello”가 변경되지 않았음에도 handleChange로 인해 setstate를 실행해 state를 변경하므로 리렌더링이 발생한다.
이처럼 props의 변화가 없음에도 컴포넌트의 렌더링을 방지하기 위해 만들어진 리액트의 고차 컴포넌트가 바로 React.memo다. React.memo는 렌더링하기에 앞서 props를 비교해 이전과 props가 같다면 렌더링 자체를 생략하고 이전에 기억해 둔(memoization) 컴포넌트를 반환한다. 앞선 예제를 memo로 감싸서 다시 실행해 보자.

const Childcomponent = memo(({ value }: { value： string }) => {
    useEffect(() => {
        console.log('렌더링!')
    })
    return <>안녕하세요! {value}</>
})

이제 Parentcomponent에서 아무리 state가 변경돼도 ChildComponent는 다시 렌더링되지 않는다. 그 이유는 props가 변경되지 않았고, 변경되지 않았다는 것을 memo가 확인하고 이전에 기억한 컴포넌트를 그대로 반환한 것이다. 결국 앞서서 발생했던 불필요한 렌더링 작업을 생략할 수 있게 됐다.

고차 함수 만들어보기

리액트의 고차 컴포넌트를 만들기에 앞서 먼저 자바스크립트에서 고차 함수를 만드는 것에 대해 살펴보고자 한다. 리액트의 함수형 컴포넌트도 결국 함수이기 때문에 함수를 기반으로 고차 함수를 만드는 것을 먼저 이해해야 한다. 고차 함수의 사전적인 정의를 살펴보면 ‘함수를 인수로 받거나 결과로 반환하는 함수’라고 정의돼 있다. 가장 대표적인 고차 함수로는 리액트에서 배열을 렌더링할 때 자주 사용하는 Array.prototype.map을 들 수 있다. 다음 예제를 통해 고차 함수가 무엇인지 알아보자.

const list = [1, 2, 3]
const doubledList = list.map((item) => item * 2)

Array.prototype.map을 사용하는 예제를 살펴보면 앞서 고차 함수의 사전적 정의와 마찬가지로 (item) => item * 2, 즉 함수를 인수로 받는다는 것을 알 수 있다. 비롯해 forEach나 reduce 등도 고차 함수임을 알 수 있다. 이번에는 리액트 코드에서 살펴보자.

// 즉시 실행 함수로 setter를 만든다.
const setstate = (function () {
    // 현재 index를 클로저로 가둬놔서 이후에도 계속해서 동일한 index에
    // 접근할 수 있도록 한다.
    let currentindex = index
    return function (value) {
        global.states[currentlndex] = value
        // 컴포넌트를 렌더링한다. 실제로 컴포넌트를 렌더링하는 코드는 생략했다.
    }
})()

위 예제는 앞서 3.1 절 ‘리액트의 모든 훅 파헤치기’에서 설명한 setstate 함수를 구현한 예제다. 이 setState는 usestate에서 반환된 두 번째 배열의 값으로 실행할 수 있는 함수를 반환한다. 이 역시 마찬가지로 함수를 결과로 반환하는’이라는 조건을 만족하므로 고차 함수라고 할 수 있다.
이 번에는 직접 고차 함수를 만들어 보자. 다음은 두 값을 더하는 함수를 고차 함수로 구현해 보았다.

function add(a) {
    return function (b) {
        return a + b
    }
}

const result = add(1) // 여기서 result는 앞서 반환한 함수를 가리킨다.
const result2 = result(2) // 비로소 a와 b룔 더한 3이 반환된다.

add(l)라는 함수를 호출하는 시점에 1이라는 정보가 a에 포함되고, 이러한 정보가 담긴 수를 result로 반환된다. 잠깐, 이것은 마치 usestate의 원리와 비슷하다. useState의 실행은 함수 호출과 동시에 끝났지만 state의 값은 별도로 선언한 환경, 즉 클로저에 기억된다. 여기에서도 마찬가지로 a=1이라는 정보가 담긴 클로저가 result에 포함됐고, result(2)를 호출하면서 이 클로저에 담긴 a=1인 정보를 활용해 1 + 2의 결과를 반환할 수 있게 됐다.

고차 함수를 활용한 리액트 고차 컴포넌트 만들어보기

사용자 인증 정보에 따라서 인증된 사용자에게는 개인화된 컴포넌트를, 그렇지 않은 사용자에게는 별도로 정의된 공통 컴포넌트를 보여주는 시나리오를 떠올려보자. 고차 함수의 특징에 따라 개발자가 만든 또 다른 함수를 반환할 수 있다는 점에서 고차 컴포넌트를 사용하면 매우 유용하다. 다음 예제를 보자.

interface LoginProps {
    loginRequired?: boolean
}
function withLoginComponent<T>(Component: ComponentType<T>) {
    return function (props: T & LoginProps) {
        const { loginRequired, ...restProps } = props
        if (loginRequired) {
            return <>로그인이 필요합니다.</>
        }
        return <Component {...(restProps as T)} />
    }
}

// 원래 구현하고자 하는 컴포넌트를 만들고, WithLoginComponent로 감싸기만 하면 끝이다.
// 로그인 여부, 로그인이 안 되면 다른 컴포넌트를 렌더링하는 책임은 모두
// 고차 컴포넌트인 WithLoginComponent에 맡길 수 있어 매우 편리하다.
const Component = withLoginComponent((props: { value: string }) => {
    return <h3>{props.value}</h3>
})

export default function App() {
    // 로그인 관련 정보를 가져온다.
    const isLogin = true
    return <Component value="text" loginRequired={isLogin} />
    // return <Component value="text" />;
}

Component는 우리가 아는 일반적인 함수형 컴포넌트와 같은 평범한 컴포넌트지만, 이 함수 자체를 withLoginComponent라 불리는 고차 컴포넌트로 감싸뒀다. withLoginComponent는 함수(함수형 컴포넌트)를 인수로 받으며. 컴포넌트를 반환하는 고차 컴포넌트다.
이처럼 고차 컴포넌트는 컴포넌트 전체를 감쌀 수 있다는 점에서 사용자 정의 훅보다 더욱 큰 영향력을 컴포넌트에 미칠 수 있다. 단순히 값을 반환하거나 부수 효과를 실행하는 사용자 정의 훅과는 다르게, 고차 컴포넌트는 컴포넌트의 결과물에 영향을 미칠 수 있는 다른 공통된 작업을 처리할 수 있다.
이번에는 고차 컴포넌트를 구현하기에 앞서 구현 시 주의할 점을 살펴보자. 사용자 정의 훅이 use로 시작하는 이름을 사용했다면 리액트의 고차 컴포넌트도 마찬가지로 with로 시작하는 이름을 사용해야 한다는 것이다. 이는 앞선 use의 경우와 같이 ESLint 규칙 등으로 강제되는 사항은 아니지만 리액트 라우터의 withRouter와 같이 리액트 커뮤니티에 널리 퍼진 일종의 관습이라 볼 수 있다. with가 접두사로 붙어 있으면 고차 컴포넌트임을 손쉽게 알아채어 개발자 스스로가 컴포넌트 사용에 주의를 기울일 수 있으므로 반드시 with로 시작하는 접두사로 고차 컴포넌트를 만들자.
고차 컴포넌트를 사용할 때 주의할 점 중 하나는 부수 효과를 최소화해야 한다는 것이다. 고차 컴포넌트는 반드시 컴포넌트를 인수로 받게 되는데, 반드시 컴포넌트의 props를 임의로 수정, 추가, 삭제하는 일은 없어야 한다. 앞의 예제의 경우에는 loginRequired라는 props를 추가했을 뿐, 기존에 인수로 받는 컴포넌트의 props는 건드리지 않았다. 만약 기존 컴포넌트에서 사용하는 props를 수정하거나 삭제한다면 고차 컴포넌트를 사용하는 쪽에서는 언제 props가 수정될지 모른다는 우려를 가지고 개발해야 하는 불편함이 생긴다. . 만약 컴포넌트에 무언가 추가적인 정보를 제공해 줄 목적이라면 별도 props로 내려주는 것이 좋다.
마지막으로 주의할 점은, 여러 개의 고차 컴포넌트로 컴포넌트를 감쌀 경우 복잡성이 커진다는 것이다. 다음 예제 코드를 보자.

const Component = withHigherOrderComponentl(
    withHigher0rderComponent2(
        withHigher0rderComponent3(
            withHigher0rderComponent4(
                withHigher0rderCoinponent5(() => {
                    return <>안녕하세요.</>
                })>
            ),
        ),
    ),
)

고차 컴포넌트가 컴포넌트를 또 다른 컴포넌트로 감싸는 구조로 돼 있다 보니, 여러 개의 고차 컴포넌트가 반복적으로 컴포넌트를 감쌀 경우 복잡성이 매우 커진다. 고차 컴포넌트가 증가할수록 개발자는 이것이 어떤 결과를 만들어 낼지 예측하기 어려워진다. 따라서 고차 컴포넌트는 최소한으로 사용하는 것이 좋다.

3.2.3 사용자 정의훅과 고차 컴포넌트 중 무엇을 써야 할까?

사용자 정의 훅과 고차 컴포넌트 모두 리액트 코드에서 어떠한 로직을 공통화해 별도로 관리할 수 있다는 특징이 있다. 애플리케이션 전반에 필요한 중복된 로직을 별도로 분리해 컴포넌트의 크기를 줄이고 가독성을 향상시키는 데 도움을 줄 수 있다. 그렇다면 어떠한 경우에 각각 사용자 정의 훅 또는 고차 컴포넌트를 써야할까?

사용자 정의 훅이 필요한 경우

단순히 useEffect, usestate와 같이 리액트에서 제공하는 훅으로만 공통 로직을 격리할 수 있다면 사용자 정의 훅을 사용하는 것이 좋다. 사용자 정의 훅은 그 자체로는 렌더링에 영향을 미치지 못하기 때문에 사용이 제한적이므로 반환하는 값을 바탕으로 무엇을 할지는 개발자에게 달려 있다. 따라서 컴포넌트 내부에 미치는 영향을 최소화해 개발자가 훅을 원하는 방향으로만 사용할 수 있다는 장점 이 있다.

// 사용자 정의 훅올 사용하는 경우
function HookComponent() {
    const { loggedln } = useLogin()

    useEffect(() => {
        if (!loggedln) {
        // do something..
        }
    }, [loggedln])
}
// 고차 컴포넌트를 사용하는 경우
const HOCComponent = withLoginComponent(() => {
// do something...
}

로그인 정보를 가지고 있는 훅인 useLogin은 단순히 loggedln에 대한 값만 제공할 뿐, 이에 대한 처리는 컴포넌트를 사용하는 쪽에서 원하는 대로 사용 가능하다. 따라서 부수 효과가 비교적 제한적이라고 볼 수 있다. 반면 WithLoginComponent는 고차 컴포넌트가 어떤 일을 하는지, 어떤 결과물을 반환할지는 고차 컴포넌트를 직접 보거나 실행하기 전까지는 알 수 없다. 대부분의 고차 컴포넌트는 렌더링에 영향을 미치는 로직이 존재하므로 사용자 정의 훅에 비해 예측하기가 어렵다.
따라서 단순히 컴포넌트 전반에 걸쳐 동일한 로직으로 값을 제공하거나 특정한 훅의 작동을 취하게 하고 싶다면 사용자 정의 훅을 사용하는 것이 좋다.

고차 컴포넌트를 사용해야 하는 경우

앞선 예제와 같이 만약 로그인되지 않은 어떤 사용자가 컴포넌트에 접근하려 할 때 애플리케이션 관점에서 컴포넌트를 감추고 로그인을 요구하는 공통 컴포넌트를 노출하는 것이 좋을 수 있다. 혹은 에러 바운더리와 비슷하게 어떠한 특정 에러가 발생했을 때 현재 컴포넌트 대신 에러가 발생했음을 알릴 수 있는 컴포넌트를 노출하는 경우도 있을 것이다. 앞선 예제를 조금 변경해 보자.

function HookComponent() {
    const { loggedln } = useLogin()
    if (!loggedln) {
        return <LoginComponent />
    }
    return <>안녕하세요.</>
}

const HOCComponent = withLoginComponent(() => {
    // loggedln state의 값을 신경 쓰지 않고 그냥 컴포넌트에 필요한 로직만
    // 추가해서 간단해졌다. loggedln state에 따른 제어는 고차 컴포넌트에서 해줄 것이다.
    return <>안녕하세요.</>
})

만약 이러한 작업을 사용자 정의 훅으로 표현해야 한다고 가정해 보자. 어차피 loggedln이 faIse인 경우에 렌더링해야 하는 컴포넌트는 동일하지만 사용자 정의 훅만으로는 이를 표현하기 어렵다. 사용자 정의 훅은 해당 컴포넌트가 반환하는 랜더링 결과물에까지 영향을 미치기는 어렵기 때문이다.
함수형 컴포넌트의 반환값, 즉 렌더링의 결과물에도 영향을 미치는 공통 로직이라면 고차 컴포넌트를 사용하자. 고차 컴포넌트는 이처럼 공통화된 렌더링 로직을 처리하기에 매우 훌륭한 방법이다. 물론 앞서 이야기한 것처럼 고차 컴포넌트가 많아질수록 복잡성이 기하급수적으로 증가하므로 신중하게 사용해야 한다.

3.2.4 정리

지금까지 사용자 정의 훅과 고차 컴포넌트가 무엇인지, 또 언제 사용하면 좋을지 살펴봤다. 개발하는 애플리케이션의 규모가 커지고, 처리해야 하는 로직이 많아질수록 중복 작업에 대한 고민 또한 필연적으로 많아질 수밖에 없다. 공통화하고 싶은 작업이 무엇인지, 또 현재 이를 처리해야 하는 상황을 잘 살펴보고 적절한 방법을 고른다면 애플리케이션 개발이 더 효율적으로 개선될 것이다.

끝!

2장 리액트 핵심 요소 깊게 살펴보기 정리

Sun, 21 Jan 2024 00:00:00 +0900

2.1 JSX란?

JSX는 자바스크립트 내부에서 표현하기 까다로웠던 XML 스타일의 트리 구문을 작성하는 데 많은 도움을 주는 새로운 문법

2.1.1 JSX의 정의

JSX는 기본적으로 JSXElement, JSXAttributes, JSXChildren, JSXStrings라는 4가지 컴포넌트를 기반으로 구성

JSXElement

JSX를 구성하는 가장 기본 요소로, HTML의 요소(element)와 비슷한 역할

JSXAttributes

JSXElement에 부여할 수 있는 속성을 의미

JSXChildren

JSXElement의 자식 값
JSXText, JSXElement, JSXFragment가 올 수 있음

2.1.3 JSX는 어떻게 자바스크립트로 변환될까?

babel/plugintransform-react-jsx 플러그인을 통해 JSX 구문을 자바스크립트가 이해할 수 있는 형태로 변환

2.2 가상 DOM과 리액트 파이버

리액트의 가상 DOM이 무엇인지, 그리고 실제 DOM에 비해 어떤 이점이 있는지에 대해서 알아보자.

2.2.2 가상 DOM의 탄생 배경

가상 DOM은 웹페이지가 표시해야 할 DOM을 일단 메모리에 저장하고 리액트가 실제 변경에 대한 준비가 완료됐을 때 실제 브라우저의 DOM에 반영
DOM 계산을 브라우저가 아닌 메모리에서 계산하는 과정을 한 번 거치게 된다면 실제로는 여러 번 발생했을 렌더링 과정을 최소화할 수 있고 브라우저와 개발자의 부담을 덜 수 있음

2.2.3 가상 DOM을 위한 아키텍처, 리액트 파이버

가상 DOM과 렌더링 과정 최적화를 가능하게 해주는 것이 바로 리액트 파이버(React Fiber)

파이버 재조정자(fiber reconciler)

가상 DOM과 실제 DOM을 비교해 변경 사항을 수집하며, 만약 이 둘 사이에 차이가 있으면 변경에 관련된 정보를 가지고 있는 파이버를 기준으로 화면에 렌더링을 요청하는 역할

리액트 파이버란?

리액트 파이버는 리액트에서 관리하는 평범한 자바스크립트 객체
- 작업을 작은 단위로 분할하고 쪼갠 다음, 우선순위를 매김
- 이러한 작업을 일시 중지하고 나중에 다시 시작할 수 있음
- 이전에 했던 작업을 다시 재사용하거나 필요하지 않은 경우에는 폐기할 수 있음
파이버는 일단 하나의 작업 단위로 구성
- 1) 렌더 단계에서 리액트는 사용자에게 노출되지 않는 모든 비동기 작업을 수행. 그리고 이 단계에서 파이버의 작업, 우선순위를 지정하거나 중지시키거나 버리는 등의 작업이 일어남
- 2) 커밋 단계에서는 DOM에 실제 변경 사항을 반영하기 위한 작업. commitWork()가 실행되는데, 이 과정은 앞서와 다르게 동기식으로 일어나고 중단될 수 없음
리액트 요소는 렌더링이 발생 할 때마다 새롭게 생성되지만 파이버는 가급적이면 재사용됨
리액트는 가상 DOM이 아닌 Value UI, 즉 값을 가지고 있는 UI를 관리하는 라이브러리
리액트의 핵심 원칙은 UI를 문자열, 숫자, 배열과 같은 값으로 관리한다는 것

리액트 파이버 트리

파이버 트리는 리액트 내부에서 두 개가 존재
하나는 현재 모습을 담은 파이버 트리이고, 다른 하나는 작업 중인 상태를 나타내는 workInProgress 트리
리액트 파이버의 작업이 끝나면 리액트는 단순히 포인터만 변경해 worklnProgress 트리를 현재 트리로 변경

2.2.4 파이버와 가상 DOM

리액트 컴포넌트에 대한 정보를 1：1로 가지고 있는 것이 파이버이며, 이 파이버는 리액트 아키텍처 내부에서 비동기로 이뤄짐
이러한 비동기 작업과 달리, 실제 브라우저 구조인 DOM에 반영하는 것은 동기적으로 일어나야 하고, 또 처리하는 작업이 많아 화면에 불완전하게 표시될 수 있는 가능성이 높으므로 이러한 작업을 가상에서, 즉 메모리상에서 먼저 수행해서 최종적인 결과물만 실제 브라우저 DOM에 적용하는 것

2.2.5 정리

가상 DOM과 리액트의 핵심은 브라우저의 DOM을 더욱 빠르게 그리고 반영하는 것이 아니라 바로 값으로 UI를 표현하는 것
화면에 표시되는 UI를 자바스크립트의 문자열, 배열 등과 마찬가지로 값으로 관리하고 이러한 흐름을 효율적으로 관리하기 위한 메커니즘이 바로 리액트의 핵심
개발자가 직접 DOM을 수동으로 하나하나 변경해야 한다면 어떤 값이 바뀌었는지, 또 그 값에 따라 어떠한 값이 변경됐고 이와 관련된 것들이 무엇이었는지 파악하기가 매우 어려울 것
이러한 어려움을 리액트 내부의 파이버와 재조정자가 내부적인 알고리즘을 통해 관리해 줌으로써 대규모 웹 애플리케이션을 효율적으로 유지보수하고 관리할 수 있게 된 것

2.3 클래스형 컴포넌트와 함수형 컴포넌트

2.3.1 클래스형 컴포넌트

클래스형 컴포넌트의 한계

데이터의 흐름을 추적하기 어려움
애플리케이션 내부 로직의 재사용이 어려움
기능이 많아질수록 컴포넌트의 크기가 커짐
클래스는 함수에 비해 상대적으로 어려움

2.3.3 함수형컴포넌트 vs. 클래스형 컴포넌트

render 내부에서 필요한 함수를 선언할때 this 바인딩을 조심할 필요 없음
state는 객체가 아닌 각각의 원시값으로 관리되어 훨씬 사용하기가 편함
렌더링하는 코드인 return에서도 굳이 this를 사용하지 않더라도 props와 state에 접근 가능
함수형 컴포넌트는 props를 받아 단순히 리액트 요소만 반환하는 함수인 반면, 클래스형 컴포넌트는 render 메서드가 있는 React.Component를 상속받아 구현하는 자바스크립트 클래스

함수형 컴포넌트와 렌더링된 값

함수형 컴포넌트는 렌더링이 일어날 때마다 그 순간의 값인 props와state를 기준으로 렌더링
클래스형 컴포넌트는 시간의 흐름에 따라 변화하는 this를 기준으로 렌더링

2.4 렌더링은 어떻게 일어나는가?

리액트의 렌더링은 브라우저가 렌더링에 필요한 DOM 트리를 만드는 과정을 의미

2.4.1 리액트의 렌더링이란?

리액트 애플리케이션 트리 안에 있는 모든 컴포넌트들이 현재 자신들이 가지고 있는 props와 state의 값을 기반으로 어떻게 UI를 구성하고 이를 바탕으로 어떤 DOM 결과를 브라우저에 제공할 것인지 계산하는 일련의 과정을 의미

2.4.2 리액트의 렌더링이 일어나는 이유

리액트에서 렌더링이 발생하는 시나리오
1) 최초 렌더링: 사용자가 처음 애플리케이션에 진입하면 당연히 렌더링해야 할 결과물이 필요
2) 리렌더링: 리렌더링은 처음 애플리케이션에 진입했을 때 최초 렌더링이 발생한 이후로 발생하는 모든 렌더링을 의미
- 함수형 컴포넌트의 useState()의 두 번째 배열 요소인 setter가 실행되는 경우
- 함수형 컴포넌트의 useReducer()의 두 번째 배열 요소인 dispatch가 실행되는 경우
- 컴포넌트의 key props가 변경되는 경우
- 부모 컴포넌트가 리렌더링된다면 자식 컴포넌트도 무조건 리렌더링

2.4.3 리액트의 렌더링 프로세스

일반적으로 렌더링 결과물은JSX 문법으로 구성
JSX 문법에서 자바스크립트로 컴파일되면서 React.createElement()를 호출하는 구문으로 변환
createElement()는 브라우저의 UI 구조를 설명할 수 있는 일반적인 자바스크립트 객체를 반환
이런 과정을 거쳐 각 컴포넌트의 렌더링 결과물을 수집한 다음, 리액트의 새로운 트리인 가상 DOM과 비교해 실제 DOM에 반영하기 위한 모든 변경 사항을 차례차례 수집(재조정)
재조정 과정이 모두 끝나면 모든 변경 사항을 하나의 동기 시퀀스로 DOM에 적용해 변경된 결과물이 보이게됨

2.4.4 렌더와 커밋

리액트의 렌더링은 렌더 단계와 커밋 단계라는 총 두 단계로 분리되어 실행
렌더 단계(Render Phase)는 컴포넌트를 렌더링하고 변경 사항을 계산하는 모든 작업
커밋 단계(Commit Phase)는 렌더 단계의 변경 사항을 실제 DOM에 적용해 사용자에게 보여주는 과정
이 단계가 끝나야 비로소 브라우저의 렌더링이 발생
이렇게 만들어진 모든 DOM 노드 및 인스턴스를 가리키도록 리액트 내부의 참조를 업데이트
그 다음 useLayoutEffect 훅 호출

2.5 컴포넌트와 함수의 무거운 연산을 기억해 두는 메모이제이션

2.5.1 주장 1: 섣부른 최적화는 독이다, 꼭 필요한 곳에만 메모이제이션을 추가하자

대부분의 가벼운 작업 자체는 메모이제이션해서 자바스크립트 메모리 어딘가에 두었다가 그것을 다시 꺼내오는 것보다는 매번 이 작업을 수행해 결과를 반환하는 것이 더 빠를 수 있음
메모제이션 비용 : 값을 비교하고 렌더링 또는 재계산이 필요한지 확인하는 작업, 그리고 이전에 결과물을 저장해 두었다가 다시 꺼내와야 한다는 두 가지 비용

2.5.2 주장 2： 렌더링 과정의 비용은 비싸다, 모조리 메모이제이션해 버리자

memo를 일단 그냥 다 적용하는 방법
- 렌더링 비용이 저렴하거나 사실 별로 렌더링이 안 되는 컴포넌트에 memo를 썼을 때 역으로 지불해야 하는 비용?
  - 잘못된 memo로 지불해야 하는 비용은 바로 props에 대한 얕은 비교가 발생하면서 지불해야 하는 비용
- 반면 memo를 하지 않았을 때 발생할 수 있는 문제
  - 렌더링을 함으로써 발생하는 비용
  - 컴포넌트 내부의 복잡한 로직의 재실행
  - 그리고 위 두 가지 모두가 모든 자식 컴포넌트에서 반복해서 일어남
  - 리액트가 구 트리와 신규 트리를비교
- 비록 섣부른 초기화라 할지라도 했을 때 누릴 수 있는 이점, 그리고 이를 실수로 빠트렸을 때 치러야 할 위험 비 용이 더 크기 때문에 최적화에 대한 확신이 없다면 가능한 한 모든 곳에 메모이제이션을 활용한 최적화를 하는 것이 좋음

끝!

2장 리액트 핵심 요소 깊게 살펴보기

Sat, 20 Jan 2024 00:00:00 +0900

이번 장에서는 리액트를 이루는 핵심적인 개념을 깊게 샆펴보고, 이러한 기능이 자바스크립트를 토대로 어떻게 동작하는지 알아보자.

2.1 JSX란?

보통 리액트를 통해 JSX를 접하기 때문에 JSX가 리액트의 전유물이라고 오해하는 경우가 종종 있다. 페이스북에서 독자적으로 개발했다는 사실에서 미루어 알 수 있듯이 JSX는 이른바 ECMAScript라고 불리는 자바스크립트 표준의 일부는 아니다. 즉, V8이나 Deno와 같은 자바스크립트 엔진이나 크롬, 웨일, 파이어폭스 같은 브라우저에 의해서 실행되거나 표현되도록 만들어진 구문이 아니다.
앞서 언급했던 것처럼 JSX는 자바스크립트 표준 코드가 아닌 페이스북이 임의로 만든 새로운 문법이기 때문에 JSX는 반드시 트랜스파일러를 거쳐야 비로소 자바스크립트 런타임이 이해할 수 있는 의미 있는 자바스크립트 코드로 변환된다.
JSX의 설계 목적은 JSX 내부에 트리 구조로 표현하고 싶은 다양한 것들을 작성해두고, 이 JSX를 트랜스파일이라는 과정을 거쳐 자바스크립트(ECMAScript)가 이해할 수 있는 코드로 변경하는 것이 목표라고 볼 수 있다.
요약하자면 JSX는 자바스크립트 내부에서 표현하기 까다로웠던 XML 스타일의 트리 구문을 작성하는 데 많은 도움을 주는 새로운 문법이라고 볼 수 있다. 이제 본격적으로 JSX가 어떻게 구성돼 있고 자바스크립트가 이를 이해하기 위해 어떤 과정을 거쳐야 하는지 살펴보자.

2.1.1 JSX의 정의

JSX는 기본적으로 JSXElement, JSXAttributes, JSXChildren, JSXStrings라는 4가지 컴포넌트를 기반으로 구성돼 있다. 각 컴포넌트에 대해 살펴보자.

JSXElement

JSX를 구성하는 가장 기본 요소로, HTML의 요소(element)와 비슷한 역할을 한다. JSXElement가 되기 위해서는 다음과 같은 형태 중 하나여야 한다.
- JSXOpeningElement: 일반적으로 볼 수 있는 요소다. JSXOpeningElement로 시작했다면 후술할 JSXClosingElement가 동일한 요소로 같은 단계에서 선언돼 있어야 올바른 JSX 문법으로 간주된다.
  - 예:〈JSXElement JSXAttribiites(optional)>
- JSXClosingElement: JSXOpeningElement가 종료됐음을 알리는 요소로, 반드시 JSXOpeningElement와 쌍으로 사용돼야 한다.
  - 예:〈JSXElement />
- JSXSelfClosingElement: 요소가 시작되고, 스스로 종료되는 형태를 의미한다. 와 동일한 모습을 띠고 있다. 이는 내부적으로 자식을 포함할 수 없는 형태를 의미한다.
  - 예:〈JSXElement JSXAttributes(optional) />
- JSXFragment: 아무런 요소가 없는 형태로, JSXSelfClosingElement 형태를 띨 수는 없다. “</>”는 불가능하다. 단 “<></>” 는가능하다.

JSXAttributes

JSXElement에 부여할 수 있는 속성을 의미한다. 단순히 속성을 의미하기 때문에 모든 경우에서 필수값이 아니고, 존재하지 않아도 에러가 나지 않는다.
- JSXSpreadAttributes: 자바스크립트의 전개 연산자와 동일한 역할을 한다고 볼 수 있다.
  - {.. .AssignmentExpression}: 이 AssignmentExpression에는 단순히 객체뿐만 아니라 자바스크립트에서 AssignmentExpression으로 취급되는 모든 표현식이 존재할 수 있다. 여기에는 조건문 표현식, 화살표 함수, 할당식 등 다양한 것이 포함돼 있다.
- JSXAttribute： 속성을 나타내는 키와 값으로 짝을 이루어서 표현한다. 키는 JSXAttributeName, 값은 JSXAttribute Value로 불린다.

JSXChildren

JSXElement의 자식 값을 나타낸다. JSX는 앞서 언급했듯 속성을 가진 트리 구조를 나타내기 위해 만들어졌기 때문에 JSX로 부모와 자식 관계를 나타낼 수 있으며, 그 자식을 JSXChildren이라고 한다.
- JSXChild： JSXChildren을 이루는 기본 단위다. 단어의 차이에서 알 수 있듯이 JSXChildren은 JSXChild를 0개 이상 가질 수 있다.
  - JSXText: {. <, >, }을 제외한 문자열
  - JSXElement: 값으로 다른 JSX 요소가 들어갈 수 있다.
  - JSXFragment: 값으로 빈 JSX 요소인 <></>가 들어갈 수 있다
  - { JSXChildExpression (optional) }: 이 JSXChildExpression은 자바스크립트의 AssignmentExpression을 의미한다. 익숙하지 않겠지만 다음과 같은 코드두 올바른 JSX 표현식으로 볼 수 있다.
```
  // 이 함수를 리액트에서 렌더링하면 "foo"라는 문자열이 출력된다.
  export default function App() {
      return <>{(() => 'foo')()}</>
  }
```

JSXStrings

HTML에서 사용 가능한 문자열은 모두 JSXStrings에서도 가능하다. 이는 개발자가 HTML의 내용을 손쉽게 JSX로 가져올 수 있도록 의도적으로 설계된 부분이다. 여기서 정의된 문자열이라 함은, “큰따옴표로 구성된 문자열”, ‘작은따옴표로 구성된 문자열’ 혹은 JSXText를 의미한다.

2.1.2 JSX 예제

백문불여일견!! 코드를 보며, 앞서 소개한 4가지 요소를 조합해 JSX를 만들어 보자. 다음 예제는 모두 유효한JSX 구조를 띠고 있다.

// 하나의 요소로 구성된 가장 단순한 형태
const ComponentA = <A>안녕하세요.</A>
// 자식이 없이 SelfClosingTag로 닫혀 있는 형태도 가능하다.
const ComponentB = <A />
// 옵션을 { }와 전개 연산자로 넣을 수 있다.
const ComponentC = <A {...{ required: true }} />
// 속성만 넣어도 가능하다.
const ComponentD = <A required />
// 속성과 속성을 넣을 수 있다.
const ComponentE = <A required={false} />
const ComponentF = (
    <A>
        {/* 문자열은 큰따옴표 및 작은따옴표 모두 가능하다. */}
        <B text="리액트" />
    </A>
)
const ComponentG = (
    <A>
        {/* 옵션의 값으로 JSXElement를 넣는 것 또한 올바론 문법이다. */}
        <B optionalChildren={<>안녕하세요.</>} />
    </A>
)
const ComponentH = (
    <A>
        {/* 여러 개의 자식도 포함할 수 있다. */}
        안녕하세요
        <B text="리액트" />
    </A>
)

2.1.3 JSX는 어떻게 자바스크립트로 변환될까?

우선 자바스크립트에서 JSX가 변환되는 방식을 알려면 리액트에서 JSX를 변환하는 @babel/plugintransform-react-jsx 플러그인을 알아야 한다. 이 플러그인은 JSX 구문을 자바스크립트가 이해할 수 있는 형태로 변환한다.
다음과 같은JSX 코드가 있다고 가정해 보자.

const ComponentA = <A> required={true}>Hello World</A>
const ComponentB = <>Hello World</>
const ComponentC = (
    <div>
        <span>hello world</span>
    </div>
)

이를 변환한 결과는 다음과 같다.

var ComponentA = React.createElement(
    A,
    {
    required: true,
    },
    'Hello World',
)
var ComponentB = React.createElement(React.Fragment, null, 'Hello World')
var ComponentC = React.createElement(
    'div',
    null.
    React.createElement('span', null, 'heUo world'),
)

@babel/plugin-transform-react-jsx를 직접 써보고 싶다면 필요한 패키지를 설치하고 다음과 같이 코드를 작성하면 된다.

2.1.4 정리

JSX는 자바스크립트 코드 내부에 HTML과 같은 트리 구조를 가진 컴포넌트를 표현할 수 있다는 점에서 각광받고 있다. 물론 인기만 있는 것은 아니다. JSX가 HTML 문법과 자바스크립트 문법이 뒤섞여서 코드 가독성을 해친다는 의견도 있다. JSX 내부에 자바스크립트 문법이 많아질수록 복잡성이 증대하면서 코드의 가독성도 해칠 것이므로 주의해서 사용해야 한다.

2.2 가상 DOM과 리액트 파이버

리액트의 특징으로 가장 많이 언급되는 것 중 하나는 바로 실제 DOM이 아닌 가상 DOM을 운영한다는 것이다. 그러나 가상 DOM이 왜 만들어졌는지, 실제 DOM과는 어떤 차이가 있는지, 그리고 정말로 실제 DOM 을 조작하는 것보다 빠른지에 대해서는 잘 모르는 경우가 많다. 이번 장에서는 리액트의 가상 DOM이 무엇인지, 그리고 실제 DOM에 비해 어떤 이점이 있는지 살펴보고 가상 DOM을 다룰 때 주의할 점에 대해서도 알아보겠다.

2.2.2 가상 DOM의 탄생 배경

가상 DOM은 말 그대로 실제 브라우저의 DOM이 아닌 리액트가 관리하는 가상의 DOM을 의미한다. 가상 DOM은 웹페이지가 표시해야 할 DOM을 일단 메모리에 저장하고 리액트가 실제 변경에 대한 준비가 완료됐을 때 실제 브라우저의 DOM에 반영한다. 이렇게 DOM 계산을 브라우저가 아닌 메모리에서 계산하는 과정을 한 번 거치게 된다면 실제로는 여러 번 발생했을 렌더링 과정을 최소화할 수 있고 브라우저와 개발자의 부담을 덜 수 있다.

2.2.3 가상 DOM을 위한 아키텍처, 리액트 파이버

그렇다면 이러한 가상 DOM을 만드는 과정을 리액트는 어떻게 처리하고 있을까? 리액트는 여러 번의 렌더링 과정을 압축해 어떻게 최소한의 렌더링 단위를 만들어 내는 것일까? 이러한 가상 DOM과 렌더링 과정 최적화를 가능하게 해주는 것이 바로 리액트 파이버(React Fiber)다.

리액트 파이버란?

리액트 파이버는 리액트에서 관리하는 평범한 자바스크립트 객체다. 파이버는 파이버 재조정자(fiber reconciler)가 관리하는데, 이는 앞서 이야기한 가상 DOM과 실제 DOM을 비교해 변경 사항을 수집하며, 만약 이 둘 사이에 차이가 있으면 변경에 관련된 정보를 가지고 있는 파이버를 기준으로 화면에 렌더링을 요청하는 역할을 한다.
리액트 파이버의 목표는 리액트 웹 애플리케이션에서 발생하는 애니메이션, 레이아웃, 그리고 사용자 인터랙션에 올바른 결과물을 만드는 반응성 문제를 해결하는 것이다. 이를 위해 파이버는 다음과 같은 일을 할 수 있다.
- 작업을 작은 단위로 분할하고 쪼갠 다음, 우선순위를 매긴다.
- 이러한 작업을 일시 중지하고 나중에 다시 시작할 수 있다.
- 이전에 했던 작업을 다시 재사용하거나 필요하지 않은 경우에는 폐기할 수 있다.
한 가지 중요한 것은 이러한 모든 과정이 비동기로 일어난다는 것이다. 과거 리액트 리액트의 조정 알고리즘은 스택 알고리즘으로 이뤄져 있었다. 스택이라는 이름에서 유추할 수 있듯이 과거에는 이 하나의 스택에 렌더링에 필요한 작업들이 쌓이면 이 스택이 빌 때까지 동기적으로 작업이 이루어졌다.
자바스크립트의 특징인 싱글 스레드라는 점으로 인해 이 동기 작업은 중단될 수 없고, 다른 작업이 수행되고 싶어도 중단할 수 없었으며, 결국 이는 리액트의 비효율성으로 이어졌다.
사용자 인터랙션에 따른 동시 다발적인 이벤트와 애니메이션은 다양한 작업을 처리하는 요즘의 웹 애플리케이션에서는 피할 수 없는 문제다. 이러한 기존 렌더링 스택의 비효율성을 타파하기 위해 리액트 팀은 이 스택 조정자 대신 파이버라는 개념을 탄생시킨다.
파이버는 일단 하나의 작업 단위로 구성돼 있다. 리액트는 이러한 작업 단위를 하나씩 처리하고 finishedWork()라는 작업으로 마무리한다. 그리고 이 작업을 커밋해 실제 브라우저 DOM에 가시적인 변경 사항을 만들어 낸다. 그리고 이러한 단계는 아래 두 단계로 나눌 수 있다.
- 1) 렌더 단계에서 리액트는 사용자에게 노출되지 않는 모든 비동기 작업을 수행한다. 그리고 이 단계에서 앞서 언급한 파이버의 작업, 우선순위를 지정하거나 중지시키거나 버리는 등의 작업이 일어난다.
- 2) 커밋 단계에서는 앞서 언급한 것처럼 DOM에 실제 변경 사항을 반영하기 위한 작업, commitWork()가 실행되는데. 이 과정은 앞서와 다르게 동기식으로 일어나고 중단될 수도 없다.
파이버가 실제 리액트 코드에서 어떻게 구현돼 있는지 살펴보자.

function FiberNode(tag, pendingProps, key, mode) {
    // Instance
    this.tag = tag
    this.key = key
    this.elementType = null
    this.type = null
    this.stateNode = null
    // Fiber
    this.return = null
    this.child = null
    this.sibling = null
    this.index = 0
    this.ref = null
    this, refCleanup = null
    this.pendingProps = pendingProps
    this.memoizedProps = null
    this.updateQueue = null
    this.memoizedState = null
    this.dependencies = null
    this.mode = mode
    // Effects
    this.flags = NoFlags
    this.subtreeFlags = NoFlags
    this.deletions = null
    this.lanes = NoLanes
    this.childLanes = NoLanes
    this.alternate = null
    // 이하 프로파일러, _DEV__ 코드는 생략
}

보다시피 파이버가 단순한 자바스크립트 객체로 구성돼 있는 것을 볼 수 있다. 파이버는 리액트 요소와 유사하다고 느낄 수 있지만 한 가지 중요한 차이점은 리액트 요소는 렌더링이 발생 할 때마다 새롭게 생성되지만 파이버는 가급적이면 재사용된다는 사실이다. 파이버는 컴포넌트가 최초로 마운트되는 시점에 생성되어 이후에는 가급적이면 재사용된다.
리액트에 작성되어 있는 파이버를 생성하는 다양한 함수를 살펴보자.

var createFiber = function (tag, pendingProps, key, mode) {
    return new FiberNode(tag, pendingProps, key, mode)
}
// 생략...
function createFiberFromElement(element, mode, lanes) {
    var owner = null
    {
        owner = element._owner
    }

    var type = element.type
    var key = element.key
    var pendingProps = element.props
    var fiber = createFiberFromTypeAndProps(
    type,
    key,
    pendingProps,
    owner,
    mode,
    lanes,
    )
        {
            fiber._debugSource = element._source
            fiber._debugOwner = element._owner
        }
        return fiber
    }

리액트 파이버의 구현체를 봤으니 이제 여기서 선언된 주요 속성을 살펴보면서 어떠한 내용을 담고 있는지살펴보자.
- tag: 파이버를 만드는 함수 이름인 createFiberFromElement를 보면 유추할 수 있겠지만 파이버는 하나의 element에 하나가 생성되는 1：1 관계를 가지고 있다.
- stateNode： 이 속성에서는 파이버 자체에 대한 참조(reference) 정보를 가지고 있으며, 이 참조를 바탕으로 리액트는 파이버와 관련된 상태에 접근한다.
- child, sibling, return： 파이버 간의 관계 개념을 나타내는 속성이다. 리액트 컴포넌트 트리가 형성되는 것과 동일하게 파이버도 트리 형식을 갖게 되는데, 이 트리 형식을 구성하는 데 필요한 정보가 이 속성 내부에 정의된다. 한 가지 리액트 컴포넌트 트리와 다른 점은 children이 없다는 것, 즉 하나의 child만 존재한다는 점이다.
- index： 여러 형제들(sibling) 사이에서 자신의 위치가 몇 번째인지 숫자로 표현한다.
- pendingProps： 아직 작업을 미처 처리하지 못한 props
- memoizedProps: pendingProps를 기준으로 렌더링이 완료된 이후에 pendingProps를 memoizedProps로 저장해 관리한다.
- updateQueue: 상태 업데이트, 콜백 함수, DOM 업데이트 등 필요한 작업을 담아두는 큐. 이 큐는 대략 다음과 같은 구조를가지고 있다.
- memoizedState： 함수형 컴포넌트의 훅 목록이 저장된다. 여기에는 단순히 useState뿐만 아니라 모든 훅 리스트가 저장된다.
- alternate: 뒤이어 설명할 리액트 파이버 트리와 이어질 개념. 리액트의 트리는 두 개인데. 이 alternate는 반대편 트리파이버를 가리킨다.
생성된 파이버는 state가 변경되거나 생명주기 메서드가 실행되거나 DOM의 변경이 필요한 시점 등에 실행된다. 그리고 중요한 것은 리액트가 파이버를 처리할 때마다 이러한 작업을 직접 바로 처리하기도 하고 스케줄링하기도 한다는 것이다. 즉, 이러한 작업들은 작은 단위로 나눠서 처리할 수도, 애니메이션과 같이 우선순위가 높은 작업은 가능한 한 빠르게 처리하거나, 낮은 작업을 연기시키는 등 좀 더 유연하게 처리된다.
리액트 파이버의 가상 DOM이 생각보다 단순한 자바스크립트 객체로 관리되고 있다는 사실에 놀랄 수도 있다. 리액트 개발 팀은 사실 리액트는 가상 DOM이 아닌 Value UI, 즉 값을 가지고 있는 UI를 관리하는 라이브러리라는 내용을 피력한 바 있다. 파이버의 객체 값에서도 알 수 있듯이 리액트의 핵심 원칙은 UI를 문자열, 숫자, 배열과 같은 값으로 관리한다는 것이다. 변수에 이러한 UI 관련 값을 보관하고, 리액트의 자바스크립트 코드 흐름에 따라 이를 관리하고, 표현하는 것이 바로 리액트다.

리액트 파이버 트리

파이버의 개념에 대해 알아봤으니 그다음으로는 파이버 트리에 대해 알아보자. 파이버 트리는 사실 리액트 내부에서 두 개가 존재한다. 하나는 현재 모습을 담은 파이버 트리이고, 다른 하나는 작업 중인 상태를 나타내는 workInProgress 트리다. 리액트 파이버의 작업이 끝나면 리액트는 단순히 포인터만 변경해 worklnProgress 트리를 현재 트리로 바꿔버린다. 이러한 기술을 더블 버퍼링이라고 한다.

즉, 먼저 현재 UI 렌더링을 위해 존재하는 트리인 current를 기준으로 모든 작업이 시작된다. 여기에서 만약 업데이트가 발생하면 파이버는 리액트에서 새로 받은 데이터로 새로운 worklnProgress 트리를 빌드하기 시작한다. 이 worklnProgress 트리를 빌드하는 작업이 끝나면 다음 렌더링에 이 트리를 사용한다. 그리고 이 worklnProgress 트리가 이에 최종적으로 렌더링되어 반영이 완료되면 current가 이 worklnProgress로 변경된다.

파이버의 작업 순서

파이버와 파이버 트리에 대해 알아봤으니 이제 파이버 트리와 파이버가 어떤 식으로 작동하는지 흐름을 살펴보자. 먼저 일반적인 파이버 노드의 생성 흐름은 다음과 같다.
- 1) 리액트는 beginWork() 함수를 실행해 파이버 작업을 수행하는데, 더 이상 자식이 없는 파이버를 만날 때까지 트리 형식으로 시작된다.
- 2) 1 번에서 작업이 끝난다면 그다음 completeWorkO 함수를 실행해 파이버 작업을 완료한다.
- 3) 형제가 있다면 형제로 넘어간다.
- 4) 2번, 3번이 모두 끝났다면 return으로 돌아가 자신의 작업이 완료됐음을 알린다.
이렇게 트리가 생성됐다. 이제 여기서 setstate 등으로 업데이트가 발생하면 어떻게 될까?
이미 리액트는 앞서 만든 current 트리가 존재하고, setState로 인한 업데이트 요청을 받아 worklnProgress 트리를 다시 빌드하기 시작한다. 이 빌드 과정은 앞서 트리를 만드는 과정과 동일하다. 최초 렌더링 시에는 모든 파이버를 새롭게 만들어야 했지만 이제는 파이버가 이미 존재하므로 되도록 새로 생성하지 않고 기존 파이버에서 업데이트된 props를 받아 파이버 내부에서 처리한다.

2.2.4 파이버와 가상 DOM

앞서 언급했듯이 리액트 컴포넌트에 대한 정보를 1：1로 가지고 있는 것이 파이버이며, 이 파이버는 리액트 아키텍처 내부에서 비동기로 이뤄진다. 이러한 비동기 작업과 달리, 실제 브라우저 구조인 DOM에 반영하는 것은 동기적으로 일어나야 하고, 또 처리하는 작업이 많아 화면에 불완전하게 표시될 수 있는 가능성이 높으므로 이러한 작업을 가상에서, 즉 메모리상에서 먼저 수행해서 최종적인 결과물만 실제 브라우저 DOM에 적용하는 것이다.

2.2.5 정리

지금까지 리액트에서 가상 DOM이라는 개념이 무엇인지, 또 가상 DOM을 구현하기 위해 만들어진 리액트 파이버의 개념과 이를 조정하는 재조정자에 대해서 알아봤다.
가상 DOM과 파이버는 단순히 브라우저에 DOM을 변경하는 작업보다 빠르다는 이유로만 만들어진 것은 아니다. 만약 이러한 도움 없이 개발자가 직접 DOM을 수동으로 하나하나 변경해야 한다면 어떤 값이 바뀌었는지, 또 그 값에 따라 어떠한 값이 변경됐고 이와 관련된 것들이 무엇이었는지 파악하기가 매우 어려울 것이다. 이러한 어려움을 리액트 내부의 파이버와 재조정자가 내부적인 알고리즘을 통해 관리해 줌으로써 대규모 웹 애플리케이션을 효율적으로 유지보수하고 관리할 수 있게 된 것이다.
가상 DOM과 리액트의 핵심은 브라우저의 DOM을 더욱 빠르게 그리고 반영하는 것이 아니라 바로 값으로 UI를 표현하는 것이다. 화면에 표시되는 UI를 자바스크립트의 문자열, 배열 등과 마찬가지로 값으로 관리하고 이러한 흐름을 효율적으로 관리하기 위한 메커니즘이 바로 리액트의 핵심이다.

2.3 클래스형 컴포넌트와 함수형 컴포넌트

함수형 컴포넌트가 각광받기 시작한 것은 16.8 버전 에서 훅이 소개된 이후였다. 함수형 컴포넌트에 훅이 등장한 이후 함수형 컴포넌트에서 상태나 생명주기 메서드 비슷한 작업을 흉내 낼수 있게 되자 상대적으로 보일러플레이트가 복잡한 클래스형 컴포넌트보다 함수형 컴포넌트를 더 많이 쓰기 시작했다.

2.3.1 클래스형 컴포넌트

클래스형 컴포넌트의 한계

지금까지 클래스형 컴포넌트를 살펴봤다. 클래스형 컴포넌트에서 제공하는 메서드만으로도 완성도 있는 리액트 애플리케이션을 만드는 데는 충분해 보인다. 그런데 어떠한 문제점 때문에 리액트는 함수형 컴포넌트에 훅을 도입한 새로운 패러다임을 만든 것일까? 그 이유를 추측해보자면 다음과 같다
- 데이터의 흐름을 추적하기 어렵다: 앞서 생명주기 메서드를 잘 살펴봤다면 state의 흐름을 추적하기가 매우 어렵다는 사실을 알 수 있을 것이다. 서로 다른 여러 메서드에서 State의 업데이트가 일어날 수 있으며, 또 코드 작성 시 메서드의 순서가 강제돼 있는 것이 아니기 때문에 사람이 읽기가 매우 어렵다.
- 애플리케이션 내부 로직의 재사용이 어렵다: 컴포넌트 간에 중복되는 로직이 있고, 이를 재사용하고 싶다고 가정해 보자. 여기서 우리가 사용할 수 있는 것은 컴포넌트를 또 다른 고차 컴포넌트 (Higher Order Component)로 감싸거나, props를 넘겨주는 방식이 있을 것이다. 그러나 모두 심각한 단점이 있는데, 공통 로직이 많아질수록 이를 감싸는 고차 컴포넌트 내지는 props가 많아지는 래퍼 지옥(wrapper hell)에 빠져들 위험성이 커진다는 점이다.
- 기능이 많아질수록 컴포넌트의 크기가 커진다.
- 클래스는 함수에 비해 상대적으로 어렵다.

2.3.3 함수형컴포넌트 vs. 클래스형 컴포넌트

render 내부에서 필요한 함수를 선언할때 this 바인딩을 조심할 필요도 없으며, state는 객체가 아닌 각각의 원시값으로 관리되어 훨씬 사용하기가 편해졌다. 물론 state는 객체도 관리할 수 있다. 렌더링하는 코드인 return에서도 굳이 this를 사용하지 않더라도 props와 state에 접근할 수 있게 됐다.

생명주기 메서드의 부재

가장 눈에 띄는 차이점이자 많은 개발자들이 적응하지 못하는 부분은 클래스형 컴포넌트의 생명주기 메서드가 함수형 컴포넌트에서는 존재하지 않는다는 것이다. 그 이유는 함수형 컴포넌트는 props를 받아 단순히 리액트 요소만 반환하는 함수인 반면, 클래스형 컴포넌트는 render 메서드가 있는 React.Component를 상속받아 구현하는 자바스크립트 클래스이기 때문이다.

함수형 컴포넌트와 렌더링된 값

리액트 개발자 댄 아브라모프가 블로그에서 이야기한 유명한 내용 중 하나로, 함수형 컴포넌트는 렌더링된 값을 고정하고, 클래스형 컴포넌트는 그렇지 못하다는 사실이다.

import React from 'react'
interface Props {
    user: string
}
// 함수형 컴포넌트로 구현한 setTimeout 예제
export function FunctionalComponent(props: Props) {
    const showMessage =()=>{
        alert('Hello' + props.user)
    }
    const handleClick =()=>{
        setTimeout(showMessage, 3000)
    }

    return <button onClick={handleClick}>Follow</button>
}
// 클래스형 컴포넌트로 구현한 setTimeout 예제
export class ClassComponent extends React.Component<Props, {}> {
    private showMessage =()=>{
        alert('Hello' + this.props.user)
    }
    private handleClick =()=>{
        setTimeout(this.showMessage, 3000)
    }
    public render() {
        return <button onClick={this.handleClick}>Follow</button>
    }
}

여기서 FunctionalComponent와 ClassComponent는 같은 작업을 하고 있다. handleClick을 클릭하면 3초 뒤에 props에 있는 user를 alert로 띄워준다. 만약 3초 사이에 props를 변경하면 어떻게 될까? 두 코드가 모두 동일하게 작동할 것 같지만 차이가 있다.
ClassComponent의 경우에는 3초 뒤에 변경된 props를 기준으로 메시지가 뜨고, FunctionalComponent는 클릭했던 시점의 props 값을 기준으로 메시지가 뜬다. 아무래도 FunctionalComponent 쪽이 일반적인 개발자가 의도한 방향일 것이다.
클래스형 컴포넌트는 props의 값을 항상 this로부터 가져온다. 클래스형 컴포넌트의 props는 외부에서 변경되지 않는 이상 불변 값이지만 this가 가리키는 객체, 즉 컴포넌트의 인스턴스의 멤버는 변경 가능한(mutable) 값이다. 따라서 render 메서드를 비롯한 리액트의 생명주기 메서드가 변경된 값을 읽을 수 있게된다.
다시 함수형 컴포넌트로 돌아와 보자. this에 바인딩된 props를 사용하는 클래스형 컴포넌트와 다르게, 함수형 컴포넌트는 props를 인수로 받는다. 그리고 this와 다르게, props는 인수로 받기 때문에 컴포넌트는 그 값을 변경할 수 없고, 해당 값을 그대로 사용하게 된다. 그리고 이러한 특성은 state도 마찬가지다.
함수형 컴포넌트는 렌더링이 일어날 때마다 그 순간의 값인 props와state를 기준으로 렌더링된다. props와 state가 변경된다면, 다시 한 번 그 값을 기준으로 함수가 호출된다고 볼 수 있다. 반면 클래스형 컴포넌트는 시간의 흐름에 따라 변화하는 this를 기준으로 렌더링이 일어난다.

2.4 렌더링은 어떻게 일어나는가?

리액트에도 렌더링이라는 과정이 존재한다. 리액트의 렌더링은 브라우저가 렌더링에 필요한 DOM 트리를 만드는 과정을 의미한다. 리액트도 브라우저와 마찬가지로 이 렌더링 작업을 위한 자체적인 렌더링 프로세스가 있으며, 이를 이해하는 것은 곧 리액트를 이해하는 첫걸음으로 볼 수 있다. 왜나하면 리액트의 렌더링은 시간과 리소스를 소비해 수행되는 과정으로, 이 비용은 모두 웹 애플리케이션을 방문하는 사용자에게 청구되며, 시간이 길어지고 복잡해질수록 유저의 사용자 경험 을 저해하기 때문이다. 따라서 리액트 개발자라면 렌더링이 어떻게, 왜, 어떤 순서로 일어나는지 알고 있어야하며 이러한 렌더링 과정을 최소한으로 줄여야 한다.

2.4.1 리액트의 렌더링이란?

리액트에서의 렌더링이란 리액트 애플리케이션 트리 안에 있는 모든 컴포넌트들이 현재 자신들이 가지고 있는 props와 state의 값을 기반으로 어떻게 UI를 구성하고 이를 바탕으로 어떤 DOM 결과를 브라우저에 제공할 것인지 계산하는 일련의 과정을 의미한다. 그럼 리액트에서는 언제 어떻게 렌더링이 일어나는지 본격적으로 살펴보자.

2.4.2 리액트의 렌더링이 일어나는 이유

렌더링 과정을 이해하는 것도 중요하지만 이보다 더 중요한 것은 렌더링이 언제 발생하느냐다. 리액트에서 렌더링이 발생하는 시 나리오는 다음과 같다.
1) 최초 렌더링: 사용자가 처음 애플리케이션에 진입하면 당연히 렌더링해야 할 결과물이 필요하다. 리액트는 브라우저에 이정보를 제공하기 위해 최초 렌더링을 수행한다.
2) 리렌더링: 리렌더링은 처음 애플리케이션에 진입했을 때 최초 렌더링이 발생한 이후로 발생하는 모든 렌더링을 의미한다. 리렌더링이 발생하는 경우는 다음과 같다
- 함수형 컴포넌트의 useState()의 두 번째 배열 요소인 setter가 실행되는 경우: useState가 반환하는 배열의 두 번째 인수는 클래스형 컴포넌트의 setstate와 마찬가지로 state를 업데이트하는 함수다. 이 함수가 실행되면 렌더링이 일어난다.
- 함수형 컴포넌트의 useReducer()의 두 번째 배열 요소인 dispatch가 실행되는 경우: useReducer도 useState와 마찬가지로 상태와 이 상태를 업데이트하는 함수를 배열로 제공한다. 이 두 번째 배열 요소를 실행하면 컴포넌트의 렌더링이 일어난다.
- 컴포넌트의 key props가 변경되는 경우: 리액트에서 key는 명시적으로 선언돼 있지 않더라도 모든 컴포넌트에서 사용할 수 있는 특수한 props다. 일반적으로 key는 다음과 같이 배열에서 하위 컴포넌트를 선언할 때 사용된다.
- 리액트에서 배열에 key를 쓰지 않으면 콘솔에 경고가 출력되기 때문에 key를 유일한 값으로 추가하는 것이 일반적이지만 정작 왜 추가해야 하는지는 모르는 경우가 많다. 왜 key가 필요할까?
- 리액트에서 key는 리렌더링이 발생하는 동안 형제 요소들 사이에서 동일한 요소를 식별하는 값이다. 동일한 자식 컴포넌트가 여러 개 있는 구조를 상상해 보자. 리렌더링이 발생하면 current 트리와 worklnProgress 트리 사이에서 어떠한 컴포넌트가 변경이 있었는지 구별해야 하는데, 이 두 트리 사이에서 같은 컴포넌트인지를 구별하는 값이 바로 key다. key가 존재한다면 두 트리 사이에서 통일한 key를 가지고 있는 컴포넌트는 이를 기준으로 구별할 수 있지만, 이 key가 없다면 단순히 파이버 내부의 sibling 인덱스만을 기준으로 판단하게 된다.
- props가 변경되는 경우 부모로부터 전달받는 값인 props가 달라지면 이를 사용하는 자식 컴포넌트에서도 변경이 필요하므로 리렌더링이 일어난다.
- 부모 컴포넌트가 렌더링될 경우: 한 가지 주의할 점은 부모 컴포넌트가 리렌더링된다면 자식 컴포넌트도 무조건 리렌더링이 일어난다는 것이다. 이에 대해서는 이후에 더 자세하게 다룬다.

2.4.3 리액트의렌더링프로세스

지금까지 리액트에서 언제 렌더링이 발생하는지 살펴봤다. 이제 본격적으로 렌더링이 어떤 과정을 거쳐 수행되는지 살펴보자.
렌더링 프로세스가 시작되면 리액트는 컴포넌트의 루트에서부터 차근차근 아래쪽으로 내려가면서 업데이트가 필요하다고 지정돼 있는 모든 컴포넌트를 찾는다. 만약 여기서 업데이트가 필요하다고 지정돼 있는 컴포넌트를 발견하면 클래스형 컴포넌트의 경우에는 클래스 내부의 render() 함수를 실행하게되고, 함수형 컴포넌트의 경우에는 Functioncomponent() 그 자체를 호출한 뒤에, 그 결과물을 저장한다.
앞서 언급한 바와 같이 일반적으로 렌더링 결과물은JSX 문법으로 구성돼 있고, 이것이 자바스크립트로 컴파일되면서 React.createElement()를 호출하는 구문으로 변환된다. 여기서 createElement는 브라우저의 UI 구조를 설명할 수 있는 일반적인 자바스크립트 객체를 반환한다. 다음 예제를 살펴보자.

function Hello() {
    return (
        <TestComponent a={35} b="yceffort">
            안녕하세요
        </TestComponent>
    )
}

위 JSX 문법은 다음과 같은 React. createElement를 호출해서 변환된다.

function Hello() {
    return React.createElement(
        Testcomponent,
        { a: 35, b: 'yceffort' },
        '안녕하세요',
    )
}

결과물은 다음과 같다.

{type: Testcomponent, props: {a: 35, b: "yceffort", children: "안녕하세요"}}

렌더링 프로세스가 실행되면서 이런 과정을 거쳐 각 컴포넌트의 렌더링 결과물을 수집한 다음, 리액트의 새로운 트리인 가상 DOM과 비교해 실제 DOM에 반영하기 위한 모든 변경 사항을 차례차례 수집한다.
이렇게 계산하는 과정을 바로 2.2절 ‘가상 DOM과 리액트 파이버’에서 다뤘던 리액트의 재조정(Reconciliation)이라고 한다. 이러한 재조정 과정이 모두 끝나면 모든 변경 사항을 하나의 동기 시퀀스로 DOM에 적용해 변경된 결과물이 보이게 된다

2.4.4 렌더와 커밋

여기서 한 가지 주목해야 할 것은 리액트의 렌더링은 렌더 단계와 커밋 단계라는 총 두 단계로 분리되어 실행된다는 것이다. 이번에는 렌더 단계와 커밋 단계에서 어떠한 일이 벌어지는지 살펴보자.
렌더 단계(Render Phase)는 컴포넌트를 렌더링하고 변경 사항을 계산하는 모든 작업을 말한다. 즉. 렌더링 프로세스에서 컴포넌트를 실행해(render() 또는 return) 이 결과와 이전 가상 DOM을 비교하는 과정을 거쳐 변경이 필요한 컴포넌트를 체크하는 단계다. 여기서 비교하는 것은 크게 세 가지로, type, props, key다. 이 세 가지 중 하나라도 변경된 것이 있으면 변경이 필요한 컴포넌트로 체크해둔다.
그 다음으로 커밋 단계(Commit Phase)는 렌더 단계의 변경 사항을 실제 DOM에 적용해 사용자에게 보여주는 과정을 말한다. 이 단계가 끝나야 비로소 브라우저의 렌더링이 발생한다.
리액트가 먼저 DOM을 커밋 단계에서 업데이트한다면 이렇게 만들어진 모든 DOM 노드 및 인스턴스를 가리키도록 리액트 내부의 참조를 업데이트한다. 그 다음, 생명주기 개념이 있는 클래스형 컴포넌트에서는 componentDidMount, componentDidUpdate 메서드를 호출하고, 함수형 컴포넌트에서는 useLayoutEffect 훅을 호출한다.
여기서 알 수 있는 중요한 사실은 리액트의 렌더링이 일어난다고 해서 무조건 DOM 업데이트가 일어나는 것은 아니라는 것이다. 렌더링을 수행했으나 커밋 단계까지 갈 필요가 없다면, 즉 변경 사항을 계산했는데 아무런 변경 사항이 감지되지 않는다면 이 커밋 단계는 생략될 수 있다.
이 두 가지 과정으로 이뤄진 리액트의 렌더링은 항상 동기식으로 작동했다. 따라서 렌더링 과정이 길어질수록 애플리케이션의 성능 저하로 이어지고, 결과적으로 그 시간만큼 브라우저의 다른 작업을 지연시킬 가능성이 있다.

2.4.6 정리

지금까지 리액트에서 렌더링이 언제 어떻게 일어나는지, 또 렌더링이 어떤 과정을 거쳐서 브라우저의 결과물에 영향을 미치는지 살펴봤다. 리액트에서 일어나는 렌더링 시나리오를 정확히 이해한다면 컴포넌트의 트 리 구조를 개선하거나 불필요한 렌더링 횟수를 줄임으로써 성능 좋은 리액트 웹 애플리케이션을 만드는 데 많은 도움이 될 것이다.

2.5 컴포넌트와 함수의 무거운 연산을 기억해 두는 메모이제이션

2.5.1 주장 1: 섣부른 최적화는 독이다, 꼭 필요한 곳에만 메모이제이션을 추가하자

먼저 꼭 필요한 곳을 신중히 골라서 메모이제이션해야 한다는 입장이다. 메모이제이션도 어디까지나 비용이 드는 작업이므로 최적화에 대한 비용을 지불 할 때는 항상 신중해야 한다고 주장한다.
대부분의 가벼운 작업 자체는 메모이제이션해서 자바스크립트 메모리 어딘가에 두었다가 그것을 다시 꺼내오는 것보다는 매번 이 작업을 수행해 결과를 반환하는 것이 더 빠를 수도 있다.
리액트와 자바스크립트의 입장에서 생각해 보자. 메모이제이션에도 비용이 든다. 값을 비교하고 렌더링 또는 재계산이 필요한지 확인하는 작업, 그리고 이전에 결과물을 저장해 두었다가 다시 꺼내와야 한다는 두 가지 비용이 있다. 항상 메모이제이션은 신중하게 접근해야 하며 섣부른 최적화는 항상 경계해야 한다.
따라서 메모이제이션은 항상 어느 정도의 트레이드 오프가 있는 기법이라고 보는 것이 옳다. 이전 결과를 캐시로 저장해 미래에 더 나은 성능을 위해 메모리를 차례대로 점유하게 된다. 렌더링도 비용이지만 메모리에 저장하는 것도 마찬가지로 비용이다. 메모이제이션으로 인한 성능 개선이 렌더링보다 낫지 않다면 결국 안하느니만 못하는 상황을 마주하게 되는 것이다.

2.5.2 주장 2： 렌더링 과정의 비용은 비싸다, 모조리 메모이제이션해 버리자

일부 컴포넌트에서는 메모이제이션을 하는 것이 성능에 도움이 된다. 섣부른 최적화인지 여부와는 관계없이, 만약 해당 컴포넌트가 렌더링이 자주 일어나며 그 렌더링 사이에 비싼 연산이 포함돼 있고, 심지어 그 컴포넌트가 자식 컴포넌트 또한 많이 가지고 있다면 memo나 다른 메모이제이션 방법을 사용하는 것이 이점이 있을 때가분명히 있다.
그렇다면 우리에게는 두 가지 선택권이 있다.
- memo를 컴포넌트의 사용에 따라 잘 살펴보고 일부에만 적용하는 방법
- memo를 일단 그냥 다 적용하는 방법
실무에 임하는 모든 개발자들은 생각보다 최적화나 성능 향상에 쏟을 시간이 많지 않다는 사실에 모두 공감할 것이다. 따라서 일단 memo로 감싼 뒤에 생각해 보는 건 어떨까? 이렇게 감싸는 것이 괜찮은지 생각해 보려면 잘못된 컴포넌트에 이뤄진 최적화, 즉 렌더링 비용이 저렴하거나 사실 별로 렌더링이 안 되는 컴포넌트에 memo를 썼을 때 역으로 지불해야 하는 비용을 생각해 보자.
잘못된 memo로 지불해야 하는 비용은 바로 props에 대한 얕은 비교가 발생하면서 지불해야 하는 비용이다. 물론 이 비용 또한 무시할 수 없다. props가 크고 복잡해진다면 이 비용 또한 커질 수 있다.
반면 memo를 하지 않았을 때 발생할 수 있는 문제는 다음과 같다.
- 렌더링을 함으로써 발생하는 비용
- 컴포넌트 내부의 복잡한 로직의 재실행
- 그리고 위 두 가지 모두가 모든 자식 컴포넌트에서 반복해서 일어남
- 리액트가 구 트리와 신규 트리를비교
얼핏 살펴보더라도 memo를 하지 않았을 때 치러야 할 잠재적인 위험 비용이 더 크다는 사실을 알수 있다.
정리하자면, 메모이제이션은 하지 않는 것보다 메모이제이션했을 때 더 많은 이점을 누릴 수 있다. 이것이 비록 섣부른 초기화라 할지라도 했을 때 누릴 수 있는 이점, 그리고 이를 실수로 빠트렸을 때 치러야 할 위험 비 용이 더 크기 때문에 최적화에 대한 확신이 없다면 가능한 한 모든 곳에 메모이제이션을 활용한 최적화를 하는 것이 좋다.

2.5.3 결론 및정리

두 의견 모두 메모이제이션이 리액트 애플리케이션에서 할 수 있는 성능 최적화라는 사실에 대해서는 이견이 없다. 먼저 아직 리액트를 배우고 있거나 혹은 리액트를 깊이 이해하고 싶고, 이를 위해 시간을 투자할 여유가 있다면 1번의 의견대로 섣부른 메모이제이션을 지양하는 자세를 견지하면서 실제 어느 지점에서 성능상 이점을 누릴 수 있는지 살펴보는 식으로 메모이제이션을 적용하는 것을 권장한다.
만약 현업에서 리액트를 사용하고 있거나 실제로 다룰 예정이지만 성능에 대해 깊게 연구해 볼 시간적 여유가 없는 상황이라면 일단 의심스러운 곳에는 먼저 다 적용해 볼 것을 권장한다. 앞서 리액트 파이버에서의 작동과 흐름을 살펴봐서 알겠지만 lodash나 간단한 함수의 경우와는 다르게 일반적으로는 props에 대한 얕은 비교를 수행하는 것보다 리액트 컴포넌트의 결과물을 다시 계산하고 실제 DOM까지 비교하는 작업이 더 무겁고 비싸다.

끝!

4장 서버 사이드 렌더링(2)

Wed, 17 Jan 2024 00:00:00 +0900

4.2 서버 사이드 렌더링을 위한 리액트 API 살펴보기

기본적으로 리액트는 프런트엔드 라이브러리로 브라우저 자바스크립트 환경에서 렌더링할 수 있는 방법을 제공하지만 이와 동시에 리액트 애플리케이션을 서버에서 렌더링할 수 있는 API도 제공한다. 이 API는 당연히 브라우저의 window 환경이 아닌 Node.js와 같은 서버 환경에서만 실행할 수 있으며 window 환경에서 실행 시 에러가 발생할 수 있다.

4.2.1 renderToString

renderToString은 함수 이름에서도 알 수 있듯이 인수로 넘겨받은 리액트 컴포넌트를 렌더링해 HTML 문자열로 반환하는 함수다. 서버 사이드 렌더링을 구현하는 데 가장 기초적인 API로, 최초의 페이지를 HTML로 먼저 렌더링한다고 언급했는데 바로 그 역할을 하는 함수가 renderToString이다.

function ChildrenComponent({ fruits }: { fruits: Array<string> }) {
    useEffect(() => {
        console.log(fruits)
    }, [fruits])

    function handleClick() {
        console. log('hello')
    }
    return (
        <ul>
        {fruits.map((fruit) => (
            <li key={fruit} onClick={handleClick}>
        {fruit}
        </li>
        ))}
        </ul>
    )
}
function SampleComponent() {
    return (
        <>
        <div>hello</div>
        <ChildrenComponent fruits={['apple', 'banana', 'peach']} />
        </>
    )
}
const result = ReactDOMServer.renderToString(
    React.createElement('div', { id: 'root' }, 〈SampleComponent />),
)

위 result는 다음과 같은 문자열을 반환한다.

<div id="root" data-reactroot="">
    <div>hello</div>
    <ul>
        <li>apple</li>
        <li>banana</li>
        <li>peach</li>
    </ul>
</div>

여기서 한 가지 눈여겨볼 것은 ChildrenComponent에 있는 useEffect와 같은 훅과 handleClick과 같은 이벤트 핸들러는 결과물에 포함되지 않았다는 것이다. 이것은 의도된 것으로, renderToString은 인수로 주어진 리액트 컴포넌트를 기준으로 빠르게 브라우저가 렌더링할수 있는 HTML을 제공하는 데 목적이 있는 함수일 뿐이다. 필요한 자바스크립트 코드는 여기에서 생성된 HTML과는 별도로 제공해 브라우저에 제공돼야 한다.
renderToString을 사용하면 앞서 언급했던 서버 사이드의 이점, 클라이언트에서 실행되지 않고 일단 먼저 완성된 HTML을 서버에서 제공할 수 있으므로 초기 렌더링에서 뛰어난 성능을 보일 것이다.
여기서 한 가지 중요한 사실은 리액트의 서버 사이드 렌더링은 단순히 ‘최초 HTML 페이지를 빠르게 그려주는 데’에 목적이 있다는 것이다. 사용자는 완성된 HTML을 빠르게 볼 수는 있지만 useEffect나 이벤트 핸들러가 없는 것을 확인할 수 있듯이 실제로 웹페이지가 사용자와 인터랙션할 준비가 되기 위해서는 이와 관련된 별도의 자바스크립트 코드를 모두 다운로드, 파싱, 실행하는 과정을 거쳐야 한다.
마지막으로 주목할 것은 div#root에 존재하는 속성인 data-reactroot다. 이 속성은 리액트 컴포넌트의 루트 엘리먼트가 무엇인지 식별하는 역할을 한다. 이 속성은 이후에 자바스크립트를 실행하기 위한 hydrate 함수에서 루트를 식별하는 기준점이 된다.

끝!

4장 서버 사이드 렌더링(1)

Wed, 17 Jan 2024 00:00:00 +0900

이번 장에서는 리액트를 활용한 서버 사이드 렌더링(Server—Side Rendering： SSR)에 대해 알아보고자 한다. 과거 리액트 애플리케이션을 만들 때 Create React App(create-react-app)이 각광받았지만 요즘은 서버 사이드 렌더링을 지원하는 Next.js 같은 프레임워크를 사용해 프로젝트를 만드는 것이 큰 인기를 끌고 있다. 이에 따라 리액트 개발자라면 리액트뿐만 아니라 서버 사이드 렌더링에 대해서도 이해하는 것이 중요해 지고 있다. 서버 사이드 렌더링의 정의와 함께 이를 리액트로 구현하는 방법까지 알아보자.

4.1 서버 사이드 렌더링이란?

본격적으로 리액트 서버 사이드 렌더링 코드를 작성하기에 앞서 서버 사이드 렌더링이란 무엇인지, 왜 서버 사이드 렌더링이 최근에 각광받게 됐는지 먼저 이론적인 측면을 살펴보고자 한다.

4.1.1 싱글 페이지 애플리케이션의 세상

서버 사이드 렌더링이 무엇인지 설명하기에 앞서 먼저 서버 사이드 렌더링 애플리케이션과 반대되는 개념인 싱글 페이지 애플리케이션에 대해 먼저 살펴보자.

싱글 펭지 애플리케이션이란?

싱글 페이지 애플리케이션(Single Page Application； SPA)이란 렌더링과 라우팅에 필요한 대부분의 기능을 서버가 아닌 브라우저의 자바스크립트에 의존하는 방식을 의미한다. 최초에 첫 페이지에서 데이터를 모두 불러온 이후에는 페이지 전환을 위한 모든 작업이 자바스크립트와 브라우저의 history.pushstate와 history.replacestate로 이뤄지기 때문에 페이지를 불러온 이후에는 서버에서 HTML을 내려받지 않고 하나의 페이지에서 모든 작업을 처리하므로 싱글 페이지 애플리케이션이라고 한다.

전통적인 방식의 애플리케이션과 싱글 페이지 애플리케이션의 작동 비교

이와 반대로 과거 서버 사이드에서 작동하던 전통적인 방식의 애플리케이션을 상상해 보자. 페이지 전환이 발생할 때마다 새롭게 페이지를 요청하고, HTML 페이지를 다운로드해 파싱하는 작업을 거친다. 이 과정은 페이지를 처음부터 새로 그려야 해서 일부 사용자는 페이지가 전환될 때 부자연스러운 모습을 보게 된다.
그러나 이러한 페이지 전환을 모두 자바스크립트로 한다면 최초에 한번 모든 리소스를 다운로드하고 나면 이후 페이지를 전환할 때 추가로 리소스를 다운로드하는 시간이 필요 없어진다. 그리고 경우에 따라 페이지 전체를 새로 렌더링하는 것이 아니라 페이지 전환에 필요한 일부 영역만 다시 그리게 되므로 훨씬 더 매끄러운 UI를 보여줄 수 있게 된다

싱글 페이지 렌더링 방식의 유행과 JAM 스택의 등

이러한 장점을 발판으로 근래에 개발된 많은 웹페이지들이 싱글 페이지 렌더링 방식을 채택했다. 그렇다면 이러한 자바스크립트 위주의 싱글 페이지 렌더링 방식은 어떻게 등장하게 된 것일까?
과거 PHP나 JSPGavaServer Pages）를 기반으로 대부분의 웹 애플리케이션이 만들어졌을 때는 거의 대부분의 렌더링이 서버 사이드에서 이뤄졌다. 페이지를 요청하면 서버에서 완성된 HTML을 내려받고, 또 페이지 이동이 있으면 새로운 페이지를 서버에서 내려받는 방식이었다. 여기서 자바스크립트는 어디까지나 사용자에게 추가적인 경험을 주기 위한 보조적인 수단으로 사용됐다.
그러나 자바스크립트가 서서히 다양한 작업을 수행하게 되면서 자바스크립트를 모듈화하는 방안이 점차 논의되기 시직됐고 그에 따라 등장한 것이 CommonJS와 AMD（Asynchronous Module Definition）다. 이러한 자바스크립트 모듈화의 결실, 그리고 사용자 기기의 성능 향상과 인터넷 속도의 발전 등으로 자바스크립트에서 할 수 있는 일이 점차 다양해지기 시작했다.
이러한 변화에 힘입어 2010년경 Backbone.js와 Angularjs, Knockout.js 등이 등장하면서 자바스크립트 수준에서 MVx 프레임워크를 구현하기 시작했다. 이는 자바스크립트에서도 어느 정도 서버에서만 할 수 있는 복잡한 작업을 할 수 있다는 것을 의미했고, 이때부터 자바스크립트의 역할과 규모가 점점 커져갔다.
이러한 프레임워크의 인기는 자바스크립트의 역할을 더욱 가중시켰고, 이후로 우리가 잘 알고 있는 React, Vue, Angular의 시대가 오게 된다.
싱글 페이지 애플리케이션, 즉 클라이언트 사이드 라우팅이 널리 퍼지게 된 것은 단순히 사용자에게 좀 더 멋진 UX를 제공하는 것이 가능해져서만은 아니다. PHP 시절, 웹 애플리케이션을 만들기 위해서는 자바스크립트 외에도 신경 쓸 것이 많았지만 싱글 페이지 애플리케이션에서는 단지 브라우저 내부에서 작동하는 자바스크립트만 잘 작성하면 문제없다. 즉, 프런트엔드 개발자들에게 좀 더 간편한 개발 경험을 제공했고, 더욱 간편하게 웹 애플리케이션을 만들 수 있다는 장점이 있다. 이러한 장점과 시대적인 요구로 많은 싱글 페이지 애플리케이션이 개발되기 시작했다.
앞서 언급한 프레임워크의 등장으로 등장한 것이 바로 JAM（JavaScript, API, Markup） 스택이다. 대부분의 작업을 자바스크립트에서 수행할 수 있었기 때문에 프런트엔드는 자바스크립트와 마크업（HTML, CSS）을 미리 빌드해 두고 정적으로 사용자에게 제공하면 이후 작동은 모두 사용자의 클라이언트에서 실행되므로 서버 확장성 문제에서 좀 더 자유로워질 수 있게 됐다.

새로운 패러다임의 웹서비스를 향한 요구

많은 양의 리소스가 자바스크립트로 넘어오기 시작하던 때, 자바스크립트 코드의 규모도 점차 커지면서 이에 대해 우려의 목소리도 조금씩 나오기 시작했다. 다만 이 시기에 있었던 폭발적인 기술의 발전으로 이러한문제가 자연스럽게 해결될 것이라 기대하기도 했었다. 왜냐하면 인터넷 속도는 날이 갈수록 빨라졌고, 프로세서나 메모리 등 하드웨어 성능 또한눈부시게 발전을 거듭했기 때문이다. 즉, 웹페이지를 불러오는 데 필요한 부담을 일정 부분 사용자에게 전가하더라도 사용자의 기기나 인터넷 환경이 더 빠르게 발전할 것이기 때문에 괜찮을 것이라는 기대감이 팽배했다. 그러한 기대에 부응하기라도 하듯 웹 애플리케이션에서 제공하는 자바스크립트 리소스의 크기와 수가 모두 증가하기 시작했다.
그렇다면 웹페이지 속도는 얼마나 개선됐을까? 정말 이러한 기대에 부응할 만큼 사용자의 디바이스가 크기도 커지고 개수도 더욱 많아진 자바스크립트 리소스를 효과적으로 처리하고 있을까?
모바일 기기의 성능은 날이 갈수 록 좋아지고 있지만 모바일에서의 웹페이지 로딩은 여전히 20초 가까이 걸릴 정도로 오래 걸린다는 것을 알 수 있다.
물론 이 모든 것이 싱글 페이지 애플리케이션의 탓이라는 것은 절대 아니다. 과거 웹 애플리케이션은 단순히 무언가 정보를 보여주기 위한 수단에 불과했지만 현재의 웹 애플리케이션은 정말 다양한 작업을 처리하고 있고, 심지어 하이브리드 애플리케이션의 형태로 앱 내부에서도 마치 웹처럼 구동되는 경우도 많다. 과거의 웹과 현재의 웹의 기능을 비교하면 정말 천지차이다. 그럼에도 중요한 사실 중 하나는 사용자의 기기와 인터넷 속도 등 웹 전반을 이루는 환경이 크게 개선됐음에도 실제 사용자들이 느끼는 웹 애플리케이션의 로딩 속도는 5년 전이나 지금이나 크게 차이가 없거나 오히려 더 느리다는 것이다.
웹사이트 방문자들은 참을성이 없기에 개발자들은 제품의 웹 서비스 환경에 대해 한 번 더 고민 할때다.

4.1.2 서버사이드렌더링이란?

싱글 페이지 애플리케이션이 자바스크립트를 활용해 하나의 페이지에서만 렌더링을 수행한다면, 서버 사이드 렌더링은 최초에 사용자에게 보여줄 페이지를 서버에서 렌더링해 빠르게 사용자에게 화면을 제공하는 방식을 의미한다.
앞서 언급했던, 웹페이지가 점점 느려지는 상황에 대한 문제의식을 싱글 페이지 애플리케이션의 태생적인 한계에서 찾고, 이를 개선하고자 서버에서 페이지를 렌더링해 제공하는 기존 방식의 웹 개발이 다시금 떠오르고 있다.
싱글 페이지 애플리케이션과 서버에서 페이지를 빌드하는 서버 사이드 렌더링의 차이는 웹페이지 렌더링의 책임을 어디에 두느냐다. 싱글 페이지 애플리케이션은 사용자에게 제공되는 자바스크립트 번들에서 렌더링을 담당하지만 서버 사이드 방식을 채택하면 렌더링에 필요한 작업을 모두 서버에서 수행한다. 클라이언트의 렌더링은 사용자 기기의 성능에 영향을 받지만 서버 사이드 렌더링은 서버에서 제공하기 때문에 비교적 안정적인 렌더링이 가능하다.

서버 사이드 렌더링의 장점

최초 페이지 렌더링을 서버에서 수행하는 것은 싱글 페이지 애플리케이션 대비 몇 가지 장점이 있다. 서버 사이드 렌더링의 장점은 다음과 같다.

최초 페이지 진입이 비교적 빠르다

사용자가 최초 페이지에 진입했을 때 페이지에 유의미한 정보가 그려지는 시간(First Contentful Paint)이 더 빨라질 수 있다. 싱글 페이지 애플리케이션이라면 사용자가 해당 페이지에 진입하고, 자바스크립트 리소스를 다운로드하고, HTTP 요청을 수행한 이후에 이 응답의 결과를 가지고 화면을 렌더링해야 할 것이다. 그러나 이러한 작업이 서버에서 이뤄진다면 한결 빠르게 렌더링될 수 있다.
일반적으로 서버에서 HTTP 요청을 수행하는 것이 더 빠르고, 또 HTML을 그리는 작업도 서버에서 해당 HTML을 문자열로 미리 그려서 내려주는 것이 클라이언트에서 기존 HTML에 삽입하는 것보다 더 빠르기 때문이다.
모든 경우에 서버 사이드 렌더링이 초기 페이지 렌더링에 비해 이점을 가진다고 볼 수 없지만 화면 렌더링이 HTTP 요청에 의존적이거나 렌더링해야 할 HTML의 크기가 커진다면 상대적으로 서버 사이드 렌더링이 더 빠를수 있다.

검색 엔진과 SNS 공유 등 메타데이터 제공이 쉽다

서버 사이드 렌더링은 검색 엔진 최적화에 유용하다. 왜 서버 사이드 렌더링이 검색 엔진 최적화에 유용한지이해하려면 먼저 검색 엔진이 사이트에서 필요한 정보를 가져가는 과정을 알아야 한다.
- 검색 엔진 로봇(머신)이 페이지에 진입한다.
- 페이지가 HTML 정보를 제공해 로봇이 이 HTML을 다운로드한다. 단, 다운로드만 하고 자바스크립트 코드는 실행하지 않는다.
- 다운로드한 HTML 페이지 내부의 오픈 그래프(Open Graph)나 메EKmeta) 태그 정보를 기반으로 페이지의 검색(공유) 정보를 가져오고 이를 바탕으로 검색 엔진에 저장한다.

누적 레이아웃 이동이 적다

서버 사이드 렌더링은 누적 레이아웃 이동(Cumulative Layout Shift)을 줄일 수 있다. 누적 레이아웃 이동이란 사용자에게 페이지를 보여준 이후에 뒤늦게 어떤 HTML 정보가 추가되거나 삭제되어 마치 화면이 덜컥 거리는 것과 같은 부정적인 사용자 경험을 말한다.
싱글 페이지 애플리케이션에서는 페이지 콘텐츠가 API 요청에 의존하고, API 요청의 응답 속도가 제각각이며, 이를 적절히 처리해두지 않는다면 이러한 누적 레이아웃 이동 문제가 발생할 수 있다. 반면 서버 사이드 렌더링의 경우에는 이러한 요청이 완전히 완료된 이후에 완성된 페이지를 제공하므로 이러한 문제에서 비교적 자유롭다.

사용자의 디바이스 성능에 비교적 자유롭다

자바스크립트 리소스 실행은 사용자의 디바이스에서만 실행되므로 절대적으로 사용자 디바이스 성능에 의존적이다. 그러나 서버 사이드 렌더링을 수행하면 이러한 부담을 서버에 나눌 수 있으므로 사용자의 디바이스 성능으로부터 조금 더 자유로워질 수 있다.

보안에 좀 더 안전하다

JAM 스택을 채택한 프로젝트의 공통된 문제점은 애플리케이션의 모든 활동이 브라우저에 노출된다는 것이다. 프런트엔드 개발자라면 모두가 알겠지만 브라우저의 개발자 도구를 사용하면 웹사이트에서 일어나는 거의 대부분의 작업을 파악할 수 있다
반면 서버 사이드 렌더링의 경우 인증 혹은 민감한 작업을 서버에서 수행하고 그 결과만 브라우저에 제공해 이러한 보안 위협을 피할 수 있다는 장점이 있다.

서버 사이드 렌더링의 단점

그러나 서버 사이드 렌더링이 마냥 좋은 것만은 아니다. 서버 사이드 렌더링을 적용하기에 앞서 몇 가지를 고려해야 한다.

소스코드를 작성할 때 항상 서버를 고려해야 한다

서버 사이드 렌더링을 적용하기로 결정했다면 소스코드 전반에 걸쳐 서버 환경에 대한 고려가 필요하다. 그 중 가장 큰 문제가 바로 브라우저 전역 객체인 window 또는 sessionstorage와 같이 브라우저에만 있는 전역 객체 등이다.
이러한 서버에 대한 고려는 작성한 코드뿐만 아니라 외부에서 의존하고 있는 라이브러리도 마찬가지다. 해당 라이브러리가 마찬가지로 서버에 대한 고려가 돼 있지 않다면 다른 대안을 찾거나 클라이언트에서만 실행될 수 있도록 처리해야 한다.
잠재적인 위험을 가진 코드를 모두 클라이언트에서 실행하는 것 또한 궁극적인 해결책이 되지 못한다. 클라이 언트에서만 실행되는 코드가 많아질수록 서버 사이드 렌더링의 장점을 잃는 셈이다.

적절한 서버가 구축돼 있어야 한다

서버 사이드 렌더 링은 말 그대로 사용자의 요청을 받아 렌더링을 수행할 서버가 필요하다. 그러나 서버를 구축하는 것은 절대 쉬운 일이 아니다. 사용자의 요청에 따라 적절하게 대응할 수 있는 물리적인 가용량을 확보해야 하고, 때로는 예기치 않은 장애 상황에 대응할 수 있도록 복구 전략도 필요하다.

서비스 지연에 따른 문제

예를 들어, 싱글 페이지 애플리케이션에서 무언가 느린 작업이 있다고 해보자. 싱글 페이지 애플리케이션은 그래도 최초에 어떤 화면이라도 보여준 상태에서 무언가 느린 작업이 수행되기 때문에 ‘로딩 중’과 같이 작업이 진행 중임을 적절히 안내한다면 충분히 사용자가 기다릴 여지가 있다.
반면 서버 사이드 렌더링에서 지연이 일어나면 어떻게 될까? 특히 이 지연 작업이 최초 렌더링에 발생한다면 큰 문제가 된다. 서버 사이드 렌더링은 서버에서 사용자에게 보여줄 페이지에 대한 렌더링 작업이 끝나기까지는 사용자에게 그 어떤 정보도 제공할 수 없다.

4.1.3 SPA와 SSR을 모두 알아야 하는 이유

세상의 모든 진리와 마찬가지로, 서버 사이드 렌더링 또한 모든 문제의 해결책이 될 수는 없다. 따라서 우리는 이 러한 모든 방법론을 이해할 필요가 있다. 그 이유에 대해 살펴보자.

서버 사이드 렌더링 역시 만능이 아니다

클라이언트에서 발생하는 모든 무거운 작업을 서버에 미루고, 작업이 모두 서버에서 이뤄진다고 해서 모든 성능 문제가 해결되는 것은 아니다. 잘못된 웹페이지 설계는 오히려 성능을 해칠 뿐만 아니라 눈에 띄는 성능 개선도 얻지 못하고 서버와 클라이언트 두 군데로 관리 포인트만 늘어나기만 하는 역효과를 낳을 수도 있다.
웹페이지에서 사용자에게 제공하고 싶은 내용이 무엇인지, 또 어떤 우선순위에 따라 페이지의 내용을 보여줄지를 잘 설계하는 것이 중요하다. 웹페이지의 설계와 목적, 그리고 우선순위에 따라 싱글 페이지 애플리케이션이 더 효율적일 수도 있다.

싱글 페이지 애플리케이션과 서버 사이드 렌더링 애플리케이션

두 방법론 중 어느 것이 옳다고 단언할 수는 없지만 적어도 싱글 페이지 애플리케이션과 LAMP 스택과 같이 서버에서 모든 페이지를 각각 빌드하는 서버 사이드 렌더링 방식인 멀티 페이지 애플리케이션에 대해서는 다음과 같이 이야기할 수 있다.
- 1. 가장 뛰어난 싱글 페이지 애플리케이션은 가장 뛰어난 멀티 페이지 애플리케이션보다 낫다. 일례로 앞서 예제로 보여준 Gmail과 같이 완성도가 매우 뛰어난 싱글 페이지 애플리케이션이 있다고 가정해 보자.
- 최초 페이지 진입 시에 보여줘야할 정보만 최적화해 요청해서 렌더링하고, 이미지와 같은 중요성이 떨어지는 리소스는 게으른 로딩으로 렌더링에 방해되지 않도록 처리했으며, 코드 분할(code splitting. 사용자에게 필요한 코드만 나눠서 번들링하는 기법) 또한 칼같이 지켜서 불필요한 자바스크립트 리소스의 다운로드 및 실행을 방지했다. 라우팅이 발생하면 변경이 필요한 HTML 영역만 교체해 사용자의 피로감을 최소화했다. 모든 것이 완벽하다.
- 1. 평균적인 싱글 페이지 애플리케이션은 평균적인 멀티 페이지 애플리케이션보다 느리다. 멀티 페이지 애플리케이션은 매번 서버에 렌더링 요청을 하고. 서버는 안정적인 리소스룔 기반으로 매 요청마다 비슷한 성능의 렌더링을 수행할 것이다.
- 그러나 일반적인 싱글 페이지 애플리케이션은 렌더링과 라우팅에 최적화가 돼 있지 않다면 사용자 기기에 따라 성능이 들쑥 날쑥하고, 적절한 성능 최적화도 돼 있지 않을 가능성이 높으므로 멀티 페이지 애플리케이션 대비 성능이 아쉬울 가능성이 크다. 그리고 이러한 최적화는 매우 어렵다. 페이지 전환 시에 필요한 리소스와 공통으로 사용하는 리소스로 분류하고 이에 따른 다운로드나 렌더링 우선순위 전략을 잘 수립해 서비스하기란 매우 어렵다.
결국 우리는 앞의 두 방법론이 모두 상황에 따라 유효한 방법이라는 것을 먼저 이해해야 한다. 두 가지 모두 장단점이 있으며 어느 하나가 완벽하다고 볼 수 없다. 싱글 페이지 애플리케이션이 제공하는 보일러플레이트나 라이브러리가 점차 완벽해지면서 잠재적인 모든 위험을 제거할 수도 있고, 멀티 페이지 애플리케이션이 브라우저 API의 도움을 받아 싱글 페이지 애플리케이션과 같은 끊김 없는 사용자 경험을 제공할 수도 있다.

현대의 서버 사이드 렌더링

먼저 기존 LAMP 스택은 모든 페이지 빌드를 서버에서 렌더링해 초기 페이지 진입이 빠르다는 장점이 있지만 이후에 라우팅이 발생할 때도 마찬가지로 서버에 의존해야 하기 때문에 싱글 페이지 렌더링 방식에 비해 라우팅이 느리다는 단점이 있다.
그래서 요즘의 서버 사이드 렌더링은 이 두 가지 장점을 모두 취한 방식으로 작동한다. 먼저, 최초 웹사이트 진입 시에는 서버 사이드 렌더링 방식으로 서버에서 완성된 HTML을 제공받고, 이후 라우팅에서는 서버에서 내려받은 자바스크립트를 바탕으로 마치 싱글 페이지 애플리케이션처럼 작동한다.
앞으로 살펴볼 Next.js, 그리고 Remix 등 요즘 각광받는 서버 사이드 렌더링 프레임워크는 모두 이러한 방식으로 작동해 사용자에게 더 나은 웹사이트 경험을 안겨준다.

4.1.4 정리

지금까지 서버 사이드 렌더링은 무엇이고, 또 어떠한 장단점이 있는지 살펴봤다. 리액트 개발자라면, 특히 다수의 사용자에게 좋은 사용자 경험을 제공할 수 있는 웹 애플리케이션을 만들고 싶은 개발자라면 두 가지 방법을 모두 숙지할 필요가 있다. 둘 중 어느 것이 완벽하게 옳다고 말할 수 없으므로 두 가지 모두를 이해하고 필요에 따라 맞는 방법을 사용할 수 있다.

끝!

React로 로그인 form 만들기

Tue, 16 Jan 2024 00:00:00 +0900

이번에는 React를 이용해 로그인 form을 만들어보자.

컴포넌트 구조 설계

이름, 비밀번호, 비밀번호 확인 Input Control을 담당하는 FormInput 컴포넌트가 있고, 이러한 FormInput 컴포넌트로 구성된 Form 컴포넌트를 구성했다.
그리고 From 컴포넌트와 Sibling으로 fontSize를 제어하는 FontControlBox 컴포넌트를 구성했다.
그리고 가입하기를 누르면 아이디, 비밀번호를 확인하는 모달인 Modal 컴포넌트가 있다.

state 관리 설계

최상위 App 컴포넌트의 자식으로 Form 컴포넌트와 Modal 컴포넌트가 있다. 우선 Modal 컴포넌트가 렌더링되기 위해서는 id, 비밀번호, 비밀번호 확인 상태값이 필요하다.
그리고 Form 컴포넌트의 가입하기(submit) 버튼을 눌렀을 때, id와 비밀번호, 그리고 비밀번호 확인하는 과정이 필요하다. 즉, id와 비밀번호, 비밀번호 확인 상태값들이 필요하다.
id와 비밀번호의 값은 Form 컴포넌트의 자식인 FormInput 컴포넌트에서 event로 받는다. 이 값들에 따라서 FormInput 컴포넌트의 에러 메세지가 렌더되기도하고, Form 컴포넌트의 가입하기 버튼을 눌렀을때 Modal 컴포넌트 렌더 여부를 체크하기도하고, Modal 컴포넌트에서 이 값들을 렌더해준다.
따라서, id, 비밀번호, 비밀번호 확인 상태 값들은 global state로 관리해야한다. Form과 Modal의 부모인 App 컴포넌트에서 관리하면 적절할 것 같다.

Context 초기 설정

아래 코드에서 FormContext는 React Context API를 사용해 전역적으로 상태를 관리하기 위해 만들었다. formData라는 상태와 setFormData라는 상태 업데이트 함수를 공유하여, 여러 컴포넌트에서 같은 폼 데이터에 접근하고 업데이트 할 수 있도록 만들었다.

const initialFormData = {
    id: '',
    pw: '',
    confirmPw: '',
}

export const FormContext = createContext({
    formData: initialFormData,
    setFormData: () => {},
})

function App() {
    const [formData, setFormData] = useState(initialFormData)

    return (
        <FormContext.Provider value= >
            <section className="form-wrapper">
                <Form />
            </section>
            <FontControlBox />
            <Modal />
        </FormContext.Provider>
    )
}

FormContext는 formData와 setFormData를 포함하는 컨텍스트다. 이렇게 하면 FormContext를 사용하는 컴포넌트는 formData와 setFormData에 접근할 수 있다. setFormData는 기본적으로 빈 함수로 설정되고, 실제로는 FormContext.Provider에서 setFormData를 전달하게 된다.

Form 컴포넌트에서의 errorData state 관리

Form 컴포넌트에서는 가입하기(submit) 버튼을 누르면, 각 FormInput 컴포넌트의 input 값들이 유효한지 알아야한다. 그리고 FormInput 컴포넌트에서는 id에 따라 유효하지 않은 경우 각각 다른 에러 메세지를 띄운다.
각 FormInput 컴포넌트의 유효성에 따른 상태값을 Form 컴포넌트에서 관리해 자식인 FormInput 컴포넌트에 props로 넘겨줘야 한다.

const initialErrorData = {
    id: '', // true or invalidId
    pw: '', // true or invalidPw
    confirmPw: '', // true or invalidConfirmPw
}

const Form = ({ modalRef }) => {
     const [errorData, setErrorData] = useState(initialErrorData)
     const handleSubmit = (e) => {
        e.preventDefault()
        const isValid = Object.values(errorData).every((val) => val === true)
        if (isValid === true) modalRef.current.showModal()
    }

     return (
        <FormInput
                id={'id'}
                label={'아이디'}
                inputProps=
                errorData={errorData}
                setErrorData={setErrorData}
        />
     )
}

따라서, 각 FormInput에 따른 에러 상태를 나타내기 위해 initialErrorData를 만들었고, Form 컴포넌트의 errorData의 초기값으로 설정한다.
errorData 객체의 value 값을 순회해 모두 true인 경우에만 모달 컴포넌트의 ref DialogElement를 열도록 한다.
그리고 errorData와 상태 업데이트 함수인 setErrorData를 FormInput 컴포넌트의 props로 넘겼다.

FormInput 컴포넌트에서의 유효성 검사와 에러 메세지 렌더

FormInput 컴포넌트의 props는 id, label, errorData, setErrorData가 있다. 그리고 type과 placeholder는 하나의 inputProps 객체로 묶어서 전달했다.
아래와 같이 Form 컴포넌트의 state인 errorData 객체의 value 값들에 대해 에러 메세지를 맵핑하고자 ERROR_MSG 객체를 만들었다. 이를 통해 가독성과 유지보수성, 그리고 확장성을 향상시킬 수 있다.

const ERROR_MSG = {
    required: '필수 정보입니다.',
    invalidId:
        '5~20자의 영문 소문자, 숫자와 특수기호(_),(-)만 사용 가능합니다.',
    invalidPw: '8~16자 영문 대 소문자, 숫자를 사용하세요.',
    invalidConfirmPw: '비밀번호가 일치하지 않습니다.',
}

그리고 onBlur 이벤트에서 checkRegex 이벤트 핸들러를 호출해 useContext 훅을 통해 받은 formData의 input 값들에 대해 유효성 검사를 수행한다.

const checkRegex = (inputId) => {
        let result
        const value = formData[inputId]
        if (value.length === 0) {
            result = 'required'
        } else {
            switch (inputId) {
                case 'id':
                    result = ID_REGEX.test(value) ? true : 'invalidId'
                    break
                case 'pw':
                    result = PW_REGEX.test(value) ? true : 'invalidPw'
                    checkRegex('confirmPw')
                    break
                case 'confirmPw':
                    result =
                        value === formData['pw'] ? true : 'invalidConfirmPw'
                    break
                default:
                    return
            }
        }
        // 정리!
        setErrorData((prev) => ({ ...prev, [inputId]: result }))
}

<input
    id={id}
    {...inputProps}
    value={formData[id]}
    onChange={(e) =>
        setFormData({ ...formData, [id]: e.target.value })
    }
    onBlur={() => checkRegex(id)}
/>

위와 같이 기존 errorData 객체에서 해당 id에 대한 값만 유효성 검사의 결과 값으로 변경해 state를 업데이트한다.

<div id="id-msg" className="mt-1 mb-3 text-xs text-red-500">
    {errorData[id] !== true ? ERROR_MSG[errorData[id]] : ''}
</div>

FormInput 컴포넌트에서 errorData의 값이 true가 아닌 경우는 ERROR_MSG를 렌더한다.

위 Form 컴포넌트의 가입하기 버튼을 눌렀을때, errorData 객체의 값들이 모두 true인 경우 Modal 컴포넌트를 렌더했다.
여기서 Form 컴포넌트에서 Modal 컴포넌트의 특정 DOM에 대한 접근이 필요하다. 따라서 forwardRef를 사용해 Modal 컴포넌트의 ref를 부모인 App 컴포넌트에 공유하고, App 컴포넌트는 공유 받은 ref를 자식인 Form 컴포넌트에 props로 전달했다.

FontControlBox 컴포넌트

FontControlBox 컴포넌트는 아래와 같다.

const $html = document.documentElement
const MAX_FONT_SIZE = 20
const MIN_FONT_SIZE = 12

const getHtmlFontSize = () => {
    return parseFloat(window.getComputedStyle($html).fontSize)
}

const FontControlBox = () => {
    const [fontSize, setFontSize] = useState(getHtmlFontSize())

    const onClickFontsizeControl = (flag) => {
        if (flag === 'increase') {
            setFontSize((prev) => prev + 1)
        } else {
            setFontSize((prev) => prev - 1)
        }
    }

    useLayoutEffect(() => {
        $html.style.fontSize = fontSize + 'px'
    }, [fontSize])

    return (
        <aside id="font-control-box" className="flex fixed bottom-0 right-0">
            <button
                id="increase-font-btn"
                onClick={() => onClickFontsizeControl('increase')}
                disabled={fontSize >= MAX_FONT_SIZE}
                className="bg-white text-gray-500 border border-gray-300 hover:bg-red-50 focus:outline-none focus:shadow-outline disabled:bg-gray-500 disabled:text-white rounded-full"
            >
                +
            </button>
            <button
                id="decrease-font-btn"
                onClick={() => onClickFontsizeControl('decrease')}
                disabled={fontSize <= MIN_FONT_SIZE}
                className="bg-white text-gray-500 border border-gray-300 hover:bg-blue-50 focus:outline-none focus:shadow-outline disabled:bg-gray-500 disabled:text-white rounded-full"
            >
                -
            </button>
        </aside>
    )
}

$html은 html 태그를 의미하고, 폰트 크기를 직접 변경하여 페이지 전체의 기본 폰트 크기를 조정하는 역할한다.
fontSize 상태는 현재 html 요소의 폰트 크기를 저장한다. 초기값으로 getHtmlFontSize()의 반환값을 사용해 현재 폰트 크기를 설정했다.
fontSize가 변경될때 마다 useLayoutEffect의 콜백 함수가 실행되고, html 요소의 fontSize 스타일을 fontSize 상태 값으로 업데이트한다.

완성본

완성본 보러가기

끝!

Vanilla JS로 로그인 form 만들기

Mon, 15 Jan 2024 00:00:00 +0900

순수 자바스크립트를 이용해 로그인 form을 만들어보자.

과제 조건

autofocus
- 페이지가 로드 된 시점에 ID 입력 창에 Focus하기
유효성 검사 로직
- ID, 비밀번호, 비밀번호 확인 필드에 대한 유효성 검사를 수행
- 유효성 검사 시점
  - input focus out 시 해당 input의 유효성을 검사
  - 가입하기 버튼을 눌렀을 때 모든 필드의 유효성을 검사
- 유효성 검사 패턴
  - 모든 필드의 값은 빠짐 없이 입력 해야함
  - ID: 5~20자. 영문 소문자, 숫자. 특수기호(_),(-)만 사용 가능
  - 비밀번호: 8~16자. 영문 대/소문자, 숫자 사용 가능
  - 비밀번호 확인: 비밀번호와 일치
커스텀 에러 메세지
- (공통) 빈 값일 경우: 필수 정보입니다.
- [ID] 유효하지 않은 값일 경우: “5~20자의 영문 소문자, 숫자와 특수기호(_),(-)만 사용 가능합니다.”
- [비밀번호] 유효하지 않은 값일 경우: “8~16자 영문 대 소문자, 숫자를 사용하세요.”
- [비밀번호 확인] 유효하지 않은 값일 경우: “비밀번호가 일치하지 않습니다.”
입력 확인 모달 창
- 제출하기 버튼 클릭 시, 모든 input의 값이 유효한 상태일 경우 입력한 아이디와 비밀번호를 확인할 수 있는 모달 창을 보여주기
- “취소하기” 버튼 클릭 시 모달 창이 닫힘
- “가입하기” 버튼 클릭 시 윈도우의 alert 창을 이용해 “가입되었습니다 🥳 “ 라는 메시지를 출력
폰트 사이즈 조절 버튼
- 회원가입 폼에 사용된 기본 폰트 사이즈는 16px
- 기본 폰트 사이즈를 기준으로 1px씩 폰트 사이즈를 조절할 수 있는 기능을 구현(최소: 12px, 최대: 20px, 아닐시 비활성화)

autofocus

document.addEventListener('DOMContentLoaded', () => {
    if ($id) {
        $id.focus()
    }
})

HTML5에서 적용 가능한 autofocus 속성으로도 가능하지만, eventListener를 설정했다. DOMContentLoaded 이벤트는 DOM이 완전히 로드되었을때 콜백 함수를 실행한다.

유효성 검사와 에러 메세지

$id.addEventListener('focusout', () => checkValidation($id, $idMsg))

$pw.addEventListener('focusout', () => checkValidation($pw, $pwMsg))

$pwCheck.addEventListener('focusout', () =>
    checkValidation($pwCheck, $pwCheckMsg)
)

const ERROR_MSG = {
    required: '필수 정보입니다.',
    invalidId:
        '5~20자의 영문 소문자, 숫자와 특수기호(_),(-)만 사용 가능합니다.',
    invalidPw: '8~16자 영문 대 소문자, 숫자를 사용하세요.',
    invalidPwCheck: '비밀번호가 일치하지 않습니다.',
}

const checkRegex = (target) => {
    const { value, id } = target
    if (value.length === 0) {
        return 'required'
    } else {
        switch (id) {
            case 'id':
                return ID_REGEX.test(value) ? true : 'invalidId'
            case 'pw':
                return PW_REGEX.test(value) ? true : 'invalidPw'
            case 'pw-check':
                return $pw.value === $pwCheck.value ? true : 'invalidPwCheck'
        }
    }
}

const checkValidation = (target, msgTarget) => {
    // 모든 필드의 값은 빠짐 없이 입력해야 합니다.
    // ID: 5~20자. 영문 소문자, 숫자. 특수기호(_),(-)만 사용 가능
    const isValid = checkRegex(target)

    // 3. 커스텀 에러 메세지
    // (1) 비어 있을 때 : input 태그에 border-red-600 class 추가
    // (2) 유효하지 않을 때
    if (isValid !== true) {
        target.classList.add('border-red-600')
        msgTarget.innerText = ERROR_MSG[isValid]
    } else {
        target.classList.remove('border-red-600')
        msgTarget.innerText = ''
    }

    return isValid
}

우선 정규 표현식에 대해 유효한지에 대해 검사를 하는 checkRegex 메서드를 구현했다.
값이 비어 있으면 ‘required’ 메세지를 반환하고, ID, 비밀번호, 비밀번호 확인 필드에 대해 패턴 검사 후 유효하다면 true 불린 값을 반환하고, 아닌 경우는 invalid 메세지를 반환하도록 했다.
checkValidation 메서드에서 targetElement에 대해 checkRegex를 수행하고, inValid인 경우 msgTargetElement의 innerText를 ERROR_MSG 객체의 필드에 해당하는 에러 메세지로 설정했다.
가독성과 한 곳에 모아 관리하기 편하기 위해 ERROR_MSG 객체 만들어 필드별로 에러 메세지들을 정의해 관리했다.

입력 확인 모달 창

<input
    id="submit"
    type="submit"
    value="가입하기"
/>

<dialog id="modal" class="rounded-lg shadow-xl text-left">
</dialog>

input 태그의 type이 submit인 경우 클릭 시 브라우저의 기본 동작은 폼을 제출하는 것이다. 따라서 폼이 제출되면 페이지가 새로고침되거나 지정된 action URL로 이동한다.

const $modal = document.getElementById('modal')
$submit.addEventListener('click', (e) => {
    e.preventDefault()
    if (
        checkValidation($id, $idMsg) === true &&
        checkValidation($pw, $pwMsg) === true &&
        checkValidation($pwCheck, $pwCheckMsg) === true
    ) {
        const $confirmId = document.getElementById('confirm-id')
        const $confrimPw = document.getElementById('confirm-pw')
        $confirmId.innerText = $id.value
        $confrimPw.innerText = $pw.value
        $modal.showModal()
    }
})

ID, 패스워드, 패스워드 확인 필드가 모두 유효한 경우, 아이디와 비밀번호를 모두 확인할 수 있는 모달 창을 보여준다.
dialog 태그를 열기 위해 showModal 메서드를 이용했다.

폰트 사이즈 조절

$increaseFontBtn.addEventListener('click', () => {
    onClickFontsizeControl('increase')
})

$decreaseFontBtn.addEventListener('click', () => {
    onClickFontsizeControl('decrease')
})

const onClickFontsizeControl = (flag) => {
    const curFontSize = parseFloat(window.getComputedStyle($html).fontSize)
    let nextFontSize = flag === 'increase' ? curFontSize + 1 : curFontSize - 1
    $html.style.fontSize = nextFontSize

    $increaseFontBtn.disabled = nextFontSize >= MAX_FONT_SIZE
    $decreaseFontBtn.disabled = nextFontSize <= MIN_FONT_SIZE
}

button 태그의 disabled 속성을 이용했다.
button 컨트롤을 이용해 html 태그의 fontSize를 변경하거나, 해당 버튼 컨트롤을 diable하는 공통의 기능을 수행하기 때문에, onClickFontsizeControl 하나의 메서드에서 input flag로 구분해 기능을 수행했다.

완성본

완성본 보러가기

끝!

1장 리액트 개발을 위해 꼭 알아야 할 자바스크립트

Sun, 14 Jan 2024 00:00:00 +0900

2024년 새해, 새로운 마음 가짐으로 모던 리액트 Deep Dive 책을 정독하기로 해본다. 프런트엔드 분야는 다른 기술 분야에 비해 진입장벽이 상대적으로 낮고 웹서비스를 손쉽고 빠르게 만들 수 있다는 장점 덕분에 많은 사람들, 특히 비전공자들이 진입하는 경우가 많다. 하지만, 리액트와 자바스크립트 사이에 겉으로 드러나지 않는 사실 을 완벽하게 이해하는 과정에 도전하게 된다면 다른 기술 분야와 마찬가지로 프런트엔드 역시 절대 쉽지 않다는 것을 깨닫게 된다. 이 책을 통해 리액트에 대해서 다시 살펴보며 생각을 정리해본다.

1장에서는 리액트 코드의 기반이 되는 자바스크립트에 대해 먼저 알아본다. 그러나 단순히 리액트 코드를 작성하는 데 그치지 않고, 웹 애플리케이션이 작동하는 이면에서 리액트가 수행하는 작업을 이해하려면 자바스크립트의 개념을 다시금 짚어볼 필요가 있다.

1.1 자바스크립트의 동등 비교

리액트 함수형 컴포넌트와 훅을 반복적으로 작성하다 보면 의존성 배열(dependencies)에 대해 고민해 본 적이 있을 것이다. 실제로 이것이 어떤 식으로 작동하는지, 또한 왜 이러한 변수들을 넣어야 하는지 이해하지 못하는 경우가 많다.
또 렌더링 관점에서도 살펴볼 만한 이유가 있다. 리액트 컴포넌트의 렌더링이 일어나는 이유 중 하나가 바로 props의 동등 비교에 따른 결과다. 그리고 이 props의 동등 비교는 객체의 얕은 비교를 기반으로 이뤄지는데, 이 얕은 비교가 리액트에서 어떻게 작동하는지 이해하지 못하면 렌더링 최적화에 어려움을 겪을 가능성이 크다.
리액트의 가상 DOM과 실제 DOM의 비교, 리액트 컴포넌트가 렌더링할지를 판단하는 방법, 변수나 함수의 메모이제이션 등 모든 작업은 자바스크립트의 동등 비교를 기반으로 한다. 자바스크립트의 이러한 동등 비교는 어떻게 수행되는지, 또 이를 리액트에서 어떻게 활용하고 있는지 살펴보자.

1.1.1 자바스크립트의 데이터 타입

자바스크립트의 모든 값은 데이터 타입을 갖고 있으며, 이 데이터 타입은 크게 원시 타입과 객체 타입으로 나눌수 있다.
- 원시 타입
  - boolean, null, undefined, number, string, symbol, bigint
- 객체 타입
  - object

객체 타입

객체 타입을 간단하게 정의하면 앞서 7가지 원시 타입 이외의 모든 것, 즉 자바스크립트를 이루고 있는 대부분의 타입이 바로 객체 타입이다.
여기서 한 가지 주목할 것이 객체 타입(object type)은 참조를 전달한다고 해서 참조 타입(reference type)으로도 불린다는 사실이다.

typeof [] ==== 'object' // true
typeof {} === 'object' // true
function hello() {}
typeof hello === 'function' // true
const hello1 = function () {}
const hello2 = function () {}
// 객체인 함수의 내용이 육안으로는 같아 보여도 참조가 다르기 때문에 false가 반환된다.
hellol === hello2 // false

1.1.2 값을 저장하는 방식의 차이

원시 타입과 객체 타입의 가장 큰 차이점이라고 한다면, 바로 값을 저장하는 방식의 차이다. 이 값을 저장하는 방식의 차이가 동등 비교를 할 때 차이를 만드는 원인이 된다.
먼저 원시 타입은 불변 형태의 값으로 저장된다. 그리고 이 값은 변수 할당 시점에 메모리 영역을 차지하고 저장된다.

let hello = 'hello world'
let hi = hello
console.log(hello === hi) // true

hello의 hello world라는 값이 hi에 복사해 전달됐기 때문이다. 값을 비교하기 때문에, 값을 전달하는 방식이 아닌 각각 선언하는 방식으로도 동일한 결과를 볼수 있다.

let hello = 'hello world'
let hi = 'hello world'
console. log(hello === hi) // true

반면 객체는 프로퍼티를 삭제, 추가, 수정할 수 있으므로 원시 값과 다르게 변경 가능한 형태로 저장되며, 값을 복사할 때도 값이 아닌 참조를 전달하게 된다.

// 다음 객체는 완벽하게 동일한 내용을 가지고 있다.
var hello = {
    greet: 'hello, world',
}
var hi = {
    greet：'hello, world',
}
// 그러나 동등 비교를 하면 false가 나온다.
console.log(hello === hi) // false
// 원시값인 내부 속성값을 비교하면 동일하다.
console.log(hello.greet === hi.greet) // true

따라서 자바스크립트 개발자는 항상 객체 간에 비교가 발생하면, 이 객체 간의 비교는 우리가 이해하는 내부의 값이 같다 하더라도 결과는 대부분 true가 아닐 수 있다는 것을 인지해야 한다.

1.1.3 자바스크립트의 또 다른 비교공식, Object.is

자바스크립트에서는 비교를 위한 또 한 가지 방법을 제공하는데, 바로 Object.is다. Object.is는 두 개의 인수를 받으며, 이 인수 두 개가 동일한지 확인하고 반환하는 메서드다. Object.is가 ==나 ===와 다른 점은 다음과 같다.
== vs. Object.is: == 비교는 같음을 비교하기 전에 양쪽이 같은 타입이 아니라면 비교할 수 있도록 강제로 형변환 (type casting)을 한 후에 변경한다. 따라서 5 == ‘ 5’와 같이 형변환 후에 값이 동일하다면 ==는 true를 반환한다. 하지만 Object.is는 이러한작업을하지 않는다. 즉. === 와동일하게 타입이 다르면 그냥 false다.
=== VS. Object.is： 이 방법에도 차이가 있다. 다음코드를 보면 알수 있듯, Object.is가좀 더 개발자가 기대하는 방식으로 정확히 비교한다.

-0 === +0 // true
Object.is(-0, +0) // false
Number.NaN === NaN // false
Object.is(Number.NaN, NaN) //true
NaN === 0 / 0 // false
Object.is(NaN, 0/0) //true

한 가지 주의해야 할 점은, Object.is를 사용한다 하더라도 객체 비교에는 별 차이가 없다는 것이다. 객체 비교는 앞서 이야기한 객체 비교 원리와 동등하다.

1.1.4 리액트에서의 동등 비교

그렇다면 리액트에서는 동등 비교가 어떻게 이루어질까? 리액트에서 사용하는 동등 비교는 ==나 ===가 아닌 이 Object.is다. Object.is는 ES6에서 제공하는 기능이기 때문에 리액트에서는 이를 구현한 폴리필(Polyfill)을 함께 사용한다.
리액트에서의 비교를 요약하자면 Object.is로 먼저 비교를 수행한 다음에 Object.is에서 수행하지 못하는 비교, 즉 객체 간 얕은 비교를 한 번 더 수행하는 것을 알 수 있다. 객체 간 얕은 비교란 객체의 첫 번째 깊이에 존재하는 값만 비교한다는 것을 의미한다.

// Object.is는 참조가 다른 객체에 대해 비교가 불가능하다.
Object.is({ hello: 'world' }, { hello： 'world' }) // false
// 반면 리액트 팀에서 구현한 shallowEqual은 객체의 1 depth까지는 비교가 가능하다.
shallowEqual({ hello: 'world' }, { hello： 'world' }) // true
// 그러나 2 depth까지 가면 이를 비교할 방법이 없으므로 false률 반환한다.
shallowEqual({ hello： { hi: 'world' } }, { hello: { hi: 'world' } }) // false

이렇게 객체의 얕은 비교까지만 구현한 이유는 무엇일까? 먼저 리액트에서 사용하는JSX props는 객체이고, 그리고 여기에 있는 props만 일차적으로 비교하면 되기 때문이다. 다음 코드를 살펴보자.
기본적으로 리액트는 props에서 꺼내온 값을 기준으로 렌더링을 수행하기 때문에 일반적인 케이스에서는 얕은 비교로 충분할 것이다. 이러한 특성을 안다면 props에 또 다른 객체를 넘겨준다면 리액트 렌더링이 예상치 못하게 작동한다는 것을 알수 있다.

import { memo, useEffect, useState } from 'react'

type Props = {
counter: number
}

const Component = memo((props: Props) => {
    useEffect(() => {
        console.log('Component has been rendered!')
    })
    return <hl>{props.counter}</hl>
})

type DeeperProps = {
    counter: {
        counter: number
    }
}

const DeeperComponent = memo((props: DeeperProps) => {
    useEffect(() => {
        console.log('DeeperComponent has been rendered!')
    })
    return <hl>{props.counter.counter}</hl>
})

export default function App() {
    const [, setcounter] = useState(0)
    function handleClick() {
        setCounter((prev) => prev + 1)
    }
    return (
        <div className="App">
        <Component counter={100} />
        <DeeperComponent counter= />
        <button onClick={handleClick}>+</button>
        </div>
    )
}

이와 같이 props가 깊어지는 경우, 즉 한 객체 안에 또다른 객체가 있을 경우 React.memo는 컴포넌트에 실제로 변경된 값이 없음에도 불구하고 메모이제이션된 컴포넌트를 반환하지 못한다. 즉, Component는 props, counter가 존재하지만, DeeperComponent는 props.counter.counter에 props가 존재한다. 상위 컴포넌트인 App에서 버튼을 클릭해서 강제로 렌더 링을 일으킬 경우, ShallowEqual을 사용하는 Component 함수는 위 로직에 따라 정확히 객체 간 비교를 수행해서 렌더 링을 방지해 주었지만 DeeperComponent 함수는 제대로 비교하지 못해 memo가 작동하지 않는 모습을 볼 수 있다.
만약 내부에 있는 객체까지 완벽하게 비교하기 위한 재귀문까지 넣었으면 어떻게 됐을까? 객체 안에 객체가 몇 개까지 있을지 알 수 없으므로 이를 재귀적으로 비교하려 할 경우 성능에 악영향을 미칠 것이다.

1.1.5 정리

지금까지 자바스크립트에 존재하는 데이터 타입은 무엇인지, 그리고 이 데이터 타입은 어떻게 저장되며 이값의 비교는 어떻게 수행되는지 살펴봤다.
자바스크립트를 기반으로 한 리액트의 함수형 프로그래밍 모델에서도 언어적인 한계를 뛰어넘을 수 없으므로 얕은 비교만을 사용해 비교를 수행해 필요한 기능을 구현하고 있다.
이러한 자바스크립트의 특징을 잘 숙지한다면 향후 함수형 컴포넌트에서 사용되는 훅의 의존성 배열의 비교, 렌더링 방지를 넘어선 useMemo와 useCallback의 필요성, 렌더링 최적화를 위해서 꼭 필요한 React.memo를 올바르게 작동시키기 위해 고려해야 할 것들을 쉽게 이해할 수 있을 것이다.

1.2 함수

1.2.1 함수란 무엇인가?

자바스크립트에서 함수란 작업을 수행하거나 값을 계산하는 등의 과정을 표현하고, 이를 하나의 블록으로 감싸서 실행 단위로 만들어 놓은 것을 의미한다.
리액트에서 컴포넌트를 만드는 함수도 이러한 기초적인 형태를 따르는 것을 알 수 있다.

function Component(props) {
    return <div>{props.hello}</div>
}

Component라고 하는 함수를 선언하고 매개변수로는 일반적으로 props라고 부르는 단일 객체를 받으며 return 문으로 JSX를 반환한다.

1.2.2 함수를 정의하는 4가지 방법

자바스크립트에서 함수를 정의하는 방법은 크게 4가지로 나눌 수 있다.

함수 선언문

자바스크립트에서 함수를 선언할 때 가장 일반적으로 사용하는 방식이다.

function add(a, b) {
    return a + b
}

함수 선언문은 표현식이 아닌 일반 문(statement)으로 분류된다. 표현식이란 무언가 값을 산출하는 구문을 의미한다. 즉, 앞선 함수 선언으로는 어떠한 값도 표현되지 않았으므로 표현식이 아닌 문으로 분류된다.

const sum = function sum(a, b) {
    return a + b
}
sum(10, 24) // 34

위 예제는 마치 sum이라는 변수에 함수 sum을 할당하는, 표현식과 같은 작동을 보였다. 그 이유는 무엇일까?
자바스크립트 엔진이 코드의 문맥에 따라 동일한 함수를 문이 아닌 표현식으로 해석하는 경우가 있기 때문이다.

함수 표현식

함수 표현식에 대해 알아보기 전에 ‘일급 객체’라는 개념을 알고 있어야 한다. 프로그래밍 세계에서 일급객체란 다른 객체들에 일반적으로 적용 가능한 연산을 모두 지원하는 객체를 의미한다.
자바스크립트에서 함수는 일급 객체다. 함수는 다른 함수의 매개변수가 될 수도 있고, 반환값이 될 수도 있으며, 앞에서 본 것처럼 할당도 가능하므로 일급 객체가 되기 위한 조건을 모두 갖추고 있다.

함수 표현식과 선언 식의 차이

이 두 가지 방식의 가장 큰 차이는 호이스팅(hoisting) 여부다. 함수의 호이스팅이라 함은, 함수 선언문이 마치 맨 앞단에 작성된 것처럼 작동하는 자바스크립트의 특징을 의미한다.

hello() // hello
function hello() {
    console.log('hello')
}
hello() // hello

함수의 호이스팅은 함수에 대한 선언을 실행 전에 미리 메모리에 등록하는 작업을 의미한다. 이러한 함수의 호이스팅이라는 특징 덕분에 함수 선언문이 미리 메모리에 등록됐고, 코드의 순서에 상관없이 정상적으로 함수를 호출할 수 있게 된 것이다.
반면 함수 표현식은 함수를 변수에 할당했다. 변수도 마찬가지로 호이스팅이 발생한다. 그러나 함수의 호이스팅과는 다르게, 호이스팅되는 시점에서 var의 경우에는 undefined로 초기화한다는 차이가 있다.
함수와 다르게 변수는, 런타임 이전에 undefined로 초기화되고, 할당문이 실행되는 시점, 즉 런타임 시점에 함수가 할당되어 작동한다는 것을 알 수 있다.

Function 생성자

const add = new Fiinction('a', 'b', 'return a + b')
add(10, 24) // 34

Function 생성자 함수를 사용해서 만든 모습은 썩 좋아보이지 않는다. 코드 작성 관점에서만 보더라도 매개변수, 그리고 함수의 몸통을 모두 문자열로 작성해야 한다.

화살표 함수

const add = (a, b) => {
    return a + b
}
const add = (a, b) => a + b

화살표 함수는 겉보기와 다르게 앞서 언급한 함수 생성 방식과 몇 가지 큰 차이점이 있다.
먼저 화살표 함수에서는 constructor를 사용할 수 없다.
그리고 화살표 함수에서는 arguments가 존재하지 않는다.
그리고 화살표 함수와 일반 함수의 가장 큰 차이점은 바로 this 바인딩이다.
화살표 함수 내부에서 this를 참조하면 상위 스코프의 this를 그대로 따르게 된다

1.4 클로저

리액트의 클래스형 컴포넌트에 대한 이해가 자바스크립트의 클래스, 프로토타입 , this에 달려 있다면, 함수형 컴포넌트에 대한 이해는 클로저에 달려 있다.
함수형 컴포넌트의 구조와 작동 방식, 훅의 원리, 의존성 배열 등 함수형 컴포넌트의 대부분의 기술이 모두 클로저에 의존하고 있기 때문에 함수형 컴포넌트 작성을 위해서는 클로저에 대해 이해하는 것이 필수다.

1.4.1 클로저의 정의

먼저 클로저에 대한 정의를 MDN에서 찾아보면 “클로저는 함수와 함수가 선언된 어휘적 환경(Lexical Scope)의 조합이라고 돼 있다.
그러나 리액트에서 함수형 컴포넌트와 훅이 등장한 16.8 버전을 기점으로 이 클로저라는 개념이 리액트에서 적극적으로 사용되기 시작하면서 클로저를 빼놓고서는 리액트가 어떤 식으로 작동하는지 이해하기 어려워졌다. 클로저는 무엇이고, 어떻게 활용되는지 살펴보자.
“선언된 어휘적 환경”이라는 것은, 변수가 코드 내부에서 어디서 선언됐는지를 말하는 것이다. 이는 앞서 이야기한, 호출되는 방식에 따라 동적으로 결정되는 this와는 다르게 코드가 작성된 순간에 정적으로 결정된다. 클로저는 이러한 어휘적 환경을 조합해 코딩하는 기법이다.

1.4.3 클로저의 활용

전역 스코프는 어디서든 원하는 값을 꺼내올 수 있다는 장점이 있지만, 반대로 이야기하면 누구든 접근할 수 있고 수정할 수 있다는 뜻도 된다. 다음 예제를 살펴보자.

var counter = 0
function handleClick() {
    counter++
}

위 counter 변수는 큰 문제를 가지고 있다. 첫째, 전역 레벨에 선언돼 있어서 누구나 수정할 수 있다. 앞서 예제로 확인했던 것처럼 window.counter를 활용하면 쉽게 해당 변수에 접근할 수 있을 것이다.
만약 리액트의 usestate의 변수가 전역 레벨에 저장돼 있으면 어떻게 될까? 자바스크립트를 조금만 아는 사람이라면 누구나 리액트 애플리케이션을 쉽게 망가뜨릴 것이다.
리액트가 관리하는 내부 상태 값은 리액트가 별도로 관리하는 클로저 내부에서만 접근할 수 있다.
클로저를 활용하면 전역 스코프의 사용을 막고, 개발자가 원하는 정보만 개발자가 원하는 방향으로 노출시킬 수 있다는 장점이 있다.

리액트에서의 클로저

그렇다면 리액트 함수형 컴포넌트의 훅에서 클로저는 어떻게 사용될까? 클로저의 원리를 사용하고 있는 대표적 인 것 중 하나가 바로 useState다.

function Component() {
const [state, setState] = useState()
function handleClickO {
    // usestate 호출은 위에서 끝났지만,
    // setState는 계속 내부의 최신값(prev)을 알고 있다.
    // 이는 클로저를 활용했기 때문에 가능하다.
    setState((prev) => prev + 1)
}
// ...

useState 함수의 호출은 Component 내부 첫 줄에서 종료됐는데, setState는 useState 내부의 최신 값을 어떻게 계속해서 확인할 수 있을까? 그것은 바로 클로저가 usestate 내부에서 활용됐기 때문이다.
외부 함수(useState)가 반환한 내부 함수(setState)는 외부 함수(useState)의 호출이 끝났음에도 자신이 선언된 외부 함수가 선언된 환경(state가 저장돼 있는 어딘가)을 기억하기 때문에 계속해서 state 값을 사용할 수 있는 것이다.

1.4.4 주의할 점

클로저는 굉장히 어렵고, 다루기 쉽지 않은 개념이다. 따라서 클로저를 사용할 때는 주의를 요한다. 먼저 다음 코드를 살펴보자.

for (var i = 0; i < 5; i++) {
    setTimeout(function () {
        console.log(i)
        }, i * 1000)
}

실제로 위 코드를 실행하면 0, 1, 2, 3, 4초 뒤에 5만 출력된다. setTimeout의 익명 함수가 클로저로 i를 잘 따라갈 것 같은데, 모두 5가 되는 이유는 무엇일까?
그 이유는 i가 전역 변수로 작동하기 때문이다. var는 for 문의 존재와 상관없이 해당 구문이 선언된 함수 레벨 스코프를 바라보고 있으므로 함수 내부 실행이 아니라면 전역 스코프에 var i가 등록돼 있을 것이다. for 문을 다 순회한 이후, 태스크 큐에 있는 setTimeout을 실행하려고했을 때, 이미 전역 레벨에 있는 i는 5로 업데이트가 완료돼 있다.
이를 올바르게 수정하는 방법은 첫째, 함수 레벨 스코프가 아닌 블록 레벨 스코프를 갖는 let으로 수정하는 것이다. let은 기본적으로 블록 레벨 스코프를 가지게 되므로 let i가 for 문을 순회하면서 각각의 스코프를 갖게 된다. 이는 setTimeout이 실행되는 시점에도 유효해서 각 콜백이 의도한 i 값을 바라보게 할 수 있다.
이처럼 클로저의 기본 개념, ‘함수와 함수가 선언된 어휘적 환경의 조합’을 주의 깊게 살펴봐야 클로저를 제대로 활용할수 있다.
클로저를 사용할 때 한 가지 주의할 점은, 클로저를 사용하는 데는 비용이 든다는 것이다. 클로저는 생성될때마다 그 선언적 환경을 기억해야 하므로 추가로 비용이 발생한다.
클로저와 그것에 따르는 비용을 확인하기 위해 다음 예제를 살펴보자. 두 함수는 엄청나게 긴 작업（길이가 천만인 배열）을 동일하게 처리한다. 클로저 유무에 따라 자바스크립트 코드에 어떤 차이가 있는지 살펴보자.

// 일반적인 함수
const aButton = document.getElementByld('a')

function heavyJob() {
    const longArr = Array.from({ length: 10000000 }, (_, i) => i + 1)
    console.log(longArr.length)
}
aButton.addEventListener('click', heavyJob)

// 클로저라면?
function heavyJobWithClosure() {
    const longArr = Array.from({ length: 10000000 }, (_, i) => i + 1)
    return function () {
        console.log(longArr.length)
    }
}

const innerFunc = heavyJobWithClosure()
bButton.addEventListener('click', function () {
    innerFunc()
})

일반적인 함수와 클로저를 사용한 함수가 실제로 어떤 차이가 있는지 크롬 개발자 도구에서 직접 확인해 볼수 있다. 먼저 일반 함수를 사용한 코드를 확인해 보면 아래와 같다.

무거운 직업을 일반적인 함수로 처리했을 때 메모리에 미차는 영향. 메모리의 전체 크기도 작고 실행 전후로도 큰 차이가 없음을 알 수 있다. 다음으로 클로저를 사용한 코드를 확인해 보면 아래와 같다.

클로저를 활용하는 함수를 크롬 개발자 도구에서 확인해 보면 클로저를 활용하는 쪽이 압도적으로 부정적인 영향을 미치는 것을 알 수 있다.
클로저 heavyJobWithClosure()로 분리해 실행하고, 이를 onClick에서 실행하는 방식인데 이미 스크립트를 실행하는 시점부터 아주 큰 배열을 메모리에 올려두고 시작하는 것을 알 수 있다（약 40MB).
클로저의 기본 원리에 따라, 클로저가 선언된 순간 내부 함수는 외부 함수의 선언적인 환경을 기억하고 있어야 하므로 이를 어디에서 사용하는지 여부에 관계없이 저장해 둔다. 실제로는 onClick 내부에서만 사용하고 있지만 이를 알 수 있는 방법이 없기 때문에 긴 배열을 저장해 두고 있는 모습이다.
반면 일반 함수의 경우에는 클릭 시 스크립트 실행이 조금 길지만 클릭과 동시에 선언, 그리고 길이를 구하는 작업이 모두 스코프 내부에서 끝났기 때문에 메모리 용량에 영향을 미치지 않았다.
클로저의 개념, 즉 외부 함수를 기억하고 이를 내부 함수에서 가져다 쓰는 메커니즘은 성능에 영향을 미친다. 클로저는 공짜가 아니므 로 클로저를 사용할 때는 주의가 필요하다.

1.6 라액트에서 자주 사용하는 자바스크립트 문법

일반적인 자바스크립트나 Node.js를 기반으로 한 코드와 리액트 코드를 비교하면 리액트 코드가 상대적으로 독특한 모습을 띤다는 것을 알 수 있다. 이러한 독특함은 JSX 구문 내부에서 객체를 조작하거나 객체의 얕은 동등 비교 문제를 피하기 위해 객체 분해 할당을 하는 등 리액트의 몇 가지 독특한 특징에서 비롯된다. 이 리액트의 독특한 특징을 이해하려면 리액트에서 자주 사용되는 자바스크립트 문법을 이해해야 한다. 그리고 자바스크립트 문법을 이해한다면 반대로 리액트가 어떻게 작동하는지도 이해할 수 있다.

1.6.1 구조 분해 할당

구조 분해 할당(Destmcturing assignment)이란 배열 또는 객체의 값을 말 그대로 분해해 개별 변수에 즉시 할당하는 것을 의미한다. 언급한 대로 배열과 객체에서 사용하며, 주로 어떠한 객체나 배열에서 선언문 없이 즉시 분해해 변수를 선언하고 할당하고 싶을 때 사용한다.

배열 구조 분해 할당

const array = [1, 2, 3, 4, 5]
const [first, second, third, ...arrayRest] = array
// first 1
// second 2
// third 3
// arrayRest [4, 5]

배열의 구조 분해 할당은，의 위치에 따라 값이 결정된다. 따라서 앞의 예제에서 중간 인덱스에 대한 할당을 생략하고 싶다면 다음과 같이 선언할 수 있다.

const array = [1, 2, 3, 4, 5]
const [first, , , , fifth] = array // 2, 3, 4는 아무런 표현식이 없으므로 변수 할당이 생략돼 있다.
first // 1
fifth // 5

이러한 방법은 실수를 유발할 가능성이 커서 일반적으로 배열의 길이가 작을 때 주로 쓰인다. 배열 분해 할당에는 기본값을 선언할 수도 있다. 만약 사용하고자 하는 배열의 길이가 짧거나 값이 없는 경우에는 (undefined) 기본값을사용할 것이다.

객체 구조 분해 할당

객체 구조 분해 할당은 말 그대로 객체에서 값을 꺼내온 뒤 할당하는 것을 의미한다. 배열 구조 분해 할당과는 달리, 객체는 객체 내부 이름으로 꺼내온다는 차이가 있다.

const object = {
    a: 1,
    b: 1,
    c：1,
    d: 1,
    e：1,
}
const { a, b, c, ...objectRest } = object
// a 1
// b 2
// c 3
// objectRest = {d: 1, e: 1}

이를 새로운 이름으로 다시 할당하는 것 또한 가능하다.

const object = {
    a: 1,
    b: 1,
}
const { a: first, b: second } = object
// first 1
// second 2

배열과 마찬가지로 기본값을 주는 것도 가능하다.

const object = {
    a：1,
    b: 1,
}
const { a = 10, b = 10, c = 10 } = object
// a 1
// b 1
// c 10

이러한 방식은 리액트 컴포넌트인 props에서 값을 바로 꺼내올 때 매우 자주 쓰는 방식이기 때문에 반드시 이해하고 있어야 한다.

1.6.2 전개 구문

전개 구문(Spread Syntax)은 앞서 소개한 구조 분해 할당과는 다르게 배열이나 객체, 문자열과 같이 순회할 수 있는 값에 대해 말 그대로 전개해 간결하게 사용할 수 있는 구문이다.
배열 내부에서 …배열을 사용하면 해당 배열을 마치 전개하는 것처럼 선언하고, 이를 내부 배열에서 활용할 수 있다. 이러한 특징을 활용하면 기존 배열에 영향을 미치지 않고 배열을 복사하는 것도 가능하다.

배열의 전개 구문

const arrl = ['a', 'b']
const arr2 = arr1

arrl === arr2 // true. 내용이 아닌 참조를 복사하기 때문에 true가 반환된다.
const arr1 = ['a', 'b']
const arr2 = [...arrl]

arrl === arr2 // false. 실제로 값만 복사됐을 뿐, 참조는 다르므로 false가 반환된다.

객체의 전개 구문

객체에서도 배열과 비슷하게 사용이 가능하다. 객체를 새로 만들 때 이 전개 구문을 사용할 수 있으며, 마찬가지로 객체를 합성하는 데 있어 편리함을 가져다 준다.

const newObj = { ...objl, ...obj2 }
// { "a": 1, "b": 2, "c": 3, "d": 4 }

한 가지 중요한 것은 객체 전개 구문에 있어서 순서가 중요하다는 것이다. 위에 있을 때와 아래에 있을 때의 작동의 순서 차이로 인해 전혀 다른 객체가 생성될 수 있다.

const obj = {
    a: 1,
    b: 1,
    c: 1,
    d: 1,
    e：1,
}

// {a： 1, b： 1, c： 10, d: 1, e： 1}
const aObj = {
    ...obj,
    c: 10,
}

// {c: 1, a: 1, b: 1, d: 1, e: 1}
const bObj = {
    c： 10,
    ...obj
}

aObj와 bObj의 결괏값은 다른데, 전개 구문 이후에 값 할당이 있다면 전개 구문이 할당한 값을 덮어쓰겠지만 반대의 경우에는 오히려 전개 구문이 해당 값을 덮어쓰는 일이 벌어질 것이다.

끝!

3.5장 노드 내장 모듈 사용하기

Wed, 23 Nov 2022 00:00:00 +0900

노드는 웹 브라우저에서 사용되는 자바스크립트보다 더 많은 기능을 제공한다. 운영체제 정보에도 접근할 수 있고, 클라이언트가 요청한 주소에 대한 정보도 가져올 수 있다. 노드에서 이러한 기능을 하는 모듈을 제공한다. 이번 챕터에서는 버전과 상관없이 안정적이고 유용한 기능을 지닌 모듈 위주로 알아보자!

3.5.1 os

웹 브라우저에 사용되는 자바스크립트는 운영체제의 정보를 가져올 수 없지만, 노드는 OS 모듈에 정보가 담겨 있어 정보를 가져올 수 있다.
내장 모듈인 os를 불러오려면 require( ‘os’) 또는 require(‘node：os’)를 하면 된다.
- os.arch()： process.arc
- os.platformO： process.platform
- os.type()： 운영체제의 종류
- os.uptime()： 운영체제 부팅 이후 흐른 시간(초)
- os.hostname()： 컴퓨터의 이름
- os.release()： 운영체제의 버전
- os.homedir()： 홈 디렉터리 경로
- os.tmpdir()： 임시 파일 저장 경로
- os.cpus()： 컴퓨터의 코어 정보
- os.freemem()： 사용 가능한 메모리
- os.totalmem()： 전체 메모리 용량
os 모듈은 주로 컴퓨터 내부 자원에 빈번하게 접근하는 경우 사용된다. 즉, 일반적인 웹 서비스를 제작할 때는 사용 빈도가 높지 않다. 하지만 운영체제별로 다른 서비스를 제공하고 싶을 때 os 모듈이 유용할 것이다.

3.5.2 path

폴더와 파일의 경로를 쉽게 조작하도록 도와주는 모듈이다. path 모듈이 필요한 이유 중 하나는 운영체제별로 경로 구분자가 다르기 때문이다. 크게 윈도 타입과 POSIX 타입으로 구분된 다. POSIX는 유닉스 기반의 운영체제들로 맥과 리눅스가 속해 있습니다.
- 윈도: C:\Users\ZeroCho처럼 \로 구분
- POSIX：/home/zerocho처럼 /로 구분
path 모듈의 속성과 메서드를 알아보자
- path.sep： 경로의 구분자(윈도는 \, POSIX는 /)
- path.delimiter： 환경 변수의 구분자
- path.dirname（경로）: 파일이 위치한 폴더 경로
- path.extname（경로）: 파일의 확장자
- path.basename（경로, 확장자）: 파일의 이름（확장자 포함）을 표시
- path.parse（경로）: 파일 경로를 root, dir, base, ext, name으로 분리
- path.format（객체）: path.parse（）한 객체를 파일 경로로 합침
- path.normalize（경로）: /나 \를 실수로 여러 번 사용했거나 혼용했을 때 정상적인 경로로 변환
- path.isAbsolute（경로）: 파일의 경로가 절대경로인지 상대경로인지
- path.relative（기준경로, 비교경로）: 경로를 두 개 넣으면 첫 번째 경로에서 두 번째 경로로 가는 방법을 알림
- path.join/resolve（경로, •••）： 여러 인수를 넣으면 하나의 경로로 합침
join과 resolve 차이
- path, join과 path.resolve 메서드는 비슷해 보이지만동작 방식이 다르다. /를 만나면 path.resolve는 절대경로로 인식해서 앞의 경로를 무시하고, path, join은 상대경로로 처리한다.

path.join('/a', '/b', 'c'); // 결과 : /a/b/c
path.join('/a', '/b', 'c'); // 결과 : /b/c

3.5.3 url

인터넷 주소를 쉽게 조작하도록 도와주는 모듈이다. url 처리에는 크게 두 가지 방식이 있다. 하나는 노드 버전 7에서 추가된 WHATWG(웹 표준을 정하는 단체의 이름) 방식의 url이고, 다른 하나는 예전부터 노드에서 사용하던 방식의 url이다. 요즘은 WHATWG 방식만 사용한다. 브라우저에서도 WHATWG 방식을 사용하므로 호환성이 좋다.

const url = require('url')；
const { URL } = url；
const myURL = new URL('http://www.gilbut.co.kr/book/bookList.aspx7sercate1=001001000#anchor')；
console.log('new URL()：', myURL)；
console.log('url.format()：', url.format(myURL))；

url 모듈 안에 URL 생성자가 있다. 참고로 URL은 노드 내장 객체이기도 해서 require할 필요는 없다. 이 생성자에 주소를 넣어 객체로 만들면 주소가 부분별로 정리된다. 이 방 식이 WHATWG의 url이다.

new URL()： URL {
href： 'http://www.gi.lbut.co.kr/book/bookl_ist.aspx?sercate1 =001001 OOONanchor',
origin: 'http://www.gilbut.co.kr',
protocol： 'http：',
username： '',
password： '',
host: 'www.gilbut.co.kr',
hostname: 'www.gilbut.co.kr',
port：'',
pathname： '/book/bookList.aspx',
search: '?sercate1=001001000',
searchParams： URLSearchParams { 'sercatel' => '001001000' },
hash： '#anchor'
}
url.format(): http://www.gilbut.co.kr/book/bookList.aspx?sercate1=001001000#anchor

콘솔

new URL()： URL {
href： ' http://www.gi.lbut.co.kr/book/bookl_ist.aspx?sercate1=001001 OOONanchor',
origin: 'http://www.gilbut.co.kr',
protocol： 'http：',
username： '',
password： '',
host: 'www.gilbut.co.kr',
hostname: 'www.gilbut.co.kr',
port：'',
pathname： '/book/bookList.aspx',
search: '?sercate1=001001000',
searchParams： URLSearchParams { 'sercatel' => '001001000' },
hash： '#anchor'
}
url.format(): http://www.gilbut.co.kr/book/bookList.aspx?sercate1=001001000#anchor

3.5.7 worker_threads

노드에서 멀티 스레드 방식으로 작업하는 방법이다. 먼저 간단한 사용 방법을 알아보자.

const {
    Worker, isMainThread, parentPort,
} = require('worker threads')；
if (isMainThread) { // 부모일 때
    const worker = new Worker(__filename)； 
    worker.on('message', message => console.log('from worker', message))； 
    worker.on('exit', () => console.log('worker exit' ))； worker.postMessage('ping')；
} else { // 워커일 때
    parentPort.on('message', (value) => {
        console.log('from parent', value)；
        parentPort.postMessage('pong')；
        parentPort.close()；
    })；
}

isMainThread를 통해 현재 코드가 메인 스레드(기존에 동작하던 싱글 스레드를 메인 스레드 또는 부모 스레드라고 부름)에서 실행되는지, 아니면 우리가 생성한 워커 스레드에서 실행되는지 구분된다.
메인 스레드에서는 new Worker를 통해 현재 파일(__filename)을 워커 스레드에서 실행시키고 있다. 물론 현재 파일의 else 부분만 워커스레드에서 실행된다.
부모에서는 워커 생성 후 worker.postMessage로 워커에 데이터를 보낼 수 있다. 워커는 parentPort.on( ‘message’) 이벤트 리스너로 부모로부터 메시지를 받고, parentPort.postMessage로 부모에게 메시지를 보낸다. 부모는 worker.on( ‘message,)로 메시지를 받는다. 참고로 메시지를 한 번만 받고 싶다면 once( ‘message’)를 사용하면 된다.
워커에서 on 메서드를 사용할 때는 직접 워커를 종료해야 한다는 점에 주의하세요. parentPort.close()를 하면 부모와의 연결이 종료된다. 종료될 때는 worker.on(‘exit’)이 실행된다.

콘솔

from parent ping
from worker pong
worker exit

아직까지는 워커 스레드를 사용해 복잡한 작업은 하지 않았다. 이번에는 여러 개의 워커 스레드에 데이터를 넘겨보자. postMessage로 데이터를 보내는 방법과는 다른 방법이다.

const {
Worker, isMainThread, parentPort, workerData,
} = require('worker—threads')；

if (isMainThread) {
    const threads = new Set()；
    threads.add(new Worker(__filename, {
        workerData： { start： 1 },
    }))；
    threads.add(new Worker(__filename, {
        workerData： { start： 2 },
    }))；
    for (let worker of threads) {
        worker.on('message', message =〉 console.log('from worker', message))； 
        worker.on('exit', () => {
            threads.delete(worker)；
            if (threads.size === 0) {
                console.log('job done')；
            }
        })；
    }
} else { // 워커일 때
    const data = workerData；
    parentPort.postMessage(data.start + 100)；
}

new Worker를 호출할 때 두 번째 인수의 workerData 속성으로 원하는 데이터를 보낼 수 있다. 워커에서는 workerData로 부모로부터 데이터를 받는다. 현재 두 개의 워커가 돌아가고 있으며, 각각 부모로부터 숫자를 받아서 100을 더해 돌려준다. 돌려주는 순간 워커가 종료되어 worker.on(‘exit’)이 실행된다. 워커 두 개가 모두종료되면 job done이 로깅된다.

콘솔

from worker 101
from worker 102
job done

이번에는 좀 더 실전적인 예제로 소수의 개수를 구하는 작업을 워커 스레드를 통해 해보자. 소수를 찾는 작업은 연산이 많이 들어가는 대표적인 작업이다.
먼저 워커 스레드를 사용하지 않으면..?

const min = 2；
const max = 10000000；
const primes = []；
function findPrimes(start, range) {
    let isPrime = true；
    const end = start + range；
    for (let i = start； i 〈 end； i++) {
        for (let j = min； j 〈 Math.sqrt(end)； j++) {
            if (i !== j && i % j === 0) {
                isPrime = false；
                break；
            }
        }
        if (isPrime) {
            primes.push(i)；
        }
        isPrime = true；
    }
}
console.time('prime')；
findPrimes(min, max)；
console.timeEnd('prime')；
console.log(primes.length)；

2부터 1,000만까지의 숫자 중에 소수가 모두 몇 개 있는지를 알아내는 코드이고, 실행 결과는 아래와 같다.

prime： 8.745s
664579

사용자의 컴퓨터 성능에 따라 다르지만 상당한 시간이 소요된다. 이번에는 워커 스레드를 사용해 여러 개의 스레드가 문제를 나눠서 풀도록 해보자. 미리 말하지만, 멀티 스레딩은 상당히 어렵다. 코드양도 많아진다.

const { Worker, isMainThread, parentPort, workerData } = require('worker_threads')；
const min = 2；
let primes = []；
function findPrimes(start, range) {
    let isPrime = true；
    const end = start + range；
    for (let i = start； i 〈 end； i++) {
        for (let j = min； j 〈 Math.sqrt(end)； j++) {
            if (i !== j && i % j = 0) {
            isPrime = false；
            break；
            }
        }
        if (isPrime) {
            primes.push(i)；
        }
        isPrime = true；
    }
}
if (isMainThread) {
    const max = 10000000;
    const threadCount = 8；
    const threads = new Set()；
    const range = Math.floor((max - min) / threadCount)；
    let start = min；
    console.time('prime')；
    for (let i = 0； i < threadCount - 1； i++) {
        const wStart = start；
        threads.add(new Worker(_filename, { workerData： { start： wStart, range } }))；
        start += range；
    }
    threads.add(new Worker(_filename, { workerData： { start, range： max - start } }))；
    for (let worker of threads) {
        worker.on('error', (err) => {
            throw err；
        })； 
        worker.on('exit', () => {
            threads.delete(worker)；
            if (threads.size === 0) {
                console.timeEnd('prime')；
                console.log(primes.length)；
            }
        })； 
        worker.on('message', (msg) => {
            primes = primes.concat(msg)；
        })；
    }
} else {
    findPrimes(workerData.start, workerData.range)；
    parentPort.postMessage(primes)；
}

여덟 개의 스레드가 일을 나눠서 처리하게 했다. 멀티 스레딩을 할 때는 일을 나눠서 처리하도록 하는 게 제일 어렵다. 어떠한 일은 공유하고 있는 데이터가 많아 일을 나누기가 어렵다. 다행히 소수의 개수를 구하는 작업은 정해진 범위(2부터 1000만)를 스레드들이 일정하게 나눠서 수행할 수 있다.

콘솔

prime： 1.752s
664579

속도가 여섯 배 정도 빨라졌다. 워커 스레드를 여덟 개 사용했다고 해서 여덟 배 빨라지는 것은 아니다. 스레드를 생성하고 스레드 사이에서 통신하는 데 상당한 비용이 발생하므로, 이 점을 고려해서 멀티 스레딩을 해야 한다. 잘못하면 멀티 스레딩을 할 때 싱글 스레딩보다 더 느려지는 현상도 발생할 수 있다.

3.5.8 child_process

노드에서 다른 프로그램을 실행하고 싶거나 명령어를 수행하고 싶을 때 사용하는 모듈이다. 이모듈을 통해 다른 언어의 코드(예를 들면. 파이썬)를 실행하고 결괏값을 받을 수 있다. 이름이 child_process(자식 프로세스)인 이유는 현재 노드 프로세스 외에 새로운 프로세스를 띄워서 명령을 수행하고 노드 프로세스에 결과를 알려주기 때문이다.

const exec = require('child_process').exec；
const process = exec('ls')；
process.stdout.on('data', function(data) {
    console.log(data.toString())；
})；// 실행 결과
process.stderr.on('data', function(data) {
    console.error(data. toString())；
})； // 실행 에러

실행하면 현재 폴더의 파일 목록들이 표시된다. 결과는 stdout(표준출력)과 stderr(표준에러)에 붙여둔 data 이벤트 리스너에 버퍼 형태로 전달된다.

끝!

3.4장 노드 내장 객체 알아보기

Tue, 22 Nov 2022 00:00:00 +0900

내장 객체와 내장 모듈은 따로 설치하지 않아도 바로 사용할 수 있으며, 브라우저의 window 객체와 비슷하다고 보면 된다. 이 절에서는 노드 프로그래밍을 할 때 많이 쓰이는 내장 객체를 알아보자.

3.4.1 global

브라우저의 window와 같은 전역 객체이며, 전역 객체이므로 모든 파일에서 접근할 수 있다. 또한, window.open 메서드를 그냥 open으로 호출할 수 있는 것처럼 global도 생략할 수 있다.
내용이 너무 많아 줄였지만 global 객체 안에는 수십 가지의 속성이 담겨 있다. 그 속성 모두를 알 필요는 없고, 자주 사용하는 속성들만 이 절에서 알아보자.
전역 객체라는 점을 이용해 파일 간에 간단한 데이터를 공유할 때 사용하기도 한다. globalA.js와 globalB.js를 같은 폴더에 생성해보자.

module.exports = () => global.message；

const A = require('./globalA')；

global.message = '안녕하세요';
console.log(A())；

console output

안녕하세요

콘솔 결과를 보면, globalB에서 넣은 global.message 값을 globalA에서도 접근할 수 있음을 알 수 있다.

3.4.2 console

브라우저에서의 console과 거의 비슷하다.
- console.time（레이블）: console.timeEnd（레이블）과 대응되어 같은 레이블을 가진 time과 timeEnd 사이의 시간을 측정한다.
- console.error（에러 내용）: 에러를 콘솔에 표시한다.
- console.table（배열）: 배열의 요소로 객체 리터럴을 넣으면, 객체의 속성들이 테이블 형식으로 표현된다.
- console.dir（객체, 옵션）: 객체를 콘솔에 표시할 때 사용한다. 첫 번째 인수로 표시할 객체를 넣고, 두 번째 인수로 옵션을 넣는다. 옵션의 colors를 true로 하면 콘솔에 색이 추가되어 보기가 한결 편해진다. depth는 객체 안의 객체를 몇 단계까지 보여줄지를 결정한다. 기본값은 2다.
- console.trace（레이블）: 에러가 어디서 발생했는지 추적할 수 있게 한다. 보통은 에러 발생 시 에러 위치를 알려주므로 자주 사용하지 않지만, 위치가 나오지 않는다면 사용할 만하다.

3.4.3 타이머

타이머 기능을 제공하는 함수인 setTimeout, setinterval, setlmediate는 노드에서 window 대신 global 객체 안에 들어 있다.
- setTimeout（콜백 함수, 밀리초）: 주어진 밀리초（1.000분의 1초） 이후에 콜백 함수를 실행한다.
- setinterval（콜백 함수, 밀 리초）: 주어진 밀리초마다 콜백 함수를 반복 실행한다.
- set1mmediate（콜백 함수）: 콜백 함수를 즉시 실행한다.
이 타이머 함수들은 모두 아이디를 반환한다. 아이디를 사용하면 타이머를 취소할 수 있다.
- clearTimeout（아이디）: setTimeout을 취소한다.
- clearinterval（아이디）: setinterval을 취소한다.
- clearlmmediate（아이디）: setImmediate를 취소한다.
setlmmediate（콜백）과 setTimeout(콜백, 0)
- setlmmediate（콜백）과 setTimeout（콜백, 0）에 담긴 콜백 함수는 이벤트 루프를 거친 뒤 즉시 실행된다. 특수한 경우에 setlmmediate는 setTimeout（콜백, 0）보다 먼저 실행된다. 파일 시스템 접근, 네트워킹 같은 I/O 작업의 콜백 함수 안에서 타이머를 호출하는 경우다. 하지만 setlmmediate가 항상 setTimeout（콜백, 0）보다 먼저 호출되는 것은 아니라는 사실만 알아두자. 헷갈리지 않도록 setTimeout（콜백, 0）은 사용하지 않는 것을 권장한다.

3.4.4 process

process 객체는 현재 실행되고 있는 노드 프로세스에 대한 정보를 담고 있습니다. process 객체 안에는 다양한 속성이 있다.

3.4.4.1 process.env

process.env를 입력하면 매우 많은 정보가 출력된다. 자세히 보면 이 정보들이 시스템의 환경 변수임을 알 수 있다. 시스템 환경 변수가 노드에 직접 영향을 미치기도 한다. 대표적인 것으로 UV_THREADPOOL_SIZE와 NODE_OPTIONS가 있다.

N0DE_0PTI0NS=--max-old-space-size=8192
UV_THREADP00L_SIZE=8

왼쪽이 환경 변수의 이름이고 오른쪽이 값이다. NODE_OPTIONS는 노드를 실행할 때의 옵션들을 입력받는 환경 변수이다. –max-old-space-size=8192는 노드의 메모리를 8GB까지 사용할 수 있게 한다.
UV_THREADPOOL_SIZE는 노드에서 기본적으로 사용하는 스레드 풀의 스레드 개수를 조절할 수 있게한다.
시스템 환경 변수 외에도 우리가 임의로 환경 변수를 저장할 수 있다. process.env는 서비스의 중요한 키를 저장하는 공간으로도 사용된다. 서버나 데이터베이스의 비밀번호와 각종 API 키를 코드에 직접 입력하는 것은 위험하다. 혹여 서비스가 해킹당해 코드가 유출될 경우, 비밀번호가 코드에 남아 있어 추가 피해가 발생할 수 있다.
따라서 중요한 비밀번호는 다음과 같이 process.env의 속성으로 대체한다.

const secretld = process.env.SECRET_ID；
const secretCode = process.env.SECRET_CODE；

3.4.4.2 process.nextTick(콜백)

이벤트 루프가 다른 콜백 함수들보다 nextTick의 콜백 함수를 우선으로 처리하도록 만든다.

setlmmediate(() => {
    console.log('immediate')；
});
process.nextTick(() => {
    console.log('nextTick')；
})；
setTimeout(() => {
    console.log('timeout')；
}, 0)； 
Promise.resolve().then(() => console.log('promise1))；

콘솔

nextTick
promise
timeout
immediate

process.nextTick은 setlmmediate나 setTimeout보다 먼저 실행된다. 코드 맨 밑에 Promise를 넣은 것은 resolve된 Promise도 nextTick처럼 다른 콜백들보다 우선시되기 때문이다. 그래서 process.nextTick과 Promise를 마이크로태스크(microtask)라고 따로 구분해서 부른다.
마이크로태스크의 재귀 호출
- process.nextTick으로 받은 콜백 함수나 resolve된 Promise는 다른 이벤트 루프에서 대기하는 콜백 함수보다도 먼저 실행된다. 그래서 비동기 처리를 할 때 setlmmediate보다 process.nextTick을 더 선호하는 개발자도있다. 하지만 이런 마이크로태스크를 재귀 호출하게 되면 이벤트 루프는 다른 콜백 함수보다 마이크로태스크를 우선해 처리하므로 콜백 함수들이 실행되지 않을 수도 있다.

3.4.4.3 process.exit(코드)

실행 중인 노드 프로세스를 종료한다. 서버 환경에서 이 함수를 사용하면 서버가 멈추므로 특수한 경우를 제외하고는 서버에서 잘 사용하지 않는다. 하지만 서버 외의 독립적인 프로그램에서는 수동으로 노드를 멈추기 위해 사용한다.
process.exit 메서드는 인수로 코드 번호를 줄 수 있다. 인수를 주지 않거나 0을 주면 정상종료를 뜻하고, 1을 주면 비정상 종료를 뜻한다. 만약 에러가 발생해서 종료하는 경우에는 1을넣으면 된다.

끝!

3장 노드 기능 알아보기

Mon, 21 Nov 2022 00:00:00 +0900

이번 챕터에서는 노드에서 사용하는 모듈인 CommonJS와 ECMAScript 모듈(ES 모듈)에 대해서 알아보자.

3.1 REPL 사용하기

자바스크립트는 스크립트 언어이므로 미리 컴파일하지 않아도 즉석에서 코드를 실행할 수 있다. 입력한 코드를 읽고(Read), 해석하고(Eval), 결과물을 반환하고(Print), 종료할 때까지 반복한다(Loop)고 해서 REPL(Reacl Eval Print Loop)이라고 한다.
노드의 REPL을 사용하려면 윈도에서는 명령 프롬프트, 맥이나 리눅스에서는 터미널을 열고 node를 입력한다

3.2 JS 파일 사용하기

REPL에 직접 코드를 입력하는 대신, 자바스크립트 파일을 만들어 실행해 보자.

function helloWorldO {
    console.log('Hello World')；
    helloNode()；
}
function helloNode() {
    console.log('Hello Node')；
}

helloWorld()；

콘솔에서 node ［자바스크립트 파일 경로］로 실행한다. (확장자(.js)는 생략 가능)

3.3 JS 파일 사용하기

노드는 코드를 모듈로 만들 수 있다는 점에서 브라우저의 자바스크립트와는 다르다. 모듈이란 특정한 기능을 하는 함수나 변수들의 집합을 말한다. 예를 들면 수학에 관련된 코드들만 모아서 모듈을 하나 만들 수 있다. 모듈은 자체로도 하나의 프로그램이면서 다른 프로그램의 부품으로도 사용할 수 있다.
모듈로 만들어두면 여러 프로그램에 해당 모듈을 재사용할 수 있다. 자바스크립트에서 코드를 재사용하기 위해 함수로 만드는 것과 비슷하다.
보통 파일 하나가 모듈 하나가 되며, 파일별로 코드를 모듈화할 수 있어 관리하기 편하다.
노드에서는 두 가지 형식의 모듈을 사용하는데, 하나는 CommonJS 모듈이고 다른 하나는 ECMAScript 모듈이다.

3.3.1 CommonJS 모듈

CommonJS 모듈은 표준 자바스크립트 모듈은 아니지만 노드 생태계에서 가장 널리 쓰이는 모듈이다. 왜 표준이 아닌데도 널리 쓰일까? 표준이 나오기 이전부터 쓰였기 때문이다.
var.js와 func.js, index.js를 같은 폴더에 만들어보자.

var.js

const odd = 'CJS 홀수입니다';
const even = 'CJS 짝수입니다';
module.exports = {
    odd,
    even,
}

module.exports에 변수들을 담은 객체를 대입했다. 이제 이 파일은 모듈로서 기능한다.
이번에는 var.js를 참조하는 func.js를 작성해보자.

func.js

const { odd, even } = require('./var')；
function checkOddOrEven(num) {
    if (num % 2) { // 홀수이면
        return odd；
    }
        return even；
}
module.exports = checkOddOrEven；

위 예제에서는 같은 폴더 안에 파일을 만들었지만, 다른 폴더에 있는 파일도 모듈로 사용할 수 있다. require 함수의 인수로 제공하는 경로만 잘 지정하면 된다.
var.js의 module.exports에 담겨 있던 객체를 불러와 func.js에서 사용하는 모습이다. 물론 const obj = require(‘./var’);로 객체를 통째로 불러온 뒤 obj.odd, obj.even처럼 접근할 수도 있다.
모듈 하나가 여러 개의 모듈을 사용할 수 있다. 그리고 모듈로부터 값을 불러올 때 변수 이름을 다르게 지정할 수도 있다.
여러 파일에 걸쳐 재사용되는 함수나 변수를 모듈로 만들어두면 편리하다. 그러나 모듈이 많아지고 모듈 간의 관계가 얽히게 되면 구조를 파악하기 어렵다는 단점도 있다.

노드에서 this는 무엇일까?

노드에서의 this는 브라우저의 this와 조금 다르다.

console.log(this)；
console.log(this === module.exports)；
console.log(this === exports)；
function whatIsThis() {
    console.log('function', this = exports, this === global)；
}
whatlsThis()；

{}
true
true
function false true

다른 부분은 브라우저의 자바스크립트와 동일하지만 최상위 스코프에 존재하는 this는 module.exports（또는 exports 객체）를 가리킨다. 또한, 함수 선언문 내부의 this는 3.4.1 절에서 배울 global 객체를 가리킨다.
이번에는 모듈을 불러오는 require에 대해 알아보자. require는 함수이고, 함수는 객체이므로 require는 객체로서 속성을 몇 개 갖고 있다. 그중에서 require.cache와 require.main을 알아보자.

require.js

console.log（'require가 가장 위에 오지 않아도 됩니다.'）;
module.exports = '저를 찾아보세요.';
require('./var')；
console.log('require.cache입니다.');
console.log(require.cache)；
console.log('require.main입니다.')；
console.log(require.main === module)；
console.log(require.main.filename)；

require가 가장 위에 오지 않아도 됩니다.
require, cache입니다.
[Object： null prototype] {
        'C:\\Users\\zerocho\\require. js' ： Module {
        id：'.'
        exports：'저를 찾아보세요.',
        filename： 'C://Users//zerocho//require.js',
        loaded： false,
        children： [ [Module] ]
        paths： [
        'C:\\Users\\zerocho\\node_modules',
        'C:\\Users\\node_modules',
        'C:\\node_modules'
        ]
    },
'C\\Users\\\zerocho\\vars.js': Module {
        id：'C\\Users\\\zerocho\\vars.js',
        exports： { odd 'CJS 홀수 입니다.'： even：'CJS 짝수입니다.'},
        filename： ： 'C\\Users\\\zerocho\\vars.js',
        loaded： true,
        children： [],
        paths： [
        'C：\\Users\\zerocho\\node_modules'z
        'C:\\Users\\nodejnodules'z
        'C：\\node_modules’
        ]
    }
}
require.main입니다.
true
C:\\Users\\zerocho\\require. js

위 예제에서 알아야 할 점은 require가 반드시 파일 최상단에 위치할 필요가 없고, module.exports도 최하단에 위치할 필요가 없다는 것이다. 아무 곳에서나 사용해도 된다.
require.cache 객체에 require.js나 var.js 같은 파일 이름이 속성명으로 들어 있는 것을 볼 수 있다. 속성값으로는 각 파일의 모듈 객체가 들어 있다. 한번 require한 파일은 require.cache에 저장되므로 다음 번에 require할 때는 새로 불러오지 않고 require.cache에 있는 것이 재사용된다.
require.main은 노드 실행 시 첫 모듈을 가리킨다. 현재 node require로 실행했으므로 require.js가 require.main이 된다.
현재 파일이 첫 모듈인지 알아보려면 require.main === module을 해보면 된다.
모듈을 사용할 때는 주의해야 할 점이 있다. 만약 두 모듈 dep1과 dep2가 있고 이 둘이 서로를 require한다면 어떻게 될까?

dep1.js

const dep2 = require('./dep2')；
console.log('require dep2', dep2)； 
module.exports =()=>{
    console.log('dep2', dep2)；
}；

dep2.js

const dep1 = require('./dep1')；
console.log('require dep1', dep1)； 
module.exports =()=>{
    console.log('dep1', dep1)；
}；

dep-run.js

const dep1 = require('./dep1')；
const dep2 = require('./dep2')；

dep1()；
dep2()；

코드가 위에서부터 실행되므로 require(‘./dep1’)이 먼저 실행된다. dep1.js에서는 제일 먼저 require(‘./dep2’)가 실행된다. 다시 dep2.js에서는 require(‘./dep1’)이 실행된다. 이과정이 계속 반복될것 같은데..?
놀랍게도 dep1의 module.exports가 함수가 아니라 빈 객체로 표시된다. 이러한 현상을 순환참조라고 부른다. 이렇게 순환 참조가 있을 경우에는 순환 참조되는 대상을 빈 객체로 만든다.

3.3.2 ECMAScript 모듈

ECMAScript 모듈（이하 ES 모듈）은 공식적인 자바스크립트 모듈 형식이다. 노드에서 아직까지는 CommonJS 모듈을 많이 쓰긴 하지만, ES 모듈이 표준으로 정해지면서 점점 ES 모듈을 사용하는 비율이 늘어나고 있다. 브라우저에서도 ES 모듈을 사용할 수 있어 브라우저와 노드 모두에 같은 모듈 형식을 사용할 수 있다는 것이 장점이다.
이전 절의 코드를 ES 모듈 스타일로 바꿔보자.

var.mjs

export const odd = 'MJS 홀수입니다';
export const even = 'MJS 짝수입니다';

func.mjs

import { oddz even } from './var.mjs'；
function checkOddOrEven(num) {
    if (num % 2) { // 홀수이면
    return odd；
    }
    return even；
}

export default checkOddOrEven；

index.mjs

import { odd, even } from './var.mjs'；
import checkNumber from './func.mjs'；
function checkStringOddOrEven(str) {
    if (str.length % 2) {
        return odd；
    }
        return even；
}
console.log(checkNumber(10));
console.log(checkStringOddOrEven('hello'))；

require와 exports, module.exports가 각각 import, export, export default로 바뀌었다. ES 모듈의 import나 export default는 require나 module처럼 함수나 객체가 아니라 문법 그 자체이다.
js 확장자에서 import를 사용하면 SyntaxError： Cannot use import statement outside a module 에러가 발생한다. mjs 확장자 대신 js 확장자를 사용하면서 ES 모듈을 사용하려면 5장에서 볼 package.json에 type： Hmodule” 속성을 넣으면 된다.

3.3.3 다이내믹 임포트

CommonJS 모듈과 ES 모듈을 비교할 때, CommonJS 모듈에서는 다이내믹 임포트(dynamic import, 동적 불러오기)가 되는데 ES 모듈에서는 다이내믹 임포트가 안 된다고 설명했다. 다이내믹 임포트가 무엇이고 ES 모듈에서는 어떤 다른 방식을 사용하는지 알아보자.

dynamic.js

const a = false；
if (a) {
    require('./func')；
}
console.log('성공')；

dynamic.js에서 require(‘./func1)는 실행되지 않는다. if문이 false라서 실행되지 않으니까. 이렇게 조건부로 모듈을 불러오는 것을 다이내믹 임포트라고 합니다.

dynamic.mjs

const a = false；
if (a) {
    import './func.mjs'；
}
console.log('성공')；

하지만 ES 모듈은 if문 안에서 import하는 것이 불가능하다. 이럴 때 다이내믹 임포트를 사용한다. dynamic.mjs를 다음과 같이 수정해 보자.

dynamic.mjs

const a = true；
if (a) {
    const m1 = await import('./func.mjs')；
    console.log(m1)；
    const m2 = await import('./var.mjs')；
    console.log(m2)；
}

import라는 함수를 사용해서 모듈을 동적으로 불러올 수 있다. import는 Promise를 반환하기에 await이나 then을 붙여야 한다.

3.3.4 filename, dirname

노드에서는 파일 사이에 모듈 관계가 있는 경우가 많으므로 현재 파일의 경로나 파일명을 알아야하는 경우가 있다. 노드는 __filename, __dirname이라는 키워드로 경로에 대한 정보를 제공한다. 파일에 __filename과 __dirname을 넣어두면 실행 시 현재 파일명과 현재 파일 경로로 바뀐다.

filename.js

console.log(__filename)；
console.log(__dirname)；

C:\Users\zerocho\filename.js
C:\Users\zerocho

윈도가 아니라면 \ 대신 /로 폴더 경로가 구분될 수 있다. 이렇게 얻은 정보를 사용해서 경로 처리를 할 수도 있다. 하지만 경로가 문자열로 반환되기도 하고, \나 / 같은 경로 구분자 문제도 있으므로 보통은 이를 해결해주는 path 모듈과 함께 쓴다.
참고로 ES 모듈에서는 __filename과 __dirname을 사용할 수 없다. 대신 import.meta.url로경로를 가져올 수 있다.

끝!

1장 노드 시작하기

Sat, 19 Nov 2022 00:00:00 +0900

JS Deep Dive를 통해 자바 스크립트 엔진에 대해 간략하게 공부를 했었다. 이번 NodeJs 교과서를 통해서 중복되는 내용은 skip하고 추가되는 내용에 대해서 정리해 보고자 한다.

1.1 핵심 개념 이해하기

노드 공식 사이트(https://nodejs.org/ko/)에서는 노드를 다음과 같이 설명하고 있다.

Node.jsR는 Chrome V8 Javascript 엔진으로 빌드된 자바스크립트 런타임입니다.

대부분은 노드를 서버로 사용하는 방법을 익히기 위해 공부할 것이다. 그런데 공식 사이트의 노드 소개 글에는 서버라는 말이 없다. 하지만 걱정하지 말자. 서버라는 말이 없는 이유는 노드가 서버만 실행할 수 있는 것은 아니기 때문이다.
먼저 서버와 런타임이 무엇인지 알아 보자.

1.1.1 서버

노드를 통해 다양한 자바스크립트 애플리케이션을 실행할 수 있지만, 노드는 서버 애플리케이션을 실행하는 데 제일 많이 사용한다.
서버는 네트워크를 통해 클라이언트에 정보나 서비스를 제공하는 컴퓨터 또는 프로그램을 말한다. 클라이 언트란 요청을 보내는 주체로 브라우저 일 수도 있고, 데스크톱 프로그램일 수도 있고, 모바일 앱일 수도 있고, 다른 서버에 요청을 보내는 서버일 수도 있다.
노드는 자바스크립트 프로그램이 서버로서 기능하기 위한 도구를 제공하므로 서버 역할을 수행할 수 있다. 왜 다른 언어를 사용하지 않고 굳이 노드를 사용해 서버를 만들까? 이 궁금증을 해결하려면 먼저 노드의 특성을 알아야 한다. 공식 웹 사이트에 게시된 노드 소개 글을 바탕으로 노드의 특성을 알아보자.

1.1.2 자바스크립트 런타임

노드는 자바스크립트 런타임이다. 런타임은 특정 언어로 만든 프로그램들을 실행할 수 있는 환경을 뜻한다. 따라서 노드는 자바스크립트 프로그램을 컴퓨터에서 실행할 수 있다. 쉽게 말해 노드는 자바스크립트 실행기라고 봐도 무방하다.
기존에는 자바스크립트 프로그램을 웹 브라우저 위에서만 실행할 수 있었다. 브라우저는 자바스크립트 런타임을 내장하고 있으므로 자바스크립트 코드를 실행할 수 있다. 브라우저 외의 환경에서 자바스크립트를 실행하기 위한 여러 시도가 있었으나, 자바스크립트의 실행 속도 문제 때문에 대부분이 큰 호응을 얻지 못했다.
하지만 2008년 구글이 V8 엔진을 사용해 크롬을 출시하자 이야기가 달라졌다. 당시 V8 엔진은 다른 자바스크립트 엔진과 달리 매우 빨랐고, 오픈 소스로 코드를 공개했다. 속도 문제가 해결되자 라이언 달(Ryan Dahl)은 2009년 V8 엔진 기반의 노드 프로젝트를 시작했다.

노드는 V8과 더불어 libuv라는 라이브러리를 사용한다. libuv 라이브러리는 노드의 특성인 이벤트 기반, 논블로킹 I/O 모델을 구현하고 있습다. 이 모델이 무엇인지, 장단점으로는 어떤 것들이 있는지 이제 알아보자!

1.1.3 이벤트 기반

이벤트 기반 시스템에서는 특정 이벤트가 발생할 때 무엇을 할지 미리 등록해둬야 한다. 이를 이벤트 리스너(event listener)에 콜백(callback) 함수를 등록한다고 표현한다.
노드도 이벤트 기반 방식으로 동작하므로 이벤트가 발생하면 이벤트 리스너에 등록해둔 콜백 함수를 호출한다. 발생한 이벤트가 없거나 발생했던 이벤트를 다 처리하면, 노드는 다음 이벤트가 발생할 때까지 대기한다.
이벤트 기반 모델에서는 이벤트 루프(event loop)라는 개념이 등장한다. 여러 이벤트가 동시에 발생했을 때 어떤 순서로 콜백 함수를 호출할지를 이벤트 루프가 판단한다.

1.1.4 논블로킹 I/O

이벤트 루프를 잘 활용하면 오래 걸리는 작업을 효율적으로 처리할 수 있다. 작업에는 두 가지 종류가 있는데, 동시에 실행될 수 있는 작업과 동시에 실행될 수 없는 작업이 있다. 기본적으로 우리가 작성한 자바스크립트 코드는 동시에 실행될 수 없다. 하지만 자바스크립트상에서 돌아가는 것이 아닌 i/o 작업 같은 것은 동시에 처리될 수 있다.
I/O는 입력（Input）/출력（OutpuO을 의미한다. 파일 시스템 접근（파일 읽기 및 쓰기, 폴더 만들기등）이나 네트워크를 통한 요청 같은 작업이 I/O의 일종이다. 이러한 작업을 할 때 노드는 논블로킹 방식으로 처리하는 방법을 제공한다. 논블로킹(non-blocking)이란 이전 작업이 완료될 때까지 대기하지 않고 다음 작업을 수행하는 것을 의미한다. 반대로 블로킹은 이전 작업이 끝나야만 다음 작업을 수행하는 것을 의미합니다.
노드는 I/O 작업을 백그라운드로 넘겨 동시에 처리하곤 한다. 따라서 동시에 처리될 수 있는 작업들은 최대한 묶어서 백그라운드로 넘겨야 시간을 절약할 수 있다.
다음 예제는 논블로킹 방식의 코드다.

function longRunningTask（） {
console.log（'작업 끝'）；
}
console.log（'시작'）；
setTimeout（longRunningTask, 0）；
console.log（'다음 작업'）；

결과는 시작 -> 다음 작업 -> 작업 끝이다. setTimeout의 콜백 함수인 longRunningTask가 태스크 큐로 보내지므로 순서대로 실행되지 않는다는 것을 알 수 있다. 다음 작업이 먼저 실행된 후, 오래 걸리는 작업이 완료된다.
다만. 아무리 논블로킹 방식으로 코드를 작성하더라도 코드가 전부 우리가 작성한 것이라면 전체 소요 시간이 짧아지지는 않는다. 우리의 코드는 서로 동시에 실행되지 않기 때문이다. 단순히 실행 순서만 바뀔 뿐…
하지만 I/O 작업이 없다고 해서 논블로킹이 의미가 없는 것은 아니다. 오래 걸리는 작업을 처리해야 하는 경우, 논블로킹을 통해 실행 순서를 바꿔줌으로써 그 작업 때문에 간단한 작업들이 대기하는 상황을 막을 수 있다는 점에서 의의가 있다. 또한, 논블로킹과 동시가 같은 의미가 아니라는 사실을 알아두자.

1.1.5 싱글스레드

스레드를 이해하기 위해서는 프로세스부터 알아야 한다. 프로세스와 스레드의 차이는 다음과 같다.
- 프로세스는 운영체제에서 할당하는 작업의 단위다. 노드나 웹 브라우저 같은 프로그램은 개별적인 프로세스다. 프로세스 간에는 메모리 등의 자원을 공유하지 않는다.
- 스레드는 프로세스 내에서 실행되는 흐름의 단위다. 프로세스는 스레드를 여러 개 생성해 여러 작업을 동시에 처리할 수 있다. 스레드들은 부모 프로세스의 자원을 공유한다. 같은 주소의 메모리에 접근 가능하므로 데이터를 공유할 수 있다.

노드가 싱글 스레드라는 말을 들어봤을 것이다. 하지만 엄밀히 말하면 싱글 스레드로 동작하지는 않는다. 노드를 실행하면 먼저 프로세스가 하나 생성된다. 그리고 그 프로세스에서 스레드들을생성하는데, 이때 내부적으로 스레드를 여러 개 생성한다. 그중에서 우리가 직접 제어할 수 있는 스레드는 하나뿐이다. 그래서 흔히 노드가 싱글 스레드라고 여겨지는 것이다.
스레드를 작업을 처리하는 일손으로 표현하기도 하는데. 하나의 스레드만 직접 조작할 수 있으므로 일손이 하나인 셈이다. 요청이 많이 들어오면 한 번에 하나씩 요청을 처리한다. 블로킹이심하게 일어나는 작업을 처리하지만 않는다면 스레드 하나로도 충분하다. 블로킹이 발생할 것같은 경우에는 논블로킹 방법으로 대기 시간을 최대한 줄인다.

끝!

46장 제너레이터와 async/await

Sat, 19 Nov 2022 00:00:00 +0900

46.1 제너레이터란?

ES6에서 도입된 제너레이터는 코드 블록의 실행을 일시 중지했다가 필요한 시점에 재개할 수 있는 특수한 함수다. 제너레이터와 일반 함수의 차이는 다음과 같다.
제너레이터 함수는 함수 호출자에게 함수 실행의 제어권을 양도할 수 있다.
- 일반 함수를 호출하면 제어권이 함수에게 넘어가고 함수 코드를 일괄 실행한다. 즉, 함수 호출자는 함수를 호출한 이후 함수 실행을 제어할 수 없다. 제너레이터 함수는 함수 실행을 함수 호출자가 제어할 수 있다. 다시 말해, 함수 호출자가 함수 실행을 일시 중지시키거나 재개시킬 수 있다. 이는 함수의 제어권을 함수가 독점하는 것이 아니라 함수 호출자에게 양도할 수 있다는 것을 의미한다.
제너레이터 함수는 함수 호출자와 함수의 상태를 주고받을 수 있다.
- 일반 함수를 호출하면 매개변수를 통해 함수 외부에서 값을 주입받고 함수 코드를 일괄 실행하여 결과값을 함수 와부로 반환한다. 즉, 함수가 실행되고 있는 동안에는 함수 외부에서 함수 내부로 값을 전달하여 함수의 상태를 변경할 수 없다. 제너레이터 함수는 함수 호출자와 양방향으로 함수의 상태를 주고받을 수 있다. 다시 말해, 제너레이터 함수는 함수 호출자에게 상태를 전달할 수 있고 함수 호출자로부터 상태를 전달받을 수도 있다.
제너레이터 함수를 호출하면 제너레이터 객체를 반환한다.
- 일반 함수를 호출하면 함수 코드를 일괄 실행하고 값을 반환한다. 제너레이터 함수를 호출하면 함수 코드를 실행하는 것이 아니라 이터러블이면서 동시에 이터레이터인 제너레이터 객체를 반환한다.

46.2 제너레이터 함수의 정의

제너레이터 함수는 function* 키워드로 선언한다. 그리고 하나 이상의 yield 표현식을 포함한다. 이것을 제외하면 일반 함수를 정의하는 방법과 같다.

// 제너러/이터 함수 선언문
function* genDecFunc() {
    yield 1;
}
// 제너레이터 함수 표현식
const genExpFunc = function* () {
    yield 1;
};
// 제너레이터 메서드
const obj = {
    * genObjMethod() {
        yield 1;
    }
}；
// 제너레이터 클래스 메서드
class MyClass {
    * genClsMethod() {
        yield 1;
    }
}

제너레이터 함수는 화살표 함수로 정의할 수 없다.
제너레이터 함수는 new 연산자와 함께 생성자 함수로 호출할 수 없다.

46.3 제너레이터 객체

제너레이터 함수를 호출하면 일반 함수처럼 함수 코드 블록을 실행하는 것이 아니라 제너레이터 객체를 생성해 반환한다. 제너레이터 함수가 반환한 제너레이터 객체는 이터러블이면서 동시에 이터레이터다.

// 제너레이터 함수
function* genFunc() {
    yield 1;
    yield 2;
    yield 3;
}
// 제너레이터 함수를 호출하면 제너레이터 객체를 반환한다.
const generator = genFunc();
// 제너레이터 객체는 이터러블이면서 동시에 이터레이터다.
// 이터러블은 Symbol, iterator 메서드를 직접 구현하거나 프로토타입 체인을 통해 상속받은 객체다.
console.log(Symbol.iterator in generator); // true
// 이터레이터는 next 메서드를 갖는다.
console.log('next' in generator); // true

제너레이터 객체는 next 메서드를 갖는 이터레이터이지만 이터레이터에는 없는 return, throw 메서드를 갖는다. 제너레이터 객체의 세 개의 메서드를 호출하면 다음과 같이 동작한다.
- next 메서드를 호출하면 제너레이터 함수의 yield 표현식까지 코드 블록을 실행하고 yield된 값을 value 프로퍼티 값으로, false를 done 프로퍼티 값으로 갖는 이터레이터 리절트 객체를 반환한다.
- return 메서드를 호출하면 인수로 전달받은 값을 value 프로퍼티 값으로, true를 done 프로퍼티 값으로 갖는 이터레이터 리절트 객체를 반환한다.
- throw 메서드를 호출하면 인수로 전달받은 에러를 발생시키고 undefined를 value 프로퍼티 값으로, true를 done 프로퍼티 값으로 갖는 이터레이터 리절트 객체를 반환한다.

function* genFunc() {
    try {
        yield 1;
        yield 2;
        yield 3;
    } catch (e) {
        console.error(e);
    }
}
const generator = genFunc();
console.log(generator.next()); // {value： 1, done: false}
console.log(generator.return('End I')); // {value: "End!", done: true}
console.log(generator.throw('Error!')); // {value: undefined, done: true}

46.4 제너레이터의 일시 중지와 재개

제너레이터는 yield 키워드와 next 메서드를 통해 실행을 일시 중지했다가 필요한 시점에 다시 재개할 수 있다. 일반 함수는 호출 이후 제어권을 함수가 독점하지만 제너레이터는 함수 호출자에게 제어권을 양도(yield)하여 필요한 시점에 함수 실행을 재개할 수 있다.
이터러블이면서 동시에 이터레이터인 제너레이터 객체는 next 메서드를 갖는다. 제너레이터 객체의 next 메서드를 호출하면 제너레이터 함수의 코드 블록을 실행한다.
단, 일반 함수처럼 한 번에 코드 블록의 모든 코드를 일괄 실행하는 것이 아니라 yield 표현식까지만 실행한다. yield 키워드는 제너레이터 함수의 실행을 일시 중지시키거나 yield 키워드 뒤에 오는 표현식의 평가 결과를 제너레이터 함수 호출자에게 반환한다.
제너레이터 객체의 next 메서드를 호출하면 yield 표현식까지 실행되고 일시 중지된다. 이때 함수의 제어권이 호출자로 양도된다. 이후 필요한 시점에 호출자가 또다시 next 메서드를 호출하면 일시 중지된 코드부터 실행을 재개하기 시작하여 다음 yield 표현식까지 실행되고 또 다시 일시 중지된다.
이때 제너레이터 객체의 next 메서드는 value, done 프로퍼티를 갖는 이터레이터 리절트 객체를 반환한다. next 메서드가 반환한 이터레이터 리절트 객체의 value 프로퍼티에는 yield 표현식에서 yield된 값(yield 키워드 뒤의 값)이 할당되고 done 프로퍼티에는 제너레이터 함수가 끝까지 실행되었는지를 나타내는 불리언 값이 할당된다.
이터레이터의 next 메서드와 달리 제너레이터 객체의 next 메서드에는 인수를 전달할 수 있다. 제너레이터 객체의 next 메서드에 전달한 인수는 제너레이터 함수의 yield 표현식을 할당받는 변수에 할당된다.

function* genFunc() {
    // 처음 next 메서드를 호출하면 첫 번째 yield 표현식까지 실행되고 일시 중지된다.
    // 이때 yield된 값 1은 next 메서드가 반환한 이터레이터 리절트 객체의 value 프로퍼티에 할당된다.
    // x 변수에는 아직 아무것도 할당되지 않았다. x 변수의 값은 next 메서드가 두 번째 호출될 때 결정된다.
    const x = yield 1;
    // 두 번째 next 메서드를 호출할 때 전달한 인수 10은 첫 번째 yield 표현식을 할당받는
    // x 변수에 할당된다. 즉, const x = yield 1;은 두 번째 next 메서드를 호출했을 때 완료된다.
    // 두 번째 next 메서드를 호출하면 두 번째 yield 표현식까지 실행되고 일시 중지된다.
    // 이때 yield된 값 x + 10은 next 메서드가 반환한 이터레이터 리절트 객체의 value 프로퍼티에 할당된다.
    const y = yield (x + 10);
    // 세 번째 next 메서드를 호출할 때 전달한 인수 20은 두 번째 yield 표현식을 할당받는 y 변수에 할당된다.
    // 즉, const y = yield (x + 10);는 세 번째 next 메서드를 호출했을 때 완료된다.
    // 세 번재 next 메서드를 호출하면 함수 끝까지 실행된다.
    // 이때 제너레이터 함수의 반환값 x + y는 next 메서드가 반환한 이터레이터 리절트 객체의
    // value 프로퍼티에 할당된다. 일반적으로 제너레이터의 반환값은 의미가 없다.
    // 따라서 제너레이터어/서는 값을 반환할 필요가 없고 return은 종료의 의미로만 사용해야 한다.
    return x + y;
}
// 제너레이터 함수를 호출하면 제너레이터 객체를 반환한다.
// 이터러블이며 동시에 이터레이터인 제너레이터 체는 next 메서드를 갖는다.
const generator = genFunc(0);
// 처음 호출하는 next 메서드에는 인수를 전달하지 않는다.
// 만약 처음 호출하는 next 메서드에 인수를 전달하면 무시된다.
// next 메서드가 반환한 이터레이터 리절트 객체의 value 프로퍼티에는 첫 번째 yield된 값 10이 할당된다.
let res = generator.next();
console.log(res); // {value: 1, done: false}
// next 메서드에 인수로 전달한 10은 genFunc 함수의 x 변수에 할당된다.
// next 메서드가 반환한 이터레이터 리절트 객체의 value 프로퍼티에는 두 번째 yield된 값 20이 할당된다.
res = generator.next(10);
console.log(res); // {value： 20, done: false}
// next 메서드에 인수로 전달한 20은 genFunc 함수의 y 변수에 할당된다.
// next 메서드가 반환한 이터레이터 리절트 객체의 value 프로퍼티에는 제너레이터 함수의 반환값 30이 할당된다.
res = generator.next(20);
console.log(res); // {value: 30, done: true}

이처럼 제너레이터 함수는 next 메서드와 yield 표현식을 통해 함수 호출자와 함수의 상태를 주고받을 수 있다. 함수 호출자는 next 메서드를 통해 yield 표현식까지 함수를 실행시켜 제너레이터 객체가 관리하는 상태（yield된 값）를 꺼내올 수 있고, next 메서드에 인수를 전달해서 제너레이터 객체에 상태（yield 표현식을 할당받는 변수）를 밀어넣을 수 있다. 이러한 제너레이터의 특성을 활용하면 비동기 처리를 동기 처리처럼 구현할수 있다. 이에 대해서는 46.5.2절 “비동기 처리”에서 자세히 살펴보자.

46.5 제너레이터의 활용

46.5.1 이터러블의 구현

제너레이터 함수를 사용하면 이터레이션 프로토콜을 준수해 이터러블을 생성하는 방식보다 간단히 이터러블을 구현할 수 있다. 제너레이터를 사용하여 무한 피보나치 수열을 생성하는 함수를 구현해 보자. 제너레이터 함수를 사용하면 이터레이션 프로토콜을 준수해 이터러블을 생성하는 방식보다 간단히 이터러블을 구현할 수 있다.

// 무한 이터러블을 생성하는 제너레이터 함수
const infiniteFibonacci = (function* () {
    let [pre, cur] = [0, 1];
    while (true) {
    [pre, cur] = [cur, pre + cur];
    yield cur;
    }
}())；
// infiniteFibonacci는 무한 이터러블이다.
for (const num of infiniteFibonacci) {
    if (num > 10000) break;
    console.log(num); // 1 2 3 5 8... 2584 4181 6765
}

46.5.2 비동기 처리

제너레이터 함수는 next 메서드와 yield 표현식을 통해 함수 호출자와 함수의 상태를 주고받을 수 있다. 이러한 특성을 활용하면 프로미스를 사용한 비동기 처리를 동기 처리처럼 구현할수 있다. 다시 말해, 프로미스의 후속 처리 메서드 then/catch/finally 없이 비동기 처리 결과를 반환하도록 구현할 수 있다. 다음 예제를살펴보자.

// 제너레이터 실행기
const async = generatorFunc => {
    const generator = generatorFunc(); // ②
    const onResolved = arg => {
        const result = generator.next(arg); // ⑤
        return result.done
        ? result.value // ⑨
        : result.value.then(res => onResolved(res)); // ⑦
    }
    return onResolved; // ③
}；
(async(function* fetchTodo() { // ①
    const url = 'https://jsonplaceholder.typicode.eom/todos/1';
    const response = yield fetch(url); // ⑥
    const todo = yield response.json(); // ⑧
    console.log(todo);
    // {userid: 1, id: 1, title: 'delectus aut autem', completed: false}
})())； // ④

위 예제는 다음과 같이 동작한다. 순서대로 살펴보자.

1) async 함수가 호출(①)되면 인수로 전달받은 제너레이터 함수 fetchTodo를 호출하여 제너레이터 객체를 생성(②)하고 onResolved 함수를 반환(③)한다. onResolved 함수는 상위 스코프의 generator 변수를 기억하는 클로저다. async 함수가 반환한 onResolved 함수를 즉시 호출(④)하여 ②에서 생성한 제너레이터 객체의 next 메서드를 처음 호출(⑤)한다.
2) next 메서드가 처음 호출(⑤)되면 제너레이터 함수 fetchTodo의 첫 번째 yield 문(⑥)까지 실행된다. 이때 next 메서드가 반환한 이터레이터 리절트 객체의 done 프로퍼티 값이 false, 즉 아직 제너레이터 함수가 끝까지 실행되지 않았다면 이터레이터 리절트 객체의 value 프로퍼티 값 즉 첫 번째 yield된 fetch 함수가 반환한 프로미스가 resolve한 Response 객체를 onResolved 함수에 인수로 전달하면서 재귀 호출(⑦)한다. 3) onResolved 함수에 인수로 전달된 Response 객체를 next 메서드에 인수로 전달하면서 next 메서드를 두 번째로 호출(⑤)한다. 이때 next 메서드에 인수로 전달한 Response 객체는 제너레이터 함수 fetchTodo의 response 변수(⑥)에 할당되고 제너레이터 함수 fetchTodo의 두 번째 yield 문(⑧)까지 실행된다. 4) next 메서드가 반환한 이터레이터 리절트 객체의 done 프로퍼티 값이 false, 즉 아직 제너레이터 함수 fetchTodo가 끝까지 실행되지 않았다면 이터레이터 리절트 객체의 value 프로퍼티 값 즉 두 번째 yield된 response, json 메서드가 반환한 프로미스가 resolve한 todo 객체를 onResolved 함수에 인수로 전달하면서 재귀 호출(⑦)한다. 5) onResolved 함수에 인수로 전달된 todo 객체를 next 메서드에 인수로 전달하면서 next 메서드를 세 번째로 호출(⑤)한다.이때 next 메서드에 인수로 전달한 todo 객체는 제너레이터 함수 fetchTodo의 todo 변수(⑧)에 할당되고 제너레이터 함수 fetchTodo가 끝까지 실행된다. 6) next 메서드가 반환한 이터레이터 리절트 객체의 done 프로퍼티 값이 true, 즉 제너레이터 함수 fetchTodo가 끝까지 실행되었다면 이터레이터 리절트 객체의 value 프로퍼티 값 즉 제너레이터 함수 fetchTodo의 반환값인 undefined를 그대로 반환(⑨)하고 처리를 종료한다.

위 예제의 제너레이터 함수를 실행하는 제너레이터 실행기인 async 함수는 이해를 돕기 위해 간략화한 예제이므로 완전하지 않다. 다음에 설명할 async/await를 사용하면 async 함수와 같은 제너레이터 실행기를 사용할 필요가 없다.

46.6 async/await

제너레이터를 사용해서 비동기 처리를 동기 처리처럼 동작하도록 구현했지만 코드가 무척이나 장황해지고 가독성도 나빠졌다. ES8(ECMAScript 2017)에서는 제너레이터보다 간단하고 가독성 좋게 비동기 처리를 동기 처리처럼 동작하도록 구현할 수 있는 async/await가 도입되었다.
async/await는 프로미스를 기반으로 동작한다. async/await를 사용하면 프로미스의 then/catch/finally 후속 처리 메서드에 콜백 함수를 전달해서 비동기 처리 결과를 후속 처리할 필요 없이 마치 동기 처리처럼 프로미스를 사용할 수 있다. 다시 말해, 프로미스의 후속 처리 메서드 없이 마치 동기 처리처럼 프로미스가 처리 결과를 반환하도록 구현할수 있다. 위 예제를 async/await로 다시 구현해 보자.

async function fetchTodo() {
    const url = 'https://jsonplaceholder.typicode.com/todos/1';
    const response = await fetch(url);
    const todo = await response.json();
    console.log(todo);
    // {userid: 1, id: 1, title: 'delectus aut autem1, completed: false}
}
fetchTodo();

46.6.1 async 함수

await 키워드는 반드시 async 함수 내부에서 사용해야 한다. async 함수는 async 키워드를 사용해 정의하며 언제나 프로미스를 반환한다. async 함수가 명시적으로 프로미스를 반환하지 않더라도 async 함수는 암묵적으로 반환값을 resolve하는 프로미스를 반환한다.

// async 함수 선언문
async function foo(n) { return n; }
foo(l).then(v => console.log(v)); // 1
// async 함수 표현식
const bar = async function (n) { return n; };
bar(2).then(v => console.log(v)); // 2
// async 화살표 함수
const baz = async n => n;
baz(3).then(v => console.log(v)); // 3
// async 메서드
const obj = {
    async foo(n) { return n; }
}；
obj.foo(4).then(v => console.log(v)); // 4
// async 클래스 메서드
class MyClass {
    async bar(n) { return n; }
}
const myClass = new MyClass();
myClass.bar(5).then(v => console.log(v)); // 5

클래스의 constructor 메서드는 async 메서드가 될 수 없다. 클래스의 constructor 메서드는 인스턴스를 반환해야 하지만 async 함수는 언제나 프로미스를 반환해야 한다.

46.6.2 await 키워드

await 키워드는 프로미스가 settled 상태(비동기 처리가 수행된 상태)가 될 때까지 대기하다가 settled 상태가 되면 프로미스가 resolve한 처리 결과를 반환한다. await 키워드는 반드시 프로미스 앞에서 사용해야 한다.

const fetch = require('node-fetch');
const getGithubllserName = async id => {
    const res = await fetch('https://api.github.com/users/${id}'); // ①
    const { name } = await res.json(); // ②
    console.log(name); // Ungmo Lee
}；
getGithubUserName(’ungmo21);

await 키워드는 프로미스가 settled 상태가 될 때까지 될 때까지 대기한다고 했다. 따라서 ①의 fetch 함수가 수행한 HTTP 요청에 대한 서버의 응답이 도착해서 fetch 함수가 반환한 프로미스가 settled 상태가 될때까지 ①은 대기하게 된다. 이후 프로미스가 settled 상태가 되면 프로미스가 resolve한 처리 결괴가 res 변수에 할당된다. 이처럼 await 키워드는 다음 실행을 일시 중지시켰다가 프로미스가 settled 상태가 되면 다시 재개한다. 다음 예제를 살펴보자.

async function foo() {
    const a = await new Promise(resolve => setTimeout(() => resolve(l), 3000));
    const b = await new Promise(resolve => setTimeout(() => resolve(2), 2000));
    const c = await new Promise(resolve => setTimeout(() => resolve(3), 1000));
    console.log([a, b, c]); // [1, 2, 3]
}
foo(); // 약 6초 소요된다.

모든 프로미스에 await 키워드를 사용하는 것은 주의해야 한다. 그런데 foo 함수가수행하는 3개의 비동기 처리는 서로 연관이 없이 개별적으로 수행되는 비동기 처리이므로 앞선 비동기 처리가 완료될 때까지 대기해서 순차적으로 처리할 필요가 없다. 따라서 foo 함수는 다음과 같이 처리하는 것이 좋다.

async function foo() {
    const res = await Promise.all([
    new Promise(resolve => setTimeout(() => resolve(l), 3000)),
    new Promise(resolve => setTimeout(() => resolve(2), 2000)),
    new Promise(resolve => setTimeout(() => resolve(3), 1000))
    ])；
    console.log(res); // [1, 2, 3]
}
foo(); // 약 3초 소요된다.

46.6.3 에러 처리

비동기 처리를 위한 콜백 패턴의 단점 중 가장 심각한 것은 에러 처리가 곤란하다는 것이다. 45.1.2절 “에러 처리의 한계”에서 살펴본 바와 같이 에러는 호출자 방향으로 전파된다. 즉, 콜 스택의 아래 방향(실행 중인 실행 컨텍스트가 푸시되기 직전에 푸시된 실행 컨텍스트 방향)으로 전파된다.
async/await에서 에러 처리는 try… catch 문을 사용할 수 있다. 콜백 함수를 인수로 전달받는 비동기 함수와는 달리 프로미스를 반환하는 비동기 함수는 명시적으로 호출할 수 있기 때문에 호출자가 명확하다.

const fetch = require('node-fetch');
const foo = async () => {
    try {
        const wrongUrl = 'https://wrong.url';
        const response = await fetch(wrongllrl);
        const data = await response.json();
        console.log(data);
    } catch (err) {
        console, error(err); // TypeError: Failed to fetch
    }
}；
foo();

위 예제의 foo 함수의 catch 문은 HTTP 통신에서 발생한 네트워크 에러뿐 아니라 try 코드 블록 내의 모든 문에서 발생한 일반적인 에러까지 모두 캐치할 수 있다.
async 함수 내에서 catch 문을 사용해서 에러 처리를 하지 않으면 async 함수는 발생한 에러를 reject하는 프로미스를 반환한다. 따라서 async 함수를 호출하고 Promise.prototype.catch 후속 처리 메서드를 사용해 에러를 캐치할 수도 있다.