
## Contents

# 서론

군 복무 시절 사수가 “전산병이라면 키보드만으로 컴퓨터 기본 조작이 가능해야 한다.”고 우스갯소리로 말한 적이 있다.

처음 컴퓨터 세팅을 하다 보면 구식 인터페이스라 마우스가 호환되지 않거나 고장났거나 하는 등의 경우가 종종 있어 어느 정도 일리 있는 말이다.

웹 개발자로서 소개하는 글을 볼 때 자주 ‘사용자 경험을 중시하며 개발’ 키워드를 볼 수 있는데 정작 결과물을 보면 웹 접근성에 미비한 경우가 많다.

스스로가 그랬는데, 이번에 과제에서 “‘tab index’에 공부해 보면 좋을 것 같습니다.”라는 피드백을 받았다.

이에 대해 알아보면서 내 웹 사이트가 키보드로 조작하기 힘들 뿐더러, 시각 장애 등의 제한된 환경에서 적합하지 않다는 것을 깨달았다.

> _웹 접근성(Web Accessibility)이란 장애의 유무와 관계없이 누구나 웹 사이트에서 제공하는 모든 정보에 접근하고 이용할 수 있도록 보장하는 것을 말한다. 즉, 웹 접근성을 준수하면 시각장애인을 포함한 장애인은 비장애인과 동등하게 인터넷 정보에 접근할 수 있게 된다. 따라서 도서관에서 제공하는 모든 웹 페이지는 웹 접근성을 준수하여 제작하여야 한다.-한국웹접근성인증평가원_

>

# Tab Index

> **`tabindex`** [전역 특성](https://developer.mozilla.org/ko/docs/Web/HTML/Global_attributes)은 요소가 포커스 가능함을 나타내며, 이름에서도 알 수 있듯, 주로 Tab 키를 사용하는 연속적인 키보드 탐색에서 어느 순서에 위치할지 지정합니다.-mdn web docs

>

대화형 컨텐츠는 `tabindex="0"`이 기본값이고, 비대화형 컨텐츠는 `tabindex="-1"`이 기본값이다.

`tabindex` 값을 1 이상으로 지정할 경우, 탭의 순서를 명시적으로 지정해줄 수 있다. 1,2,3,… 순으로 탭의 focus가 이동한다. 하지만 mdn은 다음과 같이 권장한다.

> **경고:** 0보다 큰 `tabindex` 값을 피하세요. 접근성 보조기술 사용자의 페이지 탐색과 조작에 방해될 수 있습니다. 대신, 문서의 요소 순서를 논리적인 순서대로 배치하세요.

음의 정숫값(보통 -1)을 사용할 경우 연속 키보드 탐색으로 접근 할 수는 없으나 Javascript나 시각적(마우스 클릭)으로 포커스 가능함을 뜻한다. 스크립트에서 `focus()` 메서드를 호출해 포커스를 부여할 수 있기 때문에 특정 경우에만 쓰인다.

## `tabindex=’0’`이 기본인 대화형 컨텐츠

```markdown
<a>
<button>
<details>
<input>
<select>
<textarea>
```

대표적으로 위 요소들이 tabindex를 기본적으로 지원하는 요소들이다.

피치 못할 이유로 비대화형 컨텐츠인 `div` 등에 포커싱과 상호작용이 필요할 경우 `tabindex`를 지정해주면 되겠다.

하지만 가능하면 `div` 등으로 짜여진 재사용 컴포넌트 내에 대화형 컨텐츠가 있을 경우, 추가적으로 `<button>` 등의 요소로 래핑해주는 것이 좋겠다.

![240317-175501](/posts/웹_접근성_tabindex/240317-175501.png)

_(`<div><a></a></div>`형태의 일반적인 패턴을 볼 수 있다.)_

## 고려해 볼 만 한 케이스

관련 내용을 구글링하며 텍스트 에디터에서의 사용 케이스에 대한 내용을 보았다.

키보드만으로 텍스트 에디터 조작이 요구되는 페이지에 접근하면, tab이 일반적인 인식처럼 들여쓰기로 동작할 경우 에디터를 빠져나올 수 없다.

![240317-175510](/posts/웹_접근성_tabindex/240317-175510.png)

_(탭으로 에디터 본문에 접근하면 빠져 나올 수 없는 네이버 에디터 -_ 실제 시각 장애인에게 제공되는 환경에서 별도의 방법이 제공될 것 같은데 궁금하다._)_

[CKEditor의 경우](https://ckeditor.com/ckeditor-5/demo/feature-rich/)에는 tab을 들여쓰기로 매핑하지 않고, 필요한 곳에 `contenteditable` 속성을 주어 tab으로 이동할 수 있도록 하였다.

![240317-175521](/posts/웹_접근성_tabindex/240317-175521.png)

### 내 프로젝트 돌아보기

이전에 진행한 ‘꿀매포청천’ 프로젝트에서는 React-Quill 라이브러리를 사용해 글 업로드 및 수정에 필요한 에디터 기능을 만들었다.

![240317-175538](/posts/웹_접근성_tabindex/240317-175538.png)

이를 확인해보니 `contenteditable`로 tab 접근이 되었으나, tab이 들여쓰기에 매핑되어 벗어나는데 문제가 있음을 확인했다.

이에 관해 찾아보니, 비슷한 문제를 인지한 [유저들의 논의](https://github.com/zenoamaro/react-quill/issues/756)가 있었다. 한 유저는 문제를 해결하기 위해 기존 Tab 키의 이벤트 발생과 전파를 막고, 다음 tabindex로 focusing되도록 임의로 처리해주었다.

단순히 유명한 라이브러리를 그대로 사용하기 보다는 의도한 기능이 동작하는지 확인하고 적절한 선택을 하거나, 커스텀을 해 주는 것이 바람직하다.

최근 진행했던 ‘나비장터’ 프로젝트의 경우에는 공통 컴포넌트로 사용한 `<Card/>` 를 그대로 사용하거나, 단순히 페이지 이동을 `div`에 자바스크립트 핸들러로 처리한 경우가 있어 tab으로 조작할 수 없는 범위가 발생했다.

![240317-175554](/posts/웹_접근성_tabindex/240317-175554.png)

tab-index에 대해 공부하며 모든 기능을 키보드만으로 똑같이 접근할 수 있도록 적절하게 `<Link/>`를 래핑해주거나, `tabindex='0'` 속성을 부여했다.

# 감상

대한민국의 웹 사이트가 장애인의 웹 접근성 측면에서 모자라다는 이야기들이 있다. 사용자 경험 어쩌니 해도 정작 이런 기본적인 내용도 챙기지 못했다는게 꽤 부끄러웠다.

앞으로 더 많은 웹 접근성 내용을 공부해봐야겠다.

# 참고링크

https://www.nld.go.kr/ableFront/new_standard_guide/accessibility.jsp

https://naradesign.github.io/tabindex.html

https://developer.mozilla.org/ko/docs/Web/HTML/Global_attributes/tabindex


웹 접근성 tabindex


## Contents

# 서론

나비장터 프로젝트를 진행하면서 전체 인증 인가를 관리하는 최상단 `authProvider` 레이어 및 context에 사용될 `useValidate` 훅을 만들었다.

뒤늦은 refresh 기능의 추가와 서버사이드 렌더링 시에 발생하는 문제로 인하여 코드가 복잡해지고 플로우가 쉽게 읽히지 않았지만 시간 상의 이유로 그대로 1.0 릴리즈를 했다.

때문에 이번에 리팩토링을 진행하여 간단히 기록해보고자 한다.

# 변경 전

![240104-142044](/posts/validation_로직_리팩토링하기-불필요한_state_삭제와_useEffect_간소화/240104-142044.png)

## 로직

1. validation에 문제가 발생할 경우
   1. refresh가 가능하면 `handleTokenRefresh` 로 refresh query에서 얻은 accessToken으로 갱신 후, 로그인 및 유저 정보 state를 갱신한다.
   2. refresh가 불가능하면 로그인 경로로 이동시킨 후 토스트 에러 메세지를 출력한다.
2. accessToken이 존재하지 않지만 refreshToken이 존재할 경우

   이는 validationQuery를 로그인 한 상태인, accessToken이 존재할 때에만 enable 되도록 처리했기 때문에 필요하다.

   또한 SSR로 첫 로딩할 시에 acceeToken이 없으면 refreshToken이 있음에도 에러 페이지로 이동되기 때문에 추가된 조건이다.

   - reissue Query에서 얻은 accessToken 값을 통해 유저 정보 및 로그인 상태 갱신

3. 유저 정보가 존재할 경우
   1. 에러는 없지만 `isLogggedIn` 및 `currentUser` state를 올바르게 초기화하기 위해 필요하다.

## 문제점

- useEffect 내에 과도한 로직 및 의존성
  - 코드가 쉽게 추적되지 않고, 의존성이 과다하여 로직의 변경이나 추가가 있을 경우 문제의 소지가 다분하다.
- 불필요한 state 존재와 그로 인한 문제점
  - `isLoggedIn` 과 `currentUser` 는 query에서 얻는 정보와 cookie 값의 여부에 따라 초기화되는데, 이는 불필요할 뿐더러 각각의 상태의 경우만 늘어난다.
  - 이로 인해 유저 프로필 등이 따닥 거리면서 뒤늦게 따라오는 경우가 발생한다.
  - 또한 이로 인해 *3. 유저 정보가 존재할 경우*와 같이 불필요한 조건이 추가되었다.

# 변경 후

## 불필요한 state 삭제하기

```tsx
const [isLoggedIn, setIsLoggedIn] = useState<boolean>(() => !!accessToken)
const [currentUser, setCurrentUser] = useState<User | null>(() => null)
```

`isLoggedIn` 은 token 값에, `currentUser`는 useQuery로 얻는 값에 의존하고 있다.

cookie의 value가 변하는 부분(재발급)은 SSR 이슈로 인해 새로고침으로 이어지게 처리해놓아 새로 마운트되므로 state가 필요하지 않다.

query의 data에 의존하는 state는 추가적인 상태의 경우를 야기한다.

```bash
1.
query data: undefined
currentUser: null

2.
query data: User
currentUser: null

3.
query data: User
currentUser: User
```

이를 간소화하기 위해 state를 삭제하고, 이 값들 자체를 return 한다.

```tsx
return {
  isLoggedIn: !!accessToken,
  currentUser: validateUserQuery?.data?.data.userInfo,
}
```

## useEffect 로직 분리 및 간소화

```tsx
// 유저 정보가 존재할 경우
if (validateUserQuery.data?.data?.userInfo) {
  const userInfo = validateUserQuery.data.data.userInfo
  setCurrentUser(() => userInfo)
  setIsLoggedIn(() => !!userInfo)
}
```

```tsx
const updateLoginState = (userInfo: User) => {
  setCurrentUser(() => userInfo)
  setIsLoggedIn(() => !!userInfo)
  window.location.reload()
}
```

기존 로직에서 *3. 유저 정보가 존재할 경우*는 이전 과정을 통해 삭제할 수 있게 된다.

`updateLoginState` 또한 state가 사라졌기 때문에 지워준다.

이제 *1. validation에 문제가 발생한 경우, 2. accessToken이 없지만 refreshToken이 존재할 경우*의 두 가지 케이스를 처리해보자.

```tsx
useEffect(() => {
  if ((!accessToken && refreshToken) || validateUserQuery.isError) {
    refreshTokenIfNeeded()
  }
}, [
  accessToken,
  refreshToken,
  reissueTokenQuery?.data?.data.accessToken,
  validateUserQuery.isError,
  refreshTokenIfNeeded,
])
```

- 1과 2의 조건으로 useEffect 내부 로직을 구성한다. 조건에 해당할 경우 refreshToken을 이용하는 함수를 실행한다.

```tsx
/**
 * @description: 토큰 재발급이 필요한 경우, 재발급 후 새로고침합니다.
 * @description: 리프레시 토큰까지 만료되었을 경우 handleSessionExpiration 실행
 */
const refreshTokenIfNeeded = useCallback(async () => {
  if (!refreshToken || reissueTokenQuery.isError) {
    handleSessionExpiration()
  } else if (reissueTokenQuery.data?.data?.accessToken) {
    const newToken = reissueTokenQuery.data.data.accessToken
    handleTokenRefresh({ token: newToken })
  }
}, [
  refreshToken,
  reissueTokenQuery.isError,
  reissueTokenQuery.data?.data.accessToken,
  handleSessionExpiration,
])
```

- refresh 할 수 없는 경우 `handleSessionExpiration`을 실행한다.
- refresh 할 수 있는 경우 `handleTokenRefresh`를 실행한다.

```tsx
/**
 * @description: 세션 만료시 로그인 페이지로 이동합니다.
 * @description: 리프레시 토큰까지 만료되었을 경우
 */
const handleSessionExpiration = useCallback(() => {
  Cookies.remove(Environment.tokenName())
  Cookies.remove(Environment.refreshTokenName())
  router.push(AppPath.login(), { scroll: false })
  showAuthErrorToast()
}, [router, showAuthErrorToast])
```

```tsx
/**
 *
 * @description 재발급 된 토큰을 쿠키에 저장합니다.
 */
const handleTokenRefresh = ({
  token,
  expiresInHours = 1,
}: {
  token?: string
  expiresInHours?: number
}) => {
  if (!token) return
  let expiry = new Date()
  expiry.setHours(expiry.getHours() + expiresInHours)
  Cookies.set(Environment.tokenName(), token, { expires: expiry })
  window.location.reload()
}
```

- 각각은 위와 같이 구성되었다.

## 최종

![240104-142101](/posts/validation_로직_리팩토링하기-불필요한_state_삭제와_useEffect_간소화/240104-142101.png)

코드의 흐름이 명확해지고, 불필요한 state 제거로 유저 정보가 한 번에 처리되어 데이터 갱신이 화면에 나타나는 안 좋은 경험을 개선했다.

# 추가

`window.location.reload()` 로 처리하는 부분이 사용자 경험에 부정적이기 때문에 필요한 부분만 리랜더링 할 수 있도록 해야한다.

이전에 회고에서 작성한 부분인데 백엔드에 요청할 수 있을지 확인해봐야겠다.


validation 로직 리팩토링하기


## Contents

# 서론

AI가 대세다. 온갖 서비스에서 AI라는 세련된 타이틀을 붙이기 위해 노력하고 있다.

언젠가는 길을 가는데 영어 학원 광고에 AI 시대에는 영어가 중요하다는 내용으로 광고를 하고 있더라…

여튼 보통 직접 AI 모델을 만들고, 학습시키고 좋은 성능의 서버를 구매하고 돌리는 데에는 전기세와 인력 등의 소요가 상당하기 때문에 전문적으로 이를 공급하는 B2B 서비스를 계약하여 도입하는 경우가 많은 것 같다.

나도 약간의 비용을 지불하여 chatGPT로 유명한 openai의 API를 내 블로그 서비스에서 캐주얼하게 응용해보고자 한다.

# OpenAI API 사용하기

1. openai 홈페이지에 접속하고 가입 및 로그인한다.

   [https://platform.openai.com](https://platform.openai.com/)

   ![231228-144908](/posts/ChatGPT_openai_블로그에_도입하기/231228-144908.png)

2. API keys 탭에서 새로운 secret key를 발급받고 사용한다.

   ![231228-144920](/posts/ChatGPT_openai_블로그에_도입하기/231228-144920.png)

어려울 것 없이 가입하고 키를 발급받아 사용하면 된다.

# 내 프로젝트에서 사용하기

기존 블로그 환경인 NextJS13 pages route에 openai API를 사용해보고자 한다.

## 설치 및 세팅

1. openai 라이브러리 설치

```bash
npm install openai
```

1. secret key 저장

   이전 과정에서 발급한 비밀 키를 환경변수로 저장하고 메서드 사용 시 전달해주면 된다.

```tsx
import OpenAI from 'openai'

const openai = new OpenAI({
  apiKey: process.env.OPEN_AI_KEY,
})
```

## 호출 함수 및 백엔드 정의

NextJS의 기능을 활용하여 자체 서버로 호출하는 방식으로 구현했다.

![231228-144935](/posts/ChatGPT_openai_블로그에_도입하기/231228-144935.png)

### 1. 클라이언트 함수 정의

![231228-144945](/posts/ChatGPT_openai_블로그에_도입하기/231228-144945.png)

### 2. api route 정의

![231228-144951](/posts/ChatGPT_openai_블로그에_도입하기/231228-144951.png)

openai에 전달할 명령 및 temperature 등의 설정에 대해서는 홈페이지에서 여러 예시를 제공해주고 있다.

https://platform.openai.com/docs/overview

필자는 max_tokens의 제한 등을 설정했는데, 이는 현실적 금전 소요 때문이다. 관련 내용에 대해서 후술하겠다.

## 함수 호출 및 토큰 절약

chatGPT 3.5를 웹사이트에서 무료로 사용할 수 있는 것과는 달리, API로 이용할 경우 과금이 요구된다.

블로그 서비스에 해당 기능을 도입하기로 한 가장 큰 이유인데, 만약 사용자 요청에 따라 매번 새로 요청을 갱신하는 경우 개인으로서는 부담스러운 부분이다.

내 블로그는 SSG로 정적 빌드된 html을 제공하고 있다. 빌드는 main 브랜치에 변경사항이 발생할 경우에만 이루어지기 때문에, 사용자의 요청에 따라 매번 openai 호출을 할 필요가 없다.

하지만 블로그 모든 포스트의 텍스트를 요청하는 경우 또한 상당한 토큰 소요를 요하고 정확한 수준의 요약이 필요하기 보다는, 각 포스트가 어떤 내용인지 안내해 줄 수 있는 정도의 내용이 필요했으므로 추가적으로 요청을 가공하였다.

![231228-145015](/posts/ChatGPT_openai_블로그에_도입하기/231228-145015.png)

1. 전체 텍스트 내용의 제목(#,##,###)에 해당하는 글과 그 뒤에 오는 문장을 찾는 정규 표현식을 생성
2. while 문을 통해 문장 끝까지 반복
3. 문장 끝에 해당하는 ‘.’의 index를 찾아 해당 문장을 추출 후 결합
4. 추출된 문장들에서 마크다운 부분을 제거한 후 반환

```tsx
const summary = await getSummary({
  text: extractAndCombineFirstSentences(content),
})
```

다음과 같이 사용한다.

![231228-145022](/posts/ChatGPT_openai_블로그에_도입하기/231228-145022.png)

간단한 조치이지만 요청 당 500 토큰 이상이 들어 제한에 걸리는 경우가 없어지고, 요청 당 400개 정도로 유지할 수 있게 됐다.


ChatGPT openai 블로그에 도입하기


## Contents

# 개요

이번 프로젝트에서는 MSW의 적극 활용과 에러 및 로딩 처리 등 더 완성도 있는 시스템을 갖추고자 노력했다. 설계한 몇 가지 포인트에 대해 기록해 보고자 한다.

# MSW를 이용한 병렬적 개발 일정 확보

## 개요

이번 프로젝트는 백엔드와 같은 개발 일정으로 진행되었다. 때문에 API 릴리즈에 맞춰 프론트엔드 개발 일정을 진행하기에는 이에 의존적이 될 뿐더러, 정확히 맞지 않는 부분도 존재했다.

가볍게 더미데이터를 상수화해서 작성해두고 출력할 수도 있지만, 나중에 실 API 연결에서 엣지 케이스 및 미비한 비동기 처리가 발견될 확률이 높다.

- MSW를 사용하지 않은 공통 개발 일정

![231218-162326](</posts/나비장터_회고(2)-개발/231218-162326.png>)

- MSW를 사용한 공통 개발 일정

![231218-162333](</posts/나비장터_회고(2)-개발/231218-162333.png>)

우리는 위와 같이 MSW를 통해 명세를 기반한 mock API를 작성하며 개발했다. 이를 통해 독립적인 개발 일정을 확보하고, 그때그때 적절한 비동기 에러 및 로딩 처리를 할 수 있었다.

# 프론트엔드 빌드 및 배포 아키텍쳐

![231218-162340](</posts/나비장터_회고(2)-개발/231218-162340.png>)

husky를 통해 로컬에서 사전 빌드, 테스트 코드 및 lint 유효성을 확인한다.

github에서 actions를 통해 main, develop 브랜치 대상 빌드, 테스트 유효성을 우선 확인하고 코드 리뷰를 진행하도록 했다.

이후 merge되면 스토리북과 vercel에 변경 내용을 자동 배포하여 오류를 최소화하고 결과물을 빠르게 확인할 수 있는 CICD 아키텍쳐를 구성했다.

# NextJS에서 FetchAPI와 에러 및 로딩 처리

## 자체 확장 Fetch 클래스 사용

NextJS에서 axios 등의 서드파티 라이브러리를 사용하면 캐싱 정책 등을 따로 적용해야 하는 수고가 있다.

때문에 NextJS 공식 문서에서도 이를 권장하지 않고, 기존 fetch를 확장한 형태를 사용하기 때문에 fetch를 사용하는 것이 좋다.

```tsx
...

class FetchAPI {
  private baseURL: string
  private headers: { [key: string]: string }

  private static instance: FetchAPI

  private constructor() {
    this.baseURL = ''
    this.headers = {}
  }

	// singleton으로 중복 방지
  public static getInstance(): FetchAPI {
    if (!FetchAPI.instance) {
      FetchAPI.instance = new FetchAPI()
    }
    return FetchAPI.instance
  }

  public setBaseURL(url: string): void {
    this.baseURL = url
  }

  public setDefaultHeader(key: string, value: string): void {
    this.headers[key] = value
  }

	...

  public async post(
    endpoint: string,
    body: any,
    nextInit: RequestInit = {}, // NextJS의 config를 사용할 수 있도록 추가
    customHeaders: { [key: string]: string } = {},
  ): Promise<any> {
    const response = await fetch(`${this.baseURL}${endpoint}`, {
      method: 'POST',
      headers: { ...this.headers, ...customHeaders }, // 공통 옵션 사용
      body: body instanceof FormData ? body : JSON.stringify(body),
      ...nextInit,
    })

    return this.responseHandler(response)
  }

...
```

때문에 `FetchAPI.ts` 에 싱글톤 클래스를 생성해 기존 axios 등에서 누리던 공통 헤더 및 baseUrl 기능 등을 사용하면서도 NextJS에서 권하는 옵션을 사용할 수 있도록 자체적으로 확장했다.

```tsx
// apiClient.ts
import { Environment } from '@/config/environment'
import FetchAPI from '@/lib/fetchAPI'

const apiClient = FetchAPI.getInstance()
apiClient.setDefaultHeader('Content-Type', 'application/json')
apiClient.setBaseURL(Environment.apiAddress())

export default apiClient
```

위처럼 미리 인스턴스를 공통적으로 필요한 설정과 함께 생성하여 활용할 수 있었다.

각 호출에 필요한 함수는 미리 정의해서 사용했다.

```tsx
import ApiEndPoint from '@/config/apiEndPoint'
import apiClient from '../apiClient'

const getTest = async () => {
  const response = await apiClient.get(
    ApiEndPoint.test(),
    { next: { revalidate: 10 } },
    { Authorization: 'Bearer ' },
  )
  return response
}

export { getTest }
```

위에서 생성한 apiClient를 불러와 쉽게 정의할 수 있었다.

## 에러 처리

fetchAPI의 구현을 보면 get, post, put, delete 등의 http 메서드의 return에서 `responseHandler` 를 거치는 것을 확인할 수 있다.

![231218-162403](</posts/나비장터_회고(2)-개발/231218-162403.png>)

이는 아래와 같은 형태로 구현했다.

![231218-162410](</posts/나비장터_회고(2)-개발/231218-162410.png>)

- response를 확인하고 이의 status를 확인해 각 케이스에 맞는 커스텀 에러로 throw한다.
- 각 커스텀 에러는 케이스에 맞는 에러 메세지와 함께 사전에 정의해두었다.

이는 곧 전역 또는 지역 단위의 ErrorBoundary로 전파된다. 실제 구현은 NextJS13의 error 템플릿을 통해 작성하여 명확한 모듈 단위의 목적 분리가 용이했다.

`error.tsx` 를 작성하면 자동으로 해당 위치의 layout을 ErrorBoyndary로 래핑한다. 다음과 같은 구조로 이해할 수 있다.

![231218-162422](</posts/나비장터_회고(2)-개발/231218-162422.png>)

https://nextjs.org/docs/app/building-your-application/routing/error-handling

각 에러 컴포넌트는 throw된 error를 받아 적절한 화면 또는 리다이렉팅을 처리하도록 했다.

![231218-162429](</posts/나비장터_회고(2)-개발/231218-162429.png>)

위 코드와 같이 렌더링 과정에서 일어난 문제에 대한 알맞은 화면을 제공한다.

## 접근 제한

또한 접근할 수 없는 페이지를 사전에 차단하기 위해 서버 사이드에서 middleware를 거쳐 이를 처리하도록 했다. 이를 통해 비인가 사용자가 페이지에 처음부터 접근할 수 없도록 하거나, 사전에 로그인 페이지로 이동하도록 했다.

![231218-162436](</posts/나비장터_회고(2)-개발/231218-162436.png>)

## 로딩 처리

React의 Suspense를 NextJS13에서는 `error.tsx`를 활용하듯 `loading.tsx`로 처리할 수 있다.

NextJS에서는 특히 SSR을 활용할 때 서버로부터 html을 전달받기까지의 시간이 추가로 요구된다. 중간 프로젝트에서 이를 처리하지 않아 클릭 후 html 수신까지의 시간 동안 아무 반응이 없어 사용자에게 혼동을 준 문제가 있었다.

loading을 적절히 두어 로딩 화면을 보여주도록 했다.

https://nextjs.org/docs/app/building-your-application/routing/loading-ui-and-streaming

## 전체 구조

![231218-162445](</posts/나비장터_회고(2)-개발/231218-162445.png>)

다음과 같은 구조를 통해 허용되지 않은 컨텐츠를 사전에 노출되지 않도록 처리하고, 런타임 중 생기는 로딩과 에러를 효율적으로 처리할 수 있도록 했다.

# headless한 공통 컴포넌트 구조

tailwind를 통해 효율적인 공통 컴포넌트 구조를 생성하고자 했다.

## 문제

![231218-162452](</posts/나비장터_회고(2)-개발/231218-162452.png>)

다음과 같이 특정 스타일을 변수로 관리하고 이를 주입해 사용하는 것은 적절하다고 볼 수 있으나, 타입 시스템의 추천 기능과 공통 사항을 관리하거나 다른 종류의 스타일 조각들을 관리함에 있어 불편을 야기한다.

## 해결

![231218-162500](</posts/나비장터_회고(2)-개발/231218-162500.png>)

![231218-162506](</posts/나비장터_회고(2)-개발/231218-162506.png>)

cva를 통해 기본 스타일과 선택적 style prop을 지정하고, twmerge와 clsx를 결합하여 조건부 스타일 및 중복 스타일을 조정하도록 했다.

![231218-162513](</posts/나비장터_회고(2)-개발/231218-162513.png>)

이를 통해 정의해 둔 스타일과 추가로 주입하고 싶은 스타일을 자유롭게 활용할 수 있다.

![231218-162522](</posts/나비장터_회고(2)-개발/231218-162522.png>)

- 해당 방식은 공용 컴포넌트를 커스텀하고, 수정하는데에 높은 자유도를 제공한다.
- 사진과 같이 타입 시스템에도 친화적인 방식을 제공하기 때문에 이를 적극 활용했다.

![231218-162529](</posts/나비장터_회고(2)-개발/231218-162529.png>)

# Form 관리

![231218-162536](</posts/나비장터_회고(2)-개발/231218-162536.png>)

Form을 효율적으로 관리하고 다양한 형태에서 활용하기 위해, Input을 받고 보이는 부분과 validation 모듈, hook을 통해 비동기 통신과 상태를 관리하는 세 가지 영역으로 나눠서 구현했다.

![231218-162546](</posts/나비장터_회고(2)-개발/231218-162546.png>)

위와 같이 Template은 hook으로 부터 필요한 상태만 전달받는다.

각 컴포넌트는 form의 상태를 통해 input을 갱신하거나, validation 실패에 대한 에러 메세지를 전달받을 수 있다.

![231218-162556](</posts/나비장터_회고(2)-개발/231218-162556.png>)

hook은 서버와의 통신 및 이후 처리 등을 담당한다. 여기서 에러 및 로딩에 대한 처리 등을 해줄 수 있다.

![231218-162607](</posts/나비장터_회고(2)-개발/231218-162607.png>)

![231218-162612](</posts/나비장터_회고(2)-개발/231218-162612.png>)

validation은 appValidation을 통해 사전에 정의한 zod 메서드를 통해 이루어진다.

이는 어떤 이점이 있을까?

![231218-162621](</posts/나비장터_회고(2)-개발/231218-162621.png>)

한 서비스에서는 보통 특정 필드에 대한 같은 validation 기준을 공유한다. 이를 일일이 react hook form에서 처리하면 중복 코드가 생기고, 기준이 수정될 때 불편함을 야기할 수 있다.

위와 같이 validation 기준을 zod 메서드를 통해 사전에 정의해 둔 뒤 이를 필요한 hook에 사용하면 그런 불편함을 효과적으로 해소할 수 있으며, 또한 타입 친화적인 이점도 챙길 수 있다.

# 서버 컴포넌트 관련된 문제 사항

NextJS의 SSR은 생각보다 여러 기능들에서 추가적인 접근 방식에 고려를 요한다. 최근 여러 NextJS 기반 프로젝트를 진행하면서 줄곧 깨닫고 있다.

이번 프로젝트에서 있었던 문제들을 기록해보자.

## MSW 서버 initialize 문제

NextJS13은 기본적으로 서버 렌더링으로 동작한다. CSR로 호출하는 경우에는 문제가 없었으나, SSR로 처리되는 경우에는 mock server가 initialize되기 전에 함수가 호출되어 mock route를 인식하지 못하는 문제가 있었다.

### 해결

```tsx
'use client'

import { useState, type PropsWithChildren, useEffect } from 'react'
import { Environment } from '@/config/environment'

const isMockingMode = Environment.apiMocking() === 'enabled'

const MSWComponent = ({ children }: PropsWithChildren) => {
  // mocking을 활성화하지 않았다면 바로 children을 return하기 위함
  const [mswReady, setMSWReady] = useState(() => !isMockingMode)

  useEffect(() => {
    // msw 실행 메서드를 lazy load
    const init = async () => {
      if (isMockingMode) {
        const initMocks = await import('../lib/msw/initMockApi').then(
          (res) => res.initMockApi,
        )
        await initMocks()
        setMSWReady(true) // mock server 실행 완료
      }
    }

    if (!mswReady) {
      init()
    }
  }, [mswReady])

  if (!mswReady) return null

  return <>{children}</>
}

export default MSWComponent
```

MSW 활성화 시 전역에 wrapper를 두어 렌더링 이전에 MSW가 활성화 될 수 있도록 하였다.

## 인증이 필요한 API 요청

```tsx
const token = accessToken
if (token) {
  apiClient.setDefaultHeader('Authorization', token)
  return getValidateUser()
}
```

인증(header에 jwt 토큰을 담아 요청하는)이 필요한 요청의 경우 로그인 시 fetchAPI 클래스에 해당 토큰을 공통 헤더로 설정하기 때문에 별도의 코드가 필요하지 않았다.

```tsx
const AuthProvider = ({ children }: { children: React.ReactNode }) => {
  const { isLoggedIn, currentUser } = useValidate()

  const contextValue = useMemo(
    () => ({ isLoggedIn, currentUser }),
    [isLoggedIn, currentUser],
  )

  return (
    <AuthContext.Provider value={contextValue}>{children}</AuthContext.Provider>
  )
}
```

또 로그인 여부와 유저의 간단한 정보가 전역에서 context로 전달되기 때문에 필요 시 이를 사용하면 됐다.

문제는 SSR 시에 이 공통 헤더가 아직 지정되지 않은 상태라 인증 에러가 나타난다는 것이었다.

### 해결

토큰을 쿠키에 저장해 활용하고 있었는데 `next/headers` 를 통해 서버에서 쿠키 정보를 얻어올 수 있었다.

```tsx
import { cookies } from 'next/headers'
import { Environment } from '@/config/environment'

const getServerCookie = () => {
  const cookieStore = cookies()
  const token = cookieStore.get(Environment.tokenName())

  return token?.value
}
```

위와 같이 서버 컴포넌트에서 토큰 정보를 얻는 메서드를 작성했다.

```tsx
const getUserInfo = async (): Promise<User> => {
  const token = getServerCookie()
  const res = await apiClient.get(
    ApiEndPoint.getValidateUser(),
    {},
    {
      Authorization: `${token}`,
    },
  )
  return res.data.userInfo
}
```

SSR 요청에서는 다음과 같이 토큰 정보를 추가해 줄 수 있도록 했다.

## Refresh Token 로직

refresh token 기능을 통해 access token을 갱신하는 과정에서 예상치 못한 문제가 있었다.

![231218-162641](</posts/나비장터_회고(2)-개발/231218-162641.png>)

처음 구현은 위에서 활용한 auth context 내에서 useEffect와 tanstack query를 활용해 access token의 만료를 확인하면 refresh token을 통해 갱신이 이루어지도록 했다.

![231218-162649](</posts/나비장터_회고(2)-개발/231218-162649.png>)

문제는 access token이 만료된 상황 + SSR이 있는 페이지에 최초 접속할 경우, 서버에서는 hook이 작동하기 이전에 요청이 이루어지기 때문에 refresh token이 유효함에도 갱신하지 못하고 에러 처리가 이루어졌다.

### 시도

처음에는 위에서 구현한 `getServerCookie`에서도 토큰이 유효한지 여부를 검증하는 추가 로직을 통해 유효하지 않을 경우 refresh 요청을 통해 토큰을 갱신하는, 클라이언트와 같은 로직을 통하도록 했다.

문제는 cookie의 set()은 server component에서 불가능하다는 것이다. Server Action 또는 Route Handler를 통해서만 처리될 수 있었다(https://nextjs.org/docs/app/api-reference/functions/cookies#cookiessetname-).

애초에 백엔드 응답에서 cookie를 set 해주면 될 터였지만, 해당 기능이 구현되어 있지 않았고 토큰만 보내주는 형태였다. 추가 수정을 요청할 수 있는 상태가 아니었다.

### 해결

일단 해당 경우에 에러 페이지를 통하도록 했다. 이후 클라이언트 hook이 init되고 auth hook에서 refreshToken이 확인될 경우 토큰 및 로그인, 유저 정보를 갱신하여 최초에 새로고침 처리가 되도록 방식을 수정했다.

물론 api 응답에서 cookie를 설정해주는 것이 가장 효과적인 방식이지만, api 스펙이 이를 충족하지 못 할 경우 client에서 갱신 후 새로고침을 통해 토큰을 갱신하면 간단한 방식으로 문제를 해결할 수 있다.

reissue가 잦게 일어나지 않기 때문에 해당 방식으로 처리했지만, 다른 경우에는 무조건 새로 고침을 강제하는 것은 사용자 경험에 치명적일 수 있을 것 같다.

# 회고

## 잘한 점

- NextJS의 각종 기능을 활용해 봄
  - Intercepting route, loading, error, middleware, 폰트, 이미지 최적화 등
- 적절한 에러 및 로딩 처리에 투자
- 공통 문제를 해결하고자 노력하고, 이를 공유함
- 이유 있는 기술만을 활용
  - 불필요한 전역 상태를 추가하지 않음

## 아쉬운 점

- 타입 정의, 폴더명 컨벤션 등을 초반에 챙기지 못해 불필요한 시간 소요
- 백엔드에 미리 문제될 만한 부분을 확인해주지 못함
  - CORS 이슈에 대한 백엔드 설정
  - OAuth 방식에 대해 잘못 이해하고 있는 부분을 조금 더 빨리 알려줄 수 있었을 듯

# 관련 링크

- 나비장터: [https://nabi-market-client.vercel.app](https://nabi-market-client.vercel.app/)
- 깃허브: https://github.com/team-nabi/nabi-market-client


나비장터 회고(2)-개발


## Contents

# 근황

10~12월은 나비장터 프로젝트를 진행했다. 저번 중간 프로젝트에서 아쉬웠던 기획적인 부분과 NextJS에서 권장하는 기능들을 더욱 제대로 사용해보자는 의도가 있었다.

이번 프로젝트는 백엔드 3명, 프론트엔드 3명으로 처음부터 끝까지 새로 모든 것을 만드는 과정이었다.

# 나비장터 소개

나비장터는 기존 중고장터에서 경쟁력이 떨어지는 애매한 가치의 물건들을 물물교환 형태로만 제한하여 거래하는 물물교환 거래 서비스이다.

물물교환의 특성을 십분 활용하기 위해 등록된 물건을 바탕으로 거래를 제안하고 수락한 후에 채팅 등의 소통이 가능하도록 했다. 이를 통해 사용자에게 불필요한 소통 비용을 줄이고, 마치 서로의 패를 교환하는 느낌으로 소소한 재미 포인트를 주려 의도했다.

# 타임 테이블

![231218-162113](</posts/나비장터_회고(1)-개요_및_소통/231218-162113.png>)

- 10.12~10.22: 기획, 디자인 작업
- 10.23~10.29: 개발 환경 설정 및 기초 세팅
- 10.30~11.05: 공통 컴포넌트 개발
- 11.06~11.12: 카드 리스트 조회, 인증 및 인가
- 11.13~11.19: 카드 업로드 및 수정, 거래 관련 기능
- 11.20~11.26: 채팅, 인기 게시글 기능, API 연결 및 에러 처리
- 11.27~12.03: QA 및 추가 에러 처리, 성능 최적화

# 역할

나는 이번 프로젝트에서 로컬 작업으로부터 배포까지 이어지는 전체적인 과정의 설정, MSW와 백엔드와의 통신, NextJS의 여러 기능에 대한 기초 설정, 인증 및 인가 처리, 카드의 업로드 및 수정, 마이페이지, 채팅의 구현을 했다.

또한 프론트엔드 팀의 스케쥴을 맞추기 위한 스프린트 및 각자의 테스크를 분배하는 역할을 주도했다.

# 스프린트 및 협업

## 문서화

기본적으로 노션에 여러 카테고리를 만들어 문서화를 진행했다. 다만 몇 가지의 예외를 두었다.

1. 백엔드 및 전체적인 공유가 필요한(할 수 있는) 내용은 슬랙으로 공유하되, 노션의 버그 템플릿을 작성하여 공유하기
2. 프론트엔드 내에 공통적인 개발 공유 사항 및 에러는 Github의 Wiki와 Discusstions 활용하기

특히 [Wiki](https://github.com/team-nabi/nabi-market-client/wiki)를 작성하여 공유한 것은 좋은 경험이었다. 관련 질문이 있을 때 링크를 전달하여 소통이 간결해 진 점이 기본이지만, 스스로도 까먹은 부분을 다시 확인할 수 있었고 또 후에 누군가 프로젝트에 참여하거나 내 구현의 의도를 파악할 때 쉽게 할 수 있을 것이다.

## 스프린트 및 스토리

![231218-162128](</posts/나비장터_회고(1)-개요_및_소통/231218-162128.png>)

스프린트는 디자인과 기획을 바탕으로 스토리를 작성하고 이를 세부 테스크로 나누어 각 스토리 포인트를 팀원들과 함께 의논하여 나누는, 저번과 비슷한 방식으로 진행했다.

## Jira

![231218-162136](</posts/나비장터_회고(1)-개요_및_소통/231218-162136.png>)

다만 이번에는 백엔드와의 현황 공유도 쉽게 할 겸 + 깃과 슬랙에서 티켓도 활용하며 할 겸 해서 Jira를 활용했다.

예전에 회사에서 Jira를 도입하자고 할 때는 매우 어려워 많은 학습이 필요하다는 이야기가 많았는데, 사용하다 보니 그렇게 어렵지도 않고 장점도 많은 것 같다.

## 백엔드와의 소통

![231218-162143](</posts/나비장터_회고(1)-개요_및_소통/231218-162143.png>)

API 명세와 이의 관리가 가장 중요했다. API 및 DB 스키마 설계에 적극적으로 참여해서 같은 기획적 이해를 공유하고자 했다. 또한 문서를 바탕으로 변경 및 요청 사항을 공유할 수 있도록 했다.

![231218-162149](</posts/나비장터_회고(1)-개요_및_소통/231218-162149.png>)

```bash
{
    "code": "SUCCESS",
    "message": "성공하였습니다.",
    "data": {
        "cardList": [
            {
                "cardId": 4,
                "cardTitle": "string",
                "itemName": "string",
                "priceRange": "PRICE_RANGE_ONE",
                "thumbnail": "썸네일이미지",
                "status": "TRADE_AVAILABLE",
                "createdAt": "2023-11-15T17:18:40",
                "modifiedAt": "2023-11-15T17:18:40"
            }
        ],
        "nextCursorId": "2023111517184000000004"
    }
}
```

위와 같이 요청, 응답 등을 공유하여 최신화 등을 그때그때 요청할 수 있도록 했다.

## 주간 회고 등

![231218-162159](</posts/나비장터_회고(1)-개요_및_소통/231218-162159.png>)

데일리 통합 스크럼 및 주간 회고를 통해 진행 상황 공유와 아쉬운 부분이 빠르게 논의될 수 있는 시간과 장소를 만들었다.

일례로 슬랙과 카카오톡을 목적 구분 없이 혼동해서 사용해 문제가 있었는데, 이를 주간 회고에서 공유하여 일상적 목적 또는 급한 호출에만 카카오톡을 사용하도록 구분하고 슬랙 소통에 대한 추가 룰을 만들어 프로젝트 마무리까지 소통을 명확하게 유지할 수 있었다.

# 회고

## 잘한 점

잘한 점은 위에서 기술한 내용들이지만, 이번 프로젝트에서 새로 느낀 점들이 있다.

- 중간 프로젝트에서 기획을 급하게 하여 완성해보니 불필요한 기능이 있었는데, 이번 프로젝트에서는 이에 투자하여 그런 부분이 없이 담백하게 완성할 수 있었다.
- 팀원들의 의견 존중하기
  - 몇몇 기능들을 개발함에 있어서 팀원들과 다른 의견이 꽤 있었다. 이에 중간점을 타협하여 진행함을 통해 프로젝트 기한에 맞춰 기능을 완성할 수 있었다.
- 의지 북돋아주기
  - 이 부분은 스스로 잘 했다기 보다는 팀원들에게 감사한 점인데, 서로 할 수 긍정적인 언사를 반복해서 전체적인 분위기를 좋게 만들 수 있었다. 사소해 보여도 이 부분이 없었다면 프로젝트가 지금처럼 잘 되지는 않았을 것 같다.

## 아쉬운 점

- 팀원들의 이해 진도가 맞지 않았던 부분
  - 초기 기획 및 기초 개발 과정에서 많은 회의가 필요했다. 이 때 집중도가 떨어지면 내용을 놓치기 마련인데, 이 때문에 반복해서 과거 내용을 끌고 온 경우가 몇 있었다.
  - → 명시적으로 회의록, 문서에 읽음을 체크하는 양식 등을 설정하면 좋았을 것 같다.
- 때문에 기획 시간이 다소 길어졌던 점
  - 중간 프로젝트에서의 아쉬움으로 기획을 탄탄히 하고자 했으나, 이번에는 하루이틀 더 소요되었다.
  - 물론 급하게 하는 경우보다는 좋으나, 이전 개선 사항 등을 통해 불필요한 소통을 줄여 필요한 정도의 시간만 투자됐으면 좋았을 것이다.

# 관련 링크

- 나비장터: [https://nabi-market-client.vercel.app](https://nabi-market-client.vercel.app/)
- 깃허브: https://github.com/team-nabi/nabi-market-client


나비장터 회고(1)-개요 및 소통


## Contents

# as 키워드 사용이 불가능한 경우

- `in` 연산자와 사용할 경우

  ```tsx
  // 에러: 'in' 연산자 오른쪽에 타입 단언 사용 불가능
  if (('property' in obj) as SomeType) {
  }

  // 올바른 방법
  if ('property' in (obj as SomeType)) {
  }
  ```

- 타입 가드에서의 리턴 값

  ```tsx
  // 에러: 타입 가드의 리턴 값에 'as' 사용 불가능
  function isString(value: any): value is string {
    return typeof value === ('string' as boolean)
  }

  // 올바른 방법
  function isString(value: any): value is string {
    return typeof value === 'string'
  }
  ```

- readonly에 대한 할당

  ```tsx
  type MyObject = {
    readonly myProp: number
  }

  const obj: MyObject = {
    myProp: 5,
  }

  obj.myProp = 10 as any // error
  ```

- 튜플 타입에 대한 길이 제한

  - 튜플은 배열 길이가 고정이므로, `as` 를 사용하여 튜플 길이를 초과하는 할당을 하려는 경우 에러가 발생, 의도인 경우 `as unknown` 체인을 사용한다.

  ```tsx
  let tuple: [number, number] = [1, 2]

  tuple1 = [1, 2, 3] as [number, number]
  /*
  Conversion of type '[number, number, number]' to type '[number, number]' may be a mistake because neither type sufficiently overlaps with the other. If this was intentional, convert the expression to 'unknown' first.
    Source has 3 element(s) but target allows only 2.(2352)
  */
  ```

# 콜백에서 this에 대한 타입 제공하기

- this는 let이나 const와 달리 ‘호출된’ 방식에 따라 달라지는 다이나믹 스코프이다.
- this 바인딩을 사용하거나, this를 콜백에서 사용할 시에 매개변수에 this를 추가하고, 콜백 함수를 call로 호출한다.

```tsx
function addKeyListener(
  el: HTMLElement,
  fn: (this: HTMLElement, e: KeyboardEvent) => void,
) {
  el.addEventListener('keydown', (e) => {
    fn.call(el, e)
  })
}

// 콜백 함수 매개변수에 this를 추가하면 this 바인딩이 체크되어 실수를 방지할 수 있다.
```

- 또한 라이브러리 사용자의 콜백 함수에서 this를 참조할 수 있고, 안정성이 증가한다.
- 화살표 함수를 콜백으로 작성하고 this를 참조하려고 하면 타입스크립트에서 문제를 잡아낸다.

# 타입스크립트에서 객체 순회

```tsx
const obj = {
  one: 'uno',
  two: 'dos',
  three: 'tres',
}
for (const k in obj) {
  const v = obj[k] // obj에 인덱스 시그니처가 없기 때문에 엘리먼트는 암시적으로 'any' 타입
}

// k의 타입은 string으로 추론되는 반면, obj 객체에는 특정 키만 존재하기 때문에 오류 발생

let k: keyof typeof obj
for (k in obj) {
  const v = obj[k]
}

// k의 타입을 더욱 구체적으로 명시해주어 오류 해결
```

- 왜일까?
  - 특정 객체 타입에는 그 외에 할당 가능한 다른 속성이 존재할 수 있다.
  - 그러므로 타입스크립트는 객체의 키를 string 타입으로 선택하는게 합당하다.
  - 하지만 keyof 키워드로 한정지으면 string | number로 추론되어 적합하지 못하다.
  - `Object.entries` 를 사용하자

```tsx
function foo(abc: ABC) {
  for (const [k, v] of Object.entries(abc)) {
    k // string
    v // any
  }
}
```

- keyof 선언은 상수이거나 추가적인 키 없이 정확한 타입을 원할 경우
- Object.entries는 더욱 일반적으로 쓰이지만, 키와 값의 타입을 다루기 까다롭다.

# 추천 글

[타입스크립트의 Never 타입 완벽 가이드](https://ui.toast.com/posts/ko_20220323)

[올해 버려야 할 타입스크립트 나쁜 버릇 10가지](https://ui.toast.com/weekly-pick/ko_20210217)


이펙티브 타입스크립트 더보기(5-8)


## Contents

# 근황

9월에는 데브코스의 중간 팀 프로젝트가 있었다.

이 달 내내 프로젝트만 했으니 내용이 다 관련해서 채워지지 않을까 싶다.

# 중간 프로젝트에 대해…

## 환경

![231003-165947](</posts/9월_회고(꿀매포청천_프로젝트_회고)/231003-165947.png>)

중간 프로젝트의 과제명은 **API를 활용한 웹 제작**이다.

사실 너무 당연한 내용이라 상세 내용 공개 전까지 뭘까 싶었는데 제공되는 API를 대상으로 자유롭게 프로젝트를 진행하는 것이었다.

팀 자원은 프론트만 5명과 API 제작자와의 소통.

API를 추가하거나 수정할 수 없고, 필요 시 JSON에 내용을 추가해 사용하는 식이다.

기한은 9월 1일~27일.

## 기획

### 목표

API가 한정되어 있고, 기한이 짧다 보니 상세한 시장 조사 등은 생략되었고, 각자 소기의 목표를 설정해 이루고자 하였다.

나는 사용자 경험 측면에서 완성도 있는 서비스 기능을 제공하고자 했다.

### 명명

우리 팀은 각종 거래에 대한 평가와 피드백 공유가 가능한 커뮤니티 사이트를 만들기로 했다.

프로젝트 명은 여러 의견을 취합한 끝에 서비스와 직접적으로 연관된 키워드인 _꿀매_ 에 평가와 관련되며 사용자의 관심을 끌 만한 특이한 어감과 적합한 뜻의 키워드인 중국 송나라 시대의 명판관 _포청천_ 을 결합한 _꿀매포청천_ 으로 정했다.

## 역할

팀에서 NextJS를 사용하기로 했기 때문에 내가 초기 개발 설정을 담당하게 됐다.

또한 이번 프로젝트 진행에서 관련 개발 경험이 상대적으로 많은 나는 일정 배분이나, 공통 사항에 대한 개발 및 리뷰 등을 위주로 역할을 수행하게 됐다.

제공되는 API 외에는 모든 것을 알아서 해야하는 프로젝트이다 보니 초기 역할을 나눌 필요가 있었다.

특히 팀의 전문이 아닌 디자인에 인력을 다수 배정하고, 그 외 문서 담당과 프로젝트 개발 초기 담당을 정했다.

![231003-170004](</posts/9월_회고(꿀매포청천_프로젝트_회고)/231003-170004.png>)

한창 개발이 진행될 때 이전의 역할을 나눈 때에는 당장 필요한 테스크를 두고, 적합성에 문제가 없는 경우는 선호도를 순위 매겨 불만을 최소화 할 수 있도록 노력했다.

## 개발 프로세스

### 깃허브 브랜치

위에서 언급한 조건들을 고려해 제안했다.

- 1안
  ![231003-170017](</posts/9월_회고(꿀매포청천_프로젝트_회고)/231003-170017.png>)
  - 개별 personal develop을 두고 스프린트 종료 시 develop에 합치는 루틴
  - 짧은 기간 안에 lean하게 협업하고 공통 컴포넌트를 사용하기 위해 적절치 못한 구조라 생각해 폐기
- 2안
  ![231003-170031](</posts/9월_회고(꿀매포청천_프로젝트_회고)/231003-170031.png>)
  - 각 이슈 별로 feature를 두고 develop에 지속적으로 통합.
  - 각 스프린트 별로 진행사항과 기능 구현을 유지할 release 브랜치를 설정하고 버전 1.0을 위한 main 브랜치를 설정
  - 빠른 충돌 해결과 공통 컴포넌트 사용을 위해 깃헙플로우를 약간 변형하여 사용

### 폴더 구조 및 컴포넌트 관리

간단히 서비스 관련 없는 공통 컴포넌트와 서비스 관련 공통 컴포넌트 그리고 지엽적인 컴포넌트를 관리하는 것을 제안했고, 팀원들도 환경을 고려해 이에 공감했으나 아토믹 디자인 패턴을 경험해보고 싶다는 의견이 더러 있었다.

조금 과하다는 생각은 있었지만 팀에 좋은 경험이 될 것 같아 도입하기로 했다. 기본적인 컨셉을 설명하고, 예시를 작성하여 공유했다.

### 스크럼 및 스프린트 룰

- 스크럼

![231003-170048](</posts/9월_회고(꿀매포청천_프로젝트_회고)/231003-170048.png>)

기존 진행하던 데일리 스크럼을 프로젝트 위주의 주제로 사용했다.

- 스프린트

일반적으로 스프린트는 2주에서 4주 정도로 진행하는 것이 일반적이나, 짧은 기한에 맞추어 일주일 단위로 설정했다.

![231003-170100](</posts/9월_회고(꿀매포청천_프로젝트_회고)/231003-170100.png>)

일단 기획과 디자인 틀을 잡고 함께 유저 스토리를 작성했다.

![231003-170107](</posts/9월_회고(꿀매포청천_프로젝트_회고)/231003-170107.png>)

그리고 매 스프린트 시작일에 큰 기능을 정의하고, 이에 해당하는 스토리를 부여했다.

회의 때 하나씩 살펴보며 팀원들이 생각하는 예상 작업 일 수를 산정하고 그에 맞추어 각 인원이 가능한 가용 시간에 맞추어 역할을 부여했다.

![231003-171231](</posts/9월_회고(꿀매포청천_프로젝트_회고)/231003-171231.png>)

이전 과정을 통해 정해진 스프린트의 스토리를 기반으로 이슈를 작성하고, 이슈 넘버를 각 브랜치에 포함해 쉽게 협업자 간 개발 현황 또는 목표를 파악하도록 했다.

![231003-171242](</posts/9월_회고(꿀매포청천_프로젝트_회고)/231003-171242.png>)

때문에 pull request 시에 자연스레 이슈와 해당 내용을 연결 지어 코드 변경 사항의 목적을 처음부터 설명할 필요가 없도록 했다. 때문에 코드 리뷰 간 서비스적인 맥락을 쉽게 파악토록 하고자 했다.

## 신경쓴 내용

이번 프로젝트에서(특히 NextJS를 사용하며) 내가 신경 쓴 부분은 좋은 사용자 경험을 위한 렌더링과 제한된 API를 최대한 커스텀하기 위한 방법이었다.

### NextJS 자체 백엔드를 통해 제한된 API에서 클라이언트 처리가 아닌 서버 처리로 더 많은 기능 제작

![231003-171256](</posts/9월_회고(꿀매포청천_프로젝트_회고)/231003-171256.png>)

- 이번 프로젝트의 조건 한계를 보완하기 위해 기 존재하는 API의 별도 응용을 클라이언트에 부여하지 않고 NextJS 백엔드에 위임함으로써 관심사를 분리하고 쉽게 모듈을 사용하기 위한 노력을 했다.
- 그 응용 사례의 대표적 예시가 ‘싫어요’ 기능 구현이다.

### SSR과 tanstack query prefetch를 통해 주요 화면에 대해 로딩을 노출하지 않고 좋은 사용자 경험 제공

![231003-171312](</posts/9월_회고(꿀매포청천_프로젝트_회고)/231003-171312.png>)

- 메인 페이지는 보다시피 노출하는 컨텐츠 양이 적지 않다.
- 그래서 다음과 같이 사용자의 FCP(First Contentful Paint)에 대해 좋은 경험을 부여하기 위해 전략적인 SSR과 CSR의 내용을 선택했다.
- 최초 사용자의 눈길이 가게 될 내용에 대해 서버사이드 렌더링으로 별도의 로딩 또는 스켈레톤 처리를 하지 않도록 하고, 그 이후에 상세 내용에 대해서 클라이언트 사이드 렌더링으로 전체 내용이 구성될 수 있도록 했다.

_프로젝트에 대한 자세한 발표 내용은 아래 링크에서 확인 가능합니다._

[꿀매포청천 소개](https://www.youtube.com/watch?v=i837NMZmLk8&ab_channel=지그재그)

# 잘한 점

- 기술 제안, 일정 산정 및 배분, 개발 프로세스 관리, 전체적인 개발적 간섭(?)을 하게 됐는데 나름 만족스런 결과물이 나온 것 같다.
  ![231003-171449](</posts/9월_회고(꿀매포청천_프로젝트_회고)/231003-171449.png>)
  - 팀 회고에서도 이 부분에서는 다들 만족스럽다고 해서 뿌듯했다.
  - 갈등도 딱히 없었고, 최대한 그 소지를 줄이고자 했다.
  - 짧은 일정 상 끊을 때 끊는 것을 의도했는데, 안 했으면 일정을 지키지 못 했을 것 같다.
- 팀원에게 맡긴 부분은 확실히 맡기기
  - 팀원에게 각자 challenge가 될 만한 과제를 맡겼다.
  - 나도 누군가의, 누군가도 나의 코드가 만족스럽지 않을 수 있다.
  - 일정 상 모든 개발의 부분을 딥하게 micromanagement 할 수도 없고, 할 필요도 없다.
  - 간섭 대신 자유롭게 어려움을 겪을 때 공유할 수 있는 장소와 시간을 만들고, 리뷰에서 처리할 수 있도록 했다.
  - 이를 사용하지 않는 경우에 대해서는 개인의 책임으로 하도록 의무와 책임을 자유롭게 했다.
- 매 스프린트 종료 시 배포를 통해 버그와 개선 사항을 처리하도록 했다.
- 공통 사항에 대한 공유가 활발히 이루어 진 것 같아 만족스럽다.
- 저번 팀에서의 피드백을 바탕으로 내 작업물 등에 대해 설명할 때 간단한 UML 등을 활용해 더 쉽게 이해할 수 있도록 노력했다.
  ![231003-171504](</posts/9월_회고(꿀매포청천_프로젝트_회고)/231003-171504.png>)

# 아쉬운 점 및 반성

- 세심한 일정 공유가 부족했다.
  - 최대한 일정을 산정하려 해보지만 테스크에 대해 정확한 예측을 하는게 쉽지 않다.
  - 억지로 테스크를 부과하지는 않았지만, 팀원들이 착해서 개인 일정을 고려하지 않고 수용하는 경우가 있던 것 같다.
  - 때문에 매 스프린트에 말미에 급하게 개발이 이루어져 잦은 충돌과 문제를 겪었다.
  - → 배포 일정을 자주 처리하면 조금 더 lean하게 할 수 있지 않을까
- 기술 공유가 부족했다.
  - 급한 때가 됐을 때나 회의가 진행된 이후 모르는 부분을 공유하는 경우가 있어 총 시간이 더 소요됐다.
  - 팀원 분 중에 초기에 NextJS에 대해 간략히 발표회를 연 분이 있는데, 나도 이렇게 했으면 더 원활한 프로젝트가 됐을 것 같다.

→ 위 아쉬움들을 종합해보니 초반에 먼저 상세히 설명회 식으로 열었으면 설명에 대해 집중도 챙기고 한 번에 의문점도 해소하고 갈 수 있지 않았을까 하는 생각이 든다.

- 초기 세팅에서 프로젝트 외의 문제점도 있었다.
  - 기억하기 위해 적자면, 노드 버전이 다르고 안정화 버전이 아닌 최신 버전을 사용해 문제가 생긴 케이스도 있었다. 미리 체크하고 가면 삽질을 조금이나마 줄일 수 있겠다.
- 기획 단계에서 아쉬움
  - 키 포인트를 중심으로 가지를 뻗어나가는 식으로 해야겠다.
  - 디자인에 따라 개발 난이도가 달라짐을 인식해야겠다.

# 관련 링크

- 깃허브

https://github.com/prgrms-fe-devcourse/FEDC4_Price-PCC_DONGYOUNG

- 발표 영상

[꿀매포청천 소개](https://www.youtube.com/watch?v=i837NMZmLk8&ab_channel=지그재그)

- 홈페이지

[꿀매포청천](https://price-pcc.vercel.app/)


꿀매포청천 프로젝트 회고


## Contents

# readonly와 as const

> 💡 아래 예시에서 v2의 as const 처리된 x와 v3에서 readonly 처리된 x는 어떤 차이가 있을까?

```tsx
const v1 = {
  x: 1,
  y: 2,
}

const v2 = {
  x: 1 as const,
  y: 2,
}

const v3 = {
  x: 1,
  y: 2,
} as const
```

- v2.x의 값은 `1` 자체로 고정된다.
  ```tsx
  v2.x = 1 // ok
  v2.x = 3 // Type '3' is not assignable to type '1'.
  ```
  ```tsx
  // v2는 아래와 같이 인식된다.
  const v2: {
    x: 1
    y: number
  }
  ```
- v3는 말 그대로 `readonly` 처리된다.
  ```tsx
  v3.x = 1 // Cannot assign to 'x' because it is a read-only property.
  v3.y = 1 // Cannot assign to 'y' because it is a read-only property.
  ```

미묘한 차이가 있다.

# 선택적 속성에 대한 업데이트 사항

책의 설명과 다른 부분이 있다.

```tsx
// 4. 한꺼번에 여러 속성 추가
declare let hasDates: boolean
const nameTitle = { name: 'lee', title: 'hi' }
const pharaoh = {
  ...nameTitle,
  ...(hasDates ? { start: -2589, end: -2566 } : {}),
}
pharaoh.start
// 오류 -> '{name: string; title: string;}' 형식에 'start' 속성이 없습니다.

// pharaoh.start를 사용하고 싶다면 헬퍼 함수 사용
function addOptional<T extends object, U extends object>(
  a: T,
  b: U | null,
): T & Partial<U> {
  return { ...a, ...b }
}

const pharaoh = addOptional(
  nameTitle,
  hasDates ? { start: -2589, end: -2566 } : null,
)
pharaoh.start // 정상, 타입이 number | undefined;
```

위 예시에서 선택적 속성에 대해 union으로 처리되기 때문에 별도의(`addOptional`) 처리가 필요하다고 책에서는 설명한다.

하지만 최근 버전의 타입스크립트에서는 그냥 `number | undefined` 로 추론이 된다. 왜일까?

- 4.0.5
  ![231005-162452](</posts/이펙티브_타입스크립트_더보기(3-4)/231005-162452.png>)

책에서의 설명대로 객체의 유니온으로 추론된다.

- 4.1.5
  ![231005-162504](</posts/이펙티브_타입스크립트_더보기(3-4)/231005-162504.png>)

책에서의 설명과는 달리 바로 optional로 처리된다.

### 공식 문서의 release note의 설명을 살펴보자.

[Documentation - TypeScript 4.1](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-1.html#conditional-spreads-create-optional-properties)

기존 방식은 실제 케이스에 대해서 더 정확하게 모델링하고 있다.

하지만 극단적으로 spread가 중첩되는 경우, 각 중첩에 대해 모든 경우의 수를 계산하는데 드는 비용은 극단적이며 대부분의 경우 그럴만한 가치가 없다.

때문에 typescript 팀은 더 나은 성능과 일반적인 케이스의 더 나은 사용을 위해 optional로 처리하도록 동작을 수정했다고 한다.

# 타입 좁히기

> 💡 filter method로 값을 좁힐 수 없을까?

책에서 언급한 예시에 대해서 살펴보자.

```tsx
const members = ['Janet', 'Michael']
  .map((who) => jackson5.find((n) => n === who))
  .filter((who) => who !== undefined) // 타입이 (string | undefined)[]
```

위 예시에서 타입시스템의 추론을 예상해보자면 `string[]` 라든가, `['Jenet', 'Michael']` 이라든가의 식으로 생각할 수 있지만 결과는 그렇지 않다.

후자는 그렇다 치지만 왜 전자도 걸러내지 못하는 걸까?

- 간단히 보는 결론

![231005-162527](</posts/이펙티브_타입스크립트_더보기(3-4)/231005-162527.png>)

`lib.es5.d.ts` 의 filter 구현이다. filter 메서드는 value 값을 제너릭으로 그 배열을 반환한다.

`find()` 에서는 `string | undefined` 를 반환하고 이 결과로 만들어진 mapping된 함수가 filter에서 처리되므로 생각과는 다르게 `string | undefined[]` 의 결과를 얻게 된다.

### 왜일까?

애초에 filter 메서드에 반환 타입에 대해 구체화하는 절차를 추가하면 되지 않을까?

하지만 filter의 목적을 더 생각해 볼 필요가 있다. 타입스크립트는 자바스크립트의 구현을 바탕으로 타입 추론을 한다.

→ filter 메서드는 boolean 값을 반환하여 필터링을 수행할 뿐, 내부 구현을 확인하여 타입을 확정짓는 과정과는 차이가 있다.

typescript repository에서도 관련 이슈를 꽤 찾아볼 수 있다.

https://github.com/microsoft/TypeScript/issues/16069

- 해결책

```tsx
function isDefined<T>(x: T | undefined): x is T {
  return x !== undefined
}
const members = ['Janet', 'Michael']
  .map((who) => jackson5.find((n) => n === who))
  .filter(isDefined)
```

사용자 정의 타입 가드를 추가해 줄 수 있다.

# 중첩 객체의 타입 좁히기 문제

중첩 객체에서의 태그된 유니온은 타입 좁히기가 동작하지 않는다.

스터디에서 팀원 분이 작성해 주신 아래 예시를 통해 살펴보자.

```tsx
type LoadingState = { status: { label: 'loading' } }
type SuccessState = { status: { label: 'success' }; data: string }
type ErrorState = { status: { label: 'error' }; message: string }

declare let fetchState: LoadingState | SuccessState | ErrorState

switch (fetchState.status.label) {
  case 'loading':
    console.log('로딩중..')
    break
  case 'success':
    console.log('성공! 데이터: ', fetchState.data) //  --- (1)
    break
  case 'error':
    console.error('에러: ', fetchState.message) //  --- (2)
    break
}
```

예상대로라면 각 (1), (2)의 추론이 `SuccessState` , `ErrorState` 로 추론될 것 같다.

하지만 `LoadingState | SuccessState | ErrorState` 로 모두 의도와는 다르게 타입 좁히기가 되지 않는다. data와 message를 보장하지 못하고 에러를 표시한다.

### 왜일까?

현재 타입스크립트 시스템은 정적인 분석을 시행하고 있고, 위 예시에서 사용하려 하는 ‘nested discriminated unions’의 개념을 이해하지 못한다.

현 시스템은 직접적인 관계의 프로퍼티에 대해서만 tag로써 유효하다.

관련한 제안이 있지만 크게 진행되고 있지 않은 듯 하다.

https://github.com/microsoft/TypeScript/issues/18758

- 해결책 중 한 가지는 사용자 정의 타입 가드를 활용하는 것이다.

```tsx
function isLoadingState(state: {
  status: { label: string }
}): state is LoadingState {
  return state.status.label === 'loading'
}
```

# 더 구체적인 타입 사용하기

아래 예시를 보자.

```tsx
// 기본 구현
function pluck(records, key) {
  return records.map((r) => r[key])
}

// 타입 정의
function pluck(records: any[], key: string): any[] {
  return records.map((r) => r[key])
}
```

- any 타입으로 처리해 정밀하지 못하다. 특히 반환값에서의 any는 주의할 필요가 있다.

```tsx
function pluck<T>(records: T[], key: keyof T) {
  return records.map((r) => r[key])
}
```

- `T[keyof T][]` 의 반환값을 추론한다.
- 문제가 있다.
  - `keyof T` 는 모든 T[]의 key 값이기 때문에 records의 아이템의 모든 타입들의 유니온으로 추론된다.

```tsx
function pluck<T, K extends keyof T>(records: T[], key: K): T[K][] {
  return records.map((r) => r[key])
}
```

- 위와 같이 K를 T의 특정 key로 제한한다.
- 해당하는 key의 value의 타입으로 추론이 제한된다.

# 상표 기법 활용하기

런타임에서 체크하기 쉽지만, 타입에서는 체크하기 어려운 부분에 대해 상표를 임시로 붙여줄 수 있다.

```tsx
interface Vector2D {
  x: number
  y: number
}
function calculateNorm(p: Vector2D) {
  return Math.sqrt(p.x * p.x + p.y * p.y)
}

const vec3D = { x: 3, y: 4, z: 5 }
calculateNorm(vec3D) // 결과가 나오나, 의도치 않음

interface Vector2D {
  _brand: '2d'
  x: number
  y: number
}
function vec2D(x: number, y: number): Vector2D {
  return { x, y, _brand: '2d' }
}
function calculateNorm(p: Vector2D) {
  return Math.sqrt(p.x * p.x + p.y * p.y)
}

const vec3D = { x: 3, y: 4, z: 5 }
calculateNorm(vec3D) // '_brand' 속성이 ... 형식에 없습니다.
```

- number 타입에도 상표를 붙일 수 있다.

```tsx
type Meters = number & { _brand: 'meters' }
type Seconds = number & { _brand: 'seconds' }

const meters = (m: number) => m as Meters
const seconds = (s: number) => s as Seconds

const oneKm = meters(1000) // 타입이 Meters
const onMin = seconds(60) // 타입이 Seconds
```

- number 타입에 상표를 붙여도 산술 연산 이후에는 상표가 없어지기 때문에 주의하자.
- 코드에 여러 단위가 혼합된 많은 수의 숫자가 들어 있는 경우, 숫자의 단위를 문서화하는 괜찮은 방법일 수 있다.

> 💡 string 타입에서도 메서드를 사용하면 상표가 없어지나?

그렇다. 아래 예시를 통해 간단히 확인할 수 있다.

```tsx
type a = string & { _brand: 'a' }

const cc = (s: string) => s as a

const neww = cc('hi') // -> a

const b = neww.slice(1) // -> string
```

# 도움 주신 분들

[타입스크립트스터디](https://github.com/prgrms-web-devcourse/FEDC4-TypeScript-Kkobugi-Study) 팀원 분들!!


이펙티브 타입스크립트 더보기(3-4)


## Contents

_이펙티브 타입스크립트 도서의 1, 2 장 중 혼동이 있을만한 내용에 대해 다룹니다._

# 타입스크립트의 목적

1장은 타입스크립트의 목적이나, 개념적인 위치에 대해 설명하고 있다.

이 책은 초반 장이 중요하면서도 모호하게 다가오기 때문에 초반 장을 중요하게 봐야 한다.

타입스크립트 개발의 의도에 공감하는 식으로 접근하면 편했다.

> **“타입스크립트는 자바스크립트의 상위 집합(superset)이다”**

- 자바스크립트가 타입스크립트를 포함하는 것이 아니라 타입스크립트가 자바스크립트를 포함한다.
  - → 모든 자바스크립트 프로그램은 타입스크립트 프로그램으로써 작용할 수 있지만, 반대는 성립하지 않는다.

> 💡 the intent is to catch legitimate bugs in our programs.

- 타입스크립트의 목적은 코드의 설계가 런타임에서 문제를 일으킬 수 있는 경우를 최대한 방지하는 목적이지, 런타임에서의 타입을 강제하거나 확인하는 데에 있지 않다.
  - → 개인적으로 이후에 나오는 각종 케이스들을 보면 타입스크립트는 프로그램의 타입 안정성을 보장하기 위한 각종 편의와 예외를 제공한다. strict하게 무조건적인 규칙을 검사하는 것이 아닌, 실제 나타날 수 있는 위험을 줄이는 장치를 담고 있다는 인상을 받았다.
- 즉 타입 체크를 통과하더라도 여전히 런타임에 오류가 발생할 수 있다. 그리고 런타임 오류 방지를 애초에 보장하지 않는다.
  - → 간단한 예로, 타입을 ‘apple’로 한정했는데, api로 받은 결과가 이와 다른 경우를 생각해보자. 타입스크립트에서 커버해 줄 수 없는 부분이다.

# 타입스크립트 컴파일러의 역할

> **타입스크립트 컴파일러는 두 가지 역할을 수행합니다.**

- 최신 타입스크립트/자바스크립트를 브라우저에서 동작할 수 있도록 구버전의 자바스크립트로 트랜스파일한다.
- 코드의 타입 오류를 체크한다.

→ 이 두 가지 역할은 서로 완벽히 독립적이다.

> 💡 tsc 트랜스파일링 하면 babel은 필요 없나요?

- babel은 여러 기능을 제공하지만 주요 기능은 polyfill이다.
- tsc의 target 설정으로 이를 처리할 수 있다.

- babel의 `@babel/preset-typescript` 를 사용하면 ts를 js로 트랜스파일링하면서 타입 구문을 제거한다. 그러면 타입스크립트 사용의 이점이 줄어든다.
- babel의 이점은 단순 js 버전 호환에만 있지 않다. browerlist 등을 통해 세분화된 커스터마이징이나 플러그인을 통해 특정 라이브러리에 대한 호환성을 제공해 줄 수 있다.
- 그래서 이 둘을 사용할 경우 babel을 통해 트랜스파일링 하고, tsc를 함께 사용해 타입 체킹을 해 주는 것이 좋다.
- vite 등 최신 빌드 툴 등에서는 이런 트랜스파일링과 타입 체크를 적절히 자동으로 체크해준다.

→ 타입스크립트는 ‘런타임’ 오버헤드가 없는 대신, ‘빌드타임’ 오버헤드는 존재한다.

# 구조적 타이핑과 잉여 속성 체크 그리고 타입 추론 이해하기

## 구조적 타이핑

> **자바스크립트는 본질적으로 덕 타이핑(duck typing) 기반입니다.**

- 타입스크립트 또한 이를 그대로 모델링한다.
- 호환되는 구조에 대해 타입 에러 없이 사용이 된다.

> 💡 타입스크립트의 타입 시스템은 기본적으로 ‘열려(open)’있기 때문입니다.

- `a, b`를 요구하는 함수에 대해서 `a, b, c, d` 가 들어있는 데이터를 넘기든, `a, b, x` 가 들어있는 데이터를 넘기든 문제로 인식할 수 없다.

```tsx
// 봉인된, 닫혀있는 타입 시스템을 생각하고 만든 코드
function calculate(v: {x: number, y:number}): number{
  let sum = 0
	for(const key of Object.keys(v)){
		sum += v[key]
	}
    return sum
}

-> error
// 'string' 타입이 v에 입력될 수 있다는 에러가 나온다.
// Object.keys()는 결과값으로 string[]을 제공한다. key는 keyof v가 아닌 string으로 추론된다.

// 단순히 에러를 처리해 준 코드
function calculate(v: { [x: string]: number; y: number }): number {
  let sum = 0
  for (const key of Object.keys(v)) {
    sum += v[key]
  }

  return sum
}

-> no error but not good
// 'string' 인덱스 시그니처를 추가해주어 x, y 외에 속성이 string 키의 number 값일 것임을 이해시킨다.
// 하지만 설계 의도(x와 y만 사용하는 목적)과는 다른 결과를 불러올 수 있다.

// 열려있는 타입 시스템에 의도를 명확히는 코드
function calculate(v: {x: number, y:number}): number{
    let sum = 0
    sum += v.x + v.y

    return sum
}

-> good
// 명확히 사용할 내용을 나타내주어 타입에서나 런타임에서나 문제 소지를 줄일 수 있다.
```

## 타입이 값들의 집합이라고 생각하기

> **’할당 가능한 값들의 집합’이 타입이라고 생각하면 됩니다.**

- 이 집합은 타입의 ‘범위’라고 부르기도 한다.
- 유닛(unit) 타입이라고도 불리는 리터럴(literal) 타입은 한 가지 값만 포함하는 타입이다.
- 유니온 타입은 값 집합들의 합집합을 일컫는다.

> **집합의 관점에서, 타입 체커의 주요 역할은 하나의 집합이 다른 집합의 부분 집합인지 검사하는 것이라고 볼 수 있습니다.**

- 할당 가능한’이라는 문구는 집합의 관점에서, ‘~의 원소(값과 타입의 관계)’ 또는 ‘~의 부분 집합(두 타입의 관계)’를 의미한다.
- & 연산자는 두 타입의 인터섹션(intersection, 교집합)을 계산한다.

다들 이해하기 힘들어했던 부분이다. 차근차근 아래 내용을 살펴보자.

```tsx
interface Person {
  name: string
}

interface Lifespan {
  birth: Date
  death?: Date
}
```

위와 같은 두 인터페이스가 있다.

```tsx
type PersonSpan = Person & Lifespan // -> ?
```

- 타입 연산자는 인터페이스의 속성이 아닌 값의 집합(타입의 범위)에 적용된다.
- 추가적인 속성을 가지는 값도 여전히 그 타입에 속하게 된다.

즉 선택적 속성 외 모든 타입이 필요하다.

→ Person 범위와 Lifespan 범위에 모두 속하는 값의 타입이 된다.

```tsx
type K = keyof (Person | Lifespan) // -> ?
```

`'name' | 'birth'` 아닌가요? 많이 했던 부분이다. 차근차근 뜯어보자.

잠시 다른 예를 살펴보자. microsoft의 typescript 깃허브의 이슈로 올라온 내용이다(https://github.com/microsoft/TypeScript/issues/12815).

```tsx
type A = { a: string }
type B = { b: string }
type AorB = A | B

declare const AorB: AorB

if (AorB.a) {
  // use AorB.a
}
```

위 AorB.a의 사용에서 타입스크립트는 에러를 나타낸다.

(속성 a가 AorB 유형에 존재하지 않습니다…)

왤까? 왜냐하면 AorB에서는 a가 string임을 보장할 수 없기 때문이다. 타입스크립트는 구조적 타이핑을 사용하기 때문에, B와 유니온 된 속성 a는 어떤 값이든 될 수 있다.

타입스크립트는 임의의 속성인 현재 상태에 a를 정할 수 없다. 그러므로 하나의 해결책으로 아래와 같이 a를 알려준다.

```tsx
type A = { a: string }
type B = { b: string; a: undefined }
type AorB = A | B

declare const AorB: AorB

if (AorB.a) {
  // Ok, a는 string|undefined
}
```

(사실 in 키워드를 사용해 AorB가 type A임을 알려주어도 된다. 다만 이 예시를 통해 설명하고자 하는 내용을 위해 위 예시를 작성했다)

다시 원래 내용을 살펴보자.

```tsx
Person | Lifespan -> {name: string} | {birth: Date}
```

→ `{name: string; birth: string} | {birth: Date; name: Date}` 가 되도 문제가 없다.

이 때 `keyof(Person | Lifespan)` 은 왜 `never(공집합)`으로 추론될까?

타입스크립트에서는 이 결과를 사용할 때 type-safe를 보장해야 한다.

즉 `keyof T` 인 `k` 가 `T[k]` 로 사용됐을 때 안전한 작업을 보장한다.

```tsx
interface Person {
  name: string
}

interface Lifespan {
  birth: Date
  death?: Date
}

type PersonSpan = Person | Lifespan

const person1: PersonSpan = {
  // ...
}

person1['name'] // -> ?
```

위 예시에 대해서 `person1['name']` 에 대해서 타입스크립트는 뭐라고 추론해야할까?

이전까지의 설명 내용을 통해 위 추측이 implicit한 any로 밖에 될 수 없다는 것을 알 수 있다. 그러므로 `keyof PersonSpan` 으로 생각할 수 있는 ‘name’은 특정한 타입의 값을 보장해 줄 수 없다(무엇이든 될 수 있기 때문에).

다시 돌아와서, 아래와 같이 Person과 Lifespan의 union의 key는 공집합으로 추론될 수 밖에 없음을 이해할 수 있다.

```tsx
keyof(Person | Lifespan) // -> never
```

## 잉여 속성 체크

구조적 타이핑과 잉여 속성 체크를 연속으로 접하고는 많은 혼동이 있었다. 이에 대해 알아보자.

> **구조적 타입 시스템에서 발생할 수 있는 중요한 종류의 오류를 잡을 수 있도록 ‘잉여 속성 체크’라는 과정이 수행됩니다.**

- 타입이 명시된 변수에 객체 리터럴을 할당할 때 타입스크립트는 해당 타입의 속성이 있는지, 그리고 ‘그 외의 속성은 없는지’ 확인한다.

```tsx
interface A {
	one: number;
	two: number;
}
const a: A = {
	one: 1,
	two: 2
	three: '3' // 개체 리터럴은 알려진 속성만 지정할 수 있으며 'A' 형식'three'가 없습니다.
}
```

- 구조적 타이핑 관점에서 보면 오류가 없어야한다.

> **잉여 속성 체크가 할당 가능 검사와는 별도의 과정이라는 것을 알아야 합니다.**

- 타입스크립트는 단순히 런타임에 예외를 던지는 코드에 오류를 표시하는 것 뿐만 아니라, 의도와 다르게 작성된 코드까지 찾으려고 한다.

```tsx
interface Options {
	title: string;
	darkMode?: boolean
}

function createWindow(options: Options) {
	...
}

createWindow({
	title: 'hi',
	darkmode: true // 개체 리터럴은 알려진 속성만 지정할 수 있지만 'Options' 형식에 'darkmode'이(가) 없습니다.
// 'darkMode'을(를) 쓰려고 했습니까?
})

```

- 순수한 구조적 타입 체커는 이런 종류의 오류를 찾아내지 못한다.
- 잉여 속성 체크를 이용하면 기본적으로 타입 시스템의 구조적 본질을 해치지 않으면서도 객체 리터럴에 알 수 없는 속성을 허용하지 않음으로써, 앞에서 다룬 문제점을 방지할 수 있다.

- 임시 변수를 사용하거나 객체 리터럴이 아닌 경우에는 잉여 속성 체크가 적용되지 않고 오류는 사라진다.

```tsx
const intermediate = { darkmode: true, title: 'hi' }

const o: Options = intermediate // -> 정상
```

- 타입 단언문을 사용할 때에도 적용되지 않는다.
- 인덱스 시그니처를 사용해서 타입스크립트가 추가적인 속성을 예상하도록 할 수 있다.

```tsx
interface Options {
  darkMode?: boolean
  [otherOptions: string]: unknown
}
const o: Options = { darkmode: true } // 정상
```

- 선택적 속성만 가지는 ‘약한(weak)’ 타입에도 비슷한 체크가 동작한다.

```tsx
interface A {
  name?: string
  phoneNumber?: string
}

const person = { phonenumber: '01012341234' }
const p: A = person
// ~ '{ phonenumber }' 유형에 'A' 유형과 공통적인 속성이 없습니다.

// 이런 약한 타입에 대해서 타입스크립튼는 값 타입과 선언 타입에 공통된 속성이 있는지 확인하는
// 별도의 체크를 수행한다.
```

→ 공통 속성 체크는 잉여 속성 체크와 다르게 약한 타입과 관련된 할당문마다 수행된다.

→ 임시 변수를 제거하더라도 공통 속성 체크는 여전히 동작한다.

즉 타입스크립트는 구조적 타이핑으로 모든 것을 일괄 적용하는 것이 아닌, 경우에 따라 잉여 속성 체크나 공통 속성 체크를 통해 사용자가 의도에 맞게 코드를 작성한 것이 맞는지 확인하는 별도의 장치를 두었다.


이펙티브 타입스크립트 더보기(1-2)


## Contents

# 개요

최근 진행하는 프로젝트는 NextJS13 app directory를 사용하여 진행하고 있다.

부딪혀가며 배우는 중인데, 까면 깔 수록 자체 제공 기능이 다양하고 서버 컴포넌트가 디폴트이다 보니 기존 라이브러리나 접근법에서 더 신경 써 주어야 하는 것들이 많다고 느낀다.

그 중에서 최근 잘 못하기도 했고 정리도 안 된 데이터 패칭에 대해서 알아보고자 한다.

# 공식 문서

공식 문서에서 제안한 네 가지 데이터 패칭 사례를 살펴보자.

1. 서버에서 fetch
2. 서버에서 타사 라이브러리 사용
3. 클라이언트에서 route handler 사용
4. 클라이언트에서 타사 라이브러리 사용

## 1. 서버에서 fetch 사용

### Caching

NextJS는 기본으로 제공하는 fetch API를 확장하여 사용한다. 즉, 기본 fetch API를 사용하면서 caching이나 revalidating을 커스텀 할 수 있다.

여기서 중요한 점은 React가 fetch에 대해 동일한 URL과 옵션을 가진 요청을 자동으로 memo한다는 점이다.

![230924-213514](/posts/NextJS13에서_axios와_tanstack_query는_유효할까/230924-213514.png)

> If you need to use the same data (e.g. current user) in multiple components in a tree, you do not have to fetch data globally, nor forward props between components.

때문에 NextJS 공식 문서에서는 위와 같이 렌더링 트리의 여러 구성 요소에서 동일한 데이터(예를 들면 현재 사용자 같은)를 요청하는 경우 전역적으로 데이터를 가져오거나, props로 전달하는 등의 노력이 불필요하다고 지적한다.

![230924-213529](/posts/NextJS13에서_axios와_tanstack_query는_유효할까/230924-213529.png)

- 첫 요청에 대해 MISS 처리되어 외부 데이터를 가져오는 과정을 거치고, 메모리에 SET 된다.
- 동일한 렌더링 경로에서 후속으로 처리되는 함수 호출은 요청을 실행하지 않고 메모리에서 반환한다.
- 렌더링 된 후에는 메모리가 reset되어 모든 request memoization이 지워진다.

- 해당 기능은 NextJS 기능이 아닌 React의 기능이다.
- 메모이제이션은 fetch request의 GET 메서드에만 해당한다.
  - 그러나 NextJS에서 확장이 되어서 그런지 POST 요청을 하는 fetch도 자동으로 caching 된다고 언급되어 있다.
  - 다만 메서드가 Route Handler 내부에 있는게 아니라면 해당되지 않는다고 한다.
  - 요청을 nextjs api handler로 처리해야 해당 캐싱의 이점을 볼 수 있다고 이해했다.

### Revalidation

- Time-based
  - 일정 시간이 지나면 데이터를 재검증
  - 최신성이 중요하지 않은 경우
  ```tsx
  fetch('https://...', { next: { revalidate: 3600 } })
  ```
- On-demand

  - 양식 제출 등의 이벤트 기반으로 재검증
  - 태그 기반 또는 경로 기반하여 데이터 그룹을 한 번에 재검증
  - 가능한 빨리 최신 데이터가 필요한 경우

  ```tsx
  const res = await fetch('https://...', { next: { tags: ['collection'] } })

  // api route에 해당 태그를 심어두고 revalidate를 할 때 같은 태그에 대한 요청을
  // 한 번에 revalidate 할 수 있다는 것
  ```

  - 이를 위해서 태그와 웬만하면 자체 토큰을 세팅하고, 검증할 필요가 있다.

  ```tsx
  // 토큰과 태그 검증 절차가 추가된 api route 예시
  import { NextRequest, NextResponse } from 'next/server'
  import { revalidateTag } from 'next/cache'

  // e.g a webhook to `your-website.com/api/revalidate?tag=collection&secret=<token>`
  export async function POST(request: NextRequest) {
    const secret = request.nextUrl.searchParams.get('secret')
    const tag = request.nextUrl.searchParams.get('tag')

    if (secret !== process.env.MY_SECRET_TOKEN) {
      return NextResponse.json({ message: 'Invalid secret' }, { status: 401 })
    }

    if (!tag) {
      return NextResponse.json(
        { message: 'Missing tag param' },
        { status: 400 },
      )
    }

    revalidateTag(tag)

    return NextResponse.json({ revalidated: true, now: Date.now() })
  }
  ```

  - 또한 path 기반으로도 해당 동작이 가능하다.

  ```tsx
  import { NextRequest, NextResponse } from 'next/server'
  import { revalidatePath } from 'next/cache'

  export async function POST(request: NextRequest) {
    const path = request.nextUrl.searchParams.get('path')

    if (!path) {
      return NextResponse.json(
        { message: 'Missing path param' },
        { status: 400 },
      )
    }

    revalidatePath(path)

    return NextResponse.json({ revalidated: true, now: Date.now() })
  }
  ```

- 아래와 같이 cache를 아예 처리하지 않거나 하는 커스텀이 가능하다.

```tsx
fetch('https://...', { cache: 'no-store' })
```

## 2. 서버에서 타사 라이브러리 사용

> Next.js is working on an API, `unstable_cache`, for configuring the caching and revalidating behavior of individual third-party requests.

- NextJS에서는 타사 라이브러리의 cache 및 revalidate 동작을 처리하기 위한 API를 개발 중이라고 한다.

### Tanstack Query

tanstack query를 nextjs13 app directory에서 사용하는 데에는 약간의 사전 준비가 요구된다.

아래 링크에서 그 내용을 다루고 있다.

[SSR | TanStack Query Docs](https://tanstack.com/query/v4/docs/react/guides/ssr#using-the-app-directory-in-nextjs-13)

- initialData 방법을 이용하면 API를 요청하고 응답을 page에 전달한 다음 props → initialData 순으로 넣어주어야 한다. props drilling이 발생할 수 있고, 응답이 필요한 query가 여러개인 경우 일일이 넣어주어야 해 세팅이 간단하나 권장하지 않는다.

```tsx
import { dehydrate, Hydrate } from '@tanstack/react-query'
import getQueryClient from './getQueryClient'

export default async function HydratedPosts() {
  const queryClient = getQueryClient()
  await queryClient.prefetchQuery(['posts'], getPosts)
  const dehydratedState = dehydrate(queryClient)

  return (
    <Hydrate state={dehydratedState}>
      <Posts />
    </Hydrate>
  )
}
```

두 번째 방법은 위와 같이 dehydrate와 Hydrate를 사용해 주어야 한다.

queryClient를 싱글톤 인스턴스로써 정의하고, 쿼리를 prefetch하고 이를 dehydrate 하여 page에 dehydrateState로 전달하면 된다.

위와 같이 설정하면 중첩 컴포넌트에서도 prefetch 했던 query key와 같은 key를 사용하면 SSR 시에 데이터가 유지된다.

즉 클라이언트에서 hydrate가 진행될 때 queryClient에서 dehydrate한 데이터를 바탕으로 hydrate를 하는 것이다.

tanstack query에서는 dehydrate를 시킨 다음 dehydrated state로 값을 넘겨주어야 cache로써 세팅이 되고 이를 서버사이드 렌더링에서 반환하여 동작한다.

이를 클라이언트에서도 hydrate할 때 dehydrated 된 query를 찾아 각각 hydrate 시켜준다.

### Axios

위에서 알아 본 내용에 기반하여, axios를 사용하면 nextjs에서 제공하는 cache와 revalidate를 사용하기 까다로워진다.

```tsx
import { cache } from 'react'

export const revalidate = 3600 // revalidate the data at most every hour

export const getItem = cache(async (id: string) => {
  const item = await db.item.findUnique({ id })
  return item
})
```

위 예시처럼 별도의 처리가 요구된다.

# NextJS 13에서 별도의 fetch 라이브러리는 필요 없을 수 있다.

NextJS 처럼 고도화 된 프레임워크에서는 위와 같은 설정에 드는 노력이 과연 필요한가에 대한 물음이 생길 수 밖에 없다.

물론 Infinity Scroll 같은 특정 기능에 대해서 강력한 기능을 제공하는 경우(Tanstack Query)에 대해서 일부 도입을 고려할 수 있다.

fetch 라이브러리가 axios에서 제공하는 default config, interceptor 등의 활용을 위해서는 부가적인 노력이 요구될 수 있으나, 현재 단계에서 각 서드파티 라이브러리가 제공하는 SSR에 대한 지원은 NextJS와 자연스럽게 호환된다고 보기는 힘들 것 같다.

하지만 여전히 Tanstack Query와 RSC를 기반한 NextJS의 역할이 다르기 때문에 그 사용에 충분한 의의가 있다는 의견도 있다.

즉 중요한 점은, 구현하고자 하는 특정 부분에서 어떤 전략이 필요할 지를 사전의 정의한 후 적절한 기술을 도입할 필요가 있다는 것… 그런 점에서 내가 이미 작성한 여러 코드 중에 굳이 axios나 tanstack query를 도입할 필요가 없던 내용이 다수 존재한다는 것이다.

## 참고

[React Query 와 SSR - React Query 라이브러리 코드보며 이해하기](https://velog.io/@eomttt/React-Query-와-SSR)

[Next.js v13 App Router로 제품 만들기: 이제 더 이상 Axios를 쓰지 않기로 했습니다](https://velog.io/@myeongjae-kim/Next.js-v13-App-Router로-제품-만들기-fetch를-다루는-기술)

[You Might Not Need React Query](https://tkdodo.eu/blog/you-might-not-need-react-query)

[next.js에서 react query가 필요할까?](https://xionwcfm.tistory.com/339)

[Data Fetching: Fetching, Caching, and Revalidating](https://nextjs.org/docs/app/building-your-application/data-fetching/fetching-caching-and-revalidating)


NextJS13에서 axios와 tanstack query는 유효할까


## Contents

# 서문

지난 7-9월 동안 ‘이펙티브 타입스크립트’ 도서에 대한 스터디를 진행했다.

개인적으로는 2회독이었는데, 혼자 공부한 1회독에서 책을 반도 못 흡수한 것 같아 아쉬움이 있었다.

스터디에서 함께 공부하고 발표하며 의견을 나누다보니 훨씬 쉽고 깊게 이해할 수 있어 좋았다.

![231004-152234](</posts/이펙티브_타입스크립트_더보기(0)/231004-152234.png>)

그리고 어쩌다보니 9번의 스터디 중 5번을 발표했다. 설명을 조리있거나 친절하게 잘 하는 편이 아니라서 좋은 연습 경험이었다.

[유튜브 링크](https://www.youtube.com/watch?v=4T3uN_wOxY0&list=PLvshXKhj0k4xGszZ1VBZT-dx4bdUzWA3w&ab_channel=%ED%9A%A8%EB%A6%AC%EB%B3%B4%EA%B3%A0)

그 동안은 단순하게 장 마다의 내용을 요약해서 업로드했는데, 구글링하면 비슷한 게시글이 많이 나온다. 그런데 책 자체가 불친절한 면…이나 번역이 있어 그대로 옮긴 내용들은 그다지 도움되지 않는다.

하여 주요한 깨달음이나 내용을 위주로 정리해 보고자 한다.

# 링크

- 스터디 깃허브
  https://github.com/prgrms-web-devcourse/FEDC4-TypeScript-Kkobugi-Study


이펙티브 타입스크립트 더보기(0)


## Contents

# 다양한 렌더링 방식

대표적으로 SSR과 Static Rendering, CSR을 들 수 있다.

## SSR

![230903-025756](/posts/NextJS는_SPA일까_MPA일까/230903-025756.png)

SSR은 서버 사이드에서 브라우저의 요청 시점에 HTML 파일을 생성하고, 브라우저가 응답을 받기 전에 처리되므로 클라이언트에서 템플릿 작성을 위한 중복 요청이 방지된다.

이후 DOM에 맞는 JS 이벤트 등을 hydration 과정을 통해 처리해주면 된다.

## Static Rendering

![230903-025811](/posts/NextJS는_SPA일까_MPA일까/230903-025811.png)

정적 렌더링은 빌드 타임에 이미 해당하는 HTML 파일을 작성한다. SSR은 요청에 따라 매번 HTML을 서버에서 작성하고 응답하는 과정이 필요하지만, 정적 렌더링은 만들어 둔 파일을 전송하면 되기 때문에 TTFB(Time to First Byte) 시간의 단축이 가능하다.

## CSR

![230903-025825](/posts/NextJS는_SPA일까_MPA일까/230903-025825.png)

CSR은 JS를 전달받고 브라우저에서 직접 페이지를 렌더링한다. 즉, JS 파일을 파싱한 후 데이터 전달이나 템플릿 작성 등 모든 과정이 클라이언트를 기반으로 처리된다.

# SPA와 MPA

![230903-025836](/posts/NextJS는_SPA일까_MPA일까/230903-025836.png)

MPA는 페이지마다 HTML 페이지를 서버에서 받고, SPA는 하나의 HTML을 기반으로 서버에서 JSON 등의 데이터를 요청해 동작한다.

# SPA ≠CSR, MPA ≠ SSR

SPA, MPA는 웹 페이지의 구성 방식, CSR, SSR은 렌더링 방식이다.

즉 대응되는 개념이 아닌, 별개의 개념이다.

# 이것은 SPA인가 MPA인가

NextJS에서 SSR을 사용하면 MPA로 동작한다고 생각했는데 그러면 매번 서버에서 제공하는 HTML로 갈아끼워지겠고… 어떻게 상태를 관리하고 유지하는걸까?

결론적으로 NextJS는 SPA라 하기도 MPA라 하기도 명확하지 않다.

추상적인 개념이지만 PESPA(Progressively Enhanced Single Page App)에 대해 알아보자.

![230903-025855](/posts/NextJS는_SPA일까_MPA일까/230903-025855.png)

SPA에서 챙긴 서버와의 중복 동작 문제 해결과 MPA의 요청/응답 기반 단순한 구조의 장점을 결합한… PESPA는 두 장점을 모두 취하기 위해 제안되었다.

기본적인 컨셉은 서버와 클라이언트 모두에서 동일한 구조를 공유한다는 것이다.

페이지의 데이터를 최신 상태로 유지하기 위해 변형이 발생할 때 PESPA는 페이지의 데이터 유효성을 다시 검사하는 브라우저 동작을 에뮬레이트한다.

즉 전체 페이지를 다시 로드하는 MPA와는 달리 요청과 재검증이 함께 발생한다. 서버에서 변경점을 렌더링하고 클라이언트에서 업데이트 할 수 있는 대화형 구조가 가능키 때문에 코드 중복 문제를 해결할 수 있다.

하지만 pending state나, optimistic UI등을 처리하는 것은 서버에 위치할 수 없으므로 클라이언트에서만 실행되는 일부 코드를 갖게된다.

라우팅 동작에 대해 알아보자.

## MPA

![230903-025910](/posts/NextJS는_SPA일까_MPA일까/230903-025910.png)

MPA는 기본적으로 요청에 따른 서버 렌더링 결과를 클라이언트에서 HTML를 새로 렌더링하여 처리한다.

전통적인 MPA에서는 애초에 client-side Navigation에 대해서 다룰 수 없다.

## SPA

![230903-025924](/posts/NextJS는_SPA일까_MPA일까/230903-025924.png)

prevent default하고, JS를 통해 URL을 업데이트한다.

클라이언트 라우팅 로직에서 업데이트 요구사항을 결정하고 데이터 요청을 하는 동안 UI는 대기.

서버에서 라우팅 로직을 통해 요청한 데이터를 가져와 클라이언트에 전달한다.

클라이언트에서 데이터를 받아 해당 데이터를 UI 업데이트에 사용한다.

## PESPA

![230903-025935](/posts/NextJS는_SPA일까_MPA일까/230903-025935.png)

SPA와 같이 prevent default.

라우터는 새로운 요청에 대한 데이터와 UI를 한 번에 결정한다.

데이터를 가져와 UI에 반영한다.

# NextJS

CSR과 SSR, SSG 등의 다양한 전략을 개발자가 적절히 선택하게 해 주는 Remix와 NextJS 등의 도구는 PESPA에서 server와 client 간 동일한 구조를 이어주는 브릿지 역할을 제공해준다고 할 수 있다.

NextJS는 서버에서 페이지를 렌더링하고 클라이언트에서 구성 요소만 hydration함에도 불구하고 페이지가 로드되면 여전히 SPA로 작동한다.

첫 번째 렌더링이 서버에서 이루어지지만 첫 페이지에서의 라우팅 및 탐색이 클라이언트에서 발생한다. 즉 SSR과 CSR의 장점을 섞은 방식이라 할 수 있겠다.

첫 요청 페이지를 SPA 삼아서 CSR하기 때문에 전역 상태와 같은 기능을 사용할 수 있다.

NextJS에서는 Link 태그를 통해 prefetch를 하여 페이지를 미리 로드해둔다.

구체적으로 말하자면 이동할 가능성이 있는 페이지는 미리 가져오는 작업을 하고, 그런 경우 HTML을 새로 받아와 갈아끼우는게 아닌 미리 로드된 데이터를 바로 랜더링하여 보여주는 것이다.

덕분에 SPA처럼 빠른 라우팅 전환이 가능하면서도, SSR에서 제공하는 준비된 DOM을 얻을 수 있는 것이다(React와 같이 JS를 hydration하는 과정이 일어난다).

로드 시 SSR 방식의 페이지는 JS를 로딩하고, SSG 방식의 페이지는 HTML이 아닌 JSON파일을 돌려준다.

![230903-025946](/posts/NextJS는_SPA일까_MPA일까/230903-025946.png)

[Rendering on the Web](https://web.dev/rendering-on-the-web/)

[NextJS - SPA or MPA?](https://www.code-insights.dev/posts/nextjs-spa-or-mpa)

[The Web’s Next Transition](https://www.epicweb.dev/the-webs-next-transition)

[next.js의 SSG 제대로 이해하고 사용하기 | parkgang.log](https://parkgang.github.io/blog/2021/09/07/lets-properly-understand-and-use-the-ssg-of-nextjs/)

[SPA로 SSR 구현하기](https://taero.blog/posts/SPA-with-SSR)

[Next.js의 렌더링 과정(Hydrate) 알아보기](https://www.howdy-mj.me/next/hydrate)

[The Web’s Next Transition(웹 애플리케이션 아키텍처의 미래)](https://itchallenger.tistory.com/750)

[Next.js 13 master course - Static / Dynamic Rendering](https://velog.io/@jay/Next.js-13-master-course-Static-Dynamic-Rendering)

[Next.js is an SPA](https://www.reddit.com/r/nextjs/comments/11qotnt/nextjs_is_an_spa/)

[Web: Next.js Link와 Prefetch 과정 파헤쳐보기](https://medium.com/hcleedev/web-next-js-link와-prefetch-과정-파헤쳐보기-44e22ace13e7)


NextJS는 SPA일까 MPA일까


## Contents

# UI 라이브러리에 대해서…

## UI 라이브러리는 왜 필요할까?

개발을 하다 보면 자주 듣는 격언, **\***바퀴를 다시 발명하지 마라(Don't reinvent the wheel)**\*** 라는 문장으로 쉽게 이해 할 수 있다.

과거 회사에서 사내의 디자인 시스템 개발에 대한 이야기가 있었다. 여기서 느낀 것은 고유한 디자인 시스템은 일관성과 효율에서 아주 긍정적이나, 어디까지나 회사 규모와 상황을 우선적으로 고려해야 한다는 점.

내 경험의 의식의 흐름을 따라가보자.

### 1. 새 프로젝트마다 겹치는 컴포넌트가 눈에 띈다.

1.  회사나 브랜드에는 공유하는 디자인이 있다.
2.  매번 만드는 재사용성 컴포넌트가 발생한다. - ui나 atom 정도에 폴더에 들어가는…

### 2. 공동으로 관리하고 재사용 할 디자인 시스템이 있으면 좋겠다.

1.  npm으로 간단히 라이브러리화 할 수도 있고, 특정 집단 내에서만 사용 가능하게 공유할 수도 있다.
2.  매번 새로 만드느니, 한 번 수고해서 다 같이 만들어두고 편하게 불러와서 사용하면 좋지 않을까.
3.  이와 관련해서는 쉽게 결론지을 수 있다. 2021년 NextJS 컨퍼런스 강연에서 Radix UI 개발자로 참여했던 페드로 두아르테는 모든 브라우저에서 잘 작동하고 모든 스크린 리더를 지원하는 드롭다운 메뉴를 구현하는데 사용된 시간을 아래 자료를 통해 설명했다고 한다.

    ![230817-134852](/posts/UI_라이브러리와_headless/230817-134852.png)

4.  즉 웬만한 규모가 아닌 이상 어느정도의 완성도를 보장하는 UI component set을 만드는데에는 꽤 무리가 있다.

### 3. 역시 기존 UI 라이브러리를 잘 활용하면 되겠다.

1.  antd, MUI 등 유명하고 잘 만들어진 라이브러리가 많다.
2.  잘 사용하고 있었다.
3.  음… 조금 더 커스텀한 기능을 추가할 수는 없을까
4.  어찌저찌 만들기는 했는데, 배보다 배꼽이 더 커진 느낌이다.
5.  음… 조금 더 커스텀한 스타일을 적용할 수는 없을까
6.  나는 antd와 styled-component를 함께 사용하고 있었는데, dev tool로 태그를 뒤져서 억지로 스타일을 덧붙이거나(이마저도 들쑥날쑥했다) less loader를 통해 node modules의 antd 스타일 파일을 import하여 커스텀하고, 이를 적용시켜주어야 했다.
7.  이게 맞나… 일단 import한 코드 길이도 어마어마해서 원하는 결과를 내려면 시간이 꽤 소요됐다.

### 4. 더 나은 방법이 없을까. 기능은 취하고 스타일은 커스텀할 수 있는?

## headless한 UI 라이브러리

하던 와중, 최근 새로 진행하는 프로젝트에서 tailwind를 기반으로 css를 작성하고 있는데 headless 식의 UI를 팀원 분의 제안으로 도입해보게 됐다.

> \***\*Completely unstyled, fully accessible UI components, designed to integrate beautifully with Tailwind CSS.\*\***

\_[headlessui.com](https://headlessui.com/)

완전히 **unstyled**이고, 완전히 **accessible**한… 내가 찾던 그게 꽤 오래 전부터 핫했구나

> **So, developers are forced to build custom components; an incredibly difficult task. As a result, most components on the web are inaccessible, non-performant, and lacking important features.
> Our goal is to create a well-funded, open-source component library that the community can use to build accessible design systems.**

\_[radix-ui.com](http://radix-ui.com/)

### 결론

내가 느낀 이런 headless한 성격의 ui 라이브러리의 가장 큰 매력은 몇 가지 스킬(정식으로 제공하거나, 애드온처럼 있는)들을 활용하여 같은 기능의 컴포넌트에 대해 프리셋을 설정해 둔 후, 외부에서 선택사항을 주입하여 재활용성을 극대화 할 수 있다는 것이다.

이에 대한 예시는 다른 글에서 조금 더 자세히 다뤄보겠다.

그나저나… headless한 라이브러리를 선택해서 이에 대한 프리셋을 담아 디자인 시스템화 해서 사용하는 것도 여건이 충분치 않은 상황에 좋은 선택지가 될 것 같은데, 과거에 이런 방식에 대해 말해봤으나 딱히 관심 받지 못한 기억이 떠오른다. 한땀한땀 직접 쌓아올리거나 아예 시도하지 않거나가 아니라 적당히 중장비를 사용해서 만들어 나가는 것도 좋은 것 같다는 생각이다.


UI 라이브러리와 headless


## Contents

![230711-172358](/posts/NextJS13과_NextAuth.js를_활용한_OAuth_도입기/230711-172358.png)

# 개요

요즘 서비스는 전통적인 로그인 방식을 아예 제하고 OAuth만 사용해서 가입, 인증을 구현하는 경우가 더러 있다.

이번에 새로 Blankit 프로젝트를 진행하면서 기획 단계에서 이메일 로그인을 과감히 삭제(예상되는 유저층이 모두 카카오, 구글, 네이버 중 하나 이상 가입 돼 있을 것이므로)하기로 됐다.

마침 프론트 웹을 NextJS13을 사용하기로 한 만큼 OAuth도 편하게 구현할 수 있는 NextAuth.js를 사용하기로 했다.

- NextAuth.js란?
  [NextAuth.js](https://next-auth.js.org/) (그런데 와중에 [Auth.js](https://authjs.dev/)로 이름과 페이지가 업데이트됐다)
  _~~도와줘 ChatGPT!~~_
  ![230711-172434](/posts/NextJS13과_NextAuth.js를_활용한_OAuth_도입기/230711-172434.png)

# 환경

![230711-172417](/posts/NextJS13과_NextAuth.js를_활용한_OAuth_도입기/230711-172417.png)

전체적인 구조는 간단하다.

Vercel로 배포된 NextJS서버와 AWS 상의 Spring 서버 그리고 DB.

이에 추가로 각 OAuth 서비스 운영자가 제공하는 Provider 서버가 있을 것이다.

# 과정

## 첫 번째 시도

### 구상

초기에는 찾아본 자료를 통해 일반적인 경우의 OAuth 로그인을 구현하고자 했다.

![230711-172449](/posts/NextJS13과_NextAuth.js를_활용한_OAuth_도입기/230711-172449.png)

위 그림과 같이

1. 클라이언트에서 NextAuth를 통해 서버(Next백엔드) - Provider 서버 간 통신 과정을 통해 user 정보와 auth server access token을 발급받는다.
2. 백엔드(스프링) 서버에 로그인 요청을 하면서 auth server로 부터 발급받은 access token을 보낸다.
3. 클라이언트는 백엔드(스프링) 서버로부터 유저 정보 및 api 요청에 사용될 token을 발급받는다.

의 과정이었다.

### 문제

1. Auth Service Provider와의 요청 시에는 NextJS 자체 백엔드 서버를 거쳐서 발급받고 이후에는 그 정보를 클라이언트에서 스프링 백엔드 서버에 요청한다. 이 과정이 퍽 직관적이지 못하고, 꽤 오버헤드가 많이 발생한다고 생각한다.
2. (auth provider로 부터 받은) access token을 로그인 요청시 spring 서버에 담아 보낸다. 이를 통해서 유저 정보를 spring 서버에서 auth provider에 재요청해서 DB에 저장하거나 활용할 수 있는데, 중복적으로 auth를 요청하는 상황이 불필요하며, 구현하기 복잡하다.
3. 제일 중요한 점은 NextJS backend에 적응이 안된 내가 이를 번갈아 가며 사용하는 것에 어려움을 느끼고 있다.

## 두 번째 시도

### 구상

NextAuth.js에서 권장하는 백엔드와의 연결 및 아키텍쳐가 있었다. 그런데 NextJS13 관련한 자료도 흔치 않은데 이를 응용해 데이터베이스 어뎁터를 생성하는게 녹록치 않아 처음엔 넘어갔었다.

팀원 분의 큰 도움으로 대략적인 문서의 구현 및 세부 내용을 배울 수 있었다.

[문서](https://next-auth.js.org/v3/tutorials/creating-a-database-adapter)

일단 nextAuth 자체가 nextJS api 디렉터리에 `[...nextAuth].js` 명의 파일을 생성해 작성한 `authOptions`을 기반으로 작동한다.

nextAuth.js의 장점이 이 과정에서 간단한 설정만으로 가입, 로그인 로직을 직접 구현할 필요없이 추상화 된 메서드를 통해 유저 정보와 세션, 토큰을 얻을 수 있다는 것이다.

하지만 따로 백엔드 서버(우리의 spring 서버에 해당하는)를 통해 조금 더 커스텀한 로직을 구현하길 원하는 유저를 위해 nextAuth.js에서는 adapter를 구현해 지정해줄 수 있다.

### 구현

공식 document에서는 다음과 같은 예시를 제공한다.

```jsx
export default function YourAdapter (config, options = {}) {
  return {
    async getAdapter (appOptions) {
      async createUser (profile) {
        return null
      },
      async getUser (id) {
        return null
      },
      async getUserByEmail (email) {
        return null
      },
      async getUserByProviderAccountId (
        providerId,
        providerAccountId
      ) {
        return null
      },
      async updateUser (user) {
        return null
      },
      async deleteUser (userId) {
        return null
      },
      async linkAccount (
        userId,
        providerId,
        providerType,
        providerAccountId,
        refreshToken,
        accessToken,
        accessTokenExpires
      ) {
        return null
      },
      async unlinkAccount (
        userId,
        providerId,
        providerAccountId
      ) {
        return null
      },
      async createSession (user) {
        return null
      },
      async getSession (sessionToken) {
        return null
      },
      async updateSession (
        session,
        force
      ) {
        return null
      },
      async deleteSession (sessionToken) {
        return null
      },
      async createVerificationRequest (
        identifier,
        url,
        token,
        secret,
        provider
      ) {
        return null
      },
      async getVerificationRequest (
        identifier,
        token,
        secret,
        provider
      ) {
        return null
      },
      async deleteVerificationRequest (
        identifier,
        token,
        secret,
        provider
      ) {
        return null
      }
    }
  }
}
```

이걸 보고 왜 처음에 넘어갔냐면, 예시만 있고 설명이 거의 없다시피했다. 문서가 그리 친절하진 않고… 구글링해도 사례를 찾기가 힘들다.

이후 팀원 분의 도움 덕에 다음과 같은 과정을 알 수 있었다.

먼저 adapter를 넘겨주면, 내부의 함수가 정해진 플로우대로 동작한다. 내부의 구현을 하나하나 정해줄 필요가 없다.

## 미가입 상태 로그인

1. `getUserByAccount`를 호출하여 로그인한 `Account`가 reference하는 `User`가 있는지 확인 후 리턴
2. 만약 없다면 `getUserByEmail` 호출하여 동일한 이메일로 가입된 `User`가 있는지 확인 후 리턴
   1. 만약 있다면 다른 제공업체로 가입한 것이므로 로그인 진행 멈추고 `…/signin?error=OAuthAccountNotLinked`로 이동됨 사용자에게 다른 로그인 방법으로 시도 하라는 메시지 띄어주면됨 (ex. google로 가입한 상태에서 같은 이메일인 github 로그인시 발생)
3. `createUser` 호출하여 `User` 스키마에 데이터 등록 시키고 등록한 유저 정보리턴
4. `linkAccount` 호출하여 위에 생성한 `User`와 `Account`를 데이터베이스상에서 연결

## 가입상태 로그인

1. `getUserByAccount`를 호출하여 로그인한 `Account`가 reference하는 `User`가 있는지 확인 후 리턴 (여기서 리턴된 유저의 정보가 아래의 콜백에서 사용됨)
2. 존재한다면 AuthOptions의 callbacks에 `session`함수 호출됨

   1에서 리턴한 유저 id가 `token.sub`에 담겨있는데 이를 활용해 getUserById와 같은 함수를 만들어 호출시킨후 client 에서 사용할 데이터를 담아서 리턴하면됨

이제 여기서 spring backend에서 수행할 몇 가지 api 구현을 요청하면 된다.

사전적으로 백엔드와 필요한 DB 스키마에 대한 합의가 선행되어야 한다.

NextAuth.js의 adapter 동작에 적합한 DB 모델은 마찬가지로 document에서 제안해주는 스키마를 따르도록 하자.

![230711-172510](/posts/NextJS13과_NextAuth.js를_활용한_OAuth_도입기/230711-172510.png)

Account 스키마는 Auth Provider로부터 받는 정보들을 NextAuth에서 반환해준 정보이고, User 스키마에 기본적인 유저 정보 및 서비스에서 추가로 필요한 필드를 추가해주거나 빼주면 된다.

우리 서비스의 경우로 예를 들면 경력, 업종 등을 User에 추가해주면 될 것이다.

Adapter를 통해 spring 서버에 요청할 API는

- User 생성
- User와 Account의 link
- ID를 통한 User 조회
- Email을 통한 User 조회
- Account를 통한 User 조회

가 있다.

중요한 점은 api 요청 시의 token을 어떻게 처리하냐인데, nextJS의 백엔드와 spring 간에 합의된 secret 키를 정의해두고 user next 백엔드 내부에서 user 인증이 통과된 경우에만 요청 가능하도록 했다.

![230711-172519](/posts/NextJS13과_NextAuth.js를_활용한_OAuth_도입기/230711-172519.png)

결과적으로 위와 같이 로그인 처리와 api 요청 과정을 조금 더 간소화할 수 있다.

# 결론

nextJS 13의 api 폴더와 nextAuth.js에서 제공하는 강력한 auth 관리를 통해 쉽게 OAuth 로그인을 구현할 수 있다.

하지만 여러 상황에 따라 원하는 방식으로 커스텀화하는 과정이 공식 문서의 불친절함(에 더한 나의 부족한 영어실력 덕분에) 쉽지만은 않게 느껴졌다.

여러 문서와 동료분의 도움으로 로그인의 세부 과정(다른 플랫폼으로 가입한 동일 메일 처리 등)을 커스텀할 수 있었다.

앞으로 수정사항이 생길 것 같은데, 정리해서 업데이트 해야겠다.


NextJS13과 NextAuth.js를 활용한 OAuth 도입기


## Contents

# 발단

딥다이브 스터디에서 동료 분의 발표를 듣던 중에 궁금한(잘못 알고 있던) 점이 있었다.

![230712-000905](</posts/자바스크립트_메모리_관리(V8)_조금_더_알아보기/230712-000905.png>)

```jsx
let a = 'hello'
let b = a // 요 부분에서의 동작
```

나는 데이터 영역에서 @5002의 데이터를 다른 데이터 영역으로 복사하고 (예를들면 @5004), 그 값을 변수 영역에 할당된 b에 링크해준다고 생각하고 있었다.

그런데, 발표자 분의 말씀으로는 엔진에서 효율성을 위해 데이터 영역에서 중복되는 값은 하나만 유지한다고 말씀하셔서 의아했다.

> primitive value는 불변하다.

> ‘hello’는 원시값이고 불변하므로 a와 b는 같은 value memory space의 주소값을 참조하지만, 다른 변수 주소값을 가진다.

(위 개념에서 혼동이 있었음)

대화를 나눠보니 내가 잘못 알고 있는 것 같기도 하고, 사실 이 부분에 대해서 자세히 알려주는 곳이 거의 없어서 직접 확인해보자~ 하고 구글링과 이런 저런 시도를 해 보았다.

# 이론

```jsx
const foo = 'baz'
const bar = foo
```

위의 코드는 문자열을 중복으로 구성하는 두 개의 개별 메모리 청크로 끝나게 되는가?

또는 런타임에 변수와 ‘baz’가 가리키는 문자열이 하나만 있는가?

답은 후자이다.

또 **_원시값은 스택에, 참조값은 힙 스페이스에 할당된다_**를 공식처럼 알고 있는데, 이것도 엄밀히 파보면 애매한 내용이다.

V8의 JavaScript 값은 개체, 배열, 숫자 또는 문자열인지 여부에 관계없이 객체로 표시되고 V8 힙에 할당된다. 이를 통해 객체에 대한 포인터로 모든 값을 나타낼 수 있다.

객체 리터럴을 사용하면 항상 새롭고 고유한 객체가 제공되는 반면 기본 값(숫자는 제외)은 재사용된다. 즉, **string interning**에 의해 런타임 시 메모리에 `const a = ‘foo’; const b = ‘foo’;`를 할 시 하나의 문자열만 저장된다.

![230712-000922](</posts/자바스크립트_메모리_관리(V8)_조금_더_알아보기/230712-000922.png>)

**숫자의 경우는 더 복잡하다. 아래 블로그의 내용을 옮겨봤다.**

https://v8.dev/blog/pointer-compression#value-tagging-in-v8

smi에 해당하는 값은 재사용 처럼 보이지만 사실 tagged pointer 방식으로 작동하기 때문에, 그렇게 보이는 것 뿐. 예를 들어 정수값이 반복문에서 증가할 때 마다 새 값을 할당하는 비효율을 피하기 위해 포인터 값 자체에 추가 데이터를 담은 [tagged pointer](https://en.wikipedia.org/wiki/Tagged_pointer) 방식을 사용한다. 그래서 smi 범위 안에 같은 정수 값이면 같은 포인터 값이 할당되기 때문에 결과만 보면 재사용한다고 생각되는 것… 사실 그 주소값에는 아무 값도 없다.

smi에 해당하지 않는… (예를들어 3.14) 값은

1. `smi` 의 경우에는 아무것도 가리키지 않는, 유효하지 않은 포인터로 인코딩되므로 재사용의 전체 개념이 실제로 적용되지 않는다(위에서 말한 내용).
2. `HeapNumber` (`smi` 로 간주되지 않는 숫자)의 경우
   1. 객체 프로퍼티가 가리키면 mutable한 `HeapNumber`가 되어 매번 새로운 `HeapNumber`를 할당하지 않고 값을 업데이트 할 수 있다. → `HeapNumber`를 공유할 수 없게 만드는 대가로 대다수 사용 패턴에 대한 유익한 tradeoff라고 생각한다.
   2. 다른 경우에는 재사용할 수 있지만 추가 성능 오버헤드가 발생하지 않는 경우에만 재사용할 수 있다. → 예를들어 3+0.14 와 314/100과 같은 두 개의 계산 결과가 할당될 때 이는 두 개의 `HeapNumber`값으로 할당된다. → 이 둘의 계산 결과를 확인한 이후 3.14가 존재하는지 확인하는 것이 그만한 가치가 없기 때문.

_2-1. 내용의 내용이 제대로 이해가 안 간다… 번역을 잘못한건지_

_재사용이 가능하다는 의미처럼 들렸는데, 계속 보다보니 프로퍼티의 변수를 변경 가능한 HeapNumber로 유지해 값이 업데이트 되어도 다른 HeapNumber를 찾거나 하지 않고 그 자체를 갱신한다는 내용같은데, 때문에 같은 값이라도 여러 개의 HeapNumber를 memory space에 할당할 수 있다는걸까? 다른 의견이 있으시면 알려주세요…_

# 실행

## 실행 코드 1

```jsx
		<script>
      const btn = document.querySelector("#btn");
      btn.onclick = () => {
        const string1 = "foo";
        const string2 = string1;
        const string3 = "foo";
        const string4 = "bar";
        const number1 = 5;
        const number2 = number1;
        const number3 = 5;
        const number4 = 6;
      };
    </script>
```

![230712-001045](</posts/자바스크립트_메모리_관리(V8)_조금_더_알아보기/230712-001045.png>)

‘foo’와 ‘bar’는 메모리 스페이스에 각 하나씩 들어있다.

그리고 각 변수는 각각의 value에 맞는 같은 주소를 가져다 사용한다.

## 실행 코드 2

![230712-001101](</posts/자바스크립트_메모리_관리(V8)_조금_더_알아보기/230712-001101.png>)

그냥 실행했을 때: heap number 30개가 기본적으로 init 돼 있다.

```jsx
const num3 = 3.14
const num4 = num3
const num5 = 2.17
```

위 코드를 script 내에서 초기화 해주었다.

![230712-001112](</posts/자바스크립트_메모리_관리(V8)_조금_더_알아보기/230712-001112.png>)

32 개 → heap number에서도 중복이 일어나지 않는 경우로

num3와 num4가 같은 주소의 3.14를 사용했다.

## 실행 코드 3

```jsx
function MyNumbers() {
  this.word1 = 'foo'
  this.word2 = 'goo'
  this.word3 = 'foo'
}
const num1 = new MyNumbers()
const num2 = new MyNumbers()
```

생성자의 인스턴스의 결과를 확인해보자.

![230712-001128](</posts/자바스크립트_메모리_관리(V8)_조금_더_알아보기/230712-001128.png>)

string의 경우에는 여전히 같은 주소 값의 value를 사용한다.

```
			const myHeapNumber = 3.14;
      function MyNumbers() {
        this.smi = 123;
        this.number = myHeapNumber;
	    }
      const num1 = new MyNumbers();
      const num2 = new MyNumbers();

      const num4 = myHeapNumber;
```

![230712-001140](</posts/자바스크립트_메모리_관리(V8)_조금_더_알아보기/230712-001140.png>)

smi에 해당하는 값은 @796339로 동일한 값이 사용됐다.

heap number에 해당하는 값은 같은 값을 가져도 @818117과 @818113으로 다른 메모리 스페이스의 주소를 사용한다.

# 결론

전에 읽었던 자바스크립트 딥다이브에서는 관련 내용을 설명할 때 **_세부 구현은 엔진과 브라우저 사양 등에 따라 다르다._** 라는 내용이 있었는데, 그걸 직접 확인해보니 뭔 소리인지 조금은 더 알 것만 같은 기분이랄까…

엔진의 구현은 효율적인 관리를 위해 여러 장치가 되어있는 것 같다. 저기에 나타난 주소(@숫자)도 실제 주소도 아니다.

역시 눈으로 직접 보기 전까지는 믿기 힘들다.

# 참고 문서

(위 글의 주요 내용은 아래 글들의 내용을 토대로 번역해 작성하고, 직접 코드를 작성해서 테스트해보았다.)

[What are JavaScript variables made of](https://www.zhenghao.io/posts/javascript-variables)

[Pointer Compression in V8 · V8](https://v8.dev/blog/pointer-compression#value-tagging-in-v8)

[Tagged pointer](https://en.wikipedia.org/wiki/Tagged_pointer)

[JavaScript memory model demystified](https://www.zhenghao.io/posts/javascript-memory)
