인프라가 코드로 표현된다

⇒ UI나 커맨드를 통한 수동 조작이 아닌 코드로 인프라를 관리하는 것

ex) Terraform에서는 하시코프 설정언어(HCL)를 사용

🌱 인프라 자동화의 변화

인프라 운영이 물리적인 데이터 센터(온 프레미스)에서부터 클라우드 환경에 이르기까지 형태가 변화하면서 운영하는 방식도 지속적으로 바뀌고 있다.

1. 문서로 관리

• ex) 어떤 서비스가 어느 서버에서 실행되는 지 등을 엑셀에 기록
• 결국 사람이 실제 작업을 위한 명령어와 파일을 별도로 준비해야 함
• 재사용성이 낮음

2. 스크립트

• 반복되는 작업을 스크립트로 작성해 자동화
• 스크립트는 현재의 상태와 관계없이 순서대로 각 단계를 실행하기 때문에 실행 중인 최종 상태가 스크립트의 결과와 일치하지 않을 수 있다.

3. 가상 머신

• 미리 구성된 가상 머신 이미지는 템플릿화하여 저장하고 반복적으로 사용할 수 있음
• 하지만 이미지 변경을 위한 수동 작업은 여전히 존재

4. 클라우드 인프라

• 상품화된 인프라와 데이터 센터 이용
• 확장성 뛰어남

5. 컨테이너

• 운영체제를 가상화한 환경 제공
• 컨테이너 오케스트레이션 환경을 사용한다면 특정 컴퓨팅 서버가 아닌 적절한 리소스가 있는 어딘가의 서버에 배포된다.

🌱 IaC 개념의 등장 배경

이렇게 가상화 기술이 발전하면서, 여러 대의 서버를 더 많이 쉽게 만들 수 있게 됨

⇒ 늘어나는 서버들에 대한 프로비저닝과 운영에 대한 이슈 발생(인력을 무한정으로 늘릴 수 없음)

⇒ 서버 구축과 운영에 대한 자동화가 필요

⇒ 프로그래밍 코드로 인프라를 구축하고 운영할 수 있는 IaC 개념의 등장

🌱 IaC의 장점

• 자동화

  수동으로 서버를 생성하는 게 아니라, 코드로 생성하기 때문에 서버 운명 및 관리를 모두 자동화할 수 있다.

  ex) AWS에서 새로운 서버를 생성 하기 위해서 AWS 콘솔에 로그인할 필요없이 Terraform 코드를 실행시키기기만 하면 됩니다.

• 휴먼 에러 방지

• 문서화

  • 재사용성
  • 여러 사람들 간 공유 가능
  • 속도가 빠름 ⇒ 직접 cli에서 치는 것보다 문서화된 코드를 실행하는 게 훨씬 빠름

• 형상관리

• 리뷰 및 테스트

  수동으로 서버 작업을 할 때는, 실제로 실행하기 전에 리뷰 하는 것이 굉장히 힘들수 밖에 없었습니다. 그래서 문제가 발견 되었을 때는 이미 프로덕션 애플리케이션에 영향을 주고 난 후인 경우가 많았는데, Terraform의 경우  코드 리뷰와 테스트를 통해  문제가 실제로 발생 되는 것을 어느 정도  예방할 수 있습니다.

🌱 IaC의 단점

• 코드 문법 학습
• 파이프라인 통합 ⇒ 기존 워크플로에 자동화를 위한 수고가 추가로 필요하다.
• IaC 자체 지식과 더불어 관리 대상이 되는 인프라 지식이 함께 필요하다.

🌱 테라폼의 특성

테라폼의 3가지 철학

• workflow
• IaC
• 실용주의

💡 workflow란? 어떤 기능 하나가 모든 문제를 해결해주지는 못한다 ⇒ 테라폼은 개발자나 시스템 관리자가 일하는 방식과 유사한 “workflow”를 만들기 위한 도구로 설계되었다. ⇒ workflow의 대상은 인프라 구성과 배포, 보안 구성, 계정 추가 작업 등이 될 수 있다. ⇒ 어떤 기술이 사용되더라도 workflow를 통해 환경의 변화에 크게 구애받지 않도록 설계되었다. ex) 몇 년 전에 도입한 특정 인프라 환경이 회사 전략에 따라 새로운 환경으로 변경되어도 workflow 자체는 그대로 유지될 수 있다.

🌱 프로바이더

테라폼 자체만으로는 다양한 인프라와 서비스를 프로비저닝 할 수 없다.

⇒ 인프라와 서비스 사이에서 프로바이더가 인터페이싱을 해줘야한다.

• 각 인프라와 서비스는 고유의 API를 가지고 있음
• 프로바이더는 각 API 명세를 테라폼 코드로 호출해 동작
• 마치 자바 코드에서 MySql을 연동할 때 해당 DB의 드라이버를 사용하는 것과 비슷한 원리

테라폼은 인프라를 코드로 관리하는 도구(IaC: Infrastructure as Code)이다. 하지만 테라폼 자체는 아마존 웹 서비스(AWS), 구글 클라우드(GCP), 마이크로소프트 애저(Azure) 등 다양한 클라우드 플랫폼이나 SaaS(Software as a Service) 시스템의 동작 방식이나 API를 알지 못한다.

그래서 테라폼이 직접 인프라 리소스에 접근하고 생성하는 것이 아니라, “프로바이더(Provider)”를 통해 각 서비스와 통신하고 조작한다.

자바에서 MySQL을 연결할 때도, 자바 코드가 MySQL 프로토콜을 직접 이해하진 않는다. 대신 MySQL JDBC 드라이버가 자바의 명령을 MySQL에 맞게 번역해준다.

ex) API와 테라폼 코드 사이의 중개자 역할

각 클라우드나 SaaS 서비스는 고유한 API를 제공한다. 예를 들어 AWS는 ec2:RunInstances 같은 API를 통해 EC2 인스턴스를 생성하고 이때 테라폼은 그 API를 직접 호출하지 않고, 대신 AWS 프로바이더에 다음과 같은 방식으로 명령을 내린다.

resource "aws_instance" "example" {
  ami           = "ami-123456"
  instance_type = "t2.micro"
}

이걸 받은 AWS 프로바이더는 내부적으로 해당 값을 AWS API로 변환해서 호출하고, 결과를 받아서 테라폼에게 알려준다.

🌱 테라폼 진행순서

• 테라폼 구성 파일은 기존 state와 실제 인프라 구성을 비교해 실행 계획에서 생성, 수정, 삭제 여부를 결정한다.
• terraform plan을 실행하면 암묵적으로 refresh 동작을 수행하면서 리소스 생성의 대상과 state를 기준으로 비교하는 과정을 거친다.
• -refresh = false 플래그를 사용해 리소스 생성 대상과의 동기화 과정을 생략하고 state를 기준으로 실행 계획을 생성할 수 있다.

terraform plan 실행 시 기본 동작 과정

1. 현재 상태(state file) 로컬 또는 remote backend에서 읽어옴

2. 리프레시(refresh): 현재 클라우드의 실제 리소스 상태를 API로 조회해서 .tfstate와 비교

   ⇒ 만약 여기서 실제 리소스 상태와 state가 다르다면, 실제 리소스 상태에 맞춰서 state 파일을 동기화

3. 계획 생성(plan): .tf 코드와 현재 상태를 비교해서 어떤 변경이 필요한지 계산

💡 refresh=false란?

terraform plan -refresh=false

이 명령은 👉 2번의 상태 리프레시를 건너뛰겠다는 뜻입니다.

즉, Terraform은 현재 .tfstate 파일만 믿고 변경 사항을 계산합니다.

실제 클라우드 자원이 어떤 상태인지 조회하지 않습니다.

Plan과 Apply에서 각 리소스에 발생할 수 있는 작업의 종류

Replace (/+) vs Update in-place (~)

🌱 workspace란?

• state를 관리하는 논리적인 가상 공간을 의미합니다. => 하나의 루트 모듈에서 다른 환경을 위한 리소스를 동일한 테라폼 구성으로 프로비저닝하고 관리할 수 있습니다.

• 새로운 워크스페이스가 생성되면 실행한 루트 모듈 디렉토리에 terraform.tfstate.d 디렉토리가 생성되고 하위에 생성한 워크스페이스 이름을 확인할 수 있습니다.

  

• 테라폼 구성에서 terraform.workspace를 사용하여 workspace 이름을 읽으면 workspace 기준으로 문자열을 지정하거나 조건을 부여할 수 있습니다. workspace 이름을 조건으로 동일한 코드 구성으로 다른 조건의 리소스를 생성 하는 예시

  resource "aws_instance" "web" {
    count = "${terraform.workspace == "default" ? 5 : 1}"
    ami = "~"
    instance_type = "t3.micro"
  }

🌱 workspace 관련 명령어 모음

# 새로운 워크스페이스 생성 => 자동으로 해당 워크스페이스로 전환됨 
$terraform workspace new <workspsace name>

# 사용 중인 워크스페이크 확인
$terraform workspace show

# 활성화된 워크스페이스 변경
$terraform workspace select <workspsace name>

# 워크스페이스 삭제
$terraform workspace delete <workspsace name>

🌱 쿠버네티스란?

공식문서에 나와있는 쿠버네티스의 정의는 다음과 같습니다.

Kubernetes is a portable, extensible, open source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available.

쿠버네티스란 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식 및 확장이 가능하고 선언적 구성과 자동화를 지원하는 오픈소스 플랫폼입니다.

하지만, 위의 정의를 통해서는 쿠버네티스의 의미가 잘 와 닿지는 않습니다. 그렇다면 "왜 쿠버네티스가 필요하게 되었는지, 이전의 플랫폼과는 어떤 차이점이 있는지"를 알아보겠습니다.

🌱 배포 방법의 변화

배포 방법의 변화를 3단계로 구분해 살펴보겠습니다.

1. 전통적인 배포 시대 초기 조직은 애플리케이션을 물리 서버에서 실행했었다. 한 물리 서버에서 여러 애플리케이션의 리소스 한계를 정의할 방법이 없었기에, 리소스 할당의 문제가 발생했다. 예를 들어 물리 서버 하나에서 여러 애플리케이션을 실행하면, 리소스 전부를 차지하는 애플리케이션 인스턴스가 있을 수 있고, 결과적으로는 다른 애플리케이션의 성능이 저하될 수 있었다.

이에 대한 해결책으로 서로 다른 여러 물리 서버에서 각 애플리케이션을 실행할 수도 있다. 그러나 이는 리소스가 충분히 활용되지 않는다는 점에서 확장 가능하지 않았으며, 조직이 많은 물리 서버를 유지하는 데에 높은 비용이 들었다.

2. 가상화된 배포 시대 위 전통적인 배포의 문제점에 대한 해결책으로 가상화가 도입되었다. 이는 단일 물리 서버의 CPU에서 여러 가상 시스템 (VM)을 실행할 수 있게 한다. 가상화를 사용하면 VM간에 애플리케이션을 격리하고 애플리케이션의 정보를 다른 애플리케이션에서 자유롭게 액세스할 수 없으므로, 일정 수준의 보안성을 제공할 수 있다.

가상화를 사용하면 물리 서버에서 리소스를 보다 효율적으로 활용할 수 있으며, 쉽게 애플리케이션을 추가하거나 업데이트할 수 있고 하드웨어 비용을 절감할 수 있어 더 나은 확장성을 제공한다. 가상화를 통해 일련의 물리 리소스를 폐기 가능한(disposable) 가상 머신으로 구성된 클러스터로 만들 수 있다.

각 VM은 가상화된 하드웨어 상에서 자체 운영체제를 포함한 모든 구성 요소를 실행하는 하나의 완전한 머신이다.

3. 컨테이너 개발 시대 컨테이너는 VM과 유사하지만 격리 속성을 완화하여 애플리케이션 간에 운영체제(OS)를 공유한다. 그러므로 컨테이너는 가볍다고 여겨진다. VM과 마찬가지로 컨테이너에는 자체 파일 시스템, CPU 점유율, 메모리, 프로세스 공간 등이 있다. 기본 인프라와의 종속성을 끊었기 때문에, 클라우드나 OS 배포본에 모두 이식할 수 있다.

💡 VM과 Containter의 차이점 VM은 자체 운영체제를 가지고 있지만, 컨테이너는 별도의 운영체제가 필요하지 않습니다.

컨테이너를 통한 배포 방식을 전통적인 배포 방식과 비교해보자면, 하나의 OS위에 프로그램을 여러개 구동시킨 것과 별 차이가 없어보이지만, 중요한 기술적인 차이점이 있습니다.

각 프로그램들이 “이 컴퓨터에서는 나만 구동되고 있다" 라고 판단할 수 있도록, 실제로 두 프로그램간에 간섭을 일으킬 수 없는 장벽을 치고, 동시에 OS는 각 프로그램들이 사용할 수 있는 CPU, 메모리 등의 자원 또한 독립적으로 사용할 수 있도록 할당하고 관리합니다.

물론 OS관점에서 보자면 둘다 OS 상에서 구동되는 프로그램이긴 하지만요. 이와 같은 컨테이너 동작 방식을 OS 커널을 공유하는 가상화 라고 하기도 합니다.

🌱 쿠버네티스의 필요성

도커의 등장으로 컨테이너 기반 배포 방식이 보편화되었고, 많은 서비스들이 도커를 활용하여 이미지로 관리되기 시작했습니다. 이미지가 점점 많아지면서, 관리해야하는 컨테이너와 서버들 또한 많아지게 되었습니다.

그래서 이러한 컨테이너들의 관리를 자동화할 도구(컨테이너 오케스트레이션 툴)의 필요성이 대두되었고, 쿠버네티스 역시 이러한 컨테이너 오케스트레이션 툴 중 하나로, 현재 가장 대중적으로 사용되는 툴입니다. 쿠버네티스는 분산 시스템을 탄력적으로 실행하기 위한 프레임 워크를 제공하며, 애플리케이션의 확장과 장애 조치를 처리하고, 배포 패턴 등을 제공합니다.

🙇🏻‍♂️ 참고

https://velog.io/@holicme7/K8s-%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80

ES6에서 도입된 Iteration Protocol은 iterable한, 즉 순회 가능한 데이터 컬렉션(자료구조)을 만들기 위해 ECMAScript 사양에 정의하여 미리 약속한 규칙입니다.

즉, 이터레이션 프로토콜을 지키는 자료구조를 만들면, 해당 자료구조는 순회가 가능합니다.

💡 ES6, ECMAScript 란?

ES6는 ECMAScript 2015의 줄임말입니다. ECMAScript는 JavaScript의 표준화된 버전을 가리키며, ES6는 ECMAScript의 6번째 버전을 의미합니다. ES6는 JavaScript의 새로운 기능과 문법을 도입하여 개발자들이 코드를 더욱 간결하고 효율적으로 작성할 수 있도록 도와주었습니다. 이전의 JavaScript 버전들보다 더 많은 기능과 개선 사항을 포함하고 있습니다. ES6는 let, const, 화살표 함수, 클래스, 템플릿 리터럴 등의 새로운 기능을 도입하여 JavaScript의 유연성과 표현력을 향상시켰습니다. 그러므로 현대적인 JavaScript 개발에서는 ES6를 기본적으로 사용하는 것이 일반적입니다.

ES6에서는 순회 가능한 데이터 컬렉션을 이터레이션 프로토콜을 준수하는 이터러블로 통일하여 for ... of문, 스프레드 문법, 배열 디스트럭처링 할당의 대상으로 사용할 수 있도록 일원화했습니다.

Iteration Protocol에는 2가지가 존재합니다.

• iterable protocol => 이를 준수한 객체를 iterable라고 부릅니다 .
• iterator protocol => 이를 준수한 객체를 iterator라고 부릅니다.

이에 대해서 자세히 알아보겠습니다.

이터러블

이터러블 프로토콜을 준수한 객체를 이터러블이라고 합니다.

이터러블 프로토콜을 준수하려면 아래 2가지 조건 중 하나를 만족해야 합니다.

• Symbol.iterator를 프로퍼티 키로 사용한 메서드를 직접 구현

• Symbol.iterator를 프로토타입 체인을 통해 상속받은 객체

  ex) 배열은 Array.prototype의 Symbol.iterator 메서드를 상속 받는 이터러블입니다.

  const array = [1, 2, 3];
  console.log(Symbol.iterator in array) // true

이터러블에는 다음과 같은 연산들이 가능합니다.

• for ... of문으로 순회
• 스프레드 문법과 디스트럭처링 할당의 대상으로 사용

위의 두 가지 조건을 모두 만족하지 않는, 즉 이터러블 프로토콜을 준수하지 않는 일반 객체는 for ... of문으로 순회할 수 없고, 스프레드 문법을 사용할 수 없습니다.

이터레이터

이터러블의 Symbol.iterator 메서드를 호출하면 이터레이터 프로토콜을 준수한 이터레이터를 반환합니다. 그리고 이 반환된 이터레이터는next 메서드를 갖습니다.

이터레이터의 next 메서드는 이터러블의 각 요소를 순회하기 위한 포인터의 역할을 합니다. 즉 next 메서드를 호출하면 이터러블을 순차적으로 한 단계씩 순회하며 순회 결과를 나타내는 이터레이터 리절트 객체를 반환합니다.

// 배열은 이터러블 프로토콜을 준수한 이터러블입니다.
const array = [1,2,3];

// 배열의 Symbol.iterator 메서드는 이터레이터를 반환합니다. 
const iterator = array[Symbol.iterator]();

// Symbol.iterator 메서드가 반환한 이터레이터는 next 메서드를 갖습니다. 
console.log('next' in iterator); // true

console.log(iterator.next()); // {value: 1, done: false} 
console.log(iterator.next()); // {value: 2, done: false} 
console.log(iterator.next()); // {value: 3, done: false} 
console.log(iterator.next()); // {value: undefined, done: true} 

이터레이터의 next 메서드가 반환하는 이터레이터 리젙르 객체는 다음 2개의 프로퍼티를 가집니다.

• value 프로퍼티 : 현재 순회 중인 이터러블의 값을 나타냅니다.
• done 프로퍼티 : 이터러블의 순회 완료 여부를 나타냅니다.

빌트인 이터러블

js는 이터레이션 프로토콜을 준수한 객체인 빌트인 이터러블을 제공합니다. 표준 빌트인 객체인 Array, String, Map, Set, TypedArray, arguments, DOM 컬렉션 모두 빌트인 이터러블입니다.

Map과 Set은 엄밀히 독립된 자료형으로, 객체나 배열이 아닙니다. 그럼에도 불구하고 for ... of 문으로 동작하는 이유는 인덱스로 접근하는게 아닌 이터러블 프로토콜을 따르고 있기 떄문입니다.

즉, Symbol.iterator를 프로토타입 체인을 통해 상속받은 객체들이고 각 객체의Symbol.iterator 메서드를 호출해 이터레이터를 반환받을 수 있습니다.

📌 for ... of 문

for ... of 문은 이터러블을 순회하면서 이터러블의 요소를 변수에 할당합니다.

for (변수 선언문 of 이터러블) { ... }

for(let num of numArr) { } 

for ... of 문은 내부적으로 이터레이터의 next 메서드를 호출하여 이터러블을 순회하며 next메서드가 반환한 이터레이터 리절트 객체의 value 프로퍼티 값을 for ... of 문의 변수에 할당합니다.

이터레이터 리절트 객체의 done 프로퍼티 값이 false 이면 이터러블의 순회를 계속하고 true이면 이터러블의 순회를 중단합니다.

for(const item of [1,2,3]){
    console.log(item); // 1 2 3 
}

위의 for ... of 문 코드의 내부 동작을 for문으로 표현하면 아래와 같습니다.

// 이터러블
const arr_iterable = [1,2,3];

// 이터러블의 Symbol.iterator 메서드를 호출하여 이터레이터를 생성한다. 
const iterator = arr_iterable[Symbol.iterator](); 

for(;;){
    const res = iterator.next();

    if(res.done) break;
    console.log(res.value);
}

💡 지금까지의 내용을 정리하면 다음과 같습니다.

• 이터러블 프로토콜을 준수한다는 건 다음 2가지 조건 중 하나를 만족하는 것입니다.
  • Symbol.iterator를 프로퍼티 키로 사용한 메서드를 직접 구현
  • Symbol.iterator를 프로토타입 체인을 통해 상속받은 객체
• 이터러블 프로토콜을 준수한 객체를 이터러블이라고 합니다.
• 이터러블에는 for .. of, 스프레드 문법, 구조분해 할당을 사용할 수 있습니다.
• 이터러블은 Symbol.iterator 메서드를 통해 이터레이터를 반환할 수 있습니다.
• 이터레이터란 이터레이터 프로토콜을 준수한 객체를 말합니다.
• 이터레이터의 next 메서드를 통해 이터러블의 각 요소를 순회할 수 있습니다.

📌 이터러블과 유사 배열 객체

유사 배열 객체는 마치 배열처럼 인덱스로 프로퍼티 값에 접근할 수 있고 length 프로퍼티를 갖는 객체를 말합니다. 유사 배열 객체는 length 프로퍼티를 갖기 때문에 for 문으로 순회할 수 있고, 인덱스를 나타내는 숫자 형식의 문자열을 프로퍼티 키로 가지므로 마치 배열처럼 인덱스로 프로퍼티 값에 접근할 수 있습니다.

const arrayLike = {
    0: 1,
    1: 2,
    2:3,
    length: 3
};

for(let i=0;i<arrayLike.length;i++){
    console.log(arrayLike[i]);
}

하지만 위와 같은 배열은 이터러블이 아닌 일반 객체입니다. 따라서 유사 배열 객체에는 Symbol.iterator 메서드가 없기 때문에 for ... of 문으로 순회할 수 없습니다.

하지만 ES6에서 도입된 Array.from 메서드를 사용하면 위와 같은 유사 배열을 배열로 변환할 수 있습니다.

Array.from은 유사 배열 객체 또는 이터러블을 인수로 전달받아 배열로 변환합니다.

const arrayLike = {
    0: 1,
    1: 2,
    2:3,
    length: 3
};

const arr = Array.from(arrayLike);

console.log(arr); // [1, 2, 3]

📌 사용자 정의 이터러블

위의 내용을 정리하면,

• 이터러블이란 이터레이터를 리턴하는 [Symbol.iterator]() 메서드를 가진 객체입니다.
• 이터레이터란 {value : 값, done: true/false} 형태의 이터레이터 객체를 리턴하는 next() 메서드를 가진 객체입니다.

위 두 가지 내용을 바탕으로, 직접 이터러블 객체를 만들어보겠습니다.

let range = { // 1. 객체 생성
    from: 1,
    to: 5
}

range[Symbol.iterator] = function() { // 2. 객체에 새로운 key: value를 추가
    return { // 3. next() 메서드를 가지는 객체인 이터레이터를 리턴한다. 
        current: this.from,
        last: this.to,

        next(){ // 4. {value : 값, done: true/false} 형태의 이터레이터 리절트 객체를 리턴하는 메서드입니다. 
            if(this.current <= this.last){
                return {done: false, value: this.current++};
            } else{
                return {done: true};
            }
        }   
    }
}

for(let num of range){
    console.log(num); // 1 2 3 4 5
}

• range는 이터러블 객체입니다. Symbol.iterator 메서드를 가지고 있기 때문입니다.

• range의 Symbol.iterator 메서드에서 리턴한 객체가 이터레이터입니다. next() 메서드를 가지는 객체이기 때문입니다.

• range는 이터러블 객체이므로 for ... of 문으로 순회할 수 있습니다.

위 코드는 이터러블 객체를 정의하고, 그 이터러블 객체의 이터레이터를 외부에 정의해주었는데, 이터러블 객체이자 이터레이터 객체 역할을 모두 수행하는 range 객체를 선언해주는 방법도 있습니다.

let range = {
  from: 1,
  to: 5,

  [Symbol.iterator]() { // 생성자
    this.current = this.from;
    this.last = this.to;
    return this; // 자기 자신을 반환. 자기자신엔 next()메소드가 정의되어있으니, next()메소드에서의 this는 생성자로 생성된 객체를 가리키게 된다.
  },

  next() { // 아예 객체안에 next()메서드를 정의.
    if (this.current <= this.to) {
      return { done: false, value: this.current++ };
    } else {
      return { done: true };
    }
  }
};

for (let num of range) {
  alert(num); // 1, 2, 3, 4, 5
}

📌 이터레이션 프로토콜의 필요성

이터레이션 프로토콜은 다양한 데이터 공급자가 하나의 순회 방식을 갖도록 규정하여 데이터 소비자가 효율적으로 다양한 데이터 공급자를 사용할 수 있도록 데이터 소비자와 데이터 공급자를 연결하는 인터페이스의 역할을 합니다.

🙇🏻‍♂️ 참고

• 모던 자바스크립트 Deep Dive - Ch 34 이터러블
• [JS] 📚 이터러블 & 이터레이터

일반적으로 JavaScript는 고전적인 컴파일 언어와는 다르게 코드의 실행과 동시에 한 줄씩 해석하는 인터프리터 언어로 분류됩니다. 하지만 그렇다고해서 컴파일 과정을 거치지 않는 것은 아닙니다. 이에 대해 더 자세히 알아보겠습니다.

📌 컴파일러와 인터프린터의 차이

개발자가 작성한 소스코드를 기계어로 번역하는 방식은 크게 2가지가 있습니다.

컴파일러 방식

컴파일러는 프로그램 전체를 스캔하여 이를 모두 기계어로 번역하고 이를 디스크에 저장합니다. 전체를 스캔하기 때문에 대부분 컴파일러는 초기 스캔 시간이 오래 걸립니다. 하지만 전체 실행 시간만 따지고 보면 인터프리터 보다 빠릅니다. 왜냐하면 컴파일러는 초기 스캔을 마치면 실행파일을 만들어 놓고 다음에 실행할때 이전에 만들어 놓았던 실행파일을 실행하기 때문입니다.

하지만 단점도 존재합니다. 컴파일러는 고급언어로 작성된 소스를 기계어로 번역하고 이 과정에서 오브젝트 코드(Object Code)라는 파일을 만드는데 이 오브젝트 코드를 묶어서 하나의 실행 파일로 다시 만드는 링킹(Linking) 이라는 작업을 해야합니다. 따라서 컴파일러는 통상적으로 인터프리터 보다 많은 메모리를 사용해야 합니다.

또한 컴파일러는 오류 메시지를 생성할때 전체 코드를 검사한 후에 오류 메시지를 생성합니다. 그래서 실행 전에 오류를 발견 할 수 있습니다. 대표적인 언어로 C,C++,JAVA 등이 있습니다.

인터프리터 방식

컴파일러와는 반대로 인터프리터는 프로그램 실행시 한 번에 한 문장씩 번역합니다. 그렇기 때문에 한번에 전체를 스캔하고 실행파일을 만들어서 실행하는 컴파일러보다 실행시간이 더 걸립니다. 한 문장 읽고 번역하여 실행시키는 과정을 반복하는게 만들어 놓은 실행파일을 한번 실행시키는 것보다 빠르긴 힘들 것입니다.

하지만 인터프리터는 메모리 효율이 좋습니다. 컴파일러처럼 목적코드를 만들지도 않고, 링킹 과정도 거치지 않기 때문입니다. 이 때문에 인터프리터는 메모리 사용에 컴파일러 보다 더 효율적입니다.

인터프리터는 오류 메시지 생성과정이 컴파일러와는 다릅니다. 인터프리터는 한 번에 한 문장씩 번역하기 때문에 프로그램을 실행시키고 한 문장씩 번역될때 오류를 만나게 되면 바로 프로그램을 중지합니다 그래서 프로그램을 실행해봐야지만 오류 발견이 가능합니다. 대표적인 언어로 Python, Ruby, Javascript 등이 있습니다.

📌 인터프리터 언어였던 JavaScript

초기에 JavaScript가 개발될 때, 웹 브라우저 상에서 동적인 기능을 제공하기 위한 목적으로 설계되었습니다. 이는 사용자의 브라우저에서 바로 실행될 수 있어야 했기 때문에 인터프리터 방식이 적합했습니다.

위에서 설명했듯이 인터프린터란 한 번에 한 줄씩 번역하여 실행하는 방식입니다. 하지만 JS 코드는 결국 개발자가 작성한 코드이므로, JS 엔진의 인터프리터는 우리가 작성한 console.log("Hello World!"); 같은 코드를 그 자체로 이해할 수는 없습니다. 자바스크립트가 인터프리터에 전해지기 위해서는 일련의 과정을 거쳐야 합니다.

소스코드 => 바이트코드 => 기계어

위와 같이 자바스크립트는 기계에게 전달되기전에 바이트 코드로 변환되어야 합니다. 이 바이트 코드는 가상머신에 의해 기계어로 변환되고 이를 기계가 해석하여 실행하는 것입니다.

그렇다면 JS엔진이 소스 코드를 어떻게 바이트코드로 변환하는지 알아보겠습니다.

소스코드 => Token => AST => 바이트 코드

위 과정을 간단히 말하면 JS 엔진이 소스 코드를 토크나이징, 파싱 과정을 거쳐 AST로 변환하고, 이 AST를 인터프리터가 바이트 코드로 변환합니다.

💡 정리하면,

• 초기 JS는 인터프리터 방식으로 번역되었습니다.
• JS엔진이 소스 코드를 AST로 변환하고, AST를 인터프리터가 바이트 코드로 변환합니다.
• 가상 머신이 바이트 코드를 기계어로 번역해 기계가 이를 실행합니다.

📌 컴파일 과정이 추가된 JavaScript

초기 자바스크립트는 인터프리터 언어였지만, 점차 웹에서도 다양한 요구사항들이 추가되면서 더 많은 기능들을 갖추어야 했고, 이는 자바스크립트가 점차 성능상 무거워지는 계기가 되었습니다. 이를 통해 자바스크립트 언어에서도 실행 전에 내부적으로 컴파일하는 과정이 추가되었습니다.

JS엔진의 컴파일 과정

위에서 살펴본 것 처럼, JS엔진과 인터프리터가 소스 코드를 바이트 코드로 변환한 후에 바이트 코드를 기계어로 변역해 실행합니다. 생성된 바이트 코드를 실행하는 방법에는 2가지 방법이 있습니다.

1. 인터프리터 모드

   초기 JS가 사용했던 방식으로, 인터프리터가 바이트 코드를 하나씩 읽어가며 실행합니다.

2. JIT 모드

   바이트 코드를 native code(기계어)로 컴파일하여 실행하는 방법입니다.

   
   

JIT란?

• 동적 컴파일 과정이라고 불립니다.
• 인터프리터 + 정적 컴파일 방식 (둘을 섞어놓은 느낌)
• 프로그램 실행 시점에서 인터프리터 방식으로 기계어 코드를 생성하면서 그 코드를 캐싱하여, 같은 함수가 여러 번 불릴 때마다 매번 기계어 코드를 생성하는 것을 방지합니다.
• 좀 더 구체적으로 말하면, 실행시점에 바이트 코드를 기계어로 번역하는 역할을 합니다. 바이트코드에서 번역된 기계어는 캐시에 저장되기 때문에 재사용시 다시 번역할 필요가 없습니다. 따라서 코드가 반복된다면 다시 번역하는 과정 없이 재사용할 수 있으므로 시간이 단축됩니다.

정적 컴파일 방식처럼 미리 저장하는 것이 아니라 실행 중에 코드를 번역하고 저장합니다.

인터프리터 VS JIT

💡 그렇다면 JavaScript에서는 인터프리터 모드와 JIT 모드 중에서 어떤 것이 더 효율적일까요?

일반적으로는 JIT 모드가 인터프리터 모드보다 더 효율적입니다. 직관적으로 생각해도 인터프리터 모드로 코드를 한 줄씩 번역해서 실행하는 것보다는 기계어로 미리 번역해둔 것을 수행하는게 더 빠를 것입니다.

정적 컴파일러라면 기계어를 생성하는 도중에 많은 최적화 알고리즘을 사용할 수 있어서 code quality가 높지만, JIT는 컴파일 과정 자체가 실행 중에 발생하기 때문에 이 자체가 오버헤드가 되고, 따라서 컴파일에 많은 시간을 쓸 수 없습니다.

따라서 코드 전체를 읽어서 최적화하는 방식은 당연히 사용할 수 없고, 보통 최소한의 최적화만 적용하여 기계어를 생성합니다. 이렇게 해도 인터프리터 방식보다는 기계어의 수행 성능이 훨씬 낫습니다. 따라서 JIT에 오버헤드가 포함되더라도 인터프리터 모드보다 빠르게 수행되므로 Java VM에서는 JIT를 많이 사용합니다 .

따라서 일반적으로는 인터프리터 모드로 코드를 한줄 한줄 바로 번역해서 실행하는것보다는 JIT모드로 수행하는게 더 빠릅니다.

하지만 JavaScript에서는 그렇지 않습니다. 바로 다음 2가지 이유 때문입니다.

1. JS는 동적 타입 언어이다.

JS는 동적 타입 언어입니다. 즉, 변수의 타입이 실행 중에 변할 수 있고, 프로토타입 기반 방식을 사용하는 등 매우 동적인 특성을 가지기 때문에 JavaScript JIT 컴파일러는 모든 예외적인 케이스를 고려하여 코드를 생성해야합니다.

예를 들어, 2개의 변수를 서로 더하는 코드를 생각해보겠습니다. 이 때에도 모든 예외 케이스를 고려하면 상당히 많은 양의 native code가 생성됩니다.

=> 변수가 모두 int형일 경우 / 하나라도 int형이 아닐 경우 / 더하고 나니 int 범위를 벗어나는 등 많은 예외 케이스가 존재합니다 .

이렇게 예외 케이스가 발생하게 되면 slow case로 점프하게 됩니다.

💡 slow case란?

native code로 생성하기 어려운(native code로 표현하면 양이 많아지는) 동작들을 native code로 뽑아내는 대신 미리 엔진 내부에 C로 구현된 helper function을 호출하여 동작을 수행하는 경우를 의미합니다.

그런데 이런 helper function들은 인터프리터 모드로 수행할 때와 동일한 코드를 사용하게 됩니다. JIT 컴파일러로 native code를 수행한다 해도 많은 부분이 인터프리터를 사용할때와 차이가 없게 되는 것입니다. 오히려 컴파일 오버헤드(native code를 생성해야하는)가 더해지므로 JavaScript에서 JIT는 Java에서보다 훨씬 비효율적입니다.

2. JS는 hotspot이 상대적으로 적다.

JavaScript는 주로 웹페이지의 layout을 조작하거나 사용자 입력에 반응하는 방식의 코드가 많습니다. 따라서, JS는 자주 반복되어서 수행되는 구간인 hotspot이 상대적으로 매우 적습니다.

이러한 경우 native code를 수행하는 시간에 비해, native code를 만드는 시간, 즉 컴파일 오버헤드가 상대적으로 커지게 되는 문제가 있다. 코드가 골고루 실행되기 때문에 컴파일해야하는 코드의 양이 많아지는 것입니다.

결과적으로 "컴파일 오버헤드 + native code가 인터프리터보다 빠르다"라는 JIT의 사용이유가 무의미해지는 상황입니다. (실제 JavaScript JIT가 성능 향상에 기여하는 바가 거의 없다는 연구도 진행된 바 있다고 합니다.)

💡 정리하면,

JIT는 정적컴파일에 비해 최적화를 많이 할 수 없어서 정적컴파일보다 느립니다. 하지만 그래도 인터프리터보다 빠르기 때문에 Java에서는 JIT를 사용합니다.

하지만 JavaScript는 1. 동적언어 + 2. hotspot이 적다는 특성 때문에 JIT가 인터프리터보다 빠르다고 할 수 없습니다.

따라서, JavaScript 코드는 JIT 보다 인터프리터로 수행하는 것이 낫습니다.

하지만 이번 문단의 상단에서도 말했듯, 최근에는 JavaScript가 단순히 웹에서 이벤트 처리 용도로만 사용되는 것이 아니라 그 사용 용도가 다양해지면서 점차 연산이 많아지는 프로그램에도 충분히 사용되고 있기에, JIT 방식을 완전히 외면할 수는 없다고 합니다.

따라서 최근에는, 고전적인 방식의 JavaScript코드(hotspot이 많이 없는)와 연산 중심의 코드들의 수행 성능을 모두 만족시키는 방식인 Adaptive JIT 방식을 사용합니다.

📌 Adaptive JIT

Adaptive JIT Compilation

• 실행 초기에는 인터프리터 방식으로 실행하고 자주 호출되는 메소드나 반복되는 코드를 검출하여 이러한 코드만 컴파일하는 방식

• JIT 컴파일러의 단점을 보완하기 위한 방식으로, 코드가 사용되었을때 즉시 컴파일하는 것이 아니라 여러번 호출 된 후 지연시켜 컴파일을 수행하는데 이를 Lazy Compilation이라 합니다.

• 실행시간의 대부분을 소비하는 코드만 컴파일하여 효율적으로 실행속도를 향상시킬 수 있습니다.

JIT는 코드가 실행되면 이를 저장하지만 Adaptive Compiliation은 자주 사용되는 코드만 저장하는 것

기본적으로 모든 코드는 처음에 인터프리터로 해석합니다. 그러다가 자주 반복되는 부분(hotspot)이 발견되면, 그 부분에 대해서만 JIT를 적용하여 native code로 변환합니다.

따라서, 인터프리터가 생성한 바이트 코드에 최적화된 컴파일을 진행하는 방식입니다.

🙇🏻‍♂️ 참고

자바스크립트 엔진의 최적화 기법 (1) - JITC, Adaptive Compilation

자바스크립트는 Compiler / Interpreter 언어다?

컴파일러(compiler)와 인터프리터(interpreter)의 차이

우리는 리액트를 이용해 웹을 개발하며 렌더링, 리렌더링이라는 표현을 굉장히 자주 사용합니다. 하지만 리액트 컴포넌트의 렌더링과 브라우저의 렌더링은 분명히 서로 다릅니다. 이 글은 그 차이에 대해서 설명합니다.

📌 브라우저에서의 렌더링

브라우저에서의 렌더링 과정을 설명해주세요.

위 질문은 아마 프론트엔드에서 기본적인 면접 질문 중 하나일 것입니다. 아마 많은 분들이 이미 알고 계시듯이, 브라우저에서의 렌더링 과정은 다음과 같습니다.

브라우저 렌더링 과정은 CRP(Critical Redering Path)라는 일련의 과정을 통해 진행됩니다. 그 과정을 요약하면 다음과 같습니다.

1. HTML 파싱을 통한 DOM 생성

2. CSS 파싱을 통한 CSSOM 생성

3. DOM 트리와 CSSOM 트리를 결합해 렌더 트리 생성

4. layout 과정 실행

5. paint 및 composite 과정 실행

📌 리액트에서의 렌더링

위에서 살펴본 브라우저의 렌더링과 리액트에서의 렌더링은 그 의미와 사용되는 상황이 사뭇 다릅니다.

일반적으로 우리가 "렌더링" 이라는 단어를 생각할 때, 무엇인가를 화면에 그리는 작업을 떠올릴 수 있지만, React에서의 렌더링은 오히려 화면에 무엇인가를 그리기 전 어떤 과정을 시작하는 듯한 느낌에 가깝습니다.

💡 React에서의 렌더링이란 => 컴포넌트가 state와 props를 기반으로 어떻게 UI를 구성하고 이를 바탕으로 어떤 dom 결과를 브라우저에게 제공할 것인지를 계산하는 일련의 과정을 말합니다.

React에서의 렌더링은 DOM 업데이트를 의미하지 않습니다. 즉, React에서의 렌더링은 실질적 화면 업데이트를 말하는 것이 아닙니다.

리액트 렌더링 과정

React가 UI를 어떻게 구성할 지 컴포넌트에 요청하는 과정, 즉 React에서의 렌더링 과정은 총 3단계로 나눌 수 있습니다.

1. Trigger - 렌더링을 트리거
2. Rendering - 컴포넌트를 렌더링
3. Commit - DOM에 커밋

1. Trigger

React가 데이터가 변경되었는지를 확인하는 과정입니다. 컴포넌트의 state가 변경되었다면 렌더링이 Trigger됩니다. 이는 Object.is() 메서드를 통해 state 값이 불변성을 지키고 있는지를 확인하는 과정입니다.

렌더링을 Trigger하는 경우는 다음과 같습니다.

1. state 변경

   컴포넌트의 state가 변경될 때마다 해당 컴포넌트는 리렌더링됩니다. setState 함수를 호출하여 state를 변경하면, React는 새로운 state를 이용해 컴포넌트를 리렌더링합니다.

2. props 변경

   컴포넌트가 받는 props가 변경되면 해당 컴포넌트는 리렌더링됩니다. 이것은 부모 컴포넌트로부터 props를 받는 모든 자식 컴포넌트에 적용됩니다.

3. 부모 컴포넌트 리렌더링

   부모 컴포넌트가 리렌더링되면 그의 모든 자식 컴포넌트들도 리렌더링 됩니다. 부모 컴포넌트의 state나 props가 변경되면 부모 컴포넌트는 리렌더링되며, 이에 따라 모든 자식 컴포넌트들도 리렌더링 됩니다.

4. Context 변경

   React Context API를 사용하면 컴포넌트 트리 내에서 전역적으로 데이터를 공유할 수 있습니다. Context에 변경이 생기면 그를 구독하는 모든 컴포넌트는 리렌더링됩니다.

5. Force Update

   forceUpdate 메서드를 사용하면 컴포넌트는 강제로 리렌더링 될 수 있습니다. 하지만 이 방법은 가능한 한 피해야 합니다. 대부분의 경우 state나 props의 변경으로 리렌더링을 처리할 수 있기 때문입니다.

2. Rendering

크게 Reconciliation과 Batching 과정으로 나뉩니다.

Reconciliation(재조정)

렌더링이 Trigger되면, 화면에 표시될 새로운 가상 DOM을 만듭니다. 그리고 이전 가상 DOM과 새로운 가상 DOM을 비교해 달라진 부분을 찾아내 어떤 부분을 실제 DOM에 업데이트할 지 결정합니다.

이전 가상 DOM과 새로운 가상 DOM을 비교할 때, Diffing 알고리즘이 사용됩니다. Diffing 알고리즘은 아래와 같은 작업을 합니다.

• React Element의 타입(JSX 태그 종류) 비교
• 타입이 동일할 경우 속성(attribute) 비교
• key 값 비교
• 재귀적으로 자식 Element 비교

💡 Diffing 알고리즘을 사용해 이전 가상 DOM과 새로운 가상 DOM을 비교하는 이유는 ?

=> 굳이 리렌더링 되지 않아도 되는 부분은 제외시키고 변경되어야 하는 부분만 변경하기 위해서입니다.

Batching

Reconciliation에서 상태 업데이트로 인해 실제 DOM에 업데이트할 작업들을 결정한 후 이를 다음 단계인 Commit 단계로 넘길 때, 한 번에 묶어서 넘깁니다.

즉, React는 렌더링을 최소한으로 발생시키기 위해 작업을 한 번에 묶어서 Batching(일괄 처리) 합니다.

💡 Batching을 통해 얻을 수 있는 이점은?

Commit 단계 이후, 브라우저의 렌더링 과정이 이루어집니다. 브라우저의 렌더링 과정 중 layout, painting 과정은 요소가 변경되거나 레이아웃이 변경되었을 때 다시 실행되는 과정인데 이는 비용이 비싼 작업입니다.

layout이 다시 발생하는 것을 reflow라고 부르는데 이는 paint가 다시 일어나는 과정인 repaint보다 비싼 작업입니다. 따라서 만약 React에서 setState를 호출할 때마다 리렌더링이 일어나게 되면, repaint와 reflow가 계속해서 발생되고 이는 비효율적일 것입니다.

따라서, 연속적인 상태의 변화가 있을 때 Batching을 통해 리렌더링이 한 번만 일어나도록 하는 것입니다.

3. Commit

Rendering에서 재조정된 가상 DOM을 실제 DOM에 적용하고 라이프사이클을 실행하는 단계입니다.

여기서도 DOM에 마운트 된다는 뜻이지 paint 된다는 뜻이 아닙니다. 이 단계는 항상 일관적 화면 업데이트를 위해 동기적으로 실행됩니다. 동기적으로 실행된다는 것은 콜 스택을 비우지 않고, DOM 조작을 Batching 처리 한다는 뜻입니다.

Commit 단계가 끝나면 그제서야 브라우저는 실제 DOM을 업데이트하며 화면을 그려줍니다. 즉, 이 과정이 바로 브라우저에서의 렌더링 과정입니다.

💡 해석에 따라 Commit 단계 이후에 브라우저 렌더링 과정이 일어난다고 보기도 하고, Commit 단계 내에 브라우저 렌더링 과정을 포함해서 보는 관점도 있는 것 같습니다.

💡 리액트의 렌더링이 일어난다고 해서 무조건 브라우저 렌더링(DOM 엡데이트)가 일어나는 것은 아닙니다.

• 렌더링을 수행했으나 Commit 단계까지 갈 필요가 없다면, 즉 변경 사항을 계산했는데 아무런 변경 사항이 감지되지 않는다면 이 Commit 단계는 생략될 수 있습니다.
• 즉 리액트의 렌더링은 꼭 가시적인 변경이 일어나지 않아도 발생할 수 있습니다. 렌더링 과정 중 Render 단계에서 변경 사항을 감지할 수 없다면 Commit 단계가 생략되어 브라우저의 DOM 업데이트가 일어나지 않을 수 있습니다.

즉, 이를 정리하면 다음과 같습니다.

• 리액트의 렌더링 과정에는 Trigger, Rendering, Commit 단계로 이루어져 있습니다.
• state가 변경되어 DOM 업데이트가 필요한 작업만 Batching 처리되어 Commit 단계로 전달됩니다.
• Commit 후에 브라우저 렌더링이 일어납니다.

🙇🏻‍♂️ 참고

React 렌더링과정으로 알아보는 선언적이라는 의미

[번역] 리액트에 대해서 그 누구도 제대로 설명하기 어려운 것 – 왜 Virtual DOM 인가?

평소에 자주 사용해오던 리액트 Hook을 전체적으로 정리해본 적은 없어서 이번 기회에 한 번 전체적으로 정리해보려고 합니다🫠

📌 리액트 훅이란 ?

React에서는 16.8 버전부터 Hook이란 개념이 새로 추가되었습니다. Hook은 함수형 컴포넌트에서 React state와 생명주기 기능을 연동할 수 있게 해주는 함수입니다.

리액트에서 제공하는 내장 훅(useState, useEffect, ... ) 과 사용자가 직접 정의할 수 있는 Custom Hooks가 있습니다.

어떤 문제를 해결할 수 있나요?

함수형 컴포넌트에 Hook이 나오기 전까지는, 일반적으로 클래스형 컴포넌트를 많이 사용했습니다. 하지만 클래스형 컴포넌트에서 상태(state)를 사용하고, 생명주기 메서드를 사용하는 방식은 많은 문제들과 불편함을 가지고 있었습니다.

1. 컴포넌트 간의 상태 로직을 재사용하기 어렵다.

2. 복잡한 컴포넌트들의 이해가 어렵다.

   => render props나 HOC(Higher Order Component)와 같은 패턴들

3. Class 문법 자체(ex) Class 함수 내에서의 this)가 어렵다.

이러한 문제들을 해결할 수 있는 함수형 컴포넌트에서의 Hook이 등장했습니다!

1. 컴포넌트 간의 계층을 바꾸지 않고 상태 로직을 재사용할 수 있습니다.
2. 하나의 컴포넌트를 생명주기가 아닌 기능을 기반으로 하여 작은 함수 단위로 나눌 수 있습니다.
3. Class 문법 없이도 React 기능을 사용할 수 있게끔 해준다.

훅 규칙

1. 같은 훅을 여러 번 호출할 수 있습니다.

   function Form() {
     // useState 여러번 호출 가능
     const [name, setName] = useState('Mary');
     const [surname, setSurname] = useState('Poppins');
   
     // 이하 생략

2. 컴포넌트 최상위(at the top level)에서만 호출할 수 있습니다. 반복문, 조건문, 중첩된 함수 내에서 훅을 사용할 수 없습니다.

   => 컴포넌트 최상위에서 훅을 호출하면, 컴포넌트가 렌더링 될 때마다 항상 동일한 순서로 Hook이 호출되는 것이 보장됩니다.

   이는 React가 useState와 useEffect 등의 훅이 여러 번 호출되는 중에도 훅의 상태를 올바르게 유지할 수 있도록 해줍니다.

   훅의 호출 순서가 같아야 하는 이유는?

   => React가 특정 state가 어떤 useState 호출에 해당하는지 알 수 있는 이유는 React가 Hook이 호출되는 순서에 의존하기 때문입니다. 모든 렌더링에서 Hook의 호출 순서는 같기 때문에 state를 구분할 수 있습니다. 더 자세한 내용은 여기를 참고해주세요.

3. Hook은 React 함수 내에서만 호출할 수 있습니다. 리액트 훅은 함수형 컴포넌트에서 호출해야하며, 추가적으로 custom hooks에서 또한 호출할 수 있습니다.

4. 비동기 함수(async 키워드가 붙은 함수)는 콜백함수로 사용할 수 없습니다.

   export default function App(){
     // useEffect Hook 내부에 비동기 함수가 들어가므로 에러 발생
     useEffect(async () => {
       await Promise.resolve(1)
     }, [])
   
     return {
       <div>
         <div>Test</div>
       </div>
     }

   ❓ 그 이유는?

📌 리액트 훅의 종류

리액트는 기본적으로 컴포넌트 상태를 관리할 수 있는 useState와 컴포넌트 생애주기에 개입할 수 있는 useEffect , 컴포넌트 간의 전역 상태를 관리하는 useContext 훅을 제공하고 있습니다. 추가로 제공하는 Hook은 기본 Hook의 동작 원리를 모방해서 만들어졌습니다.

추가적인 훅들의 기본적인 역할은 다음과 같습니다.

• useReducer : 상태 업데이트 로직을 reducer 함수에 따로 분리합니다.
• useRef : 컴포넌트나 HTML 엘리먼트를 레퍼런스로 관리합니다.
• useImperativeHandle : useRef의 레퍼런스를 상위 컴포넌트로 전달합니다.
• useMemo, useCallback : 의존성 배열에 적힌 값이 변할 때만 값 또는 함수를 다시 정의합니다.
• useLayoutEffect : 모든 DOM 변경 후 브라우저가 화면을 그리기 이전 시점에 effect를 동기적으로 실행합니다.
• useDebugvalue : 사용자 정의(custom) Hook의 디버깅을 도와줍니다.

📌 useState

리액트 훅의 기본이자 가장 많이 사용하는 훅인 useState는, 컴포넌트의 상태(state)를 관리할 수 있는 훅입니다.

const [number, setNumber] = useState(1);

위 코드에서는 number 라는 상태를 useState 훅을 통해 관리하고 있습니다. useState 훅의 인자로 전달된 1 이라는 값이 number의 초기값이 되고, 훅을 통해 반환되는 [number, setNumber]에서 number를 통해 상태의 값에 접근할 수 있고, setNumber 메서드를 호출함으로써 상태 값을 변경할 수 있습니다.

상태값 변경시 리렌더링 발생

const [number, setNumber] = useState(1);
setNumber(2);

useState 에서 반환된 배열의 두번째 값인 setter 함수를 호출하면 상태 값을 변경할 수 있고, 상태 값이 변경되면 해당 컴포넌트는 다시 렌더링됩니다.

=> useState(초기값)에서 인자로 전달된 값을 상태의 초기값으로 사용합니다. 하지만 이후 setter 함수에 의해 상태의 값이 변경되었다면, 다음 렌더링에서는 그 상태를 유지합니다.

setState 호출 => 상태 변경 => 리렌더링(변경된 상태값 사용)

useState 이것만은 알고 쓰자 => useState의 기본적인 사용법 외에도 useState 사용 시 주의할 점에 대해 자세히 정리한 글입니다.

📌 useEffect

컴포넌트 내의 상태의 변화가 있을 때, 이를 감지하여 특정 작업을 해줄 수 있는 훅입니다.

일반적으로 sideEffect의 처리를 위해서 사용된다고 말합니다.

sideEffect란?

=> 컴포넌트가 화면에 렌더링된 이후에 비동기로 처리되어야 하는 부수적인 효과들을 말합니다. 예를 들어 API를 호출하는 경우 데이터를 비동기적으로 가져와야 하는데, 만약 그렇지 않다면 데이터를 가져오는 시간 동안 렌더링이 지연될 수도 있기 때문입니다.

sideEffect란 다음과 같은 경우를 모두 포함합니다.

• 함수에서 함수 안의 내용물만으로 결과값을 만드는 것 외에 다른 행위들
• 함수의 output를 만들기 위해 외부에 값을 사용하는 것
• 외부 변수를 함수 안에서 변경시키는 것

사용 방법

useEffect(()=>{
   // 
}, []) // 의존성 배열

useEffect의 두번째 인자로 어떤 값을 전달하는 지에 따라, 첫번째 인자로 전달된 콜백 함수(effect)가 언제 실행되는 지가 결정됩니다.

1. 아무것도 전달하지 않으면

useEffect(()=>{

}) // 아무것도 전달 x

기본적으로는 첫 렌더링(마운트)과 그 이후의 모든 업데이트에 대해서 effect를 수행하게 됩니다. 이는 클래스 컴포넌트의 componentDidMount, componentDidUpdate를 합쳐놓은 것과 같습니다.

=> 불필요한 렌더링을 줄이고 싶다면 useEffect의 두 번째 인자인 의존성 배열 을 넣어주면 됩니다.

2. 빈 배열 [] 전달 시,

useEffect(() => {
  console.log("Component Loaded");
}, []);
// 컴포넌트가 마운트 됐을때만 실행된다. (componentDidMount)

맨 처음 컴포넌트 생성 시, 즉 마운트 될 때만 실행됩니다.

=> 물론, 마운트 될 때 실행된다는 것의 의미는 마운트 시 발생하는 렌더링 이후에 실행된다는 의미입니다.

3. 변수 전달 시, [count]

useEffect(() => {
  document.title = `You clicked ${count} times`;
}, [count]);
// count가 바뀔 때만 effect를 재실행

맨 처음 마운트 되었을 때와, count state의 값이 바뀔 때만 실행됩니다.

clean up

useEffect(()=>{
    console.log("Component Loaded");
    const handleScroll = () => {
        console.log(window.scrollY);
    };

    document.addEventListener("scroll", handleScroll);

    return () => document.removeEventListener('scroll', handleScroll);
}, []);

window에 스크롤에 대한 event를 등록하고, 컴포넌트가 사라질 때, 이를 해제해줄 수 있습니다.

=> useEffect 안의 첫 번째 인자인 콜백함수 내 return 문은 해당 컴포넌트가 제거될 때(unmount될 때) 실행됩니다.

❓ 왜 컴포넌트가 제거 될 때 return 문이 실행될까?

=> useEffect는 원래 컴포넌트가 살아있는 동안 컴포넌트 내 특정 변수나 상태가 변화될 때마다 실행되야 하므로, 이를 감지하기 위해서는 컴포넌트가 살아있는 동안 계속 감지하면서 있다가, 컴포넌트가 제거될 때 return 하는 건가 ?

=> 의존성 배열로 아무것도 전달하지 않던, []를 전달하던, [count]를 전달하던, useEffect 내의 return 문은 무조건 컴포넌트가 제거(unmount) 될 때 한번만 실행됩니다.

useEffect 실행 타이밍

useEffect로 전달된 함수는 컴포넌트 렌더링 - 화면 업데이트 - useEffect 함수 실행 순으로 실행됩니다. 즉, useEffect실행이 최초 렌더링 이후 에 된다는 것을 유의해야합니다.

만약 화면을 다 그리기 이전에 동기화 되어야 하는 경우에는, useLayoutEffect()를 활용하여 컴포넌트 렌더링 - useLayoutEffect 실행 - 화면 업데이트 순으로 effect를 실행시킬 수 있습니다.

📌 useRef

2가지 경우에 useRef를 사용할 수 있습니다.

1. DOM에 직접 접근할 때 사용합니다.

   => 리액트는 DOM으로의 직접 접근을 막고 있기 때문에 ref 를 통해 접근해야합니다.

2. 변수의 값이 변하더라도 리렌더링을 유발하고 싶지 않을 때 사용합니다.

   => ref 안에 저장되어 있는 값이 변경되어도 컴포넌트는 다시 렌더링되지 않습니다. 또한, 컴포넌트가 아무리 렌더링 되어도 ref 안에 저장되어 있는 값은 변화되지 않고 그대로 유지됩니다.

   => ref의 값은 컴포넌트의 전 생애주기를 통해 유지되기 때문입니다. 컴포넌트가 브라우저에 마운팅 된 시점부터 마운트가 해제될 때까지 같은 값을 계속해서 유지할 수 있습니다.

   => 변경 시 렌더링을 발생시키지 말아야 하는 값을 다룰 때 편리합니다.

   useState를 통해 생성된 state는 그 값이 변경될 때마다 다시 렌더링됩니다.

   VS

   useRef는 값이 변경되더라도 다시 렌더링되지 않습니다.

1. dom에 접근

const inputRef = useRef();

<input ref = {inputRef}/>

그럼 이제 inputRef.current로 input 태그에 접근할 수 있습니다.

하위 컴포넌트의 dom에 접근하고 싶다면

EX)

App 컴포넌트에서 => 하위 컴포넌트인 Input 컴포넌트의 dom에 접근하고 싶다면,

=> App 컴포넌트에서 Input 컴포넌트의 dom에 ref를 통해 접근할 수 있다.

=> forwardRef 이용

function App() {
    const inputRef = useRef(); // useRef 선언

    return (
        <div>
            <Input ref={inputRef}/> // ref 전달 
            <button onClick={()=>inputRef.current.focus()}> Focus </button>
        </div>
    );
}

const Input = React.forwardRef(( _, ref ) => {
    return (
    <>
        Input: <input ref={ref} />
    </>
    );
});

export default Input;

2. 리렌더링 유발하지 않는 변수로 사용

useRef 함수는 current 속성을 가지고 있는 객체를 반환하는데, 인자로 넘어온 초기값을 current 속성에 할당합니다. 이 current 속성은 값을 변경해도 상태를 변경할 때 처럼 React 컴포넌트가 다시 랜더링되지 않습니다. React 컴포넌트가 다시 랜더링될 때도 마찬가지로 이 current 속성의 값이 유실되지 않습니다.

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

function ManualCounter() {
  const [count, setCount] = useState(0);
  const intervalId = useRef(null);
  console.log(`랜더링... count: ${count}`);

  const startCounter = () => {
    intervalId.current = setInterval(
      () => setCount((count) => count + 1),
      1000
    );
    console.log(`시작... intervalId: ${intervalId.current}`);
  };

  const stopCounter = () => {
    clearInterval(intervalId.current);
    console.log(`정지... intervalId: ${intervalId.current}`);
  };

  return (
    <>
      <p>자동 카운트: {count}</p>
      <button onClick={startCounter}>시작</button>
      <button onClick={stopCounter}>정지</button>
    </>
  );
}

위의 예제에서는 intervalId라는 data가 렌더링 시마다 변하지 않도록 하고 싶습니다. 그래서 ntervalId를 useRef 훅을 이용해 초기화해주었습니다.

❓ useRef 작동 원리 알아보기

useRef는 선언된 컴포넌트 내에서 그냥 변수에 값을 할당하는 게 아니라, 변수에 참조값을 할당하고, 그 참조값이 값을 가리키고 있어서, 즉 한 단계 더 거쳐서 저장해서 값이 변하더라도 참조값은 변하지 않으므로 그래서 렌더링이 일어나지 않는 것 아닐까

=> const intervalId = useRef(null)에서 IntervalId가 참조값이고, intervalId.current를 통해 그 실제 값을 접근할 수 있는 것 같다 !

📌 useMemo, React.memo

useMemo

원래, 컴포넌트 내의 변수는 리렌더링 시에 다시 정의됩니다. 하지만 useMemo를 사용하면, 매 리렌더링 시마다 다시 정의되는 것이 아니라, 특정 값이 변할 때만 정의됩니다.

즉, useMemo는 변수의 최적화를 위한 훅입니다.

컴포넌트는 사실 함수입니다. 즉, 컴포넌트란 JSX를 반환하는 함수에 불과합니다. 컴포넌트가 렌더링 된다는 것은 누군가가 이 함수 컴포넌트를 호출해서 실행하는 것을 의미합니다. 이는 함수가 실행될 때마다 내부에 선언되어있던 변수, 함수 등이 매번 다시 선언되거나 다시 실행이 된다는 것을 의미합니다.

컴포넌트가 리렌더링 되는 조건

1. 컴포넌트의 state가 변경

2. 컴포넌트의 props가 변경

3. 부모 컴포넌트 리렌더링

   => 부모 컴포넌트가 리렌더링될 때 새로운 prop이 들어오지 않더라도 부모 컴포넌트가 리렌더링되면 자식 컴포넌트 역시 리렌더링 된다.

만약 컴포넌트를 최적화하지 않는다면, 부모 컴포넌트가 변경되기만 하더라도 리렌더링 될 수 있음을 의미합니다. 그리고 리렌더링 시, 연산이 많이 걸린다면 이는 비효율적일 것입니다. 따라서 이를 useMemo를 사용함으로써 해결이 가능합니다.

사용 예시

const ShowSum = ({label, n]}) => {
   // const result = sum(n);

   const result = useMemo(()=>sum(n), [n]);

   return (
       <span>
           {label}: {result}
    </span>
   )
}

export default ShowSum;

기록해 둘 표현식인 sum(n) 을 적어두고, 어떤 값이 변할 때만 이를 다시 변경할 것인지를 [ ] 안에 넣어줌 => [n] => n 값이 변할 때만 다시 계산

prop인 label의 값이 계속 바뀐다면, 바뀔 때마다 컴포넌트는 계속 리렌더링되지만, 대신 result는 렌더링 시마다 계산하지 않는 것

=> 의존성 배열에 들어있는 n 이 변할 때만 다시 계산

=> 즉, 특정 변수를 언제 다시 계산(정의)할 것인지를 지정해줄 수 있습니다.

그럼 useMemo를 이용한 변수는 state 인가 ?

useMemo를 사용하여 선언된 변수는 컴포넌트의 state와는 조금 다릅니다. useMemo는 메모이제이션된 값을 반환하는 훅으로, 특정 값이나 연산의 결과를 기억하여, 의존성이 변경되지 않으면 이전에 계산된 값을 재사용합니다.

컴포넌트의 상태(State)는 useState 훅을 사용하여 관리되며, 상태가 변경되면 컴포넌트가 리렌더링됩니다. useMemo는 주로 계산 비용이 높은 연산의 결과를 저장하고 싶을 때 사용됩니다. 이 때, 의존성 배열(dependency array)을 통해 해당 값이 의존하는 변수가 변경될 때만 다시 계산됩니다.

요약하면, useMemo로 선언된 변수는 상태(State)가 아니며, 컴포넌트의 리렌더링과 직접적인 관련이 없습니다. 대신, 특정 값을 메모이제이션하여 필요할 때만 계산을 수행하는 용도로 사용됩니다.

React.Memo

useMemo 훅과 비슷하지만 약간 다른 개념인 React.memo에 대해서도 알아보겠습니다.

위에서 컴포넌트가 리렌더링 되는 조건을 살펴봤습니다.

컴포넌트가 리렌더링 되는 조건

1. 컴포넌트의 상태가 변경
2. 부모로부터 받는 props가 변경
3. 부모 컴포넌트의 상태가 변경

위에서 알 수 있는 건, 부모 컴포넌트의 상태가 변경되기만 하더라도 자식 컴포넌트가 리렌더링 될 수 있다는 것입니다. 하지만, 부모 컴포넌트의 상태만 변경되고 자식 컴포넌트는 변경된 것이 없는데, 리렌더링된다면 이는 비효율적일 것입니다.

여기서 React.memo를 사용한다면, 부모 컴포넌트의 상태가 변경되더라도 자식 컴포넌트가 변경되지 않았을 경우 자식 컴포넌트의 리렌더링을 막을 수 있습니다.

사용 예시

단순히 함수 컴포넌트 식을 React.memo() 로만 감싸주면서 사용할 수 있습니다.

Box.jsx

const Box = React.memo(()=>{
    console.log("Box 컴포넌트 렌더링");
    return <div/>
})

export default Box;

App.jsx

function App(){
    const [count, setCount] = useState(0);

    return (
        <div>
            {count}
            <button onClick={()=>setCount(count+1)}>+</button>
            <Box/>
        </div>
    )
}

export default App;

=-> 만약 React.memo를 사용하지 않았다면 button 클릭으로 인해 부모 컴포넌트의 상태인 count 값이 증가할 때마다, 자식 컴포넌트인 Box 컴포넌트가 리렌더링되어 console.log("Box 컴포넌트 렌더링");가 계속 찍혔을 것입니다.

📌 useCallback

컴포넌트가 렌더링 될 때마다 함수가 재정의되지 않고, 의존성 배열 내의 값이 변할 때만 재정의되도록 만들어주는 훅입니다.

위에서도 말했듯이, 컴포넌트가 렌더링 된다는 것은 컴포넌트 함수가 다시 호출되는 것이고, 그 안의 함수도 다시 정의됩니다.

하지만, 함수가 재정의된다면 함수는 객체 타입이므로 그 참조값이 바뀔 것입니다. 이 때, 함수가 다시 정의되는 것을 막기 위해 useCallback 훅을 사용할 수 있습니다.

함수가 재정의되는 것을 막아줌으로써, 이 함수가 하위 컴포넌트에게 prop으로 전달된다면 그 하위 컴포넌트의 리렌더링도 방지할 수 있습니다.

=> 참조값이 변하지 않기 때문에 prop으로 전달되는 값도 변하지 않습니다.

사용 예시

CheckBox.jsx

const CheckBox = React.memo(({ label, on, onChange})) => {
  console.log(label, on);
  return (
    <label>
      {label}
      <input type="checkbox" defaultChecked={on} onChange={onChange}/>
    </label>
  )
}

export default CheckBox;

App.jsx

function App(){
  const [foodOn, setFoodOn] = useState(false);
  const [clothesOn, setClothesOn] = useState(false);
  const [shelterOn, setShelterOn] = useState(false);

  const foodChange = useCallback((e)=> setFoodOn(e.target.checked), []);
  const clothesChange = useCallback((e)=> setClothesOn(e.target.checked), []);
  const shelterChange = useCallback((e)=> setShelterOn(e.target.checked), []);

  return (
    <div>
      <CheckBox label="Food" on={foodOn} onChange={foodChange} />
      <CheckBox label="Clothes" on={clothesOn} onChange={clothesChange} />
      <CheckBox label="Shelter" on={shelterOn} onChange={shelterChange} />
    </div>
  )
}

export default App;

• Food check box의 체크를 눌렀을 때, props로 전달된 onChange인 foodChange가 실행되고, 이를 통해 App 컴포넌트의 state인 foodOn이 변경될 것입니다.

• App 컴포넌트의 state가 변경되었으므로, App 컴포넌트는 다시 렌더링 될 것입니다. 여기서 만약 useCallback으로 각 함수 foodChange, clothesChange, shelterChange를 감싸주지 않았다면, 이 함수들은 모두 재정의 될 것입니다.

• 또한, 이 함수들은 자식 컴포넌트들에게 props로 전달되고, 각 자식 컴포넌트 입장에서는 props가 변경된 것이기 때문에 자식 컴포넌트들도 리렌더링될 것입니다.

  => React.memo로 감쌋지만, props가 변경되는 것이므로 렌더링됩니다.

• 하지만 useCallback으로 각 함수를 감싸줬기 때문에, App 컴포넌트 내의 함수들인 foodChange, clothesChange, shelterChange은 App 컴포넌트가 리렌더링되어도 재정의되지 않습니다.

💡

useCallback 을 사용할 때 , 2번째 인자에 defendency array 를 넘기고, setData 로 state를 초기화 해줄 때, 함수형 업데이트로 초기화를 해주어야 합니다.

함수형 업데이트로 초기화를 해주어야, defenden array를 비워도 항상 최신의 state를 함수형 업데이트의 인자를 통해서 참조할 수 있게 됩니다.

🙇🏻‍♂️ 참고

[React] React Hooks 정리

React Hooks 이해하기

React Hooks: useRef 사용법

프로토타입이란 무엇일까요? 프로토타입에 대한 일반적인 설명은 아마 다음과 같을 것입니다.

프로토타입이란,

다른 객체의 원형이 되는 객체로서, 객체 간의 상속을 가능하게 합니다.

하지만 위의 설명은 저에게 프로토타입은 무엇이고 왜 생겨났는지, JS는 왜 클래스가 아닌 프로토타입 기반으로 설계되었는지 등의 질문에 대한 명확한 대답이 되지 못했습니다. 여러 글을 찾아보다가, 자바스크립트는 왜 프로로타입을 선택했을까 라는 글을 읽게 되었고, 덕분에 위와 같은 질문에 대한 답을 나름대로 찾을 수 있었습니다.

프로토타입이 등장한 배경부터 그 내용까지 굉장히 잘 정리되어있는 글이기에, 직접 읽어보시는 것을 추천합니다. 다음은 위 글에서 핵심이라고 생각한 내용들을 간단히 정리한 것입니다.

💡 자바스크립트는 왜 프로토타입을 선택했을까 - 요약

플라톤이 주장했던 "이데아" 이론에 기반해, 공통된 속성을 기준으로 객체를 "분류"하는 사고 방식이 프로그래밍 언어에 자연스럽게 녹아든 것이 "클래스 기반 객체 지향 프로그래밍 언어"입니다.

공통된 속성은 클래스의 프로퍼티가 되고, 프로퍼티가 유사한 객체가 있다면 일반화 과정을 통해 클래스로 추상화됩니다.

• 의미사용이론

  단어의 진정한 본래의 의미는 존재하지 않고 오직 "상황과 맥락"에 의해서만 결정된다.

• 가족 유사성 이론

  대상을 분류할 때, 모든 구성원이 공유하는 공통 속성이 아닌, 다수의 구성원이 공유하는 전형적인 특징을 통해 분류하는 이론

• 의미 사용 이론

  => 변수의 의미는 그 어휘적인(Lexical), 맥락(Context)에서 평가됩니다.

  => 실행 컨텍스트, 스코프 체인, this, 호이스팅, 클로저 등의 개념이 모두 프로토타입의 "맥락"을 표현하기 위한 것입니다.

• 가족 유사성 이론

  => 객체는 정의로부터 분류되는 것이 아니라, 가장 좋은 보기(프로토타입)으로부터 범주화됩니다.

  ex)

  function 참새(){
      this.날개갯수 = 2;
      this.날수있나 = true;
  }
  const 참새1 = new 참새();
  
  console.log("참새의 날개 갯수 : ", 참새1.날개갯수); // 2
  
  function 닭(){
    this.벼슬 = true;
  }
  
  닭.prototype = 참새1; // 오른쪽이 인스턴스인 점 주목
  const 닭1 = new 닭();

  참새1 을 프로토타입으로 갖는 닭1이 생겼습니다. 여기서 주목할 점은 오른쪽이 참새(함수)가 아니라 참새1(인스턴스) 인 점입니다. 프로토타입 이론은 이미 존재하는 사물을 통해 범주화한다는 점에서 일치합니다.

위의 글을 정리해보면, 다음과 같이 요약할 수 있습니다.

프로로타입 기반 언어인 JS는

변수나 객체의 의미가 그 변수나 객체가 속한 "맥락"에 의해서만 평가될 수 있기 때문에, 공통된 속성을 기준으로 한 "분류"가 아닌, 가장 좋은 보기(프로토타입)으로부터 객체를 범주화한다.

📌 프로로타입 기반 객체지향 프로그래밍

객체지향 프로그래밍이란?

프로그램을 절차지향적 관점에서 벗어나 여러 객체의 집합으로 표현하는 방법입니다.

객체란? => 객체의 핵심은 묶는 것

어떤 변수가 하나의 값을 가지는 것이 아니라, 여러 속성을 가지고 이 속성들을 한 곳에 묶어놓은 것이 객체가 되는 것

일반적으로는 상태를 나타내는 데이터와 데이터를 조작할 수 있는 동작들을 묶어서 객체를 정의합니다.

JS는 객체 기반의 프로그래밍 언어이며 JS를 이루고 있는 거의 "모든 것"이 객체입니다.

프로토타입 기반 객체지향

JS는 클래스 기반 OOP 언어보다 효율적이며 더 강력한 객체지향 프로그래밍 능력을 지니고 있는 프로토타입 기반의 객체지향 프로그래밍 언어입니다.

ES6에서 JS에 클래스가 도입되었지만, 기존 프로토타입 기반 객체 지향 모델을 폐지하는 것은 아닙니다. 클래스도 결국 함수이며, 기존 프로토타입 기반 패턴의 symantic sugar라고 볼 수 있습니다.

📌 프로토타입을 통한 상속 => 코드의 재사용

상속은 어떤 객체의 프로퍼티 또는 메서드를 다른 객체가 상속받아 그대로 사용할 수 있는 것을 말합니다. JS는 프로토타입을 기반으로 상속을 구현하여 불필요한 중복을 제거합니다.

즉, 각 인스턴스마다 동일한 메서드를 각각 가지고 있으면 메모리 상으로도 코드 상으로도 효율적이지 못하니까, 한 번만 정의하고 이를 재사용하는 것입니다.

예를 들어, 원을 나타내는 객체를 정의한다고 생각해봅시다.

각 원 객체마다 반지름은 다를 수 있어도 반지름을 통해 너비를 구하는 방법은 같을 것입니다. 그렇다면 각 인스턴스가 이 너비를 구하는 메서드를 공유해서 사용할 수 있도록 프로토타입에 추가할 수 있습니다.

function Circle(radius){ // 원 객체를 생성하는 생성자 함수
    this.radius = radius;
}

Circle.prototype.getArea = function(){
    return Math.PI * this.radius * 2;
}

const circle1 = new Circle(1);
const circle2 = new Circle(2);

console.log(circle1.getArea()); // 프로로타입으로부터 상속받은 getArea 메서드를 사용합니다. 

위 코드에서,Circle 생성자 함수가 생성한 모든 인스턴스는 자신의 프로토타입 Circle.prototype의 모든 프로퍼티와 메서드를 상속받습니다.

이렇듯 상속은 코드의 재사용이란 관점에서 매우 유용합니다. 이렇게 프로로타입에 프로퍼티나 메서드를 구현해두면, 각 인스턴스는 프로토타입에서 이를 상속받아 사용할 수 있습니다.

📌 프로토타입 객체 [[Prototype]]

모든 객체는 [[Prototype]] 이라는 내부 슬롯을 가지며, 이 내부 슬롯의 값은 프로토타입의 참조입니다.

좀 더 쉽게 설명하자면, 모든 객체는 [[Prototype]]이라는 직접 접근할 수는 없는 정보인 내부 슬롯을 가지고 있고, 이것이 바로 우리가 지금까지 설명한 객체의 프로토타입을 나타냅니다.

내부 슬롯은 직접 접근할 수 없기 때문에, 다음과 같이 접근합니다.

const o = {};
o.[[Prototype]] // 내부 슬롯 => 접근 불가
o.__proto__ // => Object.prototype 

[[Prototype]]에 저장되는 프로토타입은 객체가 생성될 때 그 방식에 의해 결정됩니다.

• 객체 리터럴로 생성되었다면 Object.prototype 값을 가집니다.
• 생성자 함수를 통해 생성되었다면 생성자 함수의 prototype 프로퍼티에 바인딩되어 있는 객체 값을 가집니다.

모든 객체는 하나의 프로토타입을 갖습니다. 그리고 모든 프로토타입은 생성자 함수와 연결되어 있습니다. 즉, *객체와 프로토타입과 생성자 함수는 다음 그림과 같이 서로 연결되어있습니다. *

• 생성자 함수에서 prototype에 접근할 때는 Circle.prototype으로 접근할 수 있습니다.

• 반대로 prototype에서 생성자에 접근하려면(Circle.prototype).constructor로 접근할 수 있습니다.

• 객체에서 prototype에 접근할 때는 __proto__ 접근자 프로퍼티를 통해 접근할 수 있습니다.

__proto__ 접근자 프로퍼티

모든 객체는 __proto__ 접근자 프로퍼티를 통해 자신의 프로토타입, 즉 [[Prototype]] 내부 슬롯에 간접적으로 접근할 수 있습니다.

내부 슬롯은 프로퍼티가 아닙니다. 즉, 원칙적으로는 내부 슬롯의 값에 직접 접근할 수 없습니다. 하지만 [[Prototype]] 내부 슬롯은 __proto__라는 접근자 프로퍼티를 통해 간접적으로 접근할 수 있습니다.

접근자 프로퍼티란?

자체적으로는 값 [[Value]] 프로퍼티 어트리뷰트를 갖지 않고 다른 데이터 프로퍼티의 값을 읽거나 저장할 때 사용하는 접근자 함수인 [[Get]], [[Set]] 프로퍼티 어트리뷰트로 구성된 프로퍼티입니다.

예시)

const person = {
    // 데이터 프로퍼티
    firstName: 'Minwoo'
    lastName: 'Park',

    // fullName은 접근자 함수로 구성된 접근자 프로퍼티다.
    // getter 함수
    get fullName(){
        return `${this.firstName} ${this.lastName}`;
    },


       // setter 함수    
    set fullName(name){ // 크기가 2인 배열인 name이 전달될 것임. 
        [this.firstName, this.lastName] = name.split(" ");
    }
};

// 데이터 프로퍼티를 통한 값 접근
console.log(person.firstName + '' + person.lastName); 


// 접근자 프로퍼티를 통한 프로퍼티 값의 참조
person.fullName = "minwoo park";
console.log(person.fullName); // minwoo parkd

그래서 __proto__를 통해 객체의 프로토타입 값에 접근하고, 그 값을 수정할 수 있습니다.

const obj = {};
const parent = { x : 1};

obj.__proto__;
obj.__proto__ = parent;
// setter 함수인 set __proto__가 호출되어 obj 객체의 프로토타입을 교체 

console.log(obj.x);; 

사실 __proto__ 접근자 프로퍼티는 객체가 직접 소유하는 프로퍼티가 아니라 Object.prototype의 프로퍼티입니다. 모든 객체는 상속을 통해 Object.prototype.__proto__ 접근자 프로퍼티를 사용할 수 있는 것입니다.

함수 객체의 prototype 프로퍼티

함수 객체만이 소유하는 prototype 프로퍼티는 생성자 함수가 생성할 인스턴스의 프로토타입을 가리킵니다.

// 함수 객체는 prototype 프로퍼티를 소유한다.
( function(){} ).hasOwnProperty('prototype'); // => true

// 일반 객체는 prototype 프로퍼티를 소유하지 않는다.
({}).hasOwnPropery('prototype'); // => false

따라서 생성자 함수로 호출할 수 없는 함수, 즉 non-constructor인 화살표 함수와 ES6 메서드 축약 표현으로 정의한 메서드는 prototype 프로퍼티를 소유하지 않으며 프로토타입도 생성하지 않습니다.

생성자 함수로 호출하기 위해 정의하지 않은 일반 함수(함수 선언문, 함수 표현식)도 prototype 프로퍼티를 소유하지만 객체를 생성하지 않는 일반 함수의 prototype 프로퍼티는 아무런 의미가 없습니다.

__proto__ VS prototype

위에서 살펴본 __proto__ 프로퍼티와 prototype 프로퍼티에 대한 내용들을 정리해보면, 두 프로퍼티 모두 동일한 프로토타입을 가리키지만, 사용 주체와 목적 등에서 차이가 있습니다.

📌 프로토타입의 생성 시점

프로토타입은 생성자 함수가 생성되는 시점에 더불어 생성됩니다. 프로토타입과 생성자 함수는 단독으로 존재할 수 없고 언제나 쌍으로 존재하기 때문입니다.

생성자 함수는 다음과 같이 두 종류가 있습니다.

• 사용자 정의 생성자 함수
• js 기본 제공 빌트인 생성자 함수
  

사용자 정의 생성자 함수

사용자가 정의한 생성자 함수, 즉 constructor는 함수 정의가 평가되어 함수 객체를 생성하는 시점에 프로토타입도 더불어 생성됩니다. 그리고 이 프로토타입의 프로토타입은 언제나 Object.prototype이다.

빌트인 생성자 함수

빌트인 생성자 함수(Object, String, Number, Function 등)도 일반 함수와 마찬가지로 빌트인 생성자 함수가 생성되는 시점에 프로토타입이 생성됩니다.

모든 빌트인 생성자 함수는 전역 객체가 생성되는 시점에 생성됩니다.

전역 객체에는 많은 내장된 속성과 메서드가 있습니다. 이 중 일부는 빌트인 생성자 함수입니다. 예를 들어, String, Number, Boolean, Object, Array와 같은 생성자 함수들은 모두 전역 객체에 이미 존재하며, 코드 실행 이전에 JS 엔진에 의해 생성됩니다.

프로토타입은 언제 생성되는가? 라고 물어보면 다음과 같이 정리할 수 있습니다.

• 객체가 생성되기 이전에 생성자 함수와 프로토타입은 이미 객체화되어 존재합니다.
• 이후 생성자 함수 또는 리터럴 표기법으로 객체를 생성하면 프로토타입은 생성된 객체의 [[Prototype]] 내부 슬롯에 할당됩니다.

💡 생성자 함수가 만들어질 때 객체가 가지게 될 프로토타입이 미리 만들어지고, 나중에 생성자 함수를 통해 객체가 생성되면, 그 때 객체와 프로토타입이 연결되는 것입니다.

📌 객체 생성 방식과 프로토타입의 결정

JS에서는 객체를 다양한 방법으로 생성할 수 있습니다.

• 객체 리터럴
• Object 생성자 함수
• 생성자 함수
• Object.create 메서드`
• 클래스(ES6)

여러가지 방법이 있지만, 이 방법들의 공통점은 추상 연산 OrdinaryObjectCreate 과정을 거친다는것입니다.

추상 연산 OrdinaryObjectCreate

• 자신이 생성할 객체의 프로토타입을 인수로 받습니다. => (필수)
• 자신이 생성할 객체에 추가할 프로퍼티 목록을 인수로 받습니다. => (옵션)

추상 연산이 이루어지는 과정은 다음과 같습니다.

1. 빈 객체를 생성
2. 인수로 전달받은 프로퍼티 목록을 객체에 추가
3. 인수로 전달받은 프로토타입을 객체의 [[Prototype]] 내부 슬롯에 할당

프로토타입은 추상 연산 OrdinaryObjectCreate에 전달되는 인수에 의해 결정되고, 이 인수는 객체가 생성되는 시점에 객체 생성 방식에 의해 결정됩니다.

1. 객체 리터럴

객체 리터럴에 의해 생성되는 객체의 프로토타입은 Object.prototype입니다.

const obj = {x:1};

위 객체 리터럴이 평가되면 추상 연산 OrdinaryObjectCreate에 의해 다음과 같이 Object 생성자 함수와 Object.prototype과 생성된 객체 사이에 연결이 만들어진다.

2. Object 생성자 함수

const obj = new Object();

Object 생성자 함수에 의해 생성되는 객체의 프로토타입은 Object.prototype 입니다.

3. 생성자 함수

추상 연산 OrdinaryObjectCreate에 전달되는 프로토타입은 생성자 함수의 prototype 프로퍼티에 바인딩되어 있는 객체입니다.

function Person(name){
    this.name = name;
}

const me = new Person("Lee");

정리하면

• 객체 리터럴 또는 Object 생성자 함수로 객체가 생성되었을 때는, 그 객체의 프로토타입은 Object.prototype입니다.
• 생성자 함수로 객체가 생성되었을 때는 그 생성자 함수의 고유한 프로토타입이 생성되고, 그 프로토타입의 프로토타입은 Object.prototype입니다.

📌 프로토타입 체인

프로토타입의 프로토타입은 언제나 Object.prototype 입니다.

Object.getPrototypeOf(me) === Person.prototype; // true
Object.getPrototypeOf(Person.prototype) === Object.prototype; // true

JS는 객체의 프로퍼티에 접근하려고 할 때 해당 객체에 접근하려는 프로퍼티가 없다면 [[Prototype]] 내부 슬롯의 참조를 따라 자신의 부모 역할을 하는 프로토타입의 프로퍼티를 순차적으로 검색합니다. 이를 프로토타입 체인이라고 합니다.

프로토타입 체인은 JS가 객체지향 프로그래밍의 상속을 구현하는 메커니즘입니다.

프로토타입 체인의 최상위에 위치하는 객체는 언제나 Object.prototype입니다. 프로토타입 체인의 종점인 Object.prototype에서도 프로퍼티를 검색할 수 없는 경우 undefined를 반환합니다. 이 때, 에러가 발생하지는 않습니다.

EX)

me.hasOwnPropertty('name');

hasOwnProperty 메서드가 me 객체에도 없고, Person.prototype 에도 없으므로 계속 프로토타입 체인을 따라 올라가다가, Object.prototype는 hasOwnProperty 메서드를 가지고 있기 때문에, 여기서 멈추고 이를 참조합니다.

js엔진은 Object.prototype.hasOwnProperty 메서드를 다음과 같이 호출합니다.

Object.prototype.hasOwnProperty.call(me, 'name');

=> 메서드의 this에는 me가 바인딩됩니다.

이처럼 JS 엔진은 프로토타입 체인을 따라 프로퍼티/메서드를 검색합니다. 다시 말해, JS 엔진은 객체 간의 상속 관계로 이루어진 프로토타입의 계층적인 구조에서 객체의 프로퍼티를 검색합니다. 따라서** 프로토타입 체인은 상속과 프로퍼티 검색을 위한 메커니즘**이라고 할 수 있습니다.

스코프 체인 VS 프로토타입 체인

이에 반해, 프로퍼티가 아닌 식별자는 스코프 체인에서 검색합니다. 다시 말해, JS 엔진은 함수의 중첩 관계로 이루어진 스코프의 계층적 구조에서 식별자를 검색합니다. 따라서 스코프 체인은 식별자 검색을 위한 메커니즘이라고 할 수 있습니다.

me.hasOwnProperty("name");

위 예제의 경우, 먼저 스코프 체인에서 me 식별자를 검색합니다. me 식별자는 전역에서 선언되었으므로 전역 스코프에서 검색됩니다. me 식별자를 검색한 다음, me 객체의 프로토타입 체인에서 hasOwnProperty 메서드를 검색합니다.

이처럼 스코프 체인과 프로토타입 체인은 서로 연관없이 별도로 동작하는 것이 아니라, 서로 협력하여 식별자와 프로퍼티를 검색하는데 사용됩니다.

🙇🏻‍♂️ 참고

자바스크립트는 왜 프로로타입을 선택했을까

모던 자바스크립트 Deep Dive CH19 - 프로토타입

리액트는 상태를 단방향으로 바인딩을 하는 라이브러리입니다. 부모에서 자식 방향으로만 state를 props로 전달할 수 있고, 자식의 props를 부모에게 전달하는 방법은 존재하지 않습니다.

자식 component에서 부모 component의 state를 바꿀 수 있는 방법에는 2가지가 존재합니다.

1. 자식에게 부모의 state를 변경할 수 있는 setState 함수를 props로 넘겨준다.
2. 상태 관리 도구(redux, recoil 등)을 사용한다.

하지만 1번 방법은 서비스의 규모가 조금이라도 커지게 된다면 상태 관리에 어려움을 겪을 수 있습니다. 즉, 자식을 내려보내는 depth가 조금이라도 깊어지면 1번과 같은 방법은 효율적이지 않습니다.

React 자체를 통해서도 상태 관리가 가능하지만, 다음과 같은 한계가 존재합니다.

• 컴포넌트의 상태는 공통된 상위요소까지 끌어올려야만 공유될 수 있으며, 이 과정에서 거대한 트리가 다시 렌더링되는 효과를 야기하기도 합니다.
• Context는 단일 값만 저장할 수 있으며, 자체 소비자(consumer)를 가지는 여러 값들의 집합을 담을 수는 없습니다.
• 위 두 가지 특성이 트리의 최상단(state가 존재하는 곳)부터 트리의 말단(state가 사용되는 곳)까지의 코드 분할을 어렵게 합니다.

전역 상태 관리 도구인 Recoil을 사용하면 atoms(공유 상태)에서 selectors(순수 함수)를 거쳐 React 컴포넌트로 내려가는 data-flow graph를 만들 수 있습니다.

📌 atom

Recoil에서 atom이란, 상태의 단위이고 업데이트와 구독이 가능합니다.

• 상태의 단위이고, 값의 업데이트가 가능합니다.

  => useState 훅과 비슷한 느낌이라고 생각할 수 있습니다.

• 구독이 가능합니다.

  => 모든 컴포넌트가 전역적으로 상태를 공유할 수 있습니다.

  => atom이 업데이트 되면 이를 구독한 각각의 컴포넌트는 새로운 값을 반영하여 리렌더링이 일어나게 됩니다.

  => 동일한 atom을 여러 컴포넌트에서 구독하고 있다면 모든 컴포넌트는 그 상태를 공유합니다.

• atom은 런타임에 생성될 수도 있고, React의 로컬 컴포넌트의 상태 대신 사용할 수 있습니다.

atom 정의 및 사용 예시

다음은 atom을 정의하는 예시입니다.

import { atom } from 'recoil';

// atom 생성 
export const todoListState = atom({ 
    key: 'todoListState',
    default: []
});

export const todoListFilter = atom({
    key: 'todoListFilterState',
    default: 'Show All',
})

• atom 이라는 함수를 사용해서 atom을 생성할 수 있습다.

• atom 함수에 인자로 key와 상태가 가질 기본 값 default를 넣어줘야 합니다.

• atom의 키는 전역적으로 고유해야 합니다.

  => 2개의 atom이 같은 키를 가지면 오류를 일으킵니다.

// atom을 사용하는 컴포넌트 파일 
import { todoListState } from 'store/atom'

const TodoList = (props) => {
    const [todoList, setTodoList] = useRecoilState(todoListState); // atom 구독

    const handleClickSetTodoList = (newList) => {
        setTodoList(newList);
    };

    return (
        <>
            {todoList.map((todoItem) => (
                <TodoItem key={todoItem.id} item={todoItem}/>
            ))}
        </>
    );
};

위의 코드의 useRecoilState 훅처럼 atom의 값에 접근하고 변경하기 위해 사용할 수 있는 러가지 hook들을 알아보겠습니다.

useRecoilState

const [todoList, setTodoList] = useRecoilState(todoListState); 

atom으로 정의된 state를 읽고 쓰기 위해서는 useRecoilState라는 훅을 사용할 수 있습니다.

• useState 처럼 사용하고

  => 인자에 atom 혹은 selector를 넣어 [state, setState]같은 튜플에 할당한다.

• 반환되는 배열의 첫 번째 인자 todoList는 값을 읽을 때 사용하는 값이고

• 두번째 인자 setTodoList는 atom 값을 변경할 수 있는 함수이다.

useRecoilValue

const todoList = useRecoilValue(todoListState);

만약 상태를 사용하는 컴포넌트에서 atom이나 selector의 상태는 변경하지 않고 값을 읽는 용도로만 사용한다면 useRecoilValue 훅을 사용할 수 있습니다.

이 hook은 상태를 읽을 수만 있게 하고 싶을 때 사용하는 것을 추천합니다.

useSetRecoilState

const setTodoList = useSetRecoilState(todoListState);

상태의 setter 함수만을 활용하기 위해 사용됩니다. 선언된 변수에 setter 함수를 할당하여 사용합니다.

💡 useRecoilState를 사용하면 될텐데 useSetRecoilState가 필요한 이유 ??

const [todoList, setTodoList] = useRecoilState(todoListState);

위와 같이 useRecoilState를 사용해 다음과 같이 받아오면 todoList까지 같이 받아오기 때문에 이 atom을 구독하게 됩니다. 따라서 todoList의 값이 바뀌면 이 컴포넌트는 다시 렌더링됩니다.

const setTodoList = useSetRecoilState(todoListState);

위와 같이 useSetRecoilState를 사용하면 해당 atom을 구독하지 않고 해당 atom을 업데이트만 할 수 있어서, 불필요한 렌더링을 일으키지 않습니다.

useResetRecoilState

const resetTodo = useResetRecoilState(todoListState);

전역상태를 초기(deafult) 값으로 reset하기 위해서 사용됩니다. 선언된 함수 변수에 할당하여 사용합니다.

📌 selector

• selector는 기존의 상태인 atom이나 selector에서 파생될 수 있는 data에 접근할 수 있게 해줍니다.

• selector는 atom나 다른 selector를 입력으로 받아들이는 순수 함수입니다.

• 상위에 있는 atom 또는 selector가 업데이트 되면 하위의 selector 함수도 다시 실행됩니다.

• selector를 atom과 마찬가지로 구독할 수 있고 selector가 변경될 때도 컴포넌트는 리렌더링됩니다.

selector를 사용하는 이유

=> 최소한의 상태 단위만 atoms에 저장하고 그 상태를 기반으로 파생되는 모든 데이터들은 selector에 명시한 함수를 통해서 효율적으로 계산함으로써 쓸모없는 상태의 보존을 방지합니다.

EX)

todoList도 필요하고, 특정 filter가 적용된 todoList도 필요하다면

=> 두 개의 state를 atom으로 각각 가지고 있는 것보다는, todoList라는 atom을 한 번만 선언하고 filter가 적용된 todoList를 계산해서 반환해주는 selector를 정의하는 쪽이 더 효과적입니다.

단, 지금 상황처럼 특정 filter가 적용된 todoList가 todoList에서 파생될 수 있기 때문에 selector를 사용하는 것이 가능한 것입니다.

사용 예시

기존에 존재하는 atom에 접근해 이로부터 파생된 새로운 state에 접근할 수 있는 selector를 만들어보겠습니다.

// atom 선언 
export const todoListState = atom({
    key: 'todoListState',
    default: []
});

export const todoListFilter = atom({
    key: 'todoListFilterState',
    default: 'Show All',
})

export const filteredTodoListState = selector({
    key: 'filteredTodoListState',
    get: ({get}) => {
        const filter = get(todoListFilterState);
        const list = get(todoListState); 

        switch(filter){
            case 'A': 
                return list.filter((item)=>item.isComplete);
            case 'B':
                return list.filter((item)=>!item.isComplete);
            default:
                return list;
        }
    }
})

• selector 함수를 호출해 인자로 key와 get을 넣어서 selector를 생성합니다.

• key : selector 마다 고유한 값으로 설정해줘야 합니다.

• get

  • 함수를 정의합니다. 여기서 정의해주는 함수의 리턴값이 실제로 이 selector를 호출했을 때 계산되어서 접근할 수 있는 값이 됩니다.

  • 함수의 인자로 {get}을 받아 이 get 함수를 사용해 다른 atom과 selector에 접근할 수 있습니다. 이렇게 참조했던 다른 atom 혹은 selector가 업데이트 되면 이 get 함수도 다시 실행됩니다.

    const filter = get(todoListFilterState); // atom에 접근 
    const list = get(todoListState); // atom에 접근 

  • 위 예시의 filteredTodoListState 라는 selector는 todoListFilterState와 todoListState라는 두개의 atom에 의존성을 가지고 있습니다.

• 이렇게 정의된 selector의 값에 접근하기 위해서는 useRecoilValue 훅을 사용할 수 있습니다.

  const filteredTodoList = useReocilValue(filteredTodoListState);

  현재 filteredTodoListState 라는 selector는 writable하지 않기 때문에 useRecoilState를 사용하지 않았습니다.

  selector를 정의할 때, get 함수만 정의한다면 selector는 읽기만 가능한 RecoilValueReadOnly 객체를 반환합니다. 그렇기 때문에 읽기 전용 훅은 useRecoilValue를 사용한 것이고, 만약 selector에서 set 함수를 정의한다면 쓰기도 가능한 useRecoilState 훅을 사용할 수 있습니다.

🙇🏻‍♂️ 참고

Recoil 알아보기 Recoil 200% 활용하기

자바스크립트 코드의 실행 과정 - 실행 컨텍스트에서 변수를 선언할 때의 3가지 단계(선언, 초기화, 할당)를 실행 컨텍스트와 렉시컬 환경을 통해서 설명했습니다. 이번 글에서는 이러한 변수 선언 과정을 거치면서 JS 내부에서는 어떤 일이 발생하는 지, 호이스팅이 발생하는 이유는 무엇인지에 대해 더욱 자세하게 알아보겠습니다.

📌 변수의 선언

변수를 선언했을 때, 변수 이름은 어디에 등록되는가?

변수 이름을 비롯한 모든 식별자는 실행 컨텍스트에 등록됩니다. 실행 컨텍스트란, 간단히 말하면 프로그램이 실행되는 동안 변수와 함수가 존재하는 장소입니다. 변수 이름과 변수 값은 실행 컨텍스트 내에 키/값 형식인 객체로 등록되어 관리됩니다.

JS 엔진은 소스코드를 한 줄씩 순차적으로 실행하기에 앞서 먼저 소스코드의 평가 과정을 거칩니다. 이 때 변수 선언을 포함한 모든 선언문을 소스코드에서 찾아내 먼저 실행합니다. 그리고 평가 과정이 끝나면 비로소 선언문을 제외한 소스 코드를 한 줄씩 순차적으로 실행합니다.

코드의 실행 과정 : 평가 => 실행

=> 이로 인해, 변수 선언문이 코드의 선두로 끌어 올려진 것처럼 동작하는 JS 고유의 특징을 변수 호이스팅이라고 합니다.

호이스팅이 발생하는 이유 ?

=> 코드를 순차적으로 한줄 한줄 실행하기 전에 소스 코드를 평가하면서 변수 선언문이 먼저 실행되기 때문입니다.

사실 변수 뿐만 아니라 함수, 클래스 등의 모든 식별자가 호이스팅 됩니다. 모든 선언문은 런타임 이전 단계에서 먼저 실행되기 때문입니다.

📌 값의 할당

var score = 80;

다음과 같은 코드는 변수의 선언과 값의 할당을 하나의 문으로 단축 표현한 것이며, 이는 실제로 아래와 같이 2개의 문으로 나누어 각각 실행됩니다.

var score; // 변수의 선언 
score = 80; // 값의 할당

이 때 주의 할 점은 변수 선언과 값의 할당의 실행 시점이 다르다는 것이다.

• 변수 선언 : 런타임 이전
• 값의 할당 : 런타임

값의 할당이 일어나면 undefined 값이 있던 메모리에 새로운 값인 80을 덮어 쓰는 것이 아니라, 80을 위한 새로운 메모리를 할당하고, score는 그 메모리를 가리키게 됩니다.

이는 undefined 값은 이제 더 이상 필요하지 않다는 것을 의미합니다. 이러한 불필요한 값들은 garbage collector에 의해 메모리에서 자동 해제됩니다. 단, 메모리에서 언제 해제될지는 예측할 수 없습니다.

console.log(score); // undefined

score = 80;
var score;

console.log(score); // 80

📌 변수 선언의 3가지 단계

var variable1 = "변수";
let variable2 = "123";

위와 같이 변수를 선언하고 값을 할당하는 코드가 실행되면 다음 3가지 단계로 나누어 실행됩니다.

1. 변수의 고유식별자(변수명)을 생성하고
2. 메모리에 주소를 할당하고
3. 생성한 주소에 값을 넣는다.

이를 실제 실행 컨텍스트 관점에서 다시 표현해보면 다음과 같이 표현할 수 있습니다.

1. 선언 단계

   변수를 Execution Context의 Lexical Environment에 등록합니다.

2. 초기화 단계

   Lexical Environment에 등록되어 있는 변수를 위하여 메모리를 할당하는 단계로, 여기서 변수는 undefined로 초기화됩니다.

3. 할당 단계

   변수에 실제로 값이 할당되는 단계입니다. (undefined → 특정한 값)

우리가 선언한 변수나 상수는 값이 아닌 메모리 주소를 바라보고 있습니다.

let variable = 126;
let variable2 = variable;

이렇게 새로운 변수에 기존 변수를 대입한다면, variable2가 variable의 메모리 주소를 참조하게 됩니다.

여기서 만약 다음과 같이 기존 변수의 값을 변경한다면 어떻게 될까요 ?

variable = variable + 1

=> 기존 variable이 가리키던 메모리 주소가 아닌, 새로운 메모리 주소를 할당 받고, 그곳에 값을 넣게 됩니다.

=> 이는 JS에서 원시 타입은 값의 변경이 불가능하기 때문입니다. 특정 메모리에 값이 할당이 되면, 그 메모리에 다른 값은 할당이 불가능합니다. Garbage collector가 이를 해제한 후에야 가능합니다.

=> 즉, 원시 타입 변수의 값이 변경될 때는 항상 메모리가 새로 할당됩니다.

📌 호이스팅과 var, let, const

호이스팅이란?

변수 및 함수 선언문이 스코프 내의 최상단으로 끌어올려지는 것처럼 동작하는 현상을 말합니다.

호이스팅이 발생하는 이유는 JS 엔진은 소스코드를 순차적으로 한줄 한줄 실행하기 전에 소스 코드를 평가하면서 변수와 함수 선언문을 먼저 실행하고, 이를 렉시컬 환경에 등록한 다음에 코드를 실행하기 때문입니다.

실제로 선언문이 코드 상에서 최상단으로 끌어올려지는 것은 아닙니다. 렉시컬 환경에 변수 및 함수가 등록되어 있기 때문에 코드 상에서 변수 선언문 이전에 변수를 참조하는 코드가 나와도, 해당 변수를 참조할 수 있으므로 최상단으로 끌어올려지는 것처럼 느끼는 것 뿐입니다.

var vs let, const

let, const와 var을 통해 변수를 선언할 때 변수 선언의 3가지 단계를 거치는 부분에 차이가 발생하는데, var의 경우 1번과 2번이 동시에 진행되는데 let, const는 1번만 먼저 진행됩니다.

Execution Context의 생성 과정 중 첫 번째 페이즈인 Creation Phase에서

• Variable Environment에서는 var로 선언된 변수를 변수 선언 1, 2단계 모두 진행하기에 메모리에 매핑되고 undefined로 초기화까지 마치게 됩니다.
• 반면에 Lexical Environment의 경우는 let, const로 선언된 변수를 1단계만 진행하기에 Variable Environment와는 동작 방식에 차이가 있습니다.

이를 좀 더 자세히 정리하면,

• var 키워드로 선언한 변수는 선언 단계와 초기화 단계가 한번에 이뤄집니다. 즉, 스코프에 변수를 등록하고 메모리에 변수를 위한 공간을 확보한 후, undefined로 초기화합니다. 따라서 변수 선언문 이전에 변수에 접근하여도 스코프에 변수가 존재하기 때문에 참조 에러가 발생하지 않습니다. 다만 undefined를 반환한다. 이후 변수 할당문에 도달하면 비로소 값이 할당됩니다.

• let 키워드로 선언된 변수는 선언 단계와 초기화 단계가 분리되어 진행됩니다. 즉, 스코프에 변수를 등록하지만 초기화 단계는 변수 선언문에 도달했을 때(코드 실행 후) 이뤄집니다.따라서 초기화 이전에 변수에 접근하려고 하면 참조 에러가 발생합니다. 이는 아직 변수가 초기화되지 않았기 때문입니다. 즉, 변수를 위한 메모리 공간이 아직 확보되지 않았기 때문입니다.

따라서 스코프의 시작 지점부터 초기화 시작 지점까지는 변수를 참조할 수 없습니다. 스코프의 시작 지점부터 초기화 시작 지점까지의 구간을 ‘일시적 사각지대(Temporal Dead Zone; TDZ)’라고 부릅니다.

=> 즉, let은 호이스팅 시 선언 단계만 진행됩니다.

➕ 렉시컬 환경

렉시컬 환경이란 식별자-변수 맵핑 데이터 구조입니다. 여기서 식별자는 변수/함수의 이름을 참조하고, 변수는 실제 객체 [포함된 함수 객체] 또는 원시값을 참조합니다.

렉시컬 환경의 컨셉은 다음과 같습니다.

LexicalEnvironment = {
  Identifier:  <value>,
  Identifier:  <function object>
}

다시 말해, 렉시컬 환경은 프로그램이 실행되는 동안 변수와 함수가 존재하는 장소입니다.

undefined VS "초기화되지 않은 상태"

undefined

lexicalEnvironment = {
a: undefined
}

초기화되지 않은 상태

lexicalEnvironment = {
a: <uninitialized>
}

호이스팅 함수 선언 시 렉시컬 환경의 변화

helloWorld();  // 'Hello World!'가 콘솔에 찍힌다
function helloWorld(){
  console.log('Hello World!');
}

컴파일 단계에서 함수 선언이 메모리에 추가된다는 것을 이미 알고 있기 때문에 실제 함수 선언 전에 우리 코드로 그 선언에 접근할 수 있습니다.

lexicalEnvironment = {
  helloWorld: < func >
}

자바스크립트 엔진이 helloWorld() 호출을 접하게 되면, 렉시컬 환경 내부를 살펴보고 함수를 찾은 후에 실행 시킬 수 있습니다.

=> 하지만 함수 표현식은 var, let, const로 선언하기 때문에 호이스팅 되어도 undefiend 또는 uninitialized 상태로 렉시컬 환경에 저장되기 때문에 선언문 이전에 접근 시 에러가 발생합니다.

🙇🏻‍♂️ 참고

모던 자바스크립트 Deep Dive

mdn 호이스팅

호이스팅이란

함수 표현식 vs 함수 선언식

함수 호이스팅

올해도 아좌좌 프로젝트를 진행하며 계획 이어서 작성하기 기능을 담당했고, 이를 useSessionStorage 훅을 정의해 구현하는 과정을 담은 글입니다.

📌 계획 작성 페이지

계획 작성 페이지는 계획을 작성할 수 있는 페이지입니다. 위의 파란색 박스에서 보듯이, 계획 작성 과정은 총 4단계로 구성되어 있습니다. /create 라는 url을 가지는 하나의 페이지 안에 총 4개의 단계가 진행될 수 있고, 각 단계를 나타내는 컴포넌트가 한 페이지 안에서 교체되면서 렌더링되는 구조입니다.

유저는 이 페이지에서 계획을 작성할 수 있습니다. 하지만 그 단계가 4단계나 되는 만큼, 유저가 중간에 실수 또는 고의로 페이지를 이탈할 수 있기 때문에, 다시 작성 페이지로 돌아왔을 때 이전 data를 사용해 계획을 이어서 작성할 수 있는 기능이 필요하다고 생각했습니다.

📌 세션 스토리지와 useSesseionStorage hook

계획 이어서 작성하기 기능을 구현하기 위해서는, 유저가 이전에 작성하던 data를 어딘가에 저장해야했습니다. 그래야지만 유저가 계획을 이어서 작성하려고 할 때, 이전 data를 가져와 사용할 수 있기 때문입니다.

저희 팀이 선택한 저장소는 세션 스토리지입니다. 사실 데이터를 서버에 저장할 수도, 로컬 스토리지에 저장할 수도 있지만 세션 스토리지를 선택한 이유는 다음과 같습니다.

• 유저가 계획 작성 페이지에서 작성을 하다가 실수로 다른 페이지로 이동했을 때, 다시 작성 페이지로 돌아와서 이어서 작성할 수 있도록 하고 싶었습니다.
• 위의 상황만 만족시켜주면 되겠다고 생각했기에, 브라우저를 아예 닫거나 다른 탭에서 계획 작성 페이지에 접근했을 때 data를 유지시켜줄 필요는 없다고 생각했습니다.

그래서 컴포넌트 내의 상태들을 세션 스토리지에도 저장하고 컴포넌트의 상태가 변경될 때마다 이를 세션 스토리지와 동기화시켜주기 위해, useSessionStorage 훅을 정의하였습니다.

interface SessionStorageProps<T> {
  key: string;
  initialValue: T;
  setSessionValueAtFirst?: boolean; 
}

export const useSessionStorage = <T>({ // T: 저장하려는 data의 type
  key,
  initialValue,
  setSessionValueAtFirst = false,
}: SessionStorageProps<T>) => {
  const [getItem, setStoredItem] = useState<T>(() => {
    if (typeof window !== 'undefined') {
      const item = sessionStorage.getItem(key);
      if (item) {
        // sessionStorage에 값이 있다면 그 값을 사용
        return JSON.parse(item);
      } else {
        // session에 값이 없을 때 초기값으로 사용
        if (setSessionValueAtFirst) {
          // 초기값을 sessionStorage에 저장
          sessionStorage.setItem(key, JSON.stringify(initialValue));
        }
        return initialValue;
  });

  const setItem = (value: T) => {
    setStoredItem(value); // 1. 자체 state 변경   
    sessionStorage.setItem(key, JSON.stringify(value)); // 2. 세션 스토리지 내 data 변경
  };

  return [getItem, setItem] as const;
};

useSessionStorage hook을 간단히 설명하자면 다음과 같습니다.

• state의 초기값

  • 세션스토리지에 해당 key에 대한 data가 이미 존재한다면, 그 값을 초기값으로 사용합니다.

    이는 유저가 페이지를 이탈한 후, 다시 페이지에 접근했을 때 세션스토리지에 남아있던 data를 계속 사용할 수 있도록 하기 위함입니다.

  • 세션스토리지에 해당 ket에 대한 data가 존재하지 않는다면, 인자로 받은 initialValue를 초기값으로 사용합니다.

• state에 접근

  useSessionStorage hook 내 자체 state 값을 반환합니다.

• state의 변경

  1. useSessionStorage hook 내 자체 state를 변경시켜주고

  2. 세션스토리지의 data도 변경시켜줍니다.

     => 이를 통해 컴포넌트 내 state와 세션스토리지 내 data가 항상 같은 값을 유지하는 것을 보장할 수 있습니다.

결국 이를 정리하면, useState hook을 통해 컴포넌트의 state를 관리하는 방법과 거의 동일하지만, state가 세션 스토리지에도 저장되는 것입니다.

const [number, setNumber] = useState(1);

다음과 같이 useState hook을 사용해 상태를 관리한다면,

const [원하는 getter 이름, 원하는 setter 이름] = useSessionStorage({key, 1});

이렇게 비슷한 형식으로 useSessionStorage hook을 사용할 수 있습니다.

📌 자동저장 및 이어서 작성하기 적용 예시

실제 코드 상에서 위 hook을 사용해 어떻게 자동저장 및 이어서 작성하기 기능을 구현했는지 살펴보겠습니다.

자동 저장

유저가 처음 계획 작성 페이지에 접근하게 되면, 1단계인 계획 아이콘 정하기 단계에 진입하게 됩니다. 그러면 위 이미지의 초록색 박스에 해당하는 계획 아이콘 컴포넌트에서 useSessionStorage hook을 이용해 계획 아이콘 data를 관리합니다.

CreatePlanIcon.tsx

const [iconNumber, setIconNumber] = useSessionStorage<number | null>({
  key: SESSION_STORAGE_KEY.STEP_1,
  initialValue: null,
});

1단계에 해당하는 key인 상수 SESSION_STORAGE_KEY.STEP_1를 인자로 전달해주고, 맨 처음에는 선택된 아이콘이 없기 때문에 초기값은 null로 전달해줍니다.

그리고 이 hook을 통해 반환한 getter, setter 역할을 하는 iconNumber와 setIconNumber를 각각 필요한 부분에 연결해줍니다.

다음과 같이 아이콘 선택 모달에서 유저가 특정 아이콘을 클릭했을 때, 컴포넌트 내의 계획 아이콘 data가 변경되어야 합니다. 따라서, 아이콘 선택 모달 컴포넌트에 setIconNumber 메서드를 인자로 넘겨주고, 아이콘 선택 모달 컴포넌트 내 각 이미지의 클릭 리스너에 setIconNumber 메서드를 등록해줍니다.

CreatePlanIcon.tsx

<Modal>
<ModalSelectIcon
  setIconNumber={setIconNumber}
  closeModal={() => {
    setIsSelectIconModalOpen(false); // 아이콘 선택 모달 컴포넌트에 setIconNumber 메서드를 인자로 넘겨줌
  }}
/>
</Modal>

ModalSelectIcon.tsx

<Image
    src={`/animal/${planIcons[iconNumber]}.png`}
    width={40}
    height={40}
    alt="example plan icon"
    className={classNames('select-icon-modal__icon-image')}
    onClick={() => { // 클릭 리스너에 setIconNumber 메서드를 등록
          setIconNumber(iconNumber);
          closeModal();
    }}
/>

따라서, 아이콘이 클릭되었을 때 아이콘 data는 클릭된 아이콘에 해당하는 number로 변경되고, 세션 스토리지의 정보도 동시에 변경되는 것을 볼 수 있습니다. 즉, 컴포넌트 내 state가 세션 스토리지에도 자동으로 저장되는 것입니다.

이어서 작성하기

또한, 아이콘을 선택한 후 다른 페이지로 갔다가 다시 계획 작성 페이지로 왔을 때 이전 data를 사용해 이어서 작성할 수 있습니다.

계획 작성 페이지에 다시 접근한다면, 계획 아이콘 작성 컴포넌트가 다시 mount 되고, 컴포넌트 내 state는 다시 초기화될 것입니다. 즉 아래의 코드가 다시 실행될 것입니다.

const [iconNumber, setIconNumber] = useSessionStorage<number | null>({
  key: SESSION_STORAGE_KEY.STEP_1,
  initialValue: null,
});

하지만 지금은 이미 이전에 사용한 data가 세션스토리지에 남아있기 때문에, inivialValue로 전달된 null이 아니라 세션 스토리지의 값을 초기값으로 사용합니다. 따라서 다음과 같이 이어서 작성하기가 가능합니다.

리액트에서 가장 많이 사용하는 hook은 높은 확률로 useState일 것입니다. 기본적인 hook인 만큼, 사용하면서 주의해야할 점들을 정리해보았습니다💡

📌 상태값 변경시 리렌더링 발생

useState에서 반환된 배열의 두번째 값인 setter 함수를 호출하면 상태 값을 변경할 수 있고, 상태 값이 변경되면 해당 컴포넌트는 다시 렌더링됩니다.

=> 컴포넌트가 마운트되었을 때는, 기본적으로 useState(초기값)에서 인자로 전달된 값을 상태의 초기값으로 사용합니다. 하지만 이후 setter 함수에 의해 상태의 값이 변경되었다면, 다음 렌더링에서는 그 상태를 유지합니다.

setState 호출 => 상태 변경 => 리렌더링(변경된 상태값 사용)

📌 setState는 비동기로 동작한다! 그 이유는 ?

useState의 setter 함수를 호출한 이후 바로 다음 줄에서 해당 state값을 참조하면 아직 바뀌기 이전 state가 참조됩니다. 이는 useState의 setter 함수가 비동기적으로 동작하기 때문입니다.

function App() {
  let [count, setCount] = useState(0);
  let [age, setAge] = useState(20);

  return (
    <div>
      <div>나이: {age}</div>
      <button
        onClick={() => {
          setCount(count + 1); // 나중 실행
          if (count < 3) { // 먼저 실행 
            setAge(age + 1);
          }    
        }}
      >
        카운트: {count}
      </button>
    </div>
  );
}

위 코드 상에서 버튼을 누르면 다음과 같은 일이 발생합니다.

1. 버튼을 누르면 count를 +1 해줍니다.
2. 그리고 만약에 count가 3보다 적으면 age도 +1 해줍니다.

따라서 버튼을 계속 클릭하면, age는 20에서 22가 되면 더 이상 증가하지 않고 멈춰야합니다. 하지만 실제로는 age는 23까지 증가합니다. 즉, count가 3일 때에도 age +1를 해주고 있는 것입니다.

이는 state 변경함수가 비동기적으로 동작하는 함수이기 때문입니다. setCount(count+1) 동작으로 인해 count가 3이 되기 전에 if(count < 3) {}에 먼저 진입하기 때문에 age가 23까지 증가하는 것입니다.

비동기로 동작하는 이유는?

만약 한 컴포넌트 안에서 여러 state 값을 연속으로 변경하는 일이 생긴다면 여러 번 비교하고 다시 그리는 알고리즘이 실행(렌더링이 계속 일어남)됩니다.

만약 이 과정이 동기적으로 실행된다면 바뀌지 않아도 되는 불필요한 리렌더링이 다수 발생해 비효율적이고 성능도 안 좋을 것입니다.

❓ 따라서 한번에 모아서 batch 처리를 해주기 위해 setState가 비동기적으로 동작한다는 건가?

setState 함수는 비동기적으로 동작하지만, 동기함수이다?

리액트의 setState가 동기적 함수이고 마치 비동기 함수처럼 보이는 이유는 리엑트의 리렌더링 원리가 비동기적으로 작동하기 때문입니다.

리엑트는 렌더링 함수를 호출하여 가상 돔을 업데이트합니다.

setState가 비동기 함수처럼 보이는 이유는 setState 함수 그 자체가 비동기 함수여서가 아니라 리액트가 가상돔을 사용하게 설계되어있기 때문입니다.

❓ 그렇다면, setState 함수 자체는 동기함수이므로, 호출 자체는 동기적으로 되는데, 그 변경으로 인한 가상돔을 통한 리렌더링이 비동기적으로 이루어져서 setState가 비동기적으로 작동하는 것처럼 보이는 것????

더 알아보기

https://velog.io/@jay/setStateisnotasync

setState 이후 특정 작업을 순차적으로 실행해주고 싶다면 ?

=> useEffect와 useEffect의 의존성 배열을 활용

=> 어떤 상태값이 바뀐 후 동작해야하는 코드가 있다면, useEffect를 사용해 해당 값을 감시하다가 상태가 변하면 동작하도록 해줄 수 있습니다.

📌 짧은 시간안에 setter 함수를 연속적으로 호출 시 렌더링은 1번만 진행

만약 다음과 같이 setter 함수를 연속적으로 호출 했을 경우 렌더링은 1번만 진행됩니다.

"use client"

import { useEffect, useState } from "react";

export default function Page() {
  const [number, setNumber] = useState(0);

  useEffect(() => {
    setNumber(prev => prev + 1);
    setNumber(prev => prev + 1);
    setNumber(prev => prev + 1);
    setNumber(prev => prev + 1);
    setNumber(prev => prev + 1);
  }, []);

  useEffect(() => {
    console.log(`[${performance.now()}] 렌더링 완료됨. number => ${number}`);
  }, [number]);

  return (
    <>
      { 
        (function() {
          console.log(`[${performance.now()}] component return 됨.`);
          return <></>;
        })() 
      }
      <div className="w-full relative">
        현재 number 값 : { number }
      </div>
    </>
  );
}

리액트에서는 배치 상태 업데이트라고 하여 짧은 시간 이내에 setter 함수가 연속적으로 호출 되었을 경우에는 호출 된 값 또는 업데이터 함수들을 큐에 집어 넣어 놓고 대기합니다.

그리고 그 짧은 시간이 지난 후 큐에 집어 넣은 것들을 순차적으로 일괄적으로 호출(적용) 하기 시작합니다. 이러한 배치 상태 업데이트 방식을 채택하고 있으므로, setter 함수를 연속으로 호출해도 렌더링은 1번만 발생시키는 것이 가능합니다.

📌 업데이터 함수로 상태를 변경해야 하는 경우

setter 함수의 인자에는 값을 넣을 수도 있지만, 업데이터 함수를 넣을 수도 있습니다. 업데이터 함수는 인자에 prev 값이 넘어오면서 next state 값이 반환되게 되어 있도록 정의된 함수입니다. 업데이터 함수를 사용해야 하는 경우는 바로 이전 값을 참조해야 하는 경우입니다.

const [number, setNumber] = useState(0);

useEffect(() => {
  setNumber(prev => prev + 1);
  setNumber(prev => prev + 1);
  setNumber(prev => prev + 1);
  setNumber(prev => prev + 1);
  setNumber(prev => prev + 1);
}, []);

위 코드를 실행해보면 number 는 5로 바뀌어 있는 것을 확인 할 수 있습니다. 업데이터 함수 자체도 인자에 이전 상태 값을 받아올 수 있지만, 업데이터 함수들 끼리도 이전에 호출된 업데이터 함수에서 반환된 상태 값을 이전 상태 값으로 참조할 수 있습니다. 즉 이전 값이 반드시 필요한 상태 업데이트 같은 경우에는 업데이터 함수를 사용해야 합니다.

📌 state의 불변성을 지켜야한다.

리액트에서 state의 불변성을 지킨다는 것은, 상태 변경 시 기존의 상태 객체나 배열을 직접 수정하지 않고, 새로운 객체나 배열을 생성하여 상태를 업데이트하는 것을 의미합니다.

불변성을 지켜야 하는 이유는 무엇인가요?

리액트가 상태를 업데이트 할 때, 얕은 비교를 수행하기 때문입니다.

예를 들어 상태가 배열이라면, 배열의 요소 하나하나를 다 비교하는 것이 아니라, 이전 배열의 참조값과 현재 배열의 참조값만을 비교하는 것입니다.

따라서 배열에 특정 요소가 push 되었더라도, 배열의 참조값이 바뀌지 않으면 리액트는 상태 변화를 감지하지 못합니다. 따라서 새로운 배열을 생성하여 상태를 업데이트 해줘야 합니다.

예를 들어, useEffect 훅은 의존성 배열의 원소들 중 하나라도 이전 렌더링 시의 그것과 다른 값을 가질 경우 콜백을 실행합니다.

여기서 useEffect 훅의 의존성 배열 원소들의 비교는 Object.is 메서드를 사용합니다. 원소들이 객체일 경우, 참조값이 서로 같으면 변경되지 않았다고 판단합니다.

따라서 state의 불변성을 지킴으로써 리액트는 상태변화를 감지할 수 있는 것입니다.

불변성을 유지하는 예시

새로운 객체나 배열을 생성함으로써 불변성을 유지할 수 있습니다. ..., map, filter, slice, reduce 등등 새로운 배열을 반환하는 메소드들을 활용하면 됩니다.

const [item, setItems] = useState(['item1', 'item2']);
const addItem = newItem => {
    setItems([...items, newItem]); // 새로운 객체를 생성 ?
}

📌 여러 data를 객체로 묶어서 state 관리하기

관리해야 할 data가 여러개라면, 비슷한 data 끼리는 객체로 묶고, 공통점이 없는 data들은 분리해서 각 상태의 책임을 분산하는 것이 좋습니다. 이렇게 한다면, 모듈화도 쉬워지고 불필요한 큰 객체 생성도 방지할 수 있습니다.

여기서의 책임은 변화를 의미합니다. 서로 같이 업데이트되는 상태끼리는 하나의 객체로 묶어도 된다는 의미입니다. 예를 들어 마우스의 x좌표, y좌표 같은 상태는 별도로 관리하는 것보다는 하나의 객체로 묶는 것이 더 효율적일 것입니다.

🙇🏻‍♂️ 참고

state 변경함수 사용할 때 주의점 : async

setState가 내 마음처럼 동작하지 않는 이유(feat.비동기)

useState 에 대해 알아봅시다

올해도 아좌좌 프로젝트를 진행하며 서비스 내 API 호출 횟수를 최적화하기 위해 어떤 방법들을 사용했는지 그 과정을 담은 글입니다.

📌 API 호출 최적화의 필요성

올해도 아좌좌 프로젝트를 시작할 때부터, 저희 팀의 목표는 실제 사용자들의 문제를 해결할 수 있는 서비스를 만들고, 꾸준한 도메인 분석과 사용자들의 피드백을 바탕으로 서비스를 지속적으로 발전시켜나가는 것이었습니다.

그렇기 때문에 서비스를 실제로 온라인 상에 배포할 생각이었습니다. 따라서 많은 API 호출은 곧 비용을 의미했고, 누군가가 악의적으로 많은 양의 API 호출을 하거나 꼭 필요하지 않은 API가 호출되는 상황은 최대한 방지하자는 마음 가짐으로 서비스를 개발했습니다.

그래서 API 호출 최적화를 위해 다음과 같은 방법들을 사용했습니다.

1. Next.js middleware 기능을 이용한 페이지 요청 리다이렉트

2. Tanstack-query의 staleTime 설정 및 쿼리 무효화

3. 토글 버튼에 디바운스 처리 적용

📌 Next.js middleware 기능을 이용한 페이지 요청 리다이렉트

저희 서비스에는 로그인을 해야만 접근할 수 있는 페이지들이 있습니다. 내 계획 페이지, 계획 작성 페이지, 마이 페이지가 그 예시입니다.

만약 로그인하지 않은 유저가 해당 페이지에 접근하려고 하는 경우, 페이지를 응답하기 전 nextjs middleware에서 로그인 여부를 검사해 로그인 하지 않았다면 로그인 페이지로 리다이렉트 시켜주었습니다.

middleware란?

유저가 보낸 request와 이에 대한 response 사이에 있는 소프트웨어입니다. 즉, 특정 요청이 완료되기 전 그 요청을 가로채 원하는 작업을 할 수 있습니다.

페이지를 렌더링하기 전에 서버 측에서 실행되는 함수이기 때문에, 요청에 대한 검증의 용도로 사용될 수 있습니다. 요청에 대한 응답을 rewriting, redirecting 등을 통해 수정할 수 있습니다.

더 자세한 내용은 공식문서를 참고하는 게 좋을 것 같습니다.

로그인 하지 않은 유저가 위의 페이지들에 접근하는 것을 막는 것은 기능적으로도 자연스러웠고, 만약 특정 페이지에 접근해 그 페이지 안에서 로그인 여부를 검사해 리다이렉트 처리를 한다면, 이는 페이지 응답이라는 API 호출과 페이지에 사용되는 data를 불러오는 API 호출을 추가적으로 요구하는 작업이기에 비효율적이라고 생각했습니다.

따라서, 유저에게 특정 페이지를 응답하기 이전에 middleware에서 조건을 검사해 불필요한 페이지 응답 및 API 호출을 막을 수 있었습니다.

다음은 실제 middleware 코드의 일부분입니다.

middleware.ts

import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export function middleware(request: NextRequest) {
  const cookies = request.cookies; // 1번 
  const hasAuthCookies = cookies.has('auth'); // 2번

  if (request.nextUrl.pathname === '/') {
    if (hasAuthCookies) {
      return NextResponse.redirect(new URL('/home', request.url));
    }
    return NextResponse.redirect(new URL('/login', request.url));
  } else if (request.nextUrl.pathname === '/home')  // 3번
    if (!hasAuthCookies) {
      return NextResponse.redirect(new URL('/login', request.url));
    }
  } else if (request.nextUrl.pathname === '/login') {
    if (hasAuthCookies) {
      return NextResponse.redirect(new URL('/home', request.url));
    }
  }

  ...

1. 페이지 요청에 담겨있는 cookies에 접근합니다.
2. cookies에 auth라는 key에 대한 값이 있는지 여부를 hasAuthCookies라는 변수에 저장합니다. 만약 로그인이 되어있는 유저의 요청이라면 auth라는 key에 대해 토큰 data가 값으로 들어있을 것입니다.
3. 예를 들어 내 계획 페이지(/home)에 접근했을 경우, 만약 로그인되지 않은 유저라면로그인 페이지(/login)로 리다이렉트 시킵니다.

📌 Tanstack-Query staleTime 설정 및 쿼리 무효화

data가 변경될 가능성이 거의 없는 페이지가 있다면, 이 페이지에 접근할 때마다 data를 서버에서 새로 받아오는 것은 불필요한 API를 호출하는 것일 수 있습니다. 그래서 저는 이를 해결하기 위해 Tanstack-Query의 staleTime과 쿼리 무효화 기능을 사용했습니다.

이를 위해 다음과 같은 단계를 거쳤습니다.

1. data를 받아오는 get 요청들에 대한 useQuery의 쿼리 키를 구조화합니다.
2. data가 변경될 가능성이 많이 없는 get 요청들에 대한 useQuery의 staleTime을 infinity로 설정합니다.
3. data를 변경하는 useMutation 요청이 실행됐을 때, 각 data에 해당하는 쿼리 키를 무효화합니다.
4. 쿼리 키가 무효화된 useQuery에 해당하는 data는 새로운 데이터로 업데이트됩니다.

data를 변경하는 useMutation 함수들이 호출 될 때, 어떤 get 요청을 무효화시켜줘야 하는지, get 요청에 해당되는 쿼리 키는 무엇인지 팀 기술 문서에 표로 정리했습니다.

이를 통해 data를 받아오는 요청과 업데이트 하는 요청 간의 관계를 한 눈에 파악할 수 있었습니다.

이러한 과정을 통해, 특정 data에 접근 시 무조건 서버로부터 data를 받아오는 것이 아니라, data가 변경이 되었을 때만 서버에서 새로운 data를 받아옴으로써 불필요한 API 호출을 줄였습니다.

예시 - 내 계획 페이지

위의 과정을 실제로 페이지 내에서 어떻게 적용했는지 살펴보겠습니다.

위 페이지는 내 계획 페이지입니다. 이 페이지에서는 본인이 생성한 계획들을 보여주는데, 이 data는 본인이 계획을 생성하거나 삭제하기 전까지는 변경될 가능성이 없습니다.

따라서, staleTime을 기본적으로 infinity로 설정해주고, 계획 생성 API와 계획 삭제 API가 호출될 경우에만 쿼리를 무효화해주었습니다.

자세한 과정은 다음과 같습니다.

1. 내 계획을 불러오는 get 요청에 대한 useQuery의 staleTime을 infinity로 설정합니다.

   export const useGetMyPlansQuery = () => {
     const { data } = useSuspenseQuery({
       queryKey: [QUERY_KEY.MY_PLANS],
       queryFn: getMyPlans,
       staleTime: Infinity,
     });
   
     return { myPlans: data! };
   };

2. 계획을 생성했을 때, 즉 계획을 생성하는 mutation 함수의 요청이 성공했을 때, 계획을 불러오는 query를 무효화합니다.

   export const usePostNewPlanMutation = () => {
     const queryClient = useQueryClient
   
     return useMutation({
       mutationFn: postNewPlan,
       onSuccess: () => {
         queryClient.invalidateQueries({
           queryKey: [QUERY_KEY.MY_PLANS],
         });
       },
     });
   };

   queryClient.invalidateQueries({
     queryKey: [QUERY_KEY.MY_PLANS],
   });

   이 부분에서 쿼리키를 기반으로 특정 쿼리만 무효화시켜주었음을 확인할 수 있습니다.

3. 이를 통해 내 계획 data를 페이지에 접근할 때마다 서버로부터 받아오는 것이 아니라 내 계획 data가 바뀌는 상황인 계획 생성과 계획 삭제에 성공했을 때만 새로 서버에서 data를 받아왔습니다.

Tanstack-query의 staleTime 및 쿼리 무효화 기능에 대한 자세한 설명 및 원리는 따로 TanStack-query staleTime & invalidQueries를 이용한 data 상태관리에 상세하게 정리해두었습니다.

📌 토글 버튼에 디바운스 처리 적용

저희 서비스에는 계획 공개 여부, 알림 여부 등의 상태를 toggle 할 수 있는 토글 버튼이 여러 페이지에 존재합니다. 아래 그림에서 파란색으로 감싸져있는 버튼들이 모두 토글 버튼입니다.

이러한 토글 버튼의 특성 상, 유저는 버튼을 연속으로 누를 수 있습니다. 만약 유저가 짧은 시간 동안 버튼을 굉장히 여러 번 누른다면 이는 그 횟수 만큼의 API 호출을 의미할 것입니다. 그래서 토글 버튼을 눌렀을 때 발생하는 API 호출에 대해 디바운스를 적용해 위와 같은 상황을 방지했습니다.

디바운스란 ?

이벤트를 그룹화하여 특정 시간이 지난 후 하나의 이벤트만 발생하도록 하는 기술입니다.

만약 유저가 짧은 시간 동안 특정 버튼을 연속해서 누른다면, 여러 번의 요청 중 마지막 요청만 서버에 전달하도록 했습니다. 유저가 자주 누를 가능성이 있는 계획 공개 버튼, 리마이드 알림 여부 변경 버튼의 토글 버튼에 디바운스 처리를 해줌으로써 잠재적인 API 호출 횟수를 줄일 수 있었습니다.

📌 결론

불필요한 API 호출을 줄여보자! 라는 생각으로 여러가지 방법들을 고민해보았고, 결론적으로는 다음과 같은 방법들을 적용했습니다.

1. Next.js middleware 기능을 이용한 페이지 요청 리다이렉트

2. Tanstack-query의 staleTime 설정 및 쿼리 무효화

3. 토글 버튼에 디바운스 처리 적용

앞으로도 API 호출을 더 효율적으로 할 수 있는 방법들에 대해 고민해보고, 현재 저희 서비스에 적용할 수 있는 상황이 된다면 적용하고 또 글로 정리해보려고 합니다!

올해도 아좌좌 프로젝트를 진행하며 하나의 페이지 내에서 관리되는 state와 하위 컴포넌트로 전달되는 prop이 너무 많아지는 문제를 경험했고, 이를 해결하는 과정을 담은 글입니다.

📌 하나의 페이지 내 여러 개의 state

저는 올해도 아좌좌 프로젝트에서 계획 작성 페이지의 구현을 담당했습니다.

다음과 같은 페이지인데, 한 눈에 보기에도 페이지 내에서 관리되는 data들이 많아 보입니다😅

계획 작성 페이지의 역할은 다음과 같습니다.

• 사용자로부터 계획 작성에 필요한 data를 입력 받습니다.
• 계획 생성 버튼을 눌렀을 때 계획 작성 API를 호출해 계획을 생성합니다.

페이지 level에서 계획 작성 API를 호출하기 위해서는 결국 모든 data들이 한 번에 request body에 담겨져 서버에 전송이 되어야 하므로, 계획 작성에 필요한 모든 data는 페이지 level에서 정의하고, 하위 컴포넌트에 prop으로 넘겨주는 방식으로 구현하기로 결정했습니다.

이렇게 결정한 후, 페이지 내 각 컴포넌트를 나눠보니 페이지 내 가장 하위 컴포넌트에 해당하는 RemindInput에 state가 전달되기까지 총 4개의 컴포넌트를 거쳐야 하는 prop drilling 현상이 발생했습니다.

아래 그림에서 파란색 직사각형으로 표시된 컴포넌트가 최하위 컴포넌트인 RemindInput입니다.

사실 prop의 전달이 4개의 컴포넌트를 거치는 것이 depth가 엄청 깊은 편은 아니라고 생각했지만, 하위로 전달되어야 하는 모든 data와 메서드들이 CreatePage에서 관리되었기 때문에 그 수가 너무 많았습니다.

export default function CreatePage() {
  const router 
  const [title, setTitle] = useState
  const [description, setDescription] = useState('');
  const [tags, setTags] = useState<string[]>([]);
  const [isPublic, setPublic] = useState(true);
  const toggleIsPublic = () => {
    setPublic(!isPublic);
  };

  const [remindOptions, setRemindOptions] = useState<RemindOptionType>({
    TotalPeriod: 12,
    Term: 1,
    Date: 1,
    Time: 9,
  });

  const [remindMessageList, setRemindMessageList] = useState<RemindItemType[]>(
    [],
  );

  const handleChangeRemindOption = () => {};
  const handleChangeRemindMessage = () => {};
  const fixRemindOptions = () => {};
  const makeAllRemindMessageSame = () => {};    

작성 페이지에서 관리되어야 하는 state와 이 state를 다루는 메서드들은 대략 위와 같았습니다. 이렇게 많은 state에 대한 prop drilling을 통해 다음과 같은 문제들이 발생했습니다.

• 길어지는 코드로 인해 코드의 가독성이 매우 나빠집니다.
• 중간 컴포넌트에 불필요한 프로퍼티가 전달되어 불필요한 복잡성을 초래할 수 있습니다.
• state 변경 시 props 전달 과정에 관여된 컴포넌트들에게 불필요한 리렌더링이 발생할 수 있습니다.

그래서 위와 같은 문제점들을 인지한 후, 좀 더 효율적인 방법으로 페이지 내의 data들을 관리할 수 없을까 고민을 시작했습니다.

📌 Recoil? ContextAPI?

prop으로 상태를 하위에 전달하는 방법의 문제점들을 해결하기 위해, Recoil과 ContextAPI의 사용을 고려하게 되었습니다.

상태 관리 도구인 Recoil과 ContextAPI 모두, state를 하위 컴포넌트에 prop으로 전달하는 방식이 아니라 원하는 위치에서 data를 불러와 사용할 수 있기 때문에 위에서 언급한 코드의 가독성 문제와 불필요한 프로퍼티 전달 문제 모두 해결할 수 있는 것처럼 보였습니다.

또한, Recoil을 사용했을 때에도 여전히 발생할 수 있는 불필요한 렌더링 문제를 막기 위해 atom 객체에 각 속성에 대한 selector의 get과 set을 정의하는 방법을 생각해 팀원분에게 이를 제안하기도 했습니다.

하지만, prop으로 data를 전달하는 방식의 문제점을 해결해주는 Recoil과 ContextAPI를 사용했을 때에도, 새로운 문제가 있었습니다.

💡 컴포넌트에서 전역 상태를 구독하는 순간, 그 컴포넌트는 재사용이 어려워진다.

위의 그림에서 보듯이 왼쪽의 계획 작성 페이지와 오른쪽의 계획 수정 페이지는 한 눈에 보기에도 그 구조가 상당히 유사합니다. 그래서 이 두개의 페이지에서는 공통으로 사용되는 WritableRemind 컴포넌트와 WritableRemindItem 컴포넌트가 있습니다.

하지만 작성 페이지와 수정 페이지는 서로 역할이 다른 페이지이고, 호출되어야 하는 API가 다릅니다. 따라서, 필요한 data의 구조와 성격이 조금씩 다릅니다. 그렇기 때문에 만약 Recoil을 사용한다면, 각각 서로 다른 atom을 구독해야하고 이렇게 되면 두 페이지에서 공통으로 쓰이는 컴포넌트는 각 페이지에서 사용되는 서로 다른 두 개의 atom을 구독하고 있어야 하나,,? 라는 생각이 들었습니다. 이렇게 되면 그 컴포넌트가 다루어야 하는 data의 수도 많아질 것이고, 자칫하면 컴포넌트를 분리해야 할 수도 있습니다.

prop으로 data를 전달하는 방식의 문제를 해결하기 위해 전역 상태 관리를 사용하려고 했지만, 특정 컴포넌트가 전역 상태를 구독하는 순간 그 컴포넌트의 재사용성이 줄어드는 문제가 예상되었고, 이는 적절한 해결방법이 아닌 것 같아 도입하지 않았습니다.

📌 prop 방식 사용, but 리액트 훅 최적화하기!

문제를 해결하기 위한 다른 방법들도 생각해보았습니다.

• React-hook-form 사용
• 페이지의 분리 => 계획 작성을 여러 단계로

구현 중이었던 계획 작성 페이지는 사실상 사용자로부터 data를 입력받아, 이를 조합해 서버로 전송하는 폼의 역할을 했기 때문에 React-hook-form이라는 라이브러리를 사용하면 좀 더 쉽게 상태 관리를 할 수 있지 않을까라는 생각도 들었습니다.

또한, 하나의 페이지 안에 애초부터 너무 많은 data와 로직이 담기도록 설계한 것은 아닌가 하는 생각도 들어서 페이지를 분리해 계획 작성 단계를 분리하는 방향도 생각해보았습니다.

하지만 결론적으로는, 두 방식 모두 도입하지 않았습니다.

그 이유는, 두 가지 방법 모두 "시간" 이라는 추가적 비용이 상대적으로 많이 발생하는 방법이었고 프로젝트 완성이라는 목표를 생각했을 때, 좋은 해결 방법이 아니었기 때문입니다.

두 가지 방법 모두 기술적으로는 더 뛰어난 선택이었을 수도 있지만 당시 저는 마감 기간이 정해져 있는 프로젝트를 팀원들과 함께 진행 중이었고, 프로젝트의 가장 최우선 목표는 기술적으로 뛰어난 구현이 아니라, 마감 기간 내의 프로젝트 완성이었습니다.

그래서 결국 저는 기존처럼 prop으로 data를 하위로 전달하는 방식으로 state를 관리하되, 불필요한 렌더링이 발생하지 않도록 리액트 훅 최적화를 진행하고 프로젝트 완성 이후 페이지를 분리하는 방식으로 진행하기로 결정했습니다.

리액트 훅을 최적화했던 예시는 다음과 같습니다.

useMemo()

const filteredTermOptions = useMemo(() => {
  return TERM_OPTIONS.filter(
    (option) => option.value <= remindOptions.TotalPeriod,
  );
}, [remindOptions.TotalPeriod]);

const isRemindMessageEmpty = useMemo(() => {
  return remindMessage.length === 0;
}, [remindMessage]);

다음과 같이 렌더링 시마다 재선언 될 필요가 없는 변수는 특정 data가 변할 때만 재선언 될 수 있도록 해주었습니다.

React.Memo()

export default React.memo(function WritableRemindItem({
  remindMonth,
  remindDay,
  remindMessage,
  handleChangeRemindMessage,
  makeAllRemindMessageSame,
  classNameList = [],
}: WritableRemindItemProps) {
// 이하 생략

작성 페이지에서는 prop으로 data가 전달되는 depth가 최대 4번까지 있었기에, 자식 컴포넌트가 불필요하게 리렌더링 될 수 있는 상황이 있었습니다.

그래서 작성 페이지 컴포넌트나 상위 컴포넌트의 상태가 변경되어 리렌더링 될 때, 하위 컴포넌트의 상태나 prop이 변경되지 않았다면 하위 컴포넌트는 불필요한 리렌더링이 일어나지 않도록 React.memo()를 사용해주었습니다.

useCallback()

const handleChangeRemindOption = useCallback(
  (optionKey: string, newOptionValue: number) => {
    setRemindOptions
      ...remindOptions,
      [optionKey]: newOptionValue,
    });
  },
  [remindOptions, setRemindOptions],
);

리액트에서 컴포넌트가 리렌더링 될 때, 컴포넌트 내 정의된 함수도 재정의되기 때문에 만약 이 함수가 자식 컴포넌트에게 전달된다면 자식 컴포넌트로 전달되는 prop이 변하는 것이기 때문에 자식 컴포넌트도 리렌더링 될 것입니다.

위의 handleChangeRemindOption 메서드는 하위 컴포넌트로 전달되는 함수였기에, 렌더링 될 때마다 하위 컴포넌트가 계속 리렌더링 될 것입니다.

그래서 useCallback을 사용해 연관된 data가 변하지 않는다면 함수를 재정의하지 않도록 해주어 하위 컴포넌트의 불필요한 리렌더링을 방지했습니다.

📌 결론

위의 글을 정리해보자면, 다음과 같습니다.

1. 페이지 내에서 관리해야 할 state와 prop이 너무 많다는 문제를 마주했습니다.
2. 이를 해결하기 위해 여러가지 방법을 고려해보았습니다.
   • Recoil
   • ContextAPI
   • React-hook-form
   • 페이지의 분리
3. 페이지에서 state와 prop으로 data를 관리하되, 리액트 훅을 최적화하는 방법으로 문제를 해결했습니다.

앞으로도 개발을 하며 크고 작은 다양한 문제들을 만날텐데, 그 때마다 이를 해결하기 위한 여러 가지 방법들의 장점과 비용을 계산해보고, 이를 바탕으로 근거 있고 합리적인 선택을 하는 개발자가 되려고 합니다!

올해도 아좌좌 프로젝트 초기에 공통 컴포넌트를 설계하며 컴포넌트의 책임에 대해서 고민해보았고, 그 생각의 과정을 담은 글입니다.

📌 공통 컴포넌트의 책임

일반적으로 공통 컴포넌트는, 다양한 페이지와 컴포넌트에서 사용할 수 있는 가장 기본적인 단위의 컴포넌트를 말합니다. 저는 이번 프로젝트에서 Icon, Dropdown, Input, CircleProgressBar 등의 공통 컴포넌트를 담당했습니다.

가장 작은 단위의 컴포넌트인 공통 컴포넌트를 만들면서, 공통 컴포넌트의 책임을 어디까지로 정의해야할 지 고민되기 시작했습니다.

만약 컴포넌트에 필요한 data가 있다면

• 이를 컴포넌트 내에서 컴포넌트 자체의 state로 정의해야 할지
• 외부에서 prop으로 넘겨받아 사용해야 할지

를 결정해야 했습니다.

예를 들어 사용자로부터 text를 입력받는 Input 컴포넌트를 만든다면, 다음과 같이 고민할 수 있습니다.

1. Input 컴포넌트 내 자체 state를 정의 O

• 외부에서 text를 나타내는 state와 이 state의 값을 변경하는 setState 메서드를 prop으로 전달받습니다.
• 전달받은 state값을 초기값으로 Input 컴포넌트 내 자체 state(앞으로 편의상 state_input로 지칭)를 정의하고, 이를 Input 컴포넌트 내 input 태그와 연결해 사용자가 입력하는 text가 바뀔 때마다 state_input이 업데이트 되도록 해줍니다.
• state_input이 업데이트 될 때마다 setState함수를 실행해 컴포넌트 외부의 state도 동기화되도록 해줍니다.

2. Input 컴포넌트 내 자체 state 정의 X

• 외부에서 text를 나타내는 state와 이 state의 값을 변경하는 setState 메서드를 prop으로 전달받습니다.
• input 태그에 입력되는 사용자 입력이 변경될 때마다, setState를 실행해 외부의 state를 업데이트하고, 이 값이 다시 Input 컴포넌트에 prop으로 전달되면서 Input 컴포넌트가 전달받는 state값이 변경됩니다.

이렇게 공통 컴포넌트가 자체 state를 가져야 할지의 고민으로부터 시작해 컴포넌트의 책임에 대해서 여러 글들을 찾아보며 고민해보았습니다.

그 결과 이는 상황에 따라 다르다 (Case By Case😭) 라는 결론을 내렸습니다. 결국 상황과 조건에 따라 판단해야한다는 뜻인데, 이를 판단할 때 어떠한 점들을 고려할 수 있는지에 대해서 알게 되었습니다.

📌 역할과 중복

1. 역할

첫 번째로, 컴포넌트의 역할입니다.

모든 컴포넌트는 그 종류와 범위는 다를 수 있어도 각자 고유한 역할이 있어야합니다.

이번에는 toggleButton 컴포넌트를 예시로 들어보겠습니다.

toggleButton에 대해서 생각하면 대부분 위와 같은 이미지를 떠올리실 겁니다.

이러한 이미지에서도 직관적으로 알 수 있듯이 toggleButton이란 말 그대로 토글을 해주는 역할을 하는 버튼입니다. 이는 즉, 특정 값을 계속 switch 해주는 동작을 해야한다고 생각할 수 있습니다.

이렇게 컴포넌트의 고유한 역할을 생각해보았을 때, 값을 토글하는 EX) setState(!state) 같은 로직은 토글 버튼의 고유한 기능이므로 컴포넌트 안에 정의되어야 하는 것이 바람직하다고 생각할 수 있습니다.

즉, toggleButton의 고유한 역할인 값을 toggle 한다라는 측면에서 생각해보았을 때 toggleButton 컴포넌트는 자체 state를 가지는 것이 자연스럽다고 판단할 수 있습니다.

2. 중복

두 번째로는 중복입니다.

위에서 말했듯이 toggleButton은 특정 값을 toggle 해주는 역할을 담당할 것이고, 이 로직을 간단히 코드로 나타내면 다음과 비슷할 것입니다.

const toggleState = (state, setState) => {
    setState(!state);
}

만약 toggleButton 내부에 위와 같은 로직을 작성하지 않고, 컴포넌트 외부에서 이를 작성해서 넣어준다면, toggleButton을 사용하는 모든 곳에서 위와 같은 toggleState 함수를 정의해서 넣어줘야 할 것입니다.

이를 중복의 측면에서 생각해보면, toggleButton이 사용되는 페이지가 많아질 수록 위 로직을 계속 정의해줘야 할 것이고, 결국 이는 불필요한 중복이라고 생각할 수 있습니다.

따라서 이러한 경우에는 toggleButton 내에 자체 state를 정의하고 그 state를 이용해 toggle 하는 로직까지 정의하는게 적절하다고 생각했습니다.

또한, 실제로 toggle 하려고 하는 외부의 state를 변경하는 setState 메서드만 외부에서 toggleButton 컴포넌트로 넘겨주고 필요할 때마다 이를 호출해 실제 state와 컴포넌트 내부의 state를 동기화 시켜줄 수도 있을 것입니다.

=> 이렇게 컴포넌트의 고유한 역할에 대한 로직을 내부에 정의함으로써 외부로 노출할 필요가 없는 부분은 캡슐화가 되는 효과 또한 얻을 수 있습니다.

📌 컴포넌트 정의 예시 - DebouceSwitchButton

그러면 위와 같이 컴포넌트의 역할과 중복을 고려해 실제 프로젝트에서 공통 컴포넌트를 어떻게 구현했는지 보여드리겠습니다.

DebounceSwitchButton

위에 보이는 버튼이 DebounceSwitchButton 입니다. toggle 버튼과 비슷하게 보이지만, 단순히 값을 toggle 하는 기능과 더불어 다른 책임들도 가지고 있습니다.

• 클릭될 때마다 컴포넌트 자체의 상태는 계속 toggle 되어 사용자 입장에서는 값이 바뀐 것처럼 보여야 합니다.
• 실제 서버 상태의 toggle을 일으키는 api 호출은 디바운스를 이용해 처리하고, 그 처리 자체도 원래 기존값과 다를 때만 호출해줍니다. (값이 toggle되기 때문에 컴포넌트의 상태가 변하지 않는다면 서버의 상태도 변하지 않아야 하므로)

  예를 들어, 사용자가 빠르게 두번 클릭했을 때는 사용자 입장에서는 값이 바뀌었다가 다시 원래대로 돌아온 것 처럼 느껴야하므로 클라이언트의 상태를 2번 toggle 해줍니다. 하지만, 디바운스를 적용한 서버 api 호출은, 결국은 2번 toggle 되어 값이 바뀌지 않았으므로 호출해줄 필요가 없습니다.

이러한 책임을 가진 DebounceSwichButton은 값을 toggle 해주는 자신의 고유한 역할도 담당할 뿐 아니라, debounce를 적용한 서버 api 호출을 통해 api 호출을 최소화하는 역할도 담당합니다. 실제로 위 동영상을 통해 빠르게 버튼을 2번 클릭했을 때는, 서버 api를 호출하는 콘솔이 출력되지 않는 것을 확인할 수 있습니다.

구현 방법

DebounceSwichButton을 코드 상에서 어떻게 구현했는지 살펴보겠습니다.

props

interface DebounceSwitchButtonProps {
  defaultIsOn: boolean; // 실제로 toggle 하려는 상태의 초기값  
  submitToggleAPI: () => void; // 실제 서버의 값을 toggle하는 API 함수  
  toggleName: ToggleName; // toogleButton 사용 용도 
}

DebounceSwichButton은 다음과 같은 props를 외부에서 전달받습니다.

• defaultIsOn : toggle하려는 서버 상태의 초기값
• submitToggleAPI() : 실제 서버 상태의 값을 toggle하는 API 통신 함수
• toggleName : toggleButton의 사용 용도를 나타내는 string literal 값

toggle 상태의 초기값과 toggle API 통신 함수는 컴포넌트 호출 시 매번 달라져야하는 값이므로 defaultIsOn과 submitToggleAPI는 props로 정의해 외부에서 전달받도록 했습니다. 또한, toggleName도 외부에서 전달받도록 하고, 컴포넌트 내부에서 toggleName에 따른 분기처리를 통해 렌더링 해줄 버튼의 text와 icon 등을 결정했습니다. => 즉, 위와 같은 3개의 값 모두 컴포넌트 자체에서 판단할 수 있는 data가 아니고, 호출 시마다 달라져야 하는 값이기 때문에 컴포넌트의 고유한 역할에서 제외된다고 생각해 prop으로 정의했습니다.

state

const [isOn, setIsOn] = useState(defaultIsOn); // 컴포넌트에서 toggle 되는 state
const [originalIsOn, setOriginalIsOn] = useState(defaultIsOn); // 

const toggleIsOn = () => { // 컴포넌트 자체 상태 toggle 함수
  setIsOn(!isOn);
};

const submitIfReallyChanged = () => {
  if (isOn !== originalIsOn) {
    submitToggleAPI();
    setOriginalIsOn(isOn);
  }
};

useDebounce(submitIfReallyChanged, 500, [isOn]); // 디바운스 적용

• [isOn, setIsOn] : defaultIsOn을 초기값으로 하는 컴포넌트에서 toggle 되는 컴포넌트 자체 state
• [originalIsOn, setOriginalIsOn] : 값이 여러번 toggle 되었을 때 값이 실제로 변경되었을 때만 서버 api를 호출해주기 위해 isOn과 비교할 state
• toggleIsOn() : 컴포넌트 자체 상태를 toggle 함수
• submitIfReallyChanged() : 값이 여러 번 toggle 되었을 때 값이 실제로 변경되었을 때만 서버 api를 호출해주는 함수
• useDebounce() : 컴포넌트 내부에서 디바운스 적용

컴포넌트 자체 toggle state, toggle 함수, 값이 여러번 toggle 되었을 때 값이 실제로 변경되었을 때만 서버 api를 호출해주는 함수, 디바운스 등은 컴포넌트 내부에서 정의해주었습니다. 이러한 값들은 외부에서 어떤 초기값, 서버 API 통신 함수를 전달받더라도, _동일하게 사용될 수 있는 data_들이기 때문에 DebounceSwitchButton 컴포넌트의 고유한 역할이 될 수 있고, 중복 측면에서도 컴포넌트 내부에 정의하는 것이 좋겠다고 생각했습니다.

호출 예시 및 전체 코드

다음은 실제로 DebounceSwitchButton 컴포넌트를 호출하는 예시 및 전체 코드입니다.

호출 예시

 <DebounceSwitchButton
        defaultIsOn={serverIsOn} // toggle하려는 서버 상태의 기본값이 on or off
        submitToggleAPI={submitToggleAPI} 
        toggleName="remind"
      />

전체 코드

type ToggleName = 'public' | 'ajaja' | 'remind';

const toggleText = {
  public: {
    on: '계획 공개',
    off: '계획 비공개',
  },
  ajaja: {
    on: '월요일 18:00 마다\n응원 메세지 알림 활성화',
    off: '응원 메세지 알림 비활성화',
  },
  remind: {
    on: '리마인드 알림 활성화',
    off: '리마인드 알림 비활성화',
  },
};

interface DebounceSwitchButtonProps {
  defaultIsOn: boolean;
  submitToggleAPI: () => void;
  toggleName: ToggleName;
}

export default function DebounceSwitchButton({
  defaultIsOn,
  submitToggleAPI,
  toggleName,
}: DebounceSwitchButtonProps) {
  const [isOn, setIsOn] = useState(defaultIsOn);
  const [originalIsOn, setOriginalIsOn] = useState(defaultIsOn);

  const toggleIsOn = () => {
    setIsOn(!isOn);
  };

  const submitIfReallyChanged = () => {
    if (isOn !== originalIsOn) {
      submitToggleAPI();
      setOriginalIsOn(isOn);
    }
  };

  useDebounce(submitIfReallyChanged, 500, [isOn]);

  return (
    <div className={classNames('debounce-switch')}>
      <IconSwitchButton
        onIconName={toggleName === 'public' ? 'PLAN_OPEN' : 'NOTIFICATION_ON'}
        offIconName={
          toggleName === 'public' ? 'PLAN_CLOSE' : 'NOTIFICATION_OFF'
        }
        onClick={toggleIsOn}
        isActive={isOn}
      />
      <span className={classNames('debounce-switch__text')}>
        {isOn ? toggleText[toggleName].on : toggleText[toggleName].off}
      </span>
    </div>
  );
}

📌 맺음말

공통 컴포넌트의 책임에 대해 고민하면서, 컴포넌트의 역할과 중복을 고려하려 책임을 결정할 수 있다는 사실을 알게 되었습니다. 여기서 끝나는 것이 아니라, "리액트 컴포넌트를 잘 설계한다는 것은 무엇일까?" 라는 고민으로 확장시켜 컴포넌트에 대해 더욱 본질적으로 공부해볼 계획입니다🔥

TanStack-Query에서는 useQuery를 이용해 서버의 data를 받아올 수 있고, data의 staleTime과 gcTime을 설정해줌으로써 서버 data의 상태를 관리할 수 있다. 이러한 staleTime, gcTime과 invalidQueries를 활용해 어떻게 서버 data의 상태 관리를 효율적으로 할 수 있는지 알아보자.

📌 staleTime

• 캐시된 data가 신선한 상태(fresh)로 남아있는 시간을 말한다.

• 특정 data에 대해 설정해준 stale time이 지나게되면, 그 data는 신선하지 않은 상태(stale)로 간주된다.

• 따로 stale time의 값을 설정해주지 않으면 기본값은 0이다.

  => data를 fetch 해오자마자 data를 신선하지 않다고 간주하는 것 !

• 특정 쿼리 키에 대한 data를 다시 fetch 해와야 하는 상황일 때,

  • 해당하는 data가 fresh한 상태라면, API 호출 없이 캐싱된 data가 다시 사용된다.
  • 해당하는 data가 stale한 상태라면, API 호출을 통해 신선한 data를 다시 fetch해오고, 이 data를 cache에 저장한다.

=> 즉, 서버로부터 새로 data를 받아오지 않고 캐시된 data를 최신의 data로 간주하고 사용하기 위해 설정해주는 조건이다.

📌 gcTime

• 메모리에 저장된 캐싱 데이터가 유효한 시간(캐시 메모리에 남아있는 시간)을 의미한다.

• 쿼리를 사용하는 모든 컴포넌트가 언마운트되었을 때, 쿼리는 비활성화(inactive 상태)되고 비활성화된 데이터는 gcTime이 지난 후, 캐시에서 삭제된다.

  쿼리를 사용하는 컴포넌트가 언마운트 되지 않고 계속 마운트된 상태로 화면에 계속 보여진다면, cache data는 계속 남아있다.

  => 쿼리를 사용하는 모든 컴포넌트가 언마운트 된 이후부터 gcTime이 지나야 캐시 데이터가 삭제되기 때문이다.

• 캐싱 데이터가 없다면, 특정 query key에 해당하는 쿼리 호출 시, 다시 API 요청을 통해 data를 받아온다.

• 따로 gcTime의 값을 설정해주지 않으면 기본값은 5분이다.

📌 staleTime, gcTime에 따른 data fetch

그렇다면 staleTime과 gcTime가 어떻게 설정되어있는지에 따라 data fetch가 어떻게 달라지는지 각 상황을 통해 알아보자.

특정 data를 fetch 할 때

1. staleTime 아직 안 지남, gcTime 아직 안 지남

   => API 요청 X, 캐시 데이터 사용

2. staleTime 아직 안 지남, gcTime 지남

   => staleTime은 아직 지나지 않아서 cache data를 최신의 data로 간주하고 사용하고 싶은데 gcTime이 지나서 cache에 data가 없는 상황

   => API 요청으로 새로운 data 받아와야 함

   사실 이런 경우는 해당 쿼리가 포함된 페이지나 컴포넌트가 새로 다시 mount되는 경우일 것이다.

   => 만약 unmount 되지 않고 계속 해당 쿼리가 활성화 상태라면 cache에 data가 계속 있는 상태였을 것이므로

   => unmount 되었다가 다시 mount되어 다시 data fetch 하는 경우일 듯

   EX)

   export const useGetContentList = (type: string, title: string, page: number) => {
     const { data } = useQuery(
       [{ scope: "ContentList", type, title, page }],
       () => {
         console.log(`fetch Data: ${type},${title}, ${page}`);
         return getContentList(type, title, page);
       },
       {
         staleTime: 1000000,
         gcTime: 100,
         select: (data) => {
           return data?.contentList;
         },
       }
     );
   
     return {
       contentListData: data,
     };
   };

   위와 같이 gcTime을 엄청 짧게 설정해, 쿼리가 inactive된 후 바로 삭제되도록 했을 때, 다시 해당 쿼리가 불렸을 때 다시 data를 fetch해오고 이를 cache에 추가하는 것을 확인할 수 있었다.

3. staleTime 지남, gcTime 아직 안 지남

   => API 호출로 새로운 신선한 data를 받아오는데, 받아오기 전까지는 cache data를 보여줌

   여기서 해당 useQuery에 대한 isLoading 값은 계속 false이기 때문에 사용자는 loading 화면을 보고 있지 않아도 된다.

4. staleTime 지남, gcTime 지남

   => API 호출로 새로운 신선한 data를 받아오고, 받아오기 전까지는 보여줄 data 없음

위의 각 상황들을 정리해보면 !

fetch나 refetch를 통해 data를 불러올 때

• staleTime 안 지나면 cache data 사용
  • gcTime 지나서 cache data 없으면 => refetch
• staleTime 지나면 무조건 새로운 data 받아오는 것
  • 새로운 data 받아오는 동안, cache data가 있으면 이를 보여주다가 새로운 data로 교체해주는 것

📌 invalidQueries

tanstack query는 특정 쿼리를 무효화해주는 invalidQueries 메서드를 제공한다.

// 캐시의 모든 쿼리를 무효화함
queryClient.invalidateQueries();


// `todos`로 시작하는 쿼리키를 가지는 모든 쿼리를 무효화함
queryClient.invalidateQueries({ queryKey: ['todos'] });

쿼리를 무효화한다는 것은 무슨 뜻일까 ? invalidateQueries 메서드를 통해 특정 쿼리를 무효화하면, 다음과 같은 두 가지 현상이 발생한다.

• 해당 쿼리의 상태를 stale로 바꾼다. stale된 상태는 useQuery 또는 관련 훅에서 사용 중인 모든 staleTime 구성에 오버라이드한다.
• 만약 useQuery 나 관련 훅을 통해 쿼리가 렌더링되고 있다면 백그라운드에서도 refetch한다.

=> 그래서 invalidQueries 메서드를 이용해 특정 쿼리를 무효화하면, 해당 쿼리의 data를 신선하지 않은 상태로 간주해 이후 data를 fetch 할 때 캐시의 data가 아닌 서버로부터 새로운 data를 받아올 수 있도록 하는 것이다.

📌 queryKeys

queryKeys 란?

1. React Query에서는 query keys를 기반으로 해서 쿼리 캐싱을 관리한다.
2. query key는 문자열, 문자열의 배열 혹은 중첩된 객체(nested object)로 지정 가능하다.
3. query keys는 query data에 고유하고 직렬화하여 사용해야한다.

queryKey에 queryFunction의 변수 포함하기

공식 문서에서는 다음과 같이 쿼리 키를 지정하도록 권장한다.

쿼리 키는 쿼리 function에 대한 dependencies의 역할을 한다. 쿼리 function이 의존하고 있는 변수들을 쿼리 키 배열에 넣음으로써, 각 쿼리 키에 해당하는 쿼리들이 독립적으로 cache되고, 변수가 변할 때마다 각 쿼리들이 자동적으로 refetch 되도록 할 수 있다.

📌 쿼리가 refetch 되는 조건

• 새로운 Query Instance가 마운트 될 때 ( 페이지를 이동했다가 왔을 경우 )
• 브라우저 화면을 이탈했다가 다시 Focus 할 때
• 네트워크가 다시 연결될 때
• 설정한 refetch interval에 의한 경우
• queryKey에 특정 state가 포함되고, state값이 변경될 경우

staleTime && refetch

staleTime이 0으로 설정되어있다면 data를 fetch 하는 즉시 stale한 상태로 변하게 되고, refetch가 일어나는 조건과 일치하게 되면 데이터가 패치됩니다.

즉, staleTime이 지나 data가 stale 한 상태가 되더라도, 바로 refetch가 일어나는 건 아니다.

만약 그렇다면 기본 staleTime은 0인데 페이지에 그대로 있어도 data가 무한으로 계속 refetch 될 것이다.

=> staleTime이 지나고 && refetch가 일어나는 조건에 해당될 때 refetch가 일어나는 것

refetch의 전제조건은 데이터가 stale한 상태여야 한다.

⇒ 다른 페이지 갔다가 와서 새로 mount 되더라도, data가 fresh 하다면 refetch 하지 않는다. (ex) 작성하고 다시 홈페이지가면 업데이트 x)

=> 대신 새로고침할 때는 무조건 refetch 된다. ( refetch라고 부르는 것이 올바르지 않은 듯)

📌 staleTime, InvalidQueries를 이용한 data 상태 관리

위에서 살펴본 queryKeys, staleTime, InvalidQueries의 개념을 서로 연결해 data의 상태를 어떻게 효율적으로 관리할 수 있는지 알아보자 !

특정 data가 자주 변경되지 않고, 특정 상황에서만 변경이 된다면 다음과 같은 방법으로 data를 관리할 수 있다.

1. 해당 query의 staleTime을 infinity로 설정
2. data가 변경되는 상황일 때, 해당 data에 해당하는 쿼리 키 기반으로 쿼리 무효화 invalidQueries 실행
3. data가 stale 해졌으므로, 서버에서 data를 새로 받아온다.

이를 통해 , 특정 페이지에 접근할 때마다 무조건 서버로부터 data를 받아오는 것이 아니라, data가 변경이 되었을 때만 서버에서 새로운 data를 받아옴으로써 불필요한 API 호출을 줄일 수 있다.

실제 나의 프로젝트에서 적용했던 예시를 살펴보면,

1. 내 계획을 불러오는 get 요청에 대한 useQuery의 staleTime을 infinity로 설정해주고

export const useGetMyPlansQuery = () => {
  const { data } = useSuspenseQuery({
    queryKey: [QUERY_KEY.MY_PLANS],
    queryFn: getMyPlans,
    staleTime: Infinity,
  });

  return { myPlans: data! };
};

2. 계획을 생성했을 때, 즉 계획을 생성하는 mutation 함수가 성공했을 때, 계획을 불러오는 query를 무효화 시켜줬다.

export const usePostNewPlanMutation = () => {
  const queryClient = useQueryClient();

  return useMutation({
    mutationFn: postNewPlan,
    onSuccess: () => {
      queryClient.invalidateQueries({
        queryKey: [QUERY_KEY.MY_PLANS],
      });
    },
  });
};

여기서 쿼리키를 기반으로 특정 쿼리만 무효화시켜주었음을 확인할 수 있다.

queryClient.invalidateQueries({
     queryKey: [QUERY_KEY.MY_PLANS],
   });

3. 이를 통해 내 계획 data를 페이지에 접근할 때마다 서버로부터 받아오는 것이 아니라 내 계획 data가 바뀌는 상황인 계획 생성에 성공했을 때만 새로 서버에서 data를 받아올 수 있었다.

🙇🏻‍♂️ 참고

리액트 쿼리의 staleTime과 cacheTime

공식문서 - query keys

queryKey 작성방법 및 특징

React query : Query Invalidation

10월은 중간 프로젝트를 통해 배우고 느낀 점들을 바탕으로 최종 프로젝트를 준비하고 시작하는 한 달이었다. 그 과정에서 있었던 일을 KPT 방식으로 회고해보고자 한다.

📌 K: Keep

next.js를 기술 스택으로 선택한 것

최종 프로젝트를 앞두고 팀원들끼리 next.js 를 사용할 지 말지에 대해 오랜 시간 고민했다. 모두가 다 한 번도 사용해보지 않았기에 사용하는 것에 대한 부담감과 두려움이 컸다. 하지만 단순히 그러한 이유 때문에 특정 기술의 사용 여부를 결정하는 것은 좋지 않다고 생각했다.

그래서 팀원들 모두 프로젝트 시작 전, 각자 미니 프로젝트를 진행하며 next.js를 공부하고 사용해보며 next.js를 통해 얻을 수 있는 장점과 사용하는 이유에 대해 깊게 고민해보았다.

나의 경우, 우선 웹 페이지 구성 방식과 렌더링 방법부터 자세히 공부했고 next.js가 제공하는 렌더링 방식에 대해서도 공부하며 어떤 상황에서 어떤 렌더링 방식을 사용하는 것이 좋을지에 대해서 고민해보았다.

그래서 결론적으로는 특정 페이지와 컴포넌트에 따라 이에 맞는 렌더링 방식을 선택할 수 있는 next.js를 사용하기로 결정했다.

부족한 부분을 공부한 것

중간 프로젝트를 하면서 많은 것을 배웠지만, 동시에 나의 부족한 부분도 알게 되었다. 기능 구현에 급급해 특정 기술을 고민 없이 얕게만 사용했던 부분도 있다. 그래서 최종 프로젝트를 본격적으로 시작하기 전까지 부족한 부분들에 대해 학습했다.

러닝 타입 스크립트 책을 읽으며 공부한 내용을 챕터별로 기록을 남기고 있고, 중간 프로젝트 때 react- query를 사용하면서 헷갈렸던 개념인 stale-time, cache-time에 대한 내용을 시작으로 더 깊게 학습하고자 노력했고, 쿼리 키에 대한 중요성도 많이 느낄 수 있었다.

이를 바탕으로 최종 프로젝트에는 기술을 더욱 더 깊게 이해하고 사용해보려고 노력할 것이다.

📌 P: Problem

프로젝트 진행 상황이 느린 것

처음으로 정했던 프로젝트 주제가 불분명한 문제 상황, 서비스화의 어려움, 팀원들간의 맞지 않는 관심사 등의 이유로 반려당했다. 그 주제로 와이어프레임 및 플로우차트까지 작성하고 있던 상황에서 주제를 바꿔야했고, 이 때문에 현재 프로젝트는 처음의 예상보다는 느리게 진행되고 있다.

또한, React를 기반, emotion-styled 방식으로 스타일을 적용했던 중간 프로젝트와 달리 최종 프로젝트에서는 next.js 기반, SCSS 방식으로 스타일을 적용하고 있다. css-in-js인 emotion-styled 방식으로 스타일을 적용할 때는 prop을 넘겨주어 이에 맞는 스타일을 쉽게 적용할 수 있었다.

하지만 지금은 SCSS를 사용하면서 각 컴포넌트의 class 이름을 통해 특정 스타일을 적용해주고 있는데, 이 과정에서 어떤 구조가 효율적일지 고민하고 이를 서로 통일하는 과정에서 생각보다 많은 고민과 시간이 걸리는 것 같다.

📌 T: Try

속도보다는 방향

위에서 언급한 Problem인 프로젝트 진행 상황이 느리다는 점과 더불어 최종 프로젝트의 볼륨이 너무 작다는 점도 사실 걱정 중 하나였다. 하지만 프로젝트 볼륨이 작은 것을 걱정하기보다는, 오히려 볼륨이 크지 않기에 코드의 품질을 높이고, 구조를 더 효율적으로 짜보고, 사용 기술에 대해 더 깊게 고민해볼 수 있지 않을까라는 생각도 든다.

진행 상황이 너무 느려서도 안 되겠지만, 언젠가는 짚고 넘어가야 할 문제들에 대해서 고민하고, 이를 통일하려고 노력하는 과정이라면, 결국 지금 시간이 조금 걸리더라도 확실하게 잡고 가야할 것이라고 생각한다.

"속도보다는 방향" 이라는 말이 있다. 남은 기간 동안 프로젝트를 진행하면서, 어떤 구조가 더 좋을지 고민하고, 이 기술을 왜 사용하는 지, 적절하게 사용하고 있는지 고민하고, 주어진 기간안에 서비스를 완성하는 것을 목표로 최선을 다해봐야겠다 !

필수 매개변수

JS에서는 인수의 수와 상관없이 함수를 호출할 수 있다. 하지만 TS는 함수에 선언된 모든 매개변수가 필수라고 가정한다. 함수가 잘못된 수의 인수로 호출되면 TS는 타입 오류의 형태로 의의를 제기한다.

함수의 인수가 잘못되면 오류는 표시하지만 실행은 되는 듯 ?

선택적 매개변수

함수에서 사용되는 모든 선택적 매개변수는 마지막 매개변수여야 한다. 필수 매개변수 전에 선택적 매개변수를 위치시키면 다음과 같이 TS 구문 오류가 발생한다.

function announceSinger(singer?: string, song: string){

}

기본 매개변수

JS에서 선택적 매개변수를 선언할 때 =와 값이 포함된 기본값을 제공할 수 있다.

즉, 선택적 매개변수에는 기본적으로 값이 제공되기 때문에 해당 ts 타입에는 암묵적으로 함수 내부에 | undefined 유니언 타입이 추가된다.

function rateSong(song: string, rating = 0){
    console.log(`${song} gets ${rating}/5 stars !`;
}

rateSong("Photograph");
rateSong("Set Fire to the Rain", 5);

다음 rateSong 함수에서 rating은 number 타입으로 유추되지만, 함수를 호출하는 코드에서는 선택적 number | undefined가 된다.

나머지 매개변수

... 스프레드 연산자 이용

function singAllTheSongs(singer: string, ...songs: string[]){
    for(const song of songs){
        console.log(`${song}, by ${singer}`);
    }
}

📌 반환 타입

ts는 함수가 반환할 수 있는 모든 가능한 값을 이해해 함수의 반환타입을 알려고 노력한다.

따라서 일반적으로 함수의 반환 타입을 명시하지 않는 것이 좋지만, 특정 상황에서는 반환 타입을 명시하는 방식이 유용할 때가 있다.

• 가능한 반환 값이 많은 함수가 항상 동일한 타입을 반환하도록 강제
• 재귀 함수의 반환타입을 통해 타입을 유추하는 것을 거부한다.
• 수백 개 이상의 ts 파일이 있는 큰 프로젝트에서는 ts 타입 검사 속도를 높일 수 있다 .

function A(songs: string[], count=0): number {
   // ~ 
}

const A = (songs: string[], count=0): number => {

}

📌 함수 타입

화살표 함수와 비슷하게 =>를 이용해 함수의 타입을 표현한다.

let nothingInGivesString: () => string;

다음 변수 타입은 매개변수가 없고 string 타입을 반환하는 함수를 뜻한다.

함수를 매개변수로 가지는 함수

function runOnSongs(getSongAt: (index: number) => string){
    // ~ ~
}

function getSongAt(index: number){
    return `${index}th song`;
}

다음 함수의 반환타입 : string을 반환하는 함수 or undefined

let maybeReturnsString: (() => string) | undefined;

📌 매개변수 타입 추론

let singer: (song: string) => string;

singer = function(song) {
    // song: string 타입으로 유추된다. 
    return 'Singing: ${song.toUpperCase()}!';
}

다음 singer 변수는 string 타입의 매개변수를 갖는 함수이므로 나중에 singer가 할당되는 함수 내의 song 매개변수는 string으로 예측된다.

📌 함수 타입 별칭

type StringToNumber = (input: string) => number;
let stringToNumber: StringToNumber;

타입 별칭은 특히 함수 타입에 유용하다. 타입 별칭을 이용하면 반복적으로 작성하는 매개변수와 반환 타입을 갖는 코드 공간을 많이 절약할 수 있다.

📌 void, never 반환 타입

void

• 어떤 값도 반환하지 않는 함수. return 문이 없거나 값을 반환하지 않는 return 문(return ;)을 가진 함수

• 함수 타입 선언 시 void를 사용하면 함수에서 반환되는 모든 값은 무시된다.

  => 사실 js 함수는 실제값이 반환되지 않으면 기본으로 모두 undefined를 반환하지만 void는 undefined와 동일하지 않다.

  • void : 함수의 반환 타입이 무시된다는 것을 의미한다.
  • undefined : 반환되는 리터럴 값으로, 정의되지 않은 값이 반환된다는 뜻이다.

function returnsVoid(){
    return;
}

let lazyValue: string | undefined;

lazyValue = returnsVoid();
// lazyValue는 undefined를 반환하는 타입인데 여기에 void 타입의 값을 넣으려고 하니 오류 발생 

=> undefined를 포함하는 대신 void 타입의 값을 할당하려고 하면 타입 오류가 발생한다.

void를 반환하도록 선언된 타입 위치에 전달된 함수가 반환된 모든 값을 무시하도록 설정할 수 있다.

예를 들어, 배열의 내장 forEach 메서드는 void를 반환하는 콜백을 받는다. forEach에 제공되는 함수는 원하는 모든 값을 반환할 수 있다. 다음 saveRecords 함수의 records.push(record)는 number(배열의 .push()에서 반환된 값)를 반환하지만, 여전히 newRecords.forEach에 전달된 화살표 함수에 대한 반환값이 허용된다.

const records: string[] = [];

function saveRecords(newRecords: string[]){
    newRecords.forEach(record => records.push(record));
}

saveRecords(['21', 'Come On Over', 'The Bodyguard'])

never 반환 타입

never 반환 함수는 (의도적으로) 항상 오류를 발생시키거나 무한 루프를 실행하는 함수이다.

함수를 절대 반환하지 않도록 의도하려면 명시적 : never 타입 애너테이션을 추가해 해당 함수를 호출한 후 모든 코드가 실행되지 않음을 나타낸다.

다음 fail 함수는 오류만 발생시키므로 param의 타입을 string으로 좁혀서 타입스크립트의 제어 흐름 분석을 도와준다.

function fail(message: string): never {
    throw new Error('Invariant failure: ${message}');
}

function workWithUnsafeParam(param: unknown){
    if(typeof param !== 'string'){
        fail(`param should be a string, not ${typeof param}`)
    }

    param.toUpperCase();
}

📌 함수 오버로드

하나의 최종 구현 시그니처와 그 함수의 본문 앞에 서로 다른 버전의 함수 이름, 매개변수, 반환 타입인 오버로드 시그니처를 여러번 선언함으로써 다양한 매개변수들로 호출되는 함수를 정의할 수 있다.

function createDate(timestamp: number): Date;
function createDate(month: number, day: number, year: number): Date;
function createDate(monthOrTimeStamp: number, day?: number, year?: number){
    return day === undefined || year === undefined 
        ? new Date(monthOrTimeStamp)
        : new Date(year, monthOrTimeStamp, day);
}

createDate(554356800); // ok
createDate(7, 27, 1987); // ok

createDate(4, 1) // Error

함수 오버로드는 복잡하고 설명하기 어려운 함수 타입에 사용하는 최후의 수단이다. 함수를 단순하게 유지하고 가능하면 함수 오버로드를 사용하지 않는 것이 좋다.

🪄 함수 정의 시 타입을 나타내는 가장 일반적인 2가지 방법

1. 일반 함수

   function A(a: string, b: number): number {
       // string과 number를 받아서 number를 반환하는 함수
   }

2. 화살표 함수

   const A = (a: string, b: number):number => {
       // string과 number를 받아서 number를 반환하는 함수
   }

객체 타입은 객체 리터럴과 유사하게 보이지만 필드 값 대신 타입을 사용한다.

let poetLater: {
    born: number;
    name: string;
}

poetLater = {
    born: 1935,
    name: "Mary Oliver"
}

📌 별칭 객체 타입

각 객체 타입을 계속 작성하지 않고, 각 객체 타입에 타입 별칭을 할당하는 방법이 더 일반적이다.

type Poet = {
    born: number;
    name: string;
}

let poetLater: Poet;

poetLater = {
    born: 1935,
    name: "Mary Oliver"
}

구조적 타이핑

타입을 충족하는 모든 값을 해당 값으로 사용할 수 있다 ?

hasBoth 멤버는 명시적으로 선언되지 않았음에도 두 개의 별칭 객체 타입을 모두 가지므로 두 개의 별칭 객체 타입 내에 선언된 변수를 모두 제공할 수 있습니다.

초과 속성 검사

이해 안됨 => 나중에 다시 읽어보기

📌 객체 타입 유니언

유추된 객체 타입 유니언

변수에 여러 객체 타입 중 하나가 될 수 있는 초깃값이 주어지면 TS는 해당 타입을 객체 타입 유니언으로 유추한다.

const poem = Math.random > 0.5 
    ? { name: "MinwooP", pages: 7 }
    : { name: "MinwooP", rhymes: true };

위의 poem 변수는 아래와 같은 객체 타입 유니언으로 유추된다.

{
    name: string,
    pages: number,
    ryhmes?: undefined
}
| 
{
    name: string,
    pages?: undefined,
    ryhmes: boolean
}

명시된 객체 타입 유니언

type PoemWithPages = {
    name: string,
    pages: number
}

type PoemWithRhymes = {
    name: string,
    ryhmes: boolean
}

type Poem = PoemWithPages | PoemWithRhymes;

const poem: Poem = Math.random > 0.5 
    ? { name: "MinwooP", pages: 7 }
    : { name: "MinwooP", rhymes: true };

poem.name; // ok

poem.pages // error
poem.rhymes // error

poem.pages나 poem.rhymes 처럼 잠재적으로 존재하지 않는 객체의 멤버에 대한 접근을 제한한다. pages나 rhymes는 항상 존재한다는 보장이 없기 때문.

if문을 통해 객체 타입 내로잉을 할 수 있고, 이를 통해 특정 속성에 접근할 수 있다.

if("pages" in poem){ // poem은 PoemWithPages로 좁혀짐
    poem.pages; 
}else{ // poem은 PoemWithRhymes로 좁혀짐
    poem.rhymes;
}

판별된 유니언

유니온 타입을 구성하는 타입들의 공통된 "리터럴 타입" 필드를 통해서 구분하는것

type PoemWithPages = {
    type: 'pages'; // 리터럴 타입 ? 
}

다음과 같이 객체의 속성에 type 필드를 추가하고 그 속성 값에 type명을 나타낼 수 있다.

type PomeWithPages = {
    name: string;
    number: number
    type: 'pages';
}

type PoemWithRhymes = {
    name: string;
    rhymes: boolean;
    type: 'rhymes';
}

type Poem = PoemWithPages | PoemWithRhymes;

const poem: Poem = Math.random > 0.5 
    ? { name: "MinwooP", pages: 7, type: "pages" }
    : { name: "MinwooP", rhymes: true, type: "rhymes" };

if(poem.type === "pages"){
   // pages 타입
}else{
   // rhymes 타입  
}

switch case 문을 통해서도 각 type을 구분할 수 있다.

switch(poem.type){
    case "pages": 
        // ~ 
        break;    
    case "rhymes": 
        // ~ 
        break;
}

📌 교차 타입

여러 기존 객체 타입을 별칭 객체 타입으로 결합해 새로운 타입을 생성할 수 있다.

유니언 타입과 결합해 사용할 수도 있다.

type ShortPoem = { author: string } & (
    | { kigo: string; type: "haiku"; }
    | { metor: number; type: "villanelle"; }
);

위의 ShortPoem 타입은 항상 author 속성을 가지며 하나의 type 속성으로 판별된 유니언 타입이다.

ts가 해당 이름을 출력하도록(할당 가능성 오류 때 타입 검사기가 출력하는 메시지) 타입을 일련의 별칭으로 된 객체 타입으로 분할하면 읽기가 훨씬 쉬워진다.

type ShortPoemBase = { author: string };
type Haiku = ShortPoemBase & { kigo: string; type: "haiku"; }
type Villanelle = { metor: number; type: "villanelle"};
type ShortPoem = Haiku | Villanelle;

두 개의 원시 타입을 교차 시도하면 never 키워드로 표시되는 never 타입이 된다.

=> 코드 정보에 입각한 추론

📌 유니언

• 여러 개의 타입을 가질 수 있을 때

  쉽게 말해서 이거 아님 저거

값이 유니언 타입일 때, 유니언으로 선언한 모든 타입에 존재하는 멤버 속성에만 접근할 수 있다.

ex) 다음 코드에서 physicist는 string | number 타입이므로 두 개의 타입에 모두 존재하는 toString() 메서드는 사용할 수 있지만 toUpperCase()는 string 타입에만 존재하기 때문에 사용할 수 없다.

let physicist = Math.random() > 0.5 
    ? "Marie Curie"
    : 84; // string | number

physicist.toString(); // ok

physicist.toUpperCase(); // error! 

이를 해결하려면 코드에서 값이 보다 구체적인 타입 중 하나라는 것을 TS에게 알리는 내로잉이 필요하다.

📌 내로잉

값이 정의, 선언 혹은 이전에 유추된 것보다 더 구체적인 타입임을 코드에서 유추하는 것이다.

타입을 좁히는 데 사용할 수 있는 논리적 검사를 타입 가드라고 한다.

값 할당을 통한 내로잉

변수에 직접 값을 할당하면 TS는 변수의 타입을 할당된 값이 타입으로 좁힌다.

let person: number | string;

person = "MinwooP";

person.toUpperCase(); // ok

if문 조건 검사를 통한 내로잉

let person = Math.random() > 0.5
    ? "MinwooP"
    : 51;

if(person === "MinwooP"){
    person.toUpperCase(); // ok => string으로 좁혀졌기 때문
}

person.toUpperCase(); // error

typeof 검사를 통한 내로잉

let person = Math.random() > 0.5
    ? "MinwooP"
    : 51;

if(typeof person === string){
    person.toUpperCase(); // ok => string으로 좁혀졌기 때문
}

person.toUpperCase(); // error

📌 리터럴 타입

const philosopher = "MinwooP";

• 위 변수의 타입은, string 타입이지만 단지 string 타입이 아닌 기술적으로 더 구체적인 "MinwooP"이다.

• 변수를 const로 선언하고 직접 리터럴 값을 할당하면 TS는 해당 변수를 할당된 리터럴 값으로 유추한다.

  const로 선언되어있으니 변경이 불가능하므로 리터럴 값으로 유추 !

  

let philosopher = "MinwooP"; 

그럼 이렇게 let으로 선언하면 변경가능하니 string 타입이고

const philosopher = "MinwooP";

const로 선언하면 리터럴 타입

• 리터럴 타입은 유니언 타입 애너테이션에서도 사용됨

  let lifespan: number | "ongoing" | "uncertain"

📌 엄격한 null 검사

TS 컴파일러 옵션 중, strictNullChecks를 비활성화하면, 코드의 모든 타입에 | null | undefined 를 추가해야 모든 변수가 null 또는 undefined를 할당할 수 있다.

strictNullChecks 를 활성화한 경우, string 타입인 value에 null을 할당하면 타입 오류가 발생합니다.

stringNullChecks를 비활성화해도, 무조건 null을 할당할 수 있는게 아니라 타입에 | null | undefined를 추가해야 이를 할당할 수 있는 것 ?

false, 0, "", null, undefined, NaN 처럼 falsy로 정의된 값을 제외한 모든 값은 모두 참이다.

📌 타입 별칭

재사용하는 타입에 더 쉬운 이름을 할당

type RawData = boolean | number | string ;

let rawDataFirst: RawData;
let rawDataSecond: RawData | null | undefined;

이러한 타입 별칭은 타입 애너테이션처럼 js로 컴파일되지 않는다. ts 타입 시스템에만 존재하는 것

=>

따라서 타입 별칭은 런타임 코드에서 참조할 수 없음

type someType = string | undefined;

console.log(SomeType); // Error