
import Image from './src/components/image'

최근 진행할 업무에서 무한 스크롤에 대한 요구사항이 생겼다.

아직 개발하는 단계는 아니어서 실제로 구현하기는 전이지만, 마침 블로그에 무한 스크롤을 사용 중이기도 해서 이번 기회를 통해 무지성으로 구현했던 무한 스크롤을 다시 구현해보며 겪었던 경험을 공유하려 한다.

## 무한 스크롤이란?

무한 스크롤(Infinity Scroll)은 최근 굉장히 많이 사용되는 방식이다. 스크롤링을 하는 사용자가 특정 `영역`에 도달하면 기존에 존재하던 컨텐츠 이외에 추가로 무언가를 보여주는 형태로 보통 사용자 경험을 제공한다.

이전에는 보통 **페이징**이라는 방식을 통해서 많이 보여줬지만 페이징에서는 경험할 수 없는 인터렉션은 사용자에게 때로는 더 좋은 경험을 심어주게 된다.

이런 무한 스크롤을 구현하는 방법에는 여러가지가 있지만, 이번에는 **스크롤 이벤트**를 통해서 구현해보았다.

## 스크롤 이벤트

모두가 알고있는 가장 기본적인 이벤트인 `스크롤`만을 이용해서 먼저 구현해보았다.

구현한 코드는 아래와 같다.

```typescript
import { useEffect, useState } from 'react'

const FETCH_TODO_URL = 'http://localhost:8000/todos'
const FETCH_MORE_COUNT = 10

interface Todo {
  userId: number
  id: number
  title: string
  completed: boolean
}

function Todos() {
  const [todos, setTodos] = useState<Todo[]>([])
  const [limit, setLimit] = useState(FETCH_MORE_COUNT)

  const handleTodosFetch = () => {
    const 현_화면의_높이 = window.innerHeight
    const 총_스크롤한_높이 = document.documentElement.scrollTop
    const 전체_화면_높이 = document.documentElement.offsetHeight

    // MEMO: 화면 최하단에 닿으면 조건문 내의 블럭 반응
    if (현_화면의_높이 + 총_스크롤한_높이 >= 전체_화면_높이) {
      setLimit((limit) => (limit += FETCH_MORE_COUNT)) // 현재 컨텐츠 갯수에 10개씩 추가
    }
  }

  useEffect(() => {
    const getTodos = async () => {
      const response = await fetch(`${FETCH_TODO_URL}/?_limit=${limit}`) // API Fetch
      const data = await response.json()

      setTodos(data)
    }

    getTodos()
  }, [limit])

  useEffect(() => {
    window.addEventListener('scroll', handleTodosFetch, { passive: true })

    return () => window.addEventListener('scroll', handleTodosFetch, { passive: true })
  }, [])

  return (
    <ul>
      {todos.map((todo) => (
        <li key={todo.id}>{todo.title}</li>
      ))}
    </ul>
  )
}

export default Todos
```

크게 어려운 부분 없이 정말 간단하게 작성했다.

결론은 브라우저의 스크롤이 최하단으로 이동되면 **limit** state가 변경되어 이를 감지하고 API를 호출해 이를 계속 쌓는 방식이다.

여기서 이벤트 리스너에 세 번째 인자로 **passive**를 true로 넘겨주었는데
이는 이벤트에 내장되어있는 `preventDefault` 를 호출하지 않는 것을 선언하는 것으로 이벤트를 호출할 때 preventDefault를 감지하지 않아도 되는 수고로움을 덜어 성능에 조금이나마 도움이 된다.

사실 이렇게만 구현했을 때 무한 스크롤 그 자체의 기능상으로는 문제점은 없다.

하지만 이벤트가 어떻게 처리되고 있는지 확인하면 눈앞이 아득해진다. 😵‍💫

<Image src="/images/2022/08/react/console.gif" alt="scroll console" width="100%" />

진짜 모든 이벤트를 하나부터 열까지 싹다 잡아오고 있다.

또 문제점이 되는 부분이 바로 `documentElement` 객체의 **scrollTop**과 **offsetHeight**인데, 이를 사용하게 되면 특정 조건에 따라 **Reflow**가 발생하여 레이아웃의 변화가 오기 때문에 브라우저가 다시 렌더트리를 구성하게 되고 그만큼 브라우저는 추가 연산들을 하게 된다. 😇

즉, 이러한 이유들 때문에 최소화 하는편이 좋다.

이를 가만 놔둘 수 없었던 나는 무한 스크롤에 적합한 **쓰로틀링**(Throttling)을 적용해보기로 했다.

## Throttling

쓰로틀링은 프론트엔드 개발자라면 많이 알고 있을 개념인데, 특정 시간을 주기로 하여 이벤트를 발생시키도록 하는 개념을 말한다.

보통은 직접 lodash에 있는 throttle을 많이 사용하는데(물론 직접 구현해도 무방하다) 이를 사용해 확인하기 편하도록 1초 단위로 이벤트를 호출해보았다.

```typescript
import { throttle as _throttle } from 'lodash'

// 생략..

const handleTodosFetch = _throttle(() => {
  const 현_화면의_높이 = window.innerHeight
  const 총_스크롤한_높이 = document.documentElement.scrollTop
  const 전체_화면_높이 = document.documentElement.offsetHeight

  if (현_화면의_높이 + 총_스크롤한_높이 >= 전체_화면_높이) {
    setLimit((limit) => (limit += FETCH_MORE_COUNT))
  }
}, 1000) // 1초 단위로 쓰로틀링

// 생략..
```

기대했던 대로 스크롤시 1초마다 동작해줄까?

<Image src="/images/2022/08/react/throttle.gif" alt="scroll throttle console" width="100%" />

아까의 무지막지하게 발생했던 이벤트보다는 훨씬 나아졌다. 😄

여기까지만 해도 나름 스크롤 이벤트에 대한 최적화를 잘 했다고 생각했지만 문제점이 하나 있었다.

바로 **setTimeout**의 경우 이벤트 루프를 통해 Call Stack으로 이동되어 처리가 되는데, 만약 Call Stack에 무언가의 이슈로 인해 비워지지 않는 상황이 온다면 1초의 시간을 보장할 수 없게 된다.

이를 극복하기 위해 조금 조사하다 보니 더 편리하고 효율적인 방법을 찾아냈다. 👨🏻‍💻

바로 [requestAnimationFrame](https://developer.mozilla.org/ko/docs/Web/API/Window/requestAnimationFrame) 이라는 API다.

## requestAnimationFrame

MDN 선생님께서는 아래와 같이 설명한다.

> window.requestAnimationFrame()은 브라우저에게 수행하기를 원하는 애니메이션을 알리고 다음 repaint가 진행되기 전에 해당 애니메이션을 업데이트하는 함수를 호출하게 한다.

아까 **reflow**라는 단어가 나왔었는데, 그와 연관된 `repaint`라는 단어가 등장했다.

브라우저는 reflow 이후에 repaint의 과정을 거치는데 레이아웃이 변경되어 reflow를 통해 렌더트리를 다시 그려야하는 상황이 오면 repaint는 이를 실제 화면에 그려주는 역할을 해주는 것이다.

### Event Loop

<Image src="/images/2022/08/react/eventloop.png" alt="eventloop" width="100%" />

자바스크립트 개발자라면 무조건 한 번은 봤을 이미지다.

각각의 API 마다 실행 이후 위치하는 Queue가 다르며 실제 Queue에서 이탈하여 Call Stack에 위치하게 되는 순서도 다르다.

아까 **throttle**은 setTimeout을 기반으로 동작하므로 `Task Queue`에 위치한다.

반면에 requestAnimationFrame은 그림에서 보이듯이 `Animation Frames`가 따로 존재한다. 여기에는 requestAnimationFrame에서 선언한 콜백이 위치하게 된다.

그리고 놀라운 것은 Task Queue보다 더 우선순위를 갖고있다. 즉, 이벤트 루프를 통해 Call Stack으로 이동되는 순서는

Microtask Queue -> Animation Frame -> Task Queue 순이다.

또한 브라우저의 주사율인 **60fps**(1초에 60회)을 기준으로 처리가 되기 때문에 더욱 브라우저 친화적으로 최적화가 가능하다.

이를 편하게 사용할 수 있도록 유틸 함수를 구현했다.

### 유틸 함수 구현

```typescript
function throttleByAnimationFrame(callback: (...args: any) => void) {
  return function (this: any, ...args: any[]) {
    window.requestAnimationFrame(() => {
      callback.apply(this, args)
    })
  }
}
```

이제 실제 스크롤 이벤트에 이를 활용해보자

```typescript
// 생략..
const handleTodosFetch = throttleByAnimationFrame(() => {
  const 현_화면의_높이 = window.innerHeight
  const 총_스크롤한_높이 = document.documentElement.scrollTop
  const 전체_화면_높이 = document.documentElement.offsetHeight

  if (현_화면의_높이 + 총_스크롤한_높이 >= 전체_화면_높이) {
    setLimit((limit) => (limit += FETCH_MORE_COUNT))
  }
})

// 생략..
```

이렇게 처리하면 스크롤 이벤트로 인한 **reflow**에 대한 문제점과 **setTimeout**로 인한 이벤트 루프 문제를 해결한 코드가 된다.

여기까지 스크롤 이벤트를 통해 무한 스크롤 구현부터 최적화까지 구현해보았다.

생각보다 여러 개념들이 섞여있어서 이해하기 쉽지 않았지만, 브라우저의 개념까지 들여다봤던 아주 좋은 기회였다. 👍

[예시 코드](https://github.com/fronttigger/code-playground/tree/main/infinity-scroll)


최적화까지 두 마리 토끼를?! 🐰

React에서 무한 스크롤 구현해보기 (feat. requestAnimationFrame)

react

infinity-scroll


## 제네릭의 필요성

제네릭이란 개념은 기본적으로 타입이 있는 언어를 사용하는 개발자들의 경우에는 익숙할 것이다. (Java, C 계열 등)

하지만 이전에 javascript를 사용해서 개발을 했던 개발자라면 typescript를 사용하면서부터 타입을 기재하는 것에 대한 개념을 활용하며 개발하고 있을 것이다.

보통 간단한 타입의 경우에는 사용하는 것이 크게 어렵지는 않다.

이를테면 변수 선언시 타입을 명시한다던지, 함수의 인자에 특정 타입을 명시하는 등의 방식을 통해서 처리하는 방법이 있다.

```typescript
let count: number = 0

function returnData(data: number): number {
  return data
}

returnData(1) // 1
returnData('1') // Argument of type 'string' is not assignable to parameter of type 'number'.
```

하지만 원하는 값이 항상 정해진 타입이 아니라면 어떻게 될까? 🤔

예를들어, 위 returnData 함수의 경우도 숫자를 반환할 수도 있지만 문자열을 반환해 주고 싶을 수도 있다.

이런 고민을 해결해주는 친구가 바로 **제네릭**(Generic)이다.

제네릭은 구체적인 타입을 직접 명시하지 않고 다양한 타입에 대해서 대응할 수 있도록 해주며 이를 통해 더욱 확장성 있고 재사용 가능하도록 도와준다.

처음 제네릭을 접하게 되면 어렵고 활용하기가 굉장히 어려운데, 이를 조금이라도 해소할 수 있도록 예시를 통해 어떤 느낌으로 사용되는지 알아보자

## 제네릭의 사용법

먼저 이전에 있던 returnData 함수를 제네릭을 사용해 다시 만들어보자

```typescript
function returnData<T>(data: T): T {
  return data
}

returnData<number>(1) // function returnData<number>(data: number): number
returnData(1) // function returnData<1>(data: 1): 1

returnData<string>('1') // function returnData<string>(data: string): string
returnData('1') // function returnData<"1">(data: "1"): "1"
```

위 코드에서 함수명에 `<T>`를 통해서 제네릭 타입에 대해 명시하고 이걸 인자 타입과 반환 타입에 명시해주면

개발자가 명시한 타입으로 타입이 동적으로 작동하게 된다.

이렇게 되면 이전에 있던 예시와는 다르게 원하는 값에 대한 타입에 대한 자유도가 생기기 때문에 어떤 타입의 값이든 반환할 수 있는 함수가 되었다. 🎉

그런데 여기서 한가지 의문이 드는 부분이 있다.

제네릭을 통해서 자유분방함을 준건 오케인데.. 그러면 어느정도 제약을 두려면 어떻게 해야하지..? 🤔

그럴 때 사용하는 것이 바로 `extends` 키워드다.

## extends로 제네릭 타입 상속하기

방금 만든 returnData 함수의 경우 모든 타입에 대해서 사용 가능하다.

그래서 이를 `extends` 키워드를 사용해 숫자와 문자열 두가지 타입에 대해서만 동작하도록 처리해보자

```typescript
function returnData<T extends number | string>(data: T): T {
  return data
}

returnData(1)
returnData('1')
returnData(true) // Argument of type 'boolean' is not assignable to parameter of type 'string | number'.
```

제네릭에 extends 키워드를 통해 특정 타입에 대해서만 동작하도록 명시했다.

extends는 **상속**할 때 자주 사용하는데 비슷한 맥락으로 해석하자면 T 라는 타입이 number와 string 타입을 상속했다고 보면 된다.

상속이라는 키워드 때문에 헷갈린다면 [**부분집합**](https://ko.wikipedia.org/wiki/%EB%B6%80%EB%B6%84%EC%A7%91%ED%95%A9)의 맥락으로 이해해도 충분히 해석이 가능하다.

T가 number | string의 **부분집합**이라고 생각하면 T는 number 혹은 string이 되는 것이다.

여기에 대한 예를 들면 아래와 같다.

- `<10 extends number>` // true
- `<number extends 10>` // false

실제로 타입스크립트에서 기본적으로 내장되어있는 유틸리티 타입을 통해 또하나의 케이스를 살펴보자

### Exclude

```typescript
type Exclude<T, U> = T extends U ? never : T
```

Exclude는 겹치는 타입에 대해서 제외할 수 있는 유틸리티 타입이다.

T와 U 두가지의 제네릭 타입을 받는데, 아까 살펴보았던 **extends**를 활용했다.

T는 U를 상속 했을 때 상속이 되어 있다면 never 타입을, 아니라면 T 제네릭 타입을 넣도록 했다.

여기서 갑작스레 `never` 타입이 등장해서 당황했을 수도 있는데, 여기서의 never는 **공집합**의 느낌을 주며 어떠한 타입값도 가질 수 없는 것을 뜻한다. 즉, 여기서는 아무런 타입을 할당하지 않는다고 보면 된다.

실제로 사용한 코드를 보면 다음과 같다.

```typescript
interface Person {
  name: string
  age: number
}

interface Product {
  name: string
  price: number
}

type Excluded = Exclude<Person | Product, Product> // type Excluded = Person
```

Person 혹은 Product 타입 중 Product를 제외하니 Person 타입만 남게 되었다.

이처럼 `extends` 키워드를 통해서 특정 타입에 대해서 **강제**하고 **삼항연산자**를 통해 조건을 걸어 여러가지 타입을 만들어 낼 수 있다.

## extends를 활용한 헬퍼타입 실습

이제 어느정도 **제네릭**과 **extends**에 대해서 느낌을 잡았을테니 (아닌가..? 😅) 두 가지 간단한 헬퍼타입을 만들어보자

### Readonly

Readonly는 특정 인터페이스 타입을 HelperReadonly로 감싸면 전체 프로퍼티에 대해 readonly 키워드를 붙여서 타입을 만들어주는 헬퍼타입이다.

처음 헬퍼타입을 만들기 전의 상황은 아래와 같다.

```typescript
type HelperReadonly<T> = any

const person: HelperReadonly<Person> = {
  name: 'fronttigger',
  age: 30,
}

person.name = 'backtigger'
person.age = 29
```

명시한 any를 이제 프로퍼티를 수정하려고 할 때 readonly인 경우 출력되는 에러인 **Cannot assign to 'name' because it is a read-only property.** 가 출력되도록 작업하면 된다.

[문제 풀어보기](https://www.typescriptlang.org/play#code/JYOwLgpgTgZghgYwgAgArQM4HsTIN4BQyyIcAthAFzIZhSgDmRycDVJArmQEbQEC+BAmACeABxQAJCABsJUAEoQ4AExwyRAHgAqAPmQBeFiBHIA9GeSAAlcAto4BeewByDgFLGhCHLWTzsIatLnQlVXUtdChvfSNCYlIKagByGCgcMDBgBjYoOIAaZlZ2AGYABhzBAi8cADoYlCM47kQAa1T06DjzS20AeQARTuoAYTgQECwwFgwMNNwwLGQ46rbeBDgODBRgMeAMFmQoZRUAWmDPJPlRCrLMSrzDZAAmAE525C7egaGRsbgJqeQZubyiwgy1W6022zgu32RxAGhOWDOIgqQA)

그 결과는 아래와 같다.

```typescript
type HelperReadonly<T> = {
  readonly [key in keyof T]: T[key]
}

const person: HelperReadonly<Person> = {
  name: 'fronttigger',
  age: 30,
}

person.name = 'backtigger' // Cannot assign to 'name' because it is a read-only property.
person.age = 29 // Cannot assign to 'age' because it is a read-only property.
```

제네릭 타입 하나만 사용한 간단한 헬퍼타입이다.

이제 프로퍼티에 접근하여 수정하려고 하면 원하던 에러가 출력된다. 🎉

### Pick

Pick은 두가지 제네릭 타입을 받는데 첫 번째 타입에 대해서 원하는 타입을 두 번째 타입에서 union 타입으로 명시함으로써 명시한 타입에 대해서 새롭게 타입을 만드는 헬퍼타입이다.

만들 헬퍼타입의 초기 형태다.

```typescript
type HelperPick<T, K> = any

type PersonPick = HelperPick<Person, 'name'> // type PersonPick = { name: string; }

const person: PersonPick = {
  name: 'backtigger',
}
```

최종적으로는 person에 name만 입력 가능하도록 만드는 것이다.

[문제 풀어보기](https://www.typescriptlang.org/play/?#code/JYOwLgpgTgZghgYwgAgArQM4HsTIN4BQyyIcAthAFzIZhSgDmRycDVJArmQEbQEC+BAmACeABxQAJCABsJUVMAQBrADwAVADTIA0gD5kAXhYgRyAPTnkgAJXALaOAXnsAcg4BSxoaIlpMORSqPJpctA+auhQ2CDaAOSkFJF6Qgg4tMjy4dSh4cF+hMQx7JHciMpgwAxsUJGazKzsAMwADNqWyOoA8gAirdTq4iiReCTk7LT0IAwA3Cxs1CBcvFCT-JHIwBgkWGAsGBilpNwyKGBYyO59Gd5KypEAdMit3ABWEAibMsCQUHAyyGRwZjgyMwYCQIYAwMzKEBYADuuDEUCw8hKEAw2jgIAAJshIjVlhisCj1psIAAPVabUAnXrY84gYI3ARAA)

그 결과는 아래와 같다.

```typescript
type HelperPick<T, K extends keyof T> = {
  [key in K]: T[key]
}

type PersonPick = HelperPick<Person, 'name'>

const todo: PersonPick = {
  name: 'backtigger',
}
```

두 번째 제네릭 타입에 extends를 사용하여 Person 타입의 프로퍼티 값을 가져왔으며, 이를 프로퍼티에서 사용하고 그 값을 선언해주면 완성된다.

여기까지 **제네릭**과 **extends**를 활용해 헬퍼타입을 만들어보았다.

사실 너무나도 간단한 실습이었지만 이를 기본으로 해서 사용되는 여러가지 타입에 대한 분석과 조금씩 고도화된 타이핑을 하다보면 충분히 잘 다룰 수 있을 것이다! 👨🏻‍💻

모든 코드는 [Github](https://github.com/fronttigger/code-playground/tree/main/helper-type)에 저장되어 있다.

참고자료

- [https://www.typescriptlang.org/ko/docs/handbook/2/generics.html](https://www.typescriptlang.org/ko/docs/handbook/2/generics.html)
- [https://poiemaweb.com/typescript-generic](https://poiemaweb.com/typescript-generic)


Typescript의 제네릭을 헬퍼타입을 만들어보며 알아보기

typescript

generic


import Image from './src/components/image'

## 테스트 코드 도입 썰

프론트엔드는 특성상 사용자와의 직접적인 상호작용을 통해 즉각적인 피드백을 받을 수 있다.

이는 장점이자 단점이 될 수 있는데, 그만큼 사이클을 빠르게 처리해야하는 상황이 굉장히 빈번하게 발생한다. 😅

최근 업무를 처리하다보니 새로운 신규 기능 개발도 물론 있었지만 대부분의 업무는 기존의 코드를 유지보수를 하는 경우가 굉장히 많았다.

예를들면 기존 바텀시트 내에 버튼이 새로 추가된다던지, 무언가의 상태값이 추가가 된다던지, 혹은 결제 프로세스의 변경 등 여러 기능에서 추가적인 요구사항이 쏟아졌다.

이렇게 개발하다 보니 위에서 예시를 들었던 결제와 같은 민감한 도메인, 혹은 API가 변경되어야하는 건들이 종종 발생했다. 😖

그래서 이를 개발하기 위해 건드리다보면 굉장히 불안했다.

> 혹시 이 코드 때문에 정상적으로 돌아가지 않으면 어떡하지..?  
> API가 변경되서 어디선가 사이드 이펙트가 터지면 어떡하지..?  
> 이 코드는 히스토리를 모르는데..? 엉엉 ㅠㅠㅠㅠ

위의 예시와 같이 기존에 정상적으로 돌아갔던 기능이 돌아가지 않는 것에 대한 불길한 감정들이 엄습했다. 😨

사실 위에서 작성한 예시 뿐만 아니라 수정하는 대부분의 상황에서 이런 생각이 들게 된다.

그래서 이를 타파하기 위해 과감히 도입하자고 결론내린 것이 바로 **테스트**다. (물론 100%를 해결해주진 않겠지만..)

## MSW 도입 이유

프론트엔드의 테스트는 테스트 코드를 작성하는 것 자체도 어렵지만 여러가지 제약사항이 존재했는데, 그 중에 하나가 바로 `API`였다.

테스트 환경의 **데이터** 혹은 개발된 **스키마**가 동일하지 않은 상황이 있었으며, 아직 백엔드 개발이 완성되지 않는 상태거나 완성 되었어도 문제로 인해 다시 개발을 해야하는 경우들이 굉장히 빈번하게 발생했다. 이런 고민들을 덜기 위해 여러가지를 고민하던 와중 알아낸 라이브러리 중 [MSW](https://mswjs.io/)를 알게되었다.

MSW는 한 번의 모킹 처리를 통해 **브라우저**와 **노드** 환경을 대응할 수 있다.

<Image src="/images/2022/07/react/msw.png" alt="msw" width="100%" />

브라우저에서는 `Service Worker`를 이용해 서버로 요청하는 request를 가로채 moking한 API를 반환해준다.

노드 환경에서는 `node-request-interceptor` 라이브러리를 사용하여 http, https, XMLHttpRequest 모듈을 확장해서 처리한다.

이렇게 편리하게 API를 모킹 할 수 있는 점에서 굉장히 매력적으로 다가왔다.

그래서 본격적으로 프로젝트에 도입 전 간단한 컴포넌트로 아직은 튜토리얼 수준으로 적용해본 경험을 공유하려고 한다.

[예시코드](https://github.com/fronttigger/code-playground/tree/main/msw-test-code)

## MSW 설정

먼저 MSW를 사용하기 위해 [튜토리얼](https://mswjs.io/docs/getting-started/install)을 참고했다.

### 설치

```bash
npm install msw --save-dev
# or
yarn add msw --dev
```

#### 모킹 핸들러 구현

```typescript
// src/components/mocks/handlers.ts
import { rest } from 'msw'

const review = {
  rating: 4.3,
  commentCount: 200,
}

const getReview = (isError?: boolean) => {
  return rest.get('/review', (_, res, ctx) => {
    if (isError) {
      return res(ctx.status(500))
    }

    return res(ctx.status(200), ctx.json(review))
  })
}

const reviewHandlers = [getReview()]

export default reviewHandlers
```

테스트를 진행할 특정 도메인에 해당되는 핸들러를 정의했다.

엔드포인트는 `/review`, response는 review 객체를 반환한다. 그리고 만약 에러가 발생한다면 상태 500을 반환하도록 만들었다.

### 핸들러 모듈 관리

```typescript
// src/mocks/handlers.js
import reviewHandlers from '../components/StarReview/mocks/handlers'

export const handlers = [...Object.values(reviewHandlers)]
```

많아질 핸들러를 대비해 통합 핸들러 모듈을 생성했다.

이제 이 통합한 핸들러를 통해서 브라우저, 노드 두가지 환경에 모킹을 진행하면 된다.

### 브라우저

브라우저 환경에서는 서비스 워커를 등록하여 개발 환경에서만 동작하도록 처리해줘야한다.

#### 서비스 워커 모듈 생성

```bash
npx msw init public/ --save
```

위 명령어를 통해 public 디렉토리에 서비스 워커 모듈을 생성한다.

#### 핸들러 등록

```typescript
// src/mocks/browser.js
import { setupWorker } from 'msw'
import { handlers } from './handlers'

export const worker = setupWorker(...handlers)
```

이전에 만들어 두었던 핸들러를 등록한다.

```typescript
// src/index.tsx
import React from 'react'
import ReactDOM from 'react-dom/client'
import App from './App'

if (process.env.NODE_ENV === 'development') {
  const { worker } = require('./mocks/browser')
  worker.start()
}

const root = ReactDOM.createRoot(document.getElementById('root') as HTMLElement)
root.render(
  <React.StrictMode>
    <App />
  </React.StrictMode>,
)
```

개발 환경일 때 워커를 실행하면 브라우저는 준비 끝!

### 노드

브라우저와 마찬가지로 핸들러를 등록시킨다.

#### 핸들러 등록

```typescript
// src/mocks/server.js
import { setupServer } from 'msw/node'
import { handlers } from './handlers'

export const server = setupServer(...handlers)
```

```typescript
// src/setupTests.js
import { server } from './mocks/server.js'

beforeAll(() => server.listen()) // 서버 설정

afterEach(() => server.resetHandlers()) // 각각 테스트 요청 마다 핸들러 초기화

afterAll(() => server.close()) // 테스트가 끝난 후 종료
```

#### Jest 설정

만약 CRA 환경이 아니라면 Jest 설정이 추가로 필요하다.

```typescript
// jest.setup.js
module.exports = {
  setupFilesAfterEnv: ['./jest.setup.js'],
}
```

자 이제 테스트를 위한 모든 준비가 끝났다.

아까 모킹한 API를 사용해보기 위해 간단한 컴포넌트를 예시로 테스팅 해보자! 👨🏻‍💻

## 별점 컴포넌트 구현

평점을 통해 총 5개의 별로 표시해주며 동시에 후기의 갯수를 보여주는 컴포넌트다. (자세한 스타일과 구현부는 생략한다.)

```typescript
function StarReview({ rating = 0.0, commentCount = 0 }: StarProps): JSX.Element {
  return (
    <Container>
      <StarGroup rating={rating} />
      <StarAverage>{rating.toFixed(1)}</StarAverage>
      <StarReviewContainer>
        <StarReviewRatingText>후기</StarReviewRatingText>
        <StarReviewCount>{commentCount}</StarReviewCount>
      </StarReviewContainer>
    </Container>
  )
}

export default StarReview
```

이 컴포넌트의 props는 **rating**이라는 평점과, **commentCount**의 후기 갯수를 받아서 그려준다.

이제 그려줄 데이터를 가져와보자!

## API 구현

이전에 만들었던 `/review` API를 통해 모킹한 데이터를 가져오는 함수를 구현했다.

```typescript
// src/components/StarReview/api.ts
export const getReview = async () => {
  try {
    const response = await fetch('/review')

    const data = await response.json()

    return data
  } catch (error) {
    new Error('리뷰를 가져오지 못했습니다.')
  }
}
```

이제 이를 통해 컴포넌트를 실제 화면에 그려보자

## 컴포넌트 렌더링

```typescript
// App.tsx
import { useEffect, useState } from 'react'
import StarReview from './components/StarReview'
import { getReview } from './components/StarReview/api'

function App() {
  const [review, setReview] = useState<{
    rating: number
    commentCount: number
  }>()

  useEffect(() => {
    async function getReviewData() {
      const reviewData = await getReview()

      setReview(reviewData)
    }

    getReviewData()
  }, [])

  return (
    <StarReview type="average-review" rating={review?.rating} commentCount={review?.commentCount} />
  )
}

export default App
```

만들어낸 컴포넌트를 실제 실행해보면 콘솔에 다음과 같이 출력된다.

<Image src="/images/2022/07/react/browser.png" alt="browser" width="100%" />

브라우저 상에서 서비스 워커가 `/review`에 대한 요청을 가로채서 그 요청에 관련된 정보들을 제공해준다.

응답이 잘 오는 것 까지 확인했으니 이제 테스트 코드 상에서 이상이 없는지, 그리고 그 데이터를 실제 화면에서 잘 그려지고 있는지 확인해보자!

## 테스트 코드 작성

먼저 컴포넌트를 실행 했을 때 모킹한 값이 정상적으로 그려져서 화면에 있는지 확인했다.

```typescript
import { render, screen } from '@testing-library/react'

import App from './App'

test('평점과 후기수가 표현된다.', async () => {
  render(<App />)

  const $rating = await screen.findByText('4.3')
  const $commentCount = await screen.findByText('200')

  expect($rating).toBeInTheDocument()
  expect($commentCount).toBeInTheDocument()
})
```

그런데 여기서 서버사이드의 문제로 500 에러가 날 경우가 있을 것이다.

그런 경우를 대비해 MSW에서는 핸들러를 재정의 할 수 있는 `use` 함수를 제공한다.

```typescript
import { render, screen } from '@testing-library/react'

import App from './App'

import { getReview } from './components/StarReview/handlers'
import { server } from './mocks/server'

describe('StarReview', () => {
  test('평점과 후기수가 표현된다.', async () => {
    render(<App />)

    const $rating = await screen.findByText('4.3')
    const $commentCount = await screen.findByText('200')

    expect($rating).toBeInTheDocument()
    expect($commentCount).toBeInTheDocument()
  })

  test('평점과 후기수가 없다면 초기값이 표현된다.', async () => {
    server.use(getReview(true))

    render(<App />)

    const $rating = await screen.findByText('0.0')
    const $commentCount = await screen.findByText('0')

    expect($rating).toBeInTheDocument()
    expect($commentCount).toBeInTheDocument()
  })
})
```

500을 응답받은 이후 렌더링을 하면 모킹한 값이 아닌 초기값이 들어오게 된다.

이렇게 노드 환경에서도 에러시의 처리를 원활하게 처리할 수 있다. 👍

여기까지 MSW를 활용해 브라우저 환경과 노드 환경에서 어떻게 테스팅을 할 수 있는지 알아보았다.
작업을 하면서 확실히 테스팅을 원활하게 할 수 있도록 도와준다는 점에서 서버 진영에서는 많이 활용되는 TDD를 프론트엔드 진영에서도 진입 장벽을 낮춰줄 것 같다는 생각을 했다.

Presentational 역할의 컴포넌트는 해당 API의 응답 받았을 때를 가정한 테스트를 진행하고,
Container 역할을 담당하는 컴포넌트는 API call 이후 받아내는 테스트를 통해 정상적으로 데이터가 잘 전달 되는지 확인한다면 UI와 데이터 모두를 테스트 할 수 있는 좋은 테스팅 환경이 구성되지 않을까 라는 생각이 든다. (더 좋은 테스트 방법이 있을까..? 🤔)

### 참고자료

- [MSW로 API모킹하기](https://blog.mathpresso.com/msw%EB%A1%9C-api-%EB%AA%A8%ED%82%B9%ED%95%98%EA%B8%B0-2d8a803c3d5c)
- [React Testing Libaray](https://testing-library.com/docs/react-testing-library/intro/)


테스트 시리즈의 두번째 주인공

MSW를 활용해 프론트엔드 테스트하기 (feat. Jest)

msw-test


import Image from './src/components/image'

여태까지 프론트엔드 개발자로서 업무하면서 비동기 작업을 통해 데이터를 다루었다. (물론 얼마 안되는 경력이지만.. 😅)

그런데 생각해보니 비동기 작업을 통해 **데이터**를 가져오는 것만 생각하고, 정작 **요청**에 대해서는 생각해본적이 없었다.

그래서 이번 기회에 요청작업에 대해 몇가지 알아보다가 `AbortController` 라는 객체를 알게 되었고, 이를 간단하게 사용해보며 학습한 내용을 공유해보려 한다.

[예제 코드](https://github.com/fronttigger/code-playground/tree/main/abort-controller)

## AbortController? 🤔

서론에서 유추할 수 있듯이 [AbortController](https://developer.mozilla.org/ko/docs/Web/API/AbortController)는 웹 요청에 관련된 객체이다.

그 중에서도 `요청 중단`를 할 수 있는 친구인데 이를 통해 원하지 않는 요청을 중단한다거나, 필요가 없어진 요청을 중단하는 등 요청에 대한 응답이 더이상 필요 없어진 비동기 작업의 중단를 담당한다.

몇가지 상황을 예로 들자면 아래와 같다.

1.  요청을 하였지만 응답이 너무 오래 걸린다.
2.  요청을 한 후 사용자가 다른 작업을 위해 화면을 이동했다.
3.  서비스의 특정 상황으로 인해 임의의 시간 이후 요청을 중단해야한다.

위 상황 말고도 정말 여러가지 상황으로 인해 요청을 중단해야할 수도 있을 것이다.

이런 중단을 통해 그만큼 네트워크 요청이 줄어들게 된다면 더 효율적인 서비스를 운영할 수 있지 않을까 생각된다.

AbortController는 `fetch API`를 통해 공식적으로 사용할 수 있으며 [axios](https://axios-http.com/docs/cancellation), [react-query](https://react-query.tanstack.com/guides/query-cancellation##_top) 등의 라이브러리에서도 사용법에 대한 안내를 해주고 있어 필요시 공식문서를 통해 사용해보면 된다.

먼저 AbortController를 통해 요청을 중단하는 간단한 예제부터 살펴보자

## Javascript

### 예시코드

간단한 버튼 예시로서, 버튼을 클릭하면 비동기 요청을 하고 특정 시간까지 기다린 이후 자동으로 중단시키는 방법이다.

```javascript
const FETCH_URL = 'https://jsonplaceholder.typicode.com/posts'

const $ = (selector) => document.querySelector(selector)

let abortController = null

document.addEventListener('DOMContentLoaded', () => {
  $('.fetch-button').addEventListener('click', getPostsData)
})

async function getPostsData() {
  // AbortController 할당
  abortController = new AbortController()
  // abortSignal 선언
  const { signal } = abortController

  const timer = setTimeout(() => {
    // 특정 ms 이후 요청을 수동으로 중단
    abortController.abort()
    console.log('abort')
  }, 100)

  try {
    // fetch API에 signal 선언
    const response = await fetch(FETCH_URL, { signal })
    const posts = await response.json()

    drawPosts(posts)
  } catch (error) {
    alert(error)
    exception()
  } finally {
    clearTimeout(timer)
    abortController = null
  }
}

function drawPosts(posts) {
  $('.list').innerHTML = posts
    .slice(0, 20)
    .map((post) => `<li>${post.title}</li>`)
    .join('')
}

function exception() {
  $('.list').innerHTML = '다시 요청해주세요'
}
```

코드가 길어보이지만 사실 AbortController에 대한 부분은 많이 없다. 😅

먼저 AbortController를 **생성자**를 통해 초기화한 부분이 보인다.

그리고 초기화한 abortController 변수에는 `signal`이라는 값이 존재하는데, 이를 통해 fetch API와 연결하여 **특정 신호**를 보내 요청을 중단시킬 수 있다.

AbortController는 한 가지 이상의 요청에 대해서 중단 요청을 할 수 있지만, 현재 예제에서는 하나의 요청만을 중단할 것이기 때문에 요청할 함수 내에서 매번 AbortSignal을 생성하여 signal을 생성시켰다. (요청 수 그리고 상황마다 다르게 처리할 수 있다.)

이제 중단을 위한 신호를 주기 위해 `abortController.abort()`를 통해 요청 이후 10ms 가 지나면 중단될 수 있도록 처리했다.

나머지 코드들은 HTML을 위한 코드기 때문에 크게 신경쓰지 않아도 된다. (필요시 예제 코드를 참고)

### 중단 확인

이제 요청 버튼을 클릭하면 실제로 잘 요청이 중단되는지 확인해보면 아래와 같은 에러가 출력된다.

> AbortError: The user aborted a request.

여기서 알 수 있는 것은 바로 비동기 요청에 중단에 대한 응답이 **catch**에서 처리된다는 것이다. 😲

요청이 중단되었기 때문에 drawPosts를 통해 화면에 그려지는 것 없이 exception 함수의 결과가 출력된다.

<Image src="/images/2022/06/abort-controller/abort-error.png" alt="abort error" width="100%" />

이처럼 뭔가 특정한 요청을 했는데 일정 시간이 지나면 요청을 중단 후 무언가를 통해 사용자에게 전달 할 수 있다.

그러면 정작 우리는 대부분이 리액트에서 개발하게 되는데, 이런 방법을 리액트에서는 어떻게 사용해야할까?

## React

### 예시 코드

```javascript
import React, { useEffect, useRef, useState } from 'react'
import './App.css'
import { Link } from 'react-router-dom'

const FETCH_URL = 'https://jsonplaceholder.typicode.com/posts'

function App() {
  // abortController ref로 초기화
  const abortController = useRef(null)
  const [posts, setPosts] = useState([])

  async function getPostsData() {
    // AbortController 할당
    abortController.current = new AbortController()
    // abortSignal 선언
    const { signal } = abortController.current

    try {
      // fetch API에 signal 선언
      const response = await fetch(FETCH_URL, {
        signal,
      })
      const posts = await response.json()

      setPosts(posts)
    } catch (error) {
      alert(error)
    }
  }

  // 버튼 클릭시 요청 중단
  const handleCancelClick = () => {
    abortController.current && abortController.current.abort()
  }

  useEffect(() => {
    getPostsData()

    // 컴포넌트 이탈시 요청 중단
    return () => abortController.current && abortController.current.abort()
  }, [])

  return (
    <div className="App">
      <header className="App-header">
        <button onClick={handleCancelClick}>중단</button>
        <Link to="/getout">다른 화면으로 이동</Link>
        <ul>
          {posts.slice(0, 20).map((post) => (
            <li key={post.id}>{post.title}</li>
          ))}
        </ul>
      </header>
    </div>
  )
}

export default App
```

사실 리액트에서도 크게 다른 부분은 없다.

useRef 훅을 사용하여 리렌더링에 따른 이슈를 방지하고, 이전 예시와 동일하게 비동기 요청시 AbortController를 할당해주면서 signal을 fetch API에 선언한다.

하지만 여기서는 시간에 따른 요청 중단이 아닌 버튼 클릭 이벤트, 그리고 컴포넌트 이탈시 abort()를 통해 수동으로 중단하는 형태를 띄고있다.

버튼 클릭으로 인한 중단과, 따로 중단하지 않은 두가지 케이스의 짤이다.

#### 중단하지 않은 결과

<Image src="/images/2022/06/abort-controller/none-abort.gif" alt="none abort" maxWidth="70%" />

#### 클릭시 요청 중단한 결과

<Image src="/images/2022/06/abort-controller/click-abort.gif" alt="abort click" maxWidth="70%" />

네트워크 요청이 중단된 형태와 아닌 형태 두개가 잘 처리된 것을 확인할 수 있다. 🎉


장비를 정지합니다. 안되잖아? 아 앙대!

AbortController로 네트워크 요청 중단시켜보기

javascript

abort-controller


import Image from './src/components/image'

블로그를 개설하고 약 6개월간 운영하면서 대략 26개의 글을 작성했다.

지금까지 글만 작성하면서 성능에 대해서는 크게 신경을 못썼었는데 글도 슬슬 많아지고 성능에도 욕심이 나서 구글성님의 [Lighthouse](https://developers.google.com/web/tools/lighthouse)를 통해 성능 측정을 해보았다.

### 첫 성능 측정 결과

<Image src="/images/2022/05/browser/prev.png" alt="prev result" width="60%" />

<br />

<Image src="/images/2022/04/react/bad.png" alt="bad" width="50%" />

전반적으로는 괜찮았지만 가장 밑에 있는 **Cumulative Layout Shift**가 눈에 띄었다.

[Cumulative Layout Shift](https://web.dev/i18n/ko/cls/)는 줄여서 CLS라고도 하는데 레이아웃 변화에 따른 측정값이다.

이는 사용자가 급작스런 **레이아웃 변경**으로 인해 시각적 안정성을 보장받지 못하는 경험을 측정한 점수로써 레이아웃 변동이 적고 예측이 가능할수록 점수가 0에 가까워지는 항목이다.

현재 블로그에서는 SSG 형태로 되어있으며 최초 사용자가 접근시 글에 대한 데이터를 가져와야 하기 때문에 그 때 잠깐 큰 레이아웃 이동이 일어난다.

<Image src="/images/2022/05/browser/current.gif" alt="current" width="50%" />

물론 간단한 수준의 데이터라 무거운 데이터도 아니어서 엄청 불편하진 않지만, 이전에 MPA(Multi Page Application)의 시절처럼 새로고침 되는 느낌이 들어 좋은 경험은 아니라고 판단했다. 🤔

그래서 [이전 글](https://www.fronttigger.dev/2022/react/skeleton-ui)에서 만들었던 Skeleton UI를 활용하여 CLS를 개선해보았다. (코드는 이 글에서 설명하지 않는다.)

### Skeleton UI 적용 이후

<Image src="/images/2022/05/browser/success.gif" alt="success" width="50%" />

원래 이렇게 오래걸리진 않지만 글에서는 시각적으로 보여주기 위해 약 1초동안 스켈레톤 컴포넌트를 보여주는 형태로 처리했다.

여기서 추가적으로 더 자연스럽게 보이려면 FadeIn과 같은 애니메이션을 추가하면 사용자가 더욱 좋은 경험을 누릴 수도 있을 것 같다. 😄 (이 글에서는 다루지 않는다.)

자 그러면 위와 같이 스켈레톤을 적용한 결과는 과연 어떻게 나올까?

### LightHouse 재측정 결과

<Image src="/images/2022/05/browser/next.png" alt="next" width="60%" />

<br />

<Image src="/images/2022/04/react/cool.png" alt="cool" width="50%" />

경고등이 떴었던 지난 날을 뒤로하고 가장 최고점인 0이 되었다!

점수도 그에맞게 86점에서 96점으로 무려 10점이나 상승하였다. 🎉🎉


Skeleton UI를 통해 블로그 CLS 최적화 해보기 (feat. Lighthouse)

browser

lighthouse-cls


import Image from './src/components/image'

Skeleton 컴포넌트는 통해 실제 데이터가 보여지기 전에 그려주는 컴포넌트다.

물론 화면을 구성함에 있어서 필수적인 컴포넌트는 아니겠지만 주로 사용되는 방법으로는 사용자의 **이탈방지**, 급격한 **레이아웃 이동** 방지, 기존 **로딩** 컴포넌트 대체 등 많은 이유로 사용되고 있다.

바로 아래와 같은 화면이다.

<Image src="/images/2022/05/react/wanted-skeleton.png" alt="skeleton" width="100%" />

위 화면은 원티드에서 채용정보 데이터를 그려주기 전 그려줄 위치에 미리 컨텐츠의 레이아웃을 차지하고 있는 형태이다.

이렇게 미리 컨텐츠 영역을 차지하고 대기한다면 사용자는 해당 컨텐츠의 위치를 **예측**할 수 있으며 뜬금없이 컨텐츠가 등장하지 않기 때문에 좋은 사용성을 제공할 수 있다.

위와 이어지는 개념으로 [CLS(Cumulative Layout Shift)](https://web.dev/i18n/ko/cls/)라는 것을 통해 예기치 않은 레이아웃 이동을 측정하여 점수를 매기기도 하는 등 사용성에서 굉장히 중요한 개념으로 자리매김 했다.

실제 코드는 [Github](https://github.com/fronttigger/code-playground/tree/main/skeleton)에 있으니 필요시 참고하면 된다. 💻

## 컴포넌트 기능 정의

일단 스켈레톤 컴포넌트가 가질 기능에 대해서 정의해야했다.

여러가지 자료를 찾아보던 중 [Material UI](https://mui.com/material-ui/react-skeleton/)의 스켈레톤 컴포넌트가 단순하면서 명확했다.

여기서 나는 애니메이션에 대한 기능을 추가해 총 7 개의 props로 정의했다.

- variant: 스켈레톤 컴포넌트의 모양
- width: 넓이
- height: 높이
- animation: 애니메이션 종류
- animationSpeed: 애니메이션 속도
- waveColor: 웨이브 애니메이션 색
- backgroundColor: 배경색

## 컴포넌트 구현

### props typing

먼저 각 props에 대한 타이핑을 진행했다.

```typescript
// Skeleton/index.tsx
type VariantType = 'text' | 'circular' | 'rectangular'
type AnimationType = 'pulsate' | 'wave' | false

interface SkeletonProps {
  variant?: VariantType
  width?: string
  height?: string
  animation?: AnimationType
  animationSpeed?: number
  backgroundColor?: string
  waveColor?: string
}
```

### 스타일 구현

props에 따른 스타일을 만들기 위해 컨테이너 컴포넌트를 구현했다.

```typescript
import styled from '@emotion/styled'
// 생략..
const Container = styled.div<SkeletonProps>``

function Skeleton({
  variant,
  width,
  height,
  animation,
  animationSpeed,
  backgroundColor,
  waveColor,
}: SkeletonProps): JSX.Element {
  return (
    <Container
      variant={variant}
      width={width}
      height={height}
      animation={animation}
      animationSpeed={animationSpeed}
      backgroundColor={backgroundColor}
      waveColor={waveColor}
    />
  )
}

export default Skeleton
```

이제 정의한 props에 대한 컨테이너 컴포넌트에서 조건에 맞는 스타일을 작성해주면 된다.

### variant

일단 첫번째로 모양에 대한 스타일을 정의했다.

```typescript
import styled from '@emotion/styled'
import { css, SerializedStyles } from '@emotion/react'

const variants: { [key in VariantType]: SerializedStyles } = {
  text: css`
    border-radius: 4px;
  `,
  circular: css`
    border-radius: 50%;
  `,
  rectangular: css``,
}

const Container = styled.div<SkeletonProps>`
  ${({ variant }) => variants[variant || 'text']};
`

// 생략..
```

각 모양에 대한 스타일을 객체 형태를 통해 해당 type에 대한 css를 가져오도록 했다.

### width, height

높이, 넓이는 특별한 것 없이 문자열 형태로 받아서 처리해주었다.

```typescript
import styled from '@emotion/styled'
import { css, SerializedStyles } from '@emotion/react'

// 생략..

const Container = styled.div<SkeletonProps>`
  width: ${({ width }) => width};
  height: ${({ height }) => height};

  ${({ variant }) => variants[variant || 'text']};
`
```

### animation

[애니메이션](https://mui.com/material-ui/react-skeleton/#animations)은 두 가지가 있다.

첫번째는 pulsate인데, 이는 쉽게 말하면 깜빡이는 효과다.

두번째는 wave로 좌에서 우로 파도치듯이 이동하는 효과이다.

이 두가지를 keyframe 형태로 구현했다.

```typescript
const pulsateAnimation = keyframes`
  0% {
    background-color: rgba(227, 227, 227);
  }
  50% {
    background-color: rgba(227, 227, 227, 0.6);
  }
  100% {
    background-color: rgba(227, 227, 227);
  }
`

const waveAnimation = keyframes`
  0% {
    transform: translateX(-100%);
  }
  100% {
    transform: translateX(100%);
  }
`
```

그런데 여기서 기능 정의때 추가했던 props 중 animationSpeed, backgroundColor, waveColor가 있다는 것을 눈치챘다. 🧐

위 세가지를 추가적으로 대응하기 위해서는 pulsateAnimation의 경우 keyframe를 만들기보단 background prop을 확장할 함수로 만들고, 이를 활용하는 스타일을 반환하는 함수를 구현하면 props에 따른 스타일을 구현할 수 있을 것 같았다.

```typescript
// 생략..
const getPulsateAnimation = (backgroundColor?: string) => keyframes`
  0% {
    background-color: ${backgroundColor};
  }
  50% {
    background-color: ${backgroundColor};
    opacity: 0.6;
  }
  100% {
    background-color: ${backgroundColor}
  }
`

function getBackgroundAnimation(
  animationType?: AnimationType,
  animationSpeed?: number,
  backgroundColor?: string,
  waveColor?: string,
): SerializedStyles {
  switch (animationType) {
    case 'pulsate':
    default: {
      return css`
        animation: ${getPulsateAnimation(backgroundColor)} ${`${animationSpeed}s`} ease-in-out 0.5s infinite;
      `
    }
    case 'wave': {
      return css`
        position: relative;
        overflow: hidden;

        &::before {
          content: '';
          position: absolute;
          bottom: 0;
          left: 0;
          right: 0;
          top: 0;
          width: 100%;
          height: 100%;
          transform: translateX(-100%);
          background: linear-gradient(90deg, transparent, ${waveColor}, transparent);
          animation: ${waveAnimation} ${`${animationSpeed}s`} ease-in-out 0.5s infinite;
        }
      `
    }
    case false: {
      return css``
    }
  }
}

const Container = styled.div<SkeletonProps>`
  width: ${({ width }) => width};
  height: ${({ height }) => height};
  background-color: ${({ backgroundColor }) => backgroundColor};

  ${({ variant }) => variants[variant || 'text']};
  ${({ animation, animationSpeed, backgroundColor, waveColor }) =>
    getBackgroundAnimation(animation, animationSpeed, backgroundColor, waveColor)};
`

// 생략..
```

위처럼 애니메이션의 case를 찾아 해당 prop에 맞는 스타일을 반환해주게 처리했다.

그리고 마지막으로 컴포넌트에 기본값을 정의해주었다.

```typescript
const BASE_BACKGROUND_COLOR = 'rgba(227, 227, 227)'
const WAVE_BACKGROUND_COLOR = 'rgba(0, 0, 0, 0.07)'

// 생략..

function Skeleton({
  variant = 'text',
  width = '100%',
  height = '100%',
  animation = 'pulsate',
  animationSpeed = 1.5,
  backgroundColor = BASE_BACKGROUND_COLOR,
  waveColor = WAVE_BACKGROUND_COLOR,
}: SkeletonProps): JSX.Element {
  return (
    <Container
      variant={variant}
      width={width}
      height={height}
      animation={animation}
      animationSpeed={animationSpeed}
      backgroundColor={backgroundColor}
      waveColor={waveColor}
    />
  )
}
```

자 이제 실제로 잘 동작하는지 확인해보자

## 테스트

```typescript
// App.tsx
import React from 'react'
import './App.css'

import Skeleton from './skeleton'

function App() {
  return (
    <div className="App">
      <header className="App-header">
        <div style={{ width: 40, height: 40 }}>
          <Skeleton variant="circular" />
          <div style={{ width: 200, height: 100, marginTop: 10 }}>
            <Skeleton variant="rectangular" />
          </div>
          <div style={{ width: 140, height: 14, marginTop: 10 }}>
            <Skeleton variant="text" />
          </div>
          <div style={{ width: 100, height: 14, marginTop: 5 }}>
            <Skeleton variant="text" />
          </div>
        </div>
      </header>
    </div>
  )
}

export default App
```

<br />

<Image src="/images/2022/05/react/skeleton.gif" alt="skeleton" width="40%" />

<br />

<Image src="/images/2022/05/react/skeletonwave.gif" alt="skeleton" width="40%" />

의도한대로 잘 동작한다! 🎉


데이터의 빈자리를 대신해줄 Skeleton 컴포넌트 구현하기 (feat. emotion)

skeleton-ui


React에서 [hook](https://reactjs.org/docs/hooks-intro.html)은 [16.8](https://github.com/facebook/react/blob/main/CHANGELOG.md#1680-february-6-2019)에서 추가된 기능이다.

현재 기준으로 대략 3년 정도 전에 등장했으며 첫 등장 이후로 최근까지 지속적으로 훅들이 개선되고 [추가](https://github.com/reactjs/rfcs/tree/useevent/text)되고 있다.

그렇게 훅이 등장하면서 새롭게 만들어질 컴포넌트에 한해서 function component를 리액트 팀에서 [권장](https://ko.reactjs.org/docs/hooks-overview.html#but-what-is-a-hook)되고있다.

그래서 현재 개발하는 대부분의 컴포넌트는 특별한 경우가 아니라면 대부분 함수 컴포넌트를 통해 개발하면서 훅을 사용하고 있을 것이고, 나 또한 그렇게 하고있다.

그런데 그렇게나 많이 훅을 사용하여 개발하면서 정작 이 훅들이 어떻게 동작하는지에 대해선 생각해보지 못했다. 😅

뜨끔하여 바로 관련된 아티클을 찾아보다가 2019년 JSConf에서 발표한 [유튜브 자료](https://www.youtube.com/watch?v=KJP1E-Y-xyo)가 있어 이를 시청하였고 (영어로 되어있어서 모든걸 이해한건 아니지만..) 정리해두면 많은 도움이 될 것 같았다.

## 클로저가 뭐지..?

사실 리액트를 활용해 개발하고 있다면 자바스크립트를 통해 개발하고 있으므로 클로저라는 개념에 대해 들어본 경험이 있을 것이다.

클로저에 대한 개념을 정말 여러가지로 정의하고 있지만 가장 쉽고 명확하게 정리한 개념이 있다.

> en: closure makes it possible for a function to have "private" variables.  
> ko: 클로저는 함수에 "사적인" 변수를 가질 수 있도록 해준다.

우리가 평소에 들었던 `캡슐화` 라는 개념이 바로 여기서 등장한다. 어떻게 보면 `상태`를 가지고 있다고도 말할 수 있다.

그러면 이러한 형태를 보이지 않는 경우는 어떤게 있을까?

```javascript
let foo = 1 // global scope

function add() {
  foo += 1
  return foo
}

console.log(add()) // 2
console.log(add()) // 3
console.log(add()) // 4
```

foo라는 변수에 1을 더해주는 add 함수가 있다.

언뜻 보면 잘 동작하는 것 처럼 보이지만, 문제가 발생한다.

```javascript
let foo = 1 // global scope

function add() {
  foo += 1
  return foo
}

console.log(add()) // 2
console.log(add()) // 3
foo = 9999
console.log(add()) // 10000
```

foo를 global에서 접근하여 임의로 수정이 가능하다는 점이다.

그래서 깨달았다! 💡

foo라는 변수를 밖에서 건들지 못하도록 해야겠구나!

그래서 이렇게 변경해보았다.

```javascript
function add() {
  let foo = 1
  foo += 1
  return foo
}

console.log(add()) // 2
console.log(add()) // 2
foo = 9999 // 'foo' is not defined.
console.log(add()) // 2
```

이제 밖에서 접근하진 못하지만 2값이 매번 출력된다.

이는 add 함수를 호출할 때 항상 foo를 1로 초기화하기 때문이다.

그래서 이렇게 다시 변경했다.

```javascript
function getAdd() {
  let foo = 1

  return function () {
    foo += 1

    return foo
  }
}

const add = getAdd()

console.log(add()) // 2
console.log(add()) // 3
foo = 9999 // 'foo' is not defined.
console.log(add()) // 4
```

이렇게 되면 getAdd 함수에서 add 함수를 반환해 함수를 add 함수를 호출할 때 마다 getAdd 함수에 선언되어있는 foo에 접근할 수 있다. 그리고 foo는 **변경된 값을 유지**한다.

여기서 **모듈 패턴**을 통해서도 클로저를 만들 수 있다.

```javascript
const add = (function getAdd() {
  let foo = 1

  return function () {
    foo += 1

    return foo
  }
})()

console.log(add()) // 2
console.log(add()) // 3
console.log(add()) // 4
```

이게 바로 클로저다. (두둥!)

이는 외부에서 접근할 수 없지만 내부에서는 add 함수 실행을 통해 접근할 수 있다.

바로 이런점을 활용하여 React Hook은 만들어졌다.

## closure를 hook에 적용하기

### useState 구현

```javascript
function useState(initVal) {
  let _val = initVal
  const state = () => _val
  const setState = (newVal) => {
    _val = newVal
  }

  return [state, setState]
}

const [count, setCount] = useState(1)
console.log(count()) // 1
setCount(2)
console.log(count()) // 2
```

initVal을 선언 후 그 값을 반환하는 함수와 갱신하는 함수를 만들어 배열 형태로 반환하면 완성이다.

그런데 우리는 리액트에서 useState 함수를 바로 가져와 사용하지 못한다.

바로 React 모듈 안에 위치하기 때문인데, 아까 클로저 함수를 만들었던 방식대로 모듈 패턴을 사용해보자

```javascript
const React = (function () {
  function useState(initVal) {
    let _val = initVal
    const state = () => _val
    const setState = (newVal) => {
      _val = newVal
    }

    return [state, setState]
  }

  return { useState }
})()

const [count, setCount] = React.useState(1)
console.log(count()) // 1
setCount(2)
console.log(count()) // 2
```

자 그러면 이제 훅을 실행할 컴포넌트를 만들어보자

```javascript
function Component() {
  const [count, setCount] = React.useState(1)

  return {
    render: () => console.log(count),
    click: () => setCount(count),
  }
}
```

컴포넌트에서는 렌더링과 클릭에 대한 값을 반환해주고 있다.

그러면 이제 컴포넌트를 어떻게 렌더링 해주어야할지 알려줘야한다.

```javascript
const React = (function () {
  function useState(initVal) {
    let _val = initVal
    const state = () => _val
    const setState = (newVal) => {
      _val = newVal
    }

    return [state, setState]
  }

  function render(Component) {
    const C = Component()
    C.render() // 컴포넌트 렌더링

    return C
  }

  return { useState, render }
})()

function Component() {
  const [count, setCount] = React.useState(1)

  return {
    render: () => console.log(count),
    click: () => setCount(count),
  }
}

var App = React.render(Component) // ƒ state() {}
App.click()
var App = React.render(Component) // ƒ state() {}
```

현재 함수가 찍히는 이유는 useState에서 state를 반환 함수로 보내주고 있기 때문이다.

그래서 이를 해결하기 위해 \_val 변수를 밖으로 이동시킨다.

그러면 이제 initVal까지 처리가 가능해진다.

```javascript
const React = (function () {
  let _val

  function useState(initVal) {
    const state = _val || initVal
    const setState = (newVal) => {
      _val = newVal
    }

    return [state, setState]
  }

  function render(Component) {
    const C = Component()
    C.render()

    return C
  }

  return { useState, render }
})()

function Component() {
  const [count, setCount] = React.useState(1)

  return {
    render: () => console.log(count),
    click: () => setCount(count + 1),
  }
}

var App = React.render(Component) // 1
App.click()
var App = React.render(Component) // 2
```

자 여기까지 보면 useState 선언, 렌더링 후 click을 통한 state 변경이 값이 잘 유지된 채로 진행되고 있다는 것을 알 수 있다.

## hook을 여러개 사용하기

하지만 useState를 **여러개(2개 이상)** 사용한다면 정상적으로 동작하지 않게된다.

```javascript
// ... 생략

function Component() {
  const [count, setCount] = React.useState(1)
  const [text, setText] = React.useState('apple')

  return {
    render: () => console.log({ count, text }),
    click: () => setCount(count + 1),
    type: (word) => setText(word),
  }
}

var App = React.render(Component) // { count: 1, text: "apple"}
App.click()
var App = React.render(Component) // { count: 2, text: 2 }
App.type('pear')
var App = React.render(Component) // { count: "pear", text: "pear"}
```

그 이유는 React 모듈에 있는 값은 `_val` **하나**이기 때문이다. 갱신하는 함수를 호출할 때마다 \_val을 덮어쓰기 때문에 항상 같은 값으로 갱신되게 된다.

이를 방지하기 위해 상태의 수만큼 처리할 수 있도록`배열`과 `인덱스`를 활용하여 개선해보자

```javascript
const React = (function () {
  let hooks = []
  let idx = 0

  function useState(initVal) {
    const state = hooks[idx] || initVal
    const setState = (newVal) => {
      hooks[idx] = newVal
    }

    idx += 1

    return [state, setState]
  }

  function render(Component) {
    const C = Component()
    C.render()

    console.log(idx) // 2, 4, 6

    return C
  }

  return { useState, render }
})()

function Component() {
  const [count, setCount] = React.useState(1)
  const [text, setText] = React.useState('apple')

  return {
    render: () => console.log({ count, text }),
    click: () => setCount(count + 1),
    type: (word) => setText(word),
  }
}

var App = React.render(Component) // { count: 1, text: 'apple' }
App.click()
var App = React.render(Component) // { count: 2, text: 'apple' }
App.type('pear')
var App = React.render(Component) // { count: 'pear', text: 'apple' }
```

여기서 pear를 추가한 순간 원래 text에 갱신이 되어야했지만 count에 변경이 되었다.

그 이유는 React.render를 하는 순간 Component가 useState 함수를 호출하게 되고 자동으로 idx가 추가가 된다.

그래서 이미 증가된 idx를 통해 갱신을 하다보니 값이 이상해진다.

그러면 idx가 증가되는걸 알아냈으니 이를 고쳐보자

```javascript
const React = (function () {
  let hooks = []
  let idx = 0

  function useState(initVal) {
    const state = hooks[idx] || initVal
    const setState = (newVal) => {
      hooks[idx] = newVal
    }

    idx += 1

    return [state, setState]
  }

  function render(Component) {
    idx = 0
    const C = Component()
    C.render()

    return C
  }

  return { useState, render }
})()

function Component() {
  const [count, setCount] = React.useState(1)
  const [text, setText] = React.useState('apple')

  return {
    render: () => console.log({ count, text }),
    click: () => setCount(count + 1),
    type: (word) => setText(word),
  }
}

var App = React.render(Component) // { count: 1, text: 'apple' }
App.click()
var App = React.render(Component) // { count: 1, text: 'apple' }
App.type('pear')
var App = React.render(Component) // { count: 1, text: 'apple' }

// [ <2 empty items>, 2 ]
// [ <2 empty items>, 'pear' ]
```

자 idx를 render시 0으로 초기화 해줬더니 아예 상태가 바뀌지 않는 현상으로 되어버렸다.

이런 현상은 당연하게도 render가 먼저 발생하고 그 이후 setState가 발생하면서 idx가 계속 0으로 들어가기 때문에 hooks 배열에 값이 저장되지 못하고 initVal이 계속 state를 대신한 값이 되어버리기 때문이다. 그리고 두번 호출 이후 idx가 3이 되었을 때 들어가기 때문에 값은 세번째에 들어가게 되는 것이다.

자 그러면 이렇게 변동되는 idx가 문제라는 것을 알았으니 이를 해결해보자

```javascript
function useState(initVal) {
  const state = hooks[idx] || initVal
  const _idx = idx // freeze
  const setState = (newVal) => {
    hooks[_idx] = newVal
  }

  idx += 1

  return [state, setState]
}

var App = React.render(Component) // { count: 1, text: 'apple' }
App.click()
var App = React.render(Component) // { count: 2, text: 'apple' }
App.type('pear')
var App = React.render(Component) // { count: 2, text: 'pear' }
```

바로 변동되는 idx를 useState의 고유한 값으로 고정시켜놓는 것이다.

이렇게 되면 idx가 component render 이후 idx가 증가했더라도 useState만의 고유한 idx가 있기 때문에 그에 맞는 상태를 변경할 수 있게 된다. ☺️

## hook은 호출에 대한 순서보장이 필요하다

[리액트 공식문서](https://ko.reactjs.org/docs/hooks-rules.html#only-call-hooks-at-the-top-level)에도 명시되어 있듯이 hook은 반복문, 조건문 및 중첩된 함수에서 사용하면 안된다.

그 이유는 동일한 순서로 호출이 되어야 하기 때문이다.

```javascript
function Component() {
  if (Math.random() > 0.5) {
    const [count, setCount] = React.useState(1) // ReferenceError: count is not defined
  }

  const [text, setText] = React.useState('apple')

  return {
    render: () => console.log({ count, text }),
    click: () => setCount(count + 1),
    type: (word) => setText(word),
  }
}
```

원래는 hook을 호출한 순간 각각의 상태에 대한 배열의 idx를 부여받고 그 곳에서 상태를 관리하지만,

만약 특정 조건에 따라서 hook이 생성된다면 idx가 변경될 여지가 있기 때문이다.

이처럼 리액트 훅은 클로저라는 개념을 사용하여 private한 값을 활용하여 구성되어있다.

평소에 클로저의 개념에 대해서만 대략 알고있었지 사실 실제 코드에서 적용한다거나, 의식적으로 찾아보지 않았는데 이번 기회를 통해 클로저와 훅의 원리에 대해 공부하는 좋은 계기가 되었다! 👍

[해당 영상](https://www.youtube.com/watch?v=KJP1E-Y-xyo)에 나머지 부분이 있으니 궁금하다면 더 참고하면 좋을 것 같다.


React Hook과 Closure의 관계 (feat. useState)

react-hook-closure


import Image from './src/components/image'

이전 블로그는 티스토리를 사용을 하고 있어서 사이트맵과 같은 SEO 처리를 크게 다룰 일이 없었다.  
하지만 여차저차 하다보니 블로그를 직접 만들게 되었고 만들고 보니 SEO 대응을 뒤늦게 해야겠다는 생각이 들었다.

물론 Next.js에서 기본적으로 제공하는 meta 정보와 SSG(Static Site Generation)를 통해서 어느정도는 커버가 가능하지만, 이외에 특정 브라우저에 대한 대응은 추가로 해주어야했다.

그래서 가장 기본적이고 구글에 내 존재를 인식시키기 위해 사이트맵(sitemap)을 구현하기로 하였다.

구글에서는 친절하게 [공식문서](https://developers.google.com/search/docs/advanced/guidelines/get-started?hl=ko)로 차근차근 알려주고 있어서 이를 참조하여 진행했다.

## sitemap.xml의 정체

먼저 Sitemap을 구현하기 위해 어떻게 생긴 친구인지 알아보아야했다.

그래서 이전 블로그였던 티스토리의 사이트맵을 열어보았다.

```xml
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
    <url>
        <loc>https://junjangsee.tistory.com</loc>
        <lastmod>2022-05-13T00:09:41+09:00</lastmod>
        <priority>1.0</priority>
    </url>
    <url>
        <loc>https://junjangsee.tistory.com/category</loc>
    </url>
    <url>
        <loc>https://junjangsee.tistory.com/category/Back-end</loc>
    </url>
    <url>
        <loc>https://junjangsee.tistory.com/category/Front-end</loc>
    </url>
    // ....
</urlset>
```

처음보는 태그들로 둘러싸인 화면을 볼 수 있었고 `loc`는 검색엔진에게 제공할 URL을 말한다.

즉, sitemap.xml은 브라우저에 **어떤 URL을 크롤링**할지 정해주는 역할을 해준다.

그래서 나는 lastmod, priority는 딱히 나누지 않고 loc만 제공하기로 하였다.

## sitemap 구현

현재 글은 약 25개 정도여서 직접 하드코딩으로 만들어도 문제가 없겠지만, 이를 글 작성할 때마다 추가하고 유지보수하는게 매우 귀찮을거라 생각했다.

물론 [next-sitemap](https://www.npmjs.com/package/next-sitemap)과 같이 잘 되어있는 라이브러리도 있지만, 엄청 큰 서비스도 아니고 간단한 블로그용이어서 굳이 사용할 필요성을 못느꼈다.

```typescript
// sitemap.ts

import fs from 'fs'

import { getAllPosts } from './posts'

async function createSitemap() {
  const allPosts = await getAllPosts() // 글 전체를 가져온다.
  const slugs = allPosts.map((post) => post.slug) // 글의 slug만 가져온다.

  const postUrls = slugs.map(
    (slug) => `<url>
                 <loc>https://fronttigger.dev/${slug.year}/${slug.subject}/${slug.title}</loc>
               </url>`,
  ) // slug를 통해 글 URL들을 가진 배열을 생성한다.

  const sitemap = `<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
    <url>
        <loc>https://fronttigger.dev/posts</loc>
    </url>
    <url>
        <loc>https://fronttigger.dev/about</loc>
    </url>
        ${postUrls.join('\n')}
    </urlset>`.replace(/\n|\t/g, ' ') // 글들을 그려낸다.

  await fs.promises.writeFile('public/sitemap.xml', sitemap, {
    encoding: 'utf-8',
  }) // public/sitemap.xml 위치에 파일을 생성한다.
}

createSitemap() // 실행한다.
```

주석에 간단한 역할에 대해서 명시를 해놓았지만, 큰 틀은 전체 게시글에 대한 URL을 만들고 이를 sitemap.xml 파일에 녹여내는 것이다.

자 그런데 다 만들고 나니 한가지 의문이 들었다.

지금 만든 사이트맵 함수를 동작하는 시점은 언제로 잡아야할까? 🤔

## sitemap 생성

이 함수를 만든 이유가 일일이 글을 작성 이후에 수동으로 넣기 싫어서인데.. 그러면 배포 전 빌드타임에 이를 만들어주면 되지 않을까? 생각했다.

그래서 ts-node를 활용해서 빌드 타임에 명령어를 실행하도록 처리했다.

```json
"scripts": {
    "sitemap": "ts-node --project tsconfig.node.json ./src/utils/sitemap.ts",
    "build": "npm run sitemap && next build && next export"
}
```

이렇게 되면 배포 전 build시 sitemap을 생성할거고, 그 생성한 sitemap을 구글에서 크롤링해서 도메인에 대한 정보를 심어줄 수 있다.

## robots.txt

여기서 또 중요한 개념이 있다.

바로 크롤러가 내 URL에 있는 정보들을 가져갈 수 있도록 등록을 해주어야하는데 이게 바로 `robots.txt`다.

형태는 아래와 같다.

```txt
User-agent: *
Allow: /
Sitemap: https://fronttigger.dev/sitemap.xml
```

모든 userAgent에 대해서 허용하고 sitemap의 URL까지 알려주면 내 도메인에 대한 sitemap을 가져갈 수 있도록 오픈한 것이다.

이제 배포를 해보자!

<Image src="/images/2022/04/browser/sitemap.png" alt="sitemap" width="100%" />

sitemap이 잘 나타나고 있다.

하지만

> 끝날 때까지 끝난게 아니다. ⚾️

바로 [구글 서치 콘솔](https://search.google.com/search-console/welcome?hl=ko)에 URL에 대한 검증을 통해 등록하고, 사이트맵을 수동으로 등록해주어야 모든 과정이 끝난다. (여기서는 등록에 관한 설명은 하지 않는다. 별거 없음!)

만약 등록이 완료되면 아래와 같이 처리된다.

<Image src="/images/2022/04/browser/search-console.png" alt="google search console" width="100%" />

여기까지 등록되면 sitemap에 대한 기본적인 처리가 끝이났다.

이번 계기를 통해 어떤 형태로 구글에게 정보를 넘겨줘야할지 감을 잡는 좋은 기회였다. 👍


검색이 되면 안 되는 수준 낮은 블로그

프로젝트에 사이트맵을 만들어 SEO 개선하기 (feat. Next.js)

sitemap


타입스크립트를 활용해 개발하다 보면 기존 자바스크립트만으로 개발할 때보다 안정성이 확실히 증가하는 것을 느낀다.

컴파일 단계와 타입체킹 단계에서 타입스크립트 엔진이 어련히 알아서 타입 추론과 체크를 해주는 덕분에 우리는 타입스크립트가 시키는대로 조건만 맞추어 준다면 편안- 하게 개발이 가능하다. (물론 불편한 점들도 있지만.. 😇)

하지만 타입스크립트의 타입에도 허점이 있다.
바로 부분적으로 타입 보장이 안된다는 것이다.

예를 들어보자!

## 재미난 현상 발견

```javascript
let nickname: null | string = 'fronttigger'

function whatIsNicknameType() {
  nickname // null | string

  if (nickname == null) {
    nickname // null
    return
  }

  nickname // string
}

if (nickname != null) {
  whatIsNicknameType()
}
```

위 코드를 보면 뭔가 쎄하다. 🤔

분명 whatIsNicknameType 함수를 실행하는 조건은 nickname 변수가 `null`이 아닐 때 인데, 막상 함수 내부에서의 첫 번째 nickname은 null과 string 타입 두 개의 타입이다.

뭔가 이상하지 않은가?

바로 이런 부분에서 타입스크립트는 느슨하게 타입을 검사한다.

이를 방지하기 위해 Node.js 에서는 `assert` 라는 함수를 사용한다.

## Node.js 에서는?

```typescript
const assert = require('assert')

function multiply(x, y) {
  assert(typeof x === 'number')
  assert(typeof y === 'number')

  return x * y // number * number
}

multiply(2, 2) // 4
multiply(3, '1')
// AssertionError [ERR_ASSERTION]: The expression evaluated to a falsy value: assert(typeof y === 'number')
```

assert를 통해 특정 타입을 단언을 시킨 후 반환 값을 강제했다.

만약 단언한 값이 들어오지 않을 경우 **AssertionError**를 던져낸다.

이에 관한 사항은 [타입스크립트 3.7](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-7.html#assertion-functions)에 공식적으로 명시가 되어있다.

그래서 타입스크립트는 위와 같은 현상을 해결하기 위해 `assertion signatures`를 도입하였고 이를 통해 Node.js에서 사용하던 방식처럼 사용이 가능하다.

한 번 만들어보자!

## assert function 구현

```typescript
export default function assert(condition: unknown, errorMessage?: string): asserts condition {
  if (!condition) {
    throw new Error(errorMessage || 'condition 조건이 true가 아닙니다.')
  }
}
```

함수의 타입에 `asserts` 키워드가 들어갔다.

그리고 asserts는 타입을 보장하기 위한 인자를 가진다. (여기서는 condition)

이렇게 되면 입력받은 condition이 **true**인 경우 조건이 포함하는 범위의 나머지 부분에 대한 타입을 보장받는다.

## assert function 사용

```typescript
function getNickname(name: string | null): string {
  assert(name != null) // true

  return name // string
}

getNickname('fronttigger') // fronttigger
```

위에서 만든 assert 함수를 사용한 간단한 함수를 만들어보았다.

여기서 name 인자로 넘어온 값이 'fronttigger' 문자열이므로 true가 되어 Error을 throw 하지 않는다.

원래는 내부에서 느슨한 타입체크로 인해 null 확인을 추가로 해줘야하는 번거로움이 있었지만, 이제 그럴 필요 없이 assert 함수를 true 조건으로만 맞추어준다면 그 다음 부터는 true에 대한 타입이 보장받게 된다. 👍

이런 타입 가드 함수들을 통해 보다 안전하고 깔끔한 타입스크립트 코딩이 가능하다! 💻


const 앞으로_평생할_게임 = "타입 디펜스"

타입스크립트의 Assertion Functions을 활용해 타입 보장하기

type-guard


import Image from './src/components/image'

[이전 글](https://fronttigger.dev/2022/yarn/berry-ts-rollup-react)에서 yarn berry + typescript + rollup + react를 활용하여 환경구성을 진행했었다.

그 다음 글이 제목과도 같은 추가적인 몇가지에 대한 글로 예고를 했었는데 흐름에 맞게 바로 반강제(?)로 진행하게 되었다.

이전 글의 결론은 React 컴포넌트를 만들어서 외부 프로젝트에서 사용하는 것 까지 진행했었다.

그래서 이번엔 styled-components를 통해 컴포넌트를 꾸미고, jest로 그걸 테스트하고, 스토리북을 통해 문서화까지 진행한 경험을 공유하려한다.

## styled-components Setup

styled-components를 사용하기 위해서는 먼저 디자인 시스템을 사용할 프로젝트를 위해 peerDependencies를 추가해야한다.

### peerDependencies 추가

```bash
yarn add -P styled-components
```

추가가 되었다면 이제 타입스크립트를 대응하기 위해 devDependencies에 의존성을 추가한다.

### devDependencies 추가

```bash
yarn add -D @types/styled-components
```

이렇게 되면 개발 준비 자체는 다 끝!

### babel-plugin-styled-components 의존성 추가

만약 여기서 디버깅을 용이하게 하고싶다면 아래 의존성을 추가한다.

```bash
yarn add -D babel-plugin-styled-components
```

```babelrc
// .babelrc

{
  "plugins": ["babel-plugin-styled-components"]
}
```

자 그러면 디버깅까지 준비가 끝났다.

이제 한 번 간단한 버튼 컴포넌트를 통해 테스트해보자

```typescript
// src/button/index.tsx

import React, { PropsWithChildren } from 'react'

import styled from 'styled-components'

interface ButtonProps {
  color?: string
}

const ButtonComponent = styled.button<ButtonProps>`
  color: ${({ color }) => color || 'black'};
`

function Button({ color, children }: PropsWithChildren<ButtonProps>) {
  return <ButtonComponent color={color}>{children}</ButtonComponent>
}

export default Button
```

버튼 완성! 🎉

이걸 이제 프로젝트에서 실행을 시켜보자

```typescript
import { Button } from '@fronttigger/design-system'

function App() {
  return (
    <div className="App">
      <header className="App-header">
        <Button color="red">버튼</Button>
      </header>
    </div>
  )
}

export default App
```

<Image src="/images/2022/04/yarn/button.png" alt="button" maxWidth="60%" />

완벽하게 의도한대로 동작한다!

이제 styled-components를 통해 컴포넌트를 개발할 수 있다. 👍

## Testing Setup

리액트에서도 여러가지 컴포넌트 테스팅 라이브러리가 있지만 가장 대표적인 [react-testing-library](https://testing-library.com/docs/react-testing-library/intro/)가 있다.

위 라이브러리를 활용하여 리액트 컴포넌트 테스트 환경을 구성해보자

### 의존성 설치

먼저 위 라이브러리를 사용하기 위해서는 [jest](https://jestjs.io/)가 필요하다.

```bash
yarn add -D jest babel-jest ts-jest @types/jest identity-obj-proxy
```

위 의존성을 모두 설치했다면 react-testing-library 관련된 의존성을 설치하자

```bash
yarn add -D @testing-library/dom @testing-library/jest-dom @testing-library/react @testing-library/react-hooks @testing-library/user-event @types/testing-library__jest-dom
```

벌써 엄청난 양의 라이브러리를 추가했지만 아직 멀었다.

그 이유는 테스트는 개발환경에서 작성하는 것이기 때문에 리액트가 개발환경에서 테스트될 수 있도록 babel과 react에 관련된 의존성을 또 추가해줘야한다. 😇

```bash
yarn add -D @babel/preset-env @babel/preset-react babel-preset-react-app react@17.0.2 react-dom@17.0.2 react-is
```

자 이제 거의 다왔다.

### babel 설정

방금 설치한 babel을 설정한다.

```babelrc
{
  "presets": [
    "@babel/preset-env",
    "@babel/preset-react",
    ["react-app", { "flow": false, "typescript": true }]
  ],
  "plugins": ["babel-plugin-styled-components"]
}
```

### jest 설정

자 이제 테스트의 대망의 마지막 설정 단계다.

jest를 사용하기 위해서는 두가지 파일이 필요한데 `jest.config.js`와 `jest.setup.js`다.

#### jest.setup.js

```javascript
import '@testing-library/jest-dom'
```

#### jest.config.js

```javascript
module.exports = {
  preset: 'ts-jest',
  testEnvironment: 'jsdom',
  setupFilesAfterEnv: ['./jest.setup.js'],
  moduleFileExtensions: ['ts', 'tsx', 'js', 'jsx', 'json', 'node'],
  moduleDirectories: ['src'],
  testRegex: '(/__(tests|specs)__/.*|(\\.|/)(test|spec))\\.([tj]sx?)$',
  transform: {
    '^.+\\.jsx?$': 'babel-jest',
    '^.+\\.tsx?$': 'ts-jest',
  },
  moduleNameMapper: {
    '\\.(jpg|ico|jpeg|png|gif|eot|otf|webp|svg|ttf|woff|woff2|mp4|webm|wav|mp3|m4a|aac|oga)$':
      'identity-obj-proxy',
    '\\.(css|less|scss|sass)$': 'identity-obj-proxy',
  },
  globals: {
    __PATH_PREFIX__: '',
    'ts-jest': {
      diagnostics: false,
      tsconfig: 'tsconfig.jest.json',
      babelConfig: true,
    },
  },
}
```

여기서 참고할 점은 jest를 활용할 tsconfig를 따로 분리하였다. (tsconfig.json으로 한 번에 처리해도 무방하다.)

이 두가지 파일을 통해 test에 대한 설정값을 제공한다.

### 테스트

이제 임의의 컴포넌트를 구현하고 test를 진행해보자

```typescript
// src/Accordion/index.spec.tsx

import React, { useState } from 'react'
import { render, screen } from '@testing-library/react'
import { renderHook, act } from '@testing-library/react-hooks'
import userEvent from '@testing-library/user-event'
import '@testing-library/jest-dom'

import Accordion from './index'

describe('Accordion', () => {
  test('제목 prop인 title에 "유의사항"을 입력하면 제목에 "유의사항"이 출력된다.', () => {
    render(<Accordion title="유의사항" />)

    const titleElement = screen.getByText('유의사항')
    expect(titleElement).toHaveTextContent('유의사항')
  })

  test('최초 상태의 아코디언을 클릭하면 입력한 아코디언 상세 내용인 "조심하세요"가 보여진다.', () => {
    render(<Accordion>조심하세요</Accordion>)

    const contentElement = screen.getByRole('button')
    userEvent.click(contentElement)

    const detailElement = screen.getByText('조심하세요')
    expect(detailElement).toHaveTextContent('조심하세요')
  })

  test('아코디언의 이벤트를 외부에서 받아왔을 때 상세 내용인 "조심하세요"가 보여진다.', () => {
    const { result } = renderHook((value) => useState(!!value), {
      initialProps: false,
    })

    const handleIsOpenToggle = () => {
      result.current[1]((state) => !state)
    }

    const { rerender } = render(
      <Accordion isOpen={result.current[0]} onToggle={handleIsOpenToggle}>
        조심하세요
      </Accordion>,
    )

    expect(result.current[0]).toBe(false)

    act(() => {
      handleIsOpenToggle()
    })

    rerender(
      <Accordion isOpen={result.current[0]} onToggle={handleIsOpenToggle}>
        조심하세요
      </Accordion>,
    )

    expect(result.current[0]).toBe(true)

    const detailElement = screen.getByText('조심하세요')
    expect(detailElement).toHaveTextContent('조심하세요')
  })
})
```

이제 테스트를 돌려보자

```bash
yarn jest
```

<br />
<Image src="/images/2022/04/yarn/test.png" alt="test" width="100%" />

<br />
<Image src="/images/2022/04/react/cool.png" alt="cool" maxWidth="60%" />

드디어 길고 긴 테스트를 위한 여정이 끝났다. (테스트 하기도 전에 지쳐버림.. 😭)

이제 마지막 단계인 **Storybook**을 추가해보자

## Storybook Setup

[Storybook](https://storybook.js.org/)은 UI를 문서화하는 서비스다.

특히 디자인 시스템과 같이 공통으로 사용되는 컴포넌트가 있을 경우 개발자와 디자이너간의 소통을 정말 용이하게 만들어주기 때문에 만약 디자인 시스템을 구현하게 된다면 필수로 함께 구현해야한다고 개인적으론 생각한다. 🤔

## Init

storybook은 비교적 개발자들이 쉽게 사용할 수 하도록 CLI와 template를 편리하게 제공하고 있다.

[공식문서](https://storybook.js.org/docs/react/get-started/install)도 매우 잘되어있어서 보면서 세팅하기에는 큰 무리는 없을 것 같다.

지금은 CRA와 같은 환경이 아니기 때문에 존재하고 있는 프로젝트에 아래의 명령어를 작성한다.

```bash
npx sb init
```

위 명령어를 입력하면 여러개의 폴더와 파일이 생성된다.

살펴보기 전에 일단 실행해보자

### 실행

```bash
yarn storybook
```

실행하면 아래와 같은 에러가 뜬다.

> Error: @storybook/addon-interactions tried to access core-js, but it isn't declared in its dependencies; this makes the require call ambiguous and unsound.

아마 **addon**에서 문제가 발생하는 것 같다.

로그대로 `core-js`를 추가 설치한다.

```bash
yarn add -D core-js
```

설치한 뒤 다시 실행해보면 정상적으로 화면이 출력될 것이다.

<Image src="/images/2022/04/yarn/storybook.png" alt="storybook" width="100%" />

정상적으로 설치된 후 실행까지 확인헀는데 뭔가 덜한 것처럼 찜찜하다. 😕

바로 아까 만든 테스트한 컴포넌트들이 storybook에 앞으로 보여져야 한다는 것이다.

그런데 현재 **rollup.config.js**에서는 input을 `src/**/*` 형태로 주었기 때문에 이를 수정해야한다.

### rollup.config.js 수정

먼저 src 내부에 각각의 컴포넌트 디렉토리 내부에 테스트, 스토리북, 컴포넌트를 위치시키려고 한다.

```javascript
// rollup.config.js

const inputs = fs.readdirSync('./src', { withFileTypes: true }).reduce((config, f) => {
  if (f.isDirectory() && f.name !== 'stories') {
    const name = f.name
    const dir = `src/${name}`

    const files = fs.readdirSync(dir).reduce((result, file) => {
      if (file.match(/spec|test|stories/i)) {
        return result
      }

      const filename = path.parse(file).name
      result[`${name}/${filename}`] = `${dir}/${file}`

      return result
    }, {})

    return { ...config, ...files }
  }

  return config
}, {})

const input = { ...inputs, index: './src/index.ts' }
```

그래서 src 내에 생성된 stories 디렉토리를 제외한 디렉토리(컴포넌트 디렉토리)를 순회하여 index.stories.tsx 를 제외한 컴포넌트를 input에 넣어주었다.

이렇게 되면 아래와 같은 디렉토리 구조가 된다.

<Image src="/images/2022/04/yarn/directory.png" alt="directory" maxWidth="50%" />

자 그러면 이 상태에서 다시 실행해보자

<Image src="/images/2022/04/yarn/storybook_success.png" alt="storybook success" width="100%" />

구현한 Accordion 컴포넌트가 잘 출력된다. (물론 storybook 내부 구현은 진행했다.)
이제 각 프로젝트의 특성에 맞게 UI를 만들고 storybook을 구현하면 된다.

지금까지 간단한 것 같으면서 간단하지 않은 디자인 시스템 프로젝트 환경 구성을 진행해보았다.

글로 작성하려니 필요한 부분만 최소화 해서 작성하려니까 힘들었는데 최근 React의 18 버전 릴리즈로 인한 이슈, 상호 버전 호환에 대한 이슈, 라이브러리 여부에 대한 이슈 등 엄청나게 많은 이슈들을 만났었다.

일단 개발환경은 완성했으니 gitlab ci를 이용한 CI/CD 를 구축해보려고 하는데 아마 다음 글은 그 글이 되지 않을까 싶다. (또 아님 말고 😙)


베리베리 스트로베리의 두번째 이야기 ✌️

Latest