thalassophilia.log

tanstack query 오픈소스 기여 후기

Thu, 16 Apr 2026 01:12:44 GMT

우리 팀에는 Vue로 구성된 프로젝트가 몇 개 있었고, 기존에는 전반적으로 Pinia를 중심으로 상태를 관리하고 있었다. 그런데 서버 상태와 클라이언트 상태를 같은 방식으로 다루는 데에는 분명한 한계가 있었고, 점점 vue-query를 도입해보자는 이야기가 나오기 시작했다.

vue-query를 도입하면서 가장 먼저 부딪힌 주제 중 하나는 "쿼리 키와 쿼리 함수를 어떻게 관리할 것인가"였다. 프로젝트 수가 늘어나고 화면마다 비슷한 데이터 요청 패턴이 반복되다 보니, 각자 useQuery를 호출하면서 queryKey, queryFn, staleTime, select 같은 옵션을 제각각 작성하는 방식은 금방 유지보수 비용으로 돌아올 수밖에 없었다. 그래서 우리 팀은 여러 상황을 가정해본 끝에 query factory 구조를 사용하자고 결정했다.

이 구조를 택한 이유는 단순히 코드를 예쁘게 정리하기 위해서만은 아니었다. query factory를 사용하면 다음과 같은 장점이 있었다.

쿼리 키를 한 곳에서 일관성 있게 관리할 수 있다.
queryFn과 공통 옵션을 함께 묶어 재사용할 수 있다.
같은 데이터를 조회하는 로직을 화면마다 조금씩 다르게 작성하는 일을 줄일 수 있다.
타입 추론을 최대한 유지한 채로 useQuery, prefetchQuery, invalidateQueries 등을 같은 기준으로 다룰 수 있다.

특히 우리 팀에서는 "쿼리 키를 표준화해서 관리한다"는 점보다도, 쿼리 옵션까지 하나의 단위로 묶어서 재사용할 수 있다는 점을 중요하게 봤다. 예를 들어 어떤 데이터를 조회할 때 queryKey와 queryFn만 필요한 게 아니라, staleTime, gcTime, placeholderData, select 같은 옵션이 함께 따라붙는 경우가 많다. 이럴 때 query factory를 쓰면 "이 쿼리는 이렇게 동작한다"는 규칙 자체를 하나의 팩토리로 캡슐화할 수 있었다.

그런데 이 컨벤션을 구체적으로 정리하는 과정에서 한 가지가 계속 거슬렸다. useQuery나 useInfiniteQuery는 query factory가 반환하는 옵션 객체를 자연스럽게 받아서 사용할 수 있었는데, prefetch는 흐름이 달랐다. 기존 코드에서 usePrefetchQuery를 찾아보니 아래와 같이 queryClient에 직접 접근하는 방식으로 사용하고 있었다.

처음에는 이 정도 차이는 그냥 감수하면 되는 것 아닐까 싶기도 했다. 하지만 생각해볼수록 이 방식은 우리가 정한 방향과 잘 맞지 않았다.

queryClient.prefetchQuery()를 직접 호출하면 결국 호출하는 쪽에서 다시 queryKey, queryFn, 옵션을 조립해야 한다. 그렇게 되면 조회 시점에는 query factory를 쓰고, prefetch 시점에는 다시 수동으로 옵션을 만든다는 이상한 구조가 된다. 겉으로 보기에는 사소한 차이 같지만, 실제로는 다음과 같은 문제가 생긴다.

같은 쿼리를 조회할 때와 prefetch할 때 옵션이 미묘하게 달라질 수 있다.
팀이 정한 쿼리 팩토리 구조를 모든 진입점에서 일관되게 활용할 수 없다.
"이 데이터는 어떤 정책으로 캐싱되는가"라는 규칙이 분산된다.
나중에 옵션이 바뀌었을 때 조회 코드와 prefetch 코드를 각각 찾아 수정해야 한다.

즉, 문제는 단순히 "컴포저블이 하나 없어서 불편하다"가 아니었다. query factory를 도입해 얻고 싶었던 장점을 prefetch 경로에서는 제대로 누릴 수 없다는 점이 더 아쉬웠다. 팀이 컨벤션을 정한 이유가 중복 제거와 일관성 확보에 있었는데, prefetch만 예외처럼 빠져 있으면 결국 중요한 지점에서 다시 수동 관리로 돌아가게 되기 때문이다.

공식 문서를 다시 확인해보니, tanstack/vue-query에는 usePrefetchQuery와 usePrefetchInfiniteQuery가 제공되지 않고 있었다. 반면 React Query 쪽에는 이미 훅을 제공해주고 있었고,(사실상 vue 외에 모든 라이브러리/프레임워크에서 재공해주고 있었다) Vue에서는 queryClient를 직접 사용하는 방식을 안내해주고 있었다.

이게 정말 의도된 차이인지 궁금해서 기존 discussion을 찾아봤다. 그 과정에서 나와 비슷한 문제의식을 가진 질문이 이미 올라와 있는 것을 발견했다.

메인테이너의 답변은 꽤 긍정적이었다. 직접 프로젝트에서 컴포저블을 만들어 써도 되고, 원한다면 usePrefetchQuery를 추가하는 PR을 올려도 된다는 내용이었다.

다만 그 discussion은 2년 전에 작성된 것이었기 때문에, 지금도 같은 방향으로 받아들여질지 확인하고 싶었다. 그래서 다시 한 번 discussion을 남겼고,

tkDodo 님이 흔쾌히 PR을 올려도 된다고 답변해주셨다.

답변을 확인한 뒤에는 "우리 팀에서만 임시로 래퍼를 만들어 쓸까, 아니면 아예 upstream에 기여할까"를 잠깐 고민했다. 로컬 래퍼를 만드는 건 빠른 해결책이지만, 결국 라이브러리 바깥에 별도의 규칙과 구현을 하나 더 두는 셈이었다. 그렇게 되면 팀 내부에서는 문제를 해결할 수 있어도, 장기적으로는 유지보수 포인트가 또 하나 생긴다. 반대로 upstream에 반영된다면 우리 팀뿐 아니라 같은 불편함을 겪는 다른 Vue Query 사용자들도 같은 방식으로 해결할 수 있다. 결국 "팀의 불편함을 임시 우회가 아니라 구조적으로 없애보자"는 쪽으로 생각이 기울었고, 구현을 시작하게 되었다.

우선 tanstack/query 레포를 포크한 뒤 CONTRIBUTING.md를 읽으면서 어떤 방식으로 기여를 진행해야 하는지부터 확인했다. 이후에는 이미 구현되어 있던 React Query 쪽 코드를 기준점으로 삼아 구조를 파악했다. 다만 단순 복붙으로 끝낼 수 있는 작업은 아니었다. 목표는 React와 동일한 사용 경험을 제공하되, Vue Query가 가지고 있는 반응성 특성을 자연스럽게 반영하는 것이었기 때문이다.

구현 과정에서는 특히 다음 부분을 신경 썼다.

React Query의 usePrefetchQuery 동작 방식과 API 표면을 먼저 확인했다. Vue Query 쪽 기존 composable들이 MaybeRef, getter, computed 등을 어떻게 옵션으로 처리하는지 살폈다. queryKey, enabled, 기타 옵션들이 Vue의 반응형 값으로 들어왔을 때도 자연스럽게 동작하도록 맞췄다. 단순히 usePrefetchQuery만 추가하는 것이 아니라, 빠져 있던 usePrefetchInfiniteQuery까지 함께 구현해 API 일관성을 맞췄다. 구현만으로 끝내고 싶지는 않았다. 이런 성격의 기능은 "된다"보다 "기존 패턴과 충돌 없이 안정적으로 동작한다"가 훨씬 중요하다고 생각했기 때문이다. 그래서 런타임 테스트와 타입 테스트를 함께 작성했다. 특히 아래와 같은 경우를 검증하려고 했다.

- 쿼리 상태가 이미 캐시에 있을 때는 불필요하게 prefetch하지 않는지
- reactive option이 변경되었을 때 기대한 방식으로 반응하는지
- 타입 추론이 기존 query options 흐름을 해치지 않는지
- infinite query에서도 동일한 사용 경험을 제공하는지

여기에 더해 문서도 함께 보완했다. 기능이 추가되더라도 공식 문서에 드러나지 않으면 실제 사용자 입장에서는 존재하지 않는 기능과 크게 다르지 않다고 생각했기 때문이다. 그래서 API 레퍼런스 문서에 usePrefetchQuery와 usePrefetchInfiniteQuery 관련 내용을 추가하고, 내비게이션에서도 해당 항목을 찾을 수 있도록 반영했다.

PR을 올리기 전에는 CONTRIBUTING.md 가이드에 적힌 절차대로 테스트를 모두 수행했다. 로컬에서 필요한 검증을 마친 뒤 PR을 올렸고, 약 열흘 정도 지난 후 메인테이너가 리뷰 후 머지해주었다.

PR 링크

이제 vue-query에서 usePrefetchQuery와 usePrefetchInfiniteQuery를 @tanstack/vue-query 5.98.0 이상부터 사용할 수 있다.

이번 경험이 특히 의미 있었던 이유는, 단순히 "오픈소스에 기여했다"는 사실 때문만은 아니다. 처음 출발점은 꽤 작았다. 팀에서 Vue Query 도입 컨벤션을 논의하다가, query factory를 중심으로 구조를 맞추고 싶었고, 그 과정에서 prefetch만 유독 예외처럼 느껴졌다. 처음에는 그냥 팀 내부 유틸로 감싸서 해결할 수도 있었겠지만, 그렇게 하면 우리가 중요하게 생각했던 일관성과 재사용성의 기준이 라이브러리 바깥으로 밀려나게 된다. 나는 가능하면 팀이 정한 좋은 기준을 "각자 알아서 지키는 규칙"이 아니라, 도구 자체가 자연스럽게 받쳐주는 형태로 만들고 싶었다.

결국 이번 컨트리뷰팅은 기능 하나를 추가하는 작업이라기보다, 팀이 더 일관된 방식으로 서버 상태를 다루게 만들고 싶다는 문제의식에서 시작된 일이었다. 실제로 컨벤션을 정하는 과정에서 발견한 불편함을 그냥 참고 넘어가지 않고, 왜 불편한지 구조적으로 설명해보고, 라이브러리 레벨에서 풀 수 있는지 확인하고, 그 해결책을 직접 구현해 반영해봤다는 점이 개인적으로도 꽤 인상 깊었다.

무엇보다 좋았던 건, 이 작업이 개인적인 만족으로 끝나지 않았다는 점이다. 팀 입장에서는 query factory와 query options를 조회와 prefetch 양쪽에서 더 일관되게 활용할 수 있게 되었고, 나 역시 "우리 팀이 더 좋은 방식으로 개발할 수 있도록 필요한 기반을 직접 개선해볼 수 있다"는 감각을 얻었다. 앞으로도 팀에서 일하다가 반복적으로 마주치는 불편함이 있다면, 단순히 우회하는 데서 멈추지 않고 정말 개선할 가치가 있는 문제인지 한 번 더 생각해보고 싶다. 그리고 그게 가능하다면, 팀 내부뿐 아니라 바깥 생태계에도 도움이 되는 방식으로 풀어내고 싶다.

[데브코스] 11.19 - 12.18 한달 회고

Mon, 01 Jan 2024 04:39:15 GMT

데브코스를 시작한지도 어느 덧 3개월이 훌쩍 지났습니다. 이번 달의 강의에서는 Vue와 React를 중점으로 배우고 프로젝트를 진행했습니다.

vue 사용후기

Pinia 적용

강의에서는 pinia의 option stores를 사용하여 프로젝트를 진행하였습니다. 영화 검색기에도 option store를 사용했는데 actions가 두 개 이상 늘어나니 가독성이 급격히 떨어지는 것을 느낄 수 있었습니다. pinia에서 제공하는 다른 방법은 setup store입니다. 상태, getter, actions를 객체로 정의하는 option stores와 달리 setup store는 커스텀 훅과 비슷한 형식으로 상태, getter, actions를 정의할 수 있습니다. 이로 인해 option stores보다 action과 상태가 한 눈에 들어와 가독성, 유지 보수 면에서 좋다고 생각했습니다. 또, 프로젝트 전반에서 composition api를 사용하고 있기 때문에 일관성도 있다고 생각해 변경하게 되었습니다.

useFetch 구현

바닐라 자바스크립트로 프로젝트를 구현할때부터 useFetch를 만들어 사용하려는 시도를 했습니다. get 요청은 다른 요청과 다르게 UI와 밀접한 연관이 있습니다. 이는 데이터가 상태로 관리되어야 하기 때문에 따로 커스텀 훅 형식으로 개발해두면 다양한 get 요청에서 사용하여 중복 로직을 줄이고 함수들이 한 가지 일에 더 집중할 수 있다고 생각했습니다.

바닐라 자바스크립트 프로젝트에서는 렌더링 이슈 때문에 결국 useFetch를 사용하지 못했습니다. 이번 프로젝트에서 처음부터 useFetch를 구현할 생각은 없었지만 이번에 get 요청이 세 가지였고, 스토어에 로딩 상태, 에러 상태, 데이터 상태를 변경하는 로직들이 여러 번 등장하여 결국 만들게 되었습니다. 짧은 시간 안에 구현했기 때문에 범용성을 고려하여 개발하는 것이 까다로웠습니다. 특히 pagination 관련 로직들의 구현과 타입이 까다로웠습니다.

쉽게 생각하면 tanstack query의 useQuery를 가져다 사용하면 단순히 끝날 일이지만 손수 구현해가며 범용성과 구조를 고민해보는 시간이 많이 도움이 되었습니다. 기회가 된다면 useQuery를 참고하여 pagination 로직을 다시 구현해보는 것도 좋을 것 같습니다.

후기

프로그래머스를 통해 Vue를 배우기 전까지는 Vue에 대한 필요성을 크게 느끼지 못했습니다. 리액트가 지배적인 시장 환경에서 저는 리액트를 주로 사용하고 있었고, Vue를 배울 계획이 없었습니다. 하지만 실제로 Vue를 경험해보니, 그 독특한 장점이 눈에 띄었고 흥미로웠습니다.

최근 리액트에 대한 불만이 쌓이며, 내심 리액트의 세계가 빨리 끝나기를 바라고 있었습니다. 리액트의 자유도는 다양한 기술적 접근을 가능하게 했지만, 이로 인해 많은 고민을 하기도 했습니다. 기술을 다루는 방식과 형태가 여러 가지였고, 하나의 기능을 더 할 때마다 지금 나의 방식이 최선에 가까운 방식인지 고민하고 best practice를 찾아보는 시간이 많았습니다. 이로 인해 불필요하게 개발 속도가 느려진다는 생각이 들기도 했고 스트레스로 다가왔습니다. 또, 리액트의 함수형 컴포넌트는 props나 상태가 바뀌면 컴포넌트와 그 컴포넌트의 자식 컴포넌트가 리렌더링 됩니다. 이는 리액트 함수형 컴포넌트의 고유한 특성이기 때문에 불필요한 리렌더링이 발생하진 않는지, 성능 이슈가 있는 건 아닌지 확인해야 하고, 이로 인해 useCallback, useMemo, useEffect 같은 것을 사용해야 했습니다. 앞에서 말한 것과 같이, 리액트는 자유롭기 때문에 useEffect나 useMemo를 어느 상황에서, 언제 써야 하는지, 또 쓴다면 어떻게 사용해야 하는지, 어떤 방법이 가독성을 덜 해치는지에 대한 고민도 뒤따라왔습니다.

이런 배경에서 Vue에 대해 알아보니, 여러 가지 장점이 마음에 들었습니다. 우선, props나 state가 변경된다고 script가 재평가 되는 것이 아니기 때문에 성능 최적화나 리렌더링에 대한 고민이 없었습니다. 프레임워크로서의 강제성은 기술적 결정에 대한 고민을 줄여주었고, 이벤트 수식어를 사용하여 이벤트 리스닝을 더 세밀하게 제어할 수 있습니다. 특히 Transition 컴포넌트는 리액트에서의 애니메이션 처리와 비교해 간결하고 편리해보였습니다.

그러나 막상 프로젝트를 시작하니 어색하고 불편한 점도 있었습니다. 리액트에 익숙해져 있어 부모 상태가 변경되면 당연히 자식 컴포넌트가 리렌더링 된다고 생각하여 꽤 많은 시간을 고민하기도 하고, 문제가 생겨서 검색했을 때 자료가 적어 애를 먹기도 했습니다. 또 타입스크립트로 ref로 선언한 변수의 타입을 지정할 때 항상 Ref를 사용해야 하는 점이 불편하기도 했습니다. 또, 리액트는 모든 이벤트를 delegation으로 처리하기 때문에 항상 돔에 직접 이벤트 바인딩해도 성능 이슈가 없으나, Vue는 각 돔 요소에 직접 이벤트 리스너를 할당하기 때문에 delegation을 직접 해야 하는 것도 불편한 점 중 하나였습니다.

Vue에 대해 딥 다이브한 것은 아니지만 짧게 나마 새로운 기술을 익히고 기존에 알고 있던 기술과 장단점을 알아 보는 게 즐거웠습니다.

프로젝트 후기

작은 프로젝트를 현재 팀원들과 함께 협업하고 있습니다. 팀원분들이 항상 적극적이고 다양한 의견을 내주셔서 프로젝트가 더욱 풍부하고 다채로운 방향으로 나아가고 있다고 생각합니다. 의견 조율과 협업 과정에서 발생하는 어려움이 있지만, 이것 또한 중요한 학습 기회가 되고 있습니다. 서로 다른 배경과 경험을 가진 개발자들과 함께 일하면서, 의사소통의 중요성과 팀워크의 가치를 더욱 깊이 이해하게 되었습니다.

프로젝트의 진행 과정에서, 커뮤니케이션의 역할이 얼마나 중요한지 다시 한번 깨닫게 되었습니다. 모든 팀원이 자신의 의견을 자유롭게 표현할 수 있는 환경을 조성함으로써, 각자의 아이디어와 기술을 최대한 활용할 수 있었습니다.

개발 컨벤션과 스타일의 차이를 조율하는 과정은 시간이 많이 소요되고 있지만, 이를 통해 각 팀원의 개발 방식과 생각을 더 깊이 이해할 수 있었습니다. 서로의 작업 스타일을 존중하고 배우면서, 협업을 하는 방식을 배워갈 수 있었습니다.

[바닐라 자바스크립트] 함수형 컴포넌트 만들기: 렌더링 최적화, 컴포넌트 단위 렌더링

Wed, 13 Dec 2023 09:26:05 GMT

[바닐라 자바스크립트] 함수형 컴포넌트 만들기 시리즈 1편: 컴포넌트 생성하기 2편: useState 만들기

지난 포스트에서 useState까지 만들어봤습니다. 이번 포스트에서는 현재 프로젝트의 큰 문제점인 전체 컴포넌트 리렌더링 이슈를 개선해보겠습니다.

✅ 컴포넌트 단위 렌더링

📍 계획

useState의 setState가 호출되어 리렌더링이 될 때 어떻게 해당 컴포넌트만 리렌더링할 수 있을까요? 변경이 일어난 컴포넌트를 돔에서 찾아, 새로운 돔으로 갈아끼워주면 다른 컴포넌트들은 리렌더링되지 않을 수 있을 것 같습니다. 변경이 일어난 컴포넌트를 돔에서 쉽게 찾기 위해서 컴포넌트를 생성할때 컴포넌트 이름을 id로 가진 div으로 한 번 감싸 렌더링하면 쉽게 접근할 수 있습니다.

아래와 같은 흐름으로 구현하면 컴포넌트 단위 렌더링이 되도록 할 수 있을 것 같습니다.

컴포넌트를 생성할 때, 컴포넌트 이름을 id로 가진 div으로 한 번 감싸 렌더링합니다. ex) ${todo.element}
render 함수를 호출할때 현재 변경이 일어난 컴포넌트를 넘깁니다.
render 함수는 변경이 일어난 컴포넌트 이름을 id로 가진 돔이 있는지 확인하고, 있다면 새로 컴포넌트를 생성하여 innerHTML로 갈아끼워줍니다.

📍 기존 코드 확인

src/index.js

import createComponent from './core/component.js';
import App from './App.js';

const render = () => { const $app = document.getElementById('app'); const appComponent = createComponent(App);

  $app.innerHTML = appComponent.element;
  appComponent.bindEvents();

};

render();

현재 `render` 함수는 App 컴포넌트를 생성하고 innerHTML을 사용하여 돔에 그리도록 구현되어 있습니다. 이 함수는 useState 훅에서 `setState`가 호출되어 상태가 변경되면 호출됩니다. 그렇기 때문에 작은 컴포넌트의 상태가 변경되더라도 전체 App이 다시 생성되고 그려집니다.

- `src/core/hooks/useState.js`

```js
import { getCurrentComponent } from '../currentComponent.js';
import render from '../render.js';

const componentsState = {};

function useState(initialValue) {
  // ...생략

  const setState = newValue => {
    const currentState = componentsState[id][stateIndex];

    const updatedState =
      typeof newValue === 'function' ? newValue(currentState) : newValue;

    if (currentState !== updatedState) {
      componentsState[id][stateIndex] = updatedState;
      render();
    }
  };

  return [stateValue, setState];
}

export default useState;

✅ 1. 컴포넌트 생성시 div로 감싸 렌더링

우선, 변경이 일어난 컴포넌트를 수월하게 찾기 위해 컴포넌트를 생성할 때 컴포넌트 이름을 id로 가진 div로 감싸는 것부터 해보겠습니다.

src/core/component.js

현재 생성된 컴포넌트의 이름을 id로 가진 div로 감싸 다시 컴포넌트 인스턴스의 element에 할당해주었습니다.

✅ 2. 새로운 render 함수 구현

우선, 기존에 src/index.js에 있는 render는 그대로 두고 새롭게 render 함수를 구현해보겠습니다.

src/core/render.js

const render = (component, props) => {
  // 여기서 createComponent를 호출
};

export default render;

파라미터로 component와 props를 받아 createComponent를 호출하여 변경이 일어난 컴포넌트를 다시 호출합니다.

변경이 일어나 리렌더링 해야 하는 컴포넌트를 getElementById로 찾고, 컴포넌트가 존재한다면 갈아 끼워줍니다. innerHTML을 사용할 경우

가 계속 중첩되어 렌더링 될테니 자신을 포함시켜 갈아끼우는 outerHTML을 사용합니다.

render 함수는 useState에서 사용되고 있습니다. useState는 자신을 호출한 컴포넌트 정보를 currentComponent를 통해 알 수 있습니다. 상태가 변경됐을때 상태를 사용하는 컴포넌트를 리렌더링 하기 위해서는 currentComponent를 render 함수의 인수로 넘겨야 합니다. 현재 currentComponent에 저장되는 컴포넌트 정보는 컴포넌트 id와 stateIndex입니다. 여기에 추가로 컴포넌트 함수 자체와 props를 저장해야 합니다.

✅ 3. useState에서 사용할 currentComponent에 정보 추가

src/core/component.js

기존 render는 App 컴포넌트만 렌더링 하는 반면, 새로 구현된 render는 파라미터로 컴포넌트 함수와 props를 받아 컴포넌트 인스턴스를 생성하고 innerHTML로 렌더링하고 있습니다. 기존 render 함수를 사용하고 있는 곳을 모두 변경하도록 하겠습니다.

src/index.js

import createComponent from './core/component.js';
import App from './App.js';

const $app = document.getElementById('app');
const appComponent = createComponent(App);

$app.innerHTML = appComponent.element;
appComponent.bindEvents();

기존 render 함수를 제거하고 App 컴포넌트만 생성하여 렌더합니다.

src/core/useState.js

core/component.js에서 컴포넌트 함수와 props를 주입해주고 있기 때문에 useState에서 가져와 render 함수의 인수로 주입하고 있습니다.

그럼 이제, 컴포넌트 단위로 렌더링이 이루어지는지 확인해보겠습니다.

✅ 컴포넌트 단위 렌더링 확인

간단하게 제목을 토글하는 컴포넌트와 숫자를 count하는 컴포넌트 두 개를 렌더링 하겠습니다.

src/App.js

import createComponent from './core/component.js';
import ToggleTitle from './components/ToggleTitle.js';
import Count from './components/Count.js';

function App() { const toggleTitleComponent = createComponent(ToggleTitle); const countComponent = createComponent(Count);

const bindEvents = () => { toggleTitleComponent.bindEvents(); countComponent.bindEvents(); };

return { element:


        ${toggleTitleComponent.element}
        ${countComponent.element}

, bindEvents, }; }

export default App;

- `src/components/ToggleTitle.js`
```js
import useState from '../core/hooks/useState.js';

function ToggleTitle() {
  const [showTitle, setShowTitle] = useState(true);

  const bindEvents = () => {
    const toggleTitleButton = document.querySelector('.toggle-title');

    toggleTitleButton.addEventListener('click', () => setShowTitle(!showTitle));
  };

  return {
    element: `
      컴포넌트 단위 렌더링
      
    `,
    bindEvents,
  };
}

export default ToggleTitle;

src/components/Count.js

import useState from '../core/hooks/useState.js';

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

const bindEvents = () => { const addCount = document.querySelector('.add-count');

addCount.addEventListener('click', () => {
  setCount(count + 1);
});

};

return { element:

count: ${count}

, bindEvents, }; }

export default Count;

제대로 렌더링 되는지 확인해보았습니다.
![](https://velog.velcdn.com/images/kim-jaemin420/post/3b4d4f4d-db35-4ced-a1de-c4fd30e23143/image.gif)

최초 1번의 상태 변화 후에는 이벤트 리스너가 호출되지 않습니다. 그 이유는 현재 `bindEvents` 함수를 상위 컴포넌트에서 호출해주고 있기 때문입니다. 처음 렌더링 시에는 엔트리 포인트인 App이 생성되면서 하위 컴포넌트의 `bindEvents`를 호출해주지만, 그 이후에 `Count` 컴포넌트만 호출될 때에는 `bindEvents`가 호출되지 않기 때문에 이벤트 리스너가 바인딩 되지 않습니다.

이를 해결하기 위해 컴포넌트가 생성될때 `bindEvents`를 호출하도록 수정하겠습니다.

## ✅ 컴포넌트 생성시, 이벤트 바인딩 함수 호출

- `src/core/component.js`

![](https://velog.velcdn.com/images/kim-jaemin420/post/2a51eb1f-fac4-4895-86b5-11378f645e39/image.png)

`requestAnimationFrame`을 사용하여 돔이 생성된 후에 이벤트 바인딩 함수가 호출하도록 하였습니다. 컴포넌트가 생성될때 이벤트 바인딩을 해주니 더 이상 상위 컴포넌트가 하위 컴포넌트의 이벤트 바인딩 함수를 호출할 필요가 없습니다

- `src/App.js`

```js
import createComponent from './core/component.js';
import ToggleTitle from './components/ToggleTitle.js';
import Count from './components/Count.js';

function App() {
  const toggleTitleComponent = createComponent(ToggleTitle);
  const countComponent = createComponent(Count);

  return {
    element: `
      
        ${toggleTitleComponent.element}
        ${countComponent.element}
      
    `,
  };
}

export default App;

마지막으로 결과를 확인하겠습니다.

첫 렌더링 이후에는 Count 상태나 ToggleTitle의 상태가 변하더라도 다른 컴포넌트에 영향을 주지 않습니다.

이렇게 간단하게 렌더링 최적화를 해보고, 이벤트 바인딩도 부모로부터 분리하게 되었습니다. 다음 포스트에서는 전역 상태 관리를 직접 구현해보도록 하겠습니다.

[바닐라 자바스크립트] 함수형 컴포넌트 만들기: useState 만들기

Tue, 05 Dec 2023 16:45:51 GMT

[바닐라 자바스크립트] 함수형 컴포넌트 만들기 시리즈 1편: 컴포넌트 생성하기

이전 포스트에서는 컴포넌트를 생성하는 함수를 구현하고 현재 사용 중인 상태 관리 방식의 문제점들에 대해 살펴보았습니다. 특히, 외부에서 state 변수를 직접 조작하는 구조의 위험성과 복잡성에 초점을 맞추었습니다. 이런 접근은 예기치 못한 사이드 이펙트를 일으키고, 상태의 추적과 디버깅을 어렵게 만듭니다. 이러한 문제들을 해결하기 위해, 더 안정적이고 선언적인 상태 관리 방법을 도입할 필요성을 느끼게 되었습니다.

이번 포스트에서는 React의 useState와 유사한 기능을 직접 구현하는 방법을 탐구해보려 합니다. useState는 React에서 상태를 관리하는 가장 기본적이면서도 강력한 훅입니다. 이를 통해 상태를 보다 효과적으로 관리하고, 컴포넌트의 렌더링을 더욱 효율적으로 제어할 수 있습니다. 또, 상태 관리의 복잡성을 줄이고 코드의 가독성과 유지보수성을 향상시킬 수 있습니다.

그럼 useState와 비슷하게 동작하는 훅을 javascript로 단계별로 구현해보겠습니다.

✅ 프로젝트 세팅

이전 포스트에 이어 프로젝트를 진행하겠습니다. 지금까지 작성된 코드는 아래와 같습니다.

src/core/component.js

function createComponent(component) {
  const componentInstance = component();

    return componentInstance;
}

export default createComponent;


- `src/index.js`
```js
import createComponent from './core/component.js';
import App from './App.js';

const render = () => {
    const $app = document.getElementById('app');
    const appComponent = createComponent(App);

      $app.innerHTML = appComponent.element;
};

render();

src/App.js

import createComponent from './core/component.js';
import Todos from './components/Todos.js';

function App() { const state = { todos: ['item1', 'itme2']; };

  const setState = { /* ... 생략 */};

const todosComponent = createComponent(Todos, { todos: state.todos });

  return {
    element: `
        
            ${todosComponent.element}
        
    `,
};

}

export default App;


- `src/components/Todos.js`
```js
function Todos({ todos }) {
    return {
        element: `
            
                ${todos.map((todo) => `${todo}`).join('')}
            
        `,
    };
}

export default Todos;

간단한 프로젝트 세팅을 마쳤습니다. 그럼 이제 어떤 흐름으로 useState를 구현할지 생각해보겠습니다.

✅ useState에서 상태 저장 방법

📍 컴포넌트의 상태 저장하기

우선 useState로 상태를 관리하려면 컴포넌트의 상태를 변수에 저장하는 과정이 필요합니다. 여러 컴포넌트의 다양한 상태를 저장하려면 다음과 같은 형태로 저장할 수 있을 것 같습니다.

const componentsState = {
    ComponentA: [1, true, ['todos']],
      ComponentB: ['name'],
};

ComponentA에서는 값이 숫자인 상태, 불리언인 상태, 배열인 상태 세 가지를 사용하고 있고 ComponentB는 값이 문자열인 상태 한 가지만 사용하고 있습니다.

componentsState 객체에 컴포넌트 이름이 키로, 상태 배열이 값으로 저장됩니다. useState 함수 내에서 현재 stateIndex를 저장하고 stateIndex를 1씩 늘려주면 현재 상태는 자신의 상태 index를 기억할 수 있고 다음 상태는 이전 상태 다음으로 저장될 수 있습니다.

const useState = () => {
      const componentName = 현재 컴포넌트의 이름;
      let stateIndex = 현재 컴포넌트의 stateIndex값;

    const setState = () => {
        // setState는 자신의 상위 스코프에 있는 stateIndex 값을 기억한다.
    };

      stateIndex += 1;

      return [componentsState[componentName][stateIndex], setState];
};

이렇게 저장한다면 컴포넌트 내에서 상태들이 섞이지 않으면서 자신이 저장된 index 값을 기억할 수 있습니다.

그럼 이제 현재 렌더링 중인 컴포넌트에서 어떻게 컴포넌트 이름과 stateIndex를 가져와야 할지 고민해보겠습니다.

📍 컴포넌트의 이름과 stateIndex 초기값

useState에서 현재 렌더링 중인 컴포넌트의 정보를 알려면 컴포넌트가 생성될때 이름과 stateIndex 초기값을 부여할 수 있을 것 같습니다.

src/core/component.js

기존 createComponent는 단순히 컴포넌트를 호출해서 반환하는 역할을 했습니다. useState에서 현재 렌더링중인 컴포넌트 정보를 알기 위해 컴포넌트를 호출할때 currentComponent라는 변수에 컴포넌트 이름과 stateIndex의 초기값을 할당해줍니다. currentComponent를 export 하고 있기 때문에 useState에서 import 하여 사용할 수 있습니다.

이렇게 currentComponent 변수에 현재 컴포넌트의 이름과 상태 index를 할당하면 useState에서 활용할 수 있습니다.

그런데 현재 구조에서는 한 가지 문제점이 있습니다. 컴포넌트 내에서 다른 여러 컴포넌트를 렌더링 했을 때 currentComponent에 저장된 값은 무엇일까요? 중첩된 컴포넌트가 어떻게 렌더링되는지 절차적으로 알아보겠습니다.

✅ 컴포넌트 렌더링 과정과 현재 컨텍스트 기억하기

📍 중첩된 컴포넌트 렌더링 과정

우선 다음과 같은 상황을 가정하겠습니다.

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

      const childComponent = createComponent(ChildComponent);

      return {
        element: `
            
                ${childComponent.element}
                count: ${count}
            
        `,
    };
}

ParentComponent내에서 count라는 상태를 선언하고 그 뒤에 createComponent를 사용하여 ChildComponent를 생성하고 렌더링까지 하고 있습니다. 그렇다면 콘솔 로그를 찍어 currentComponent에 어떤 값이 할당되고 있는지 확인해보겠습니다.

function ParentComponent() {
      console.log(1, currentComponent);

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

      console.log(2, currentComponent);

      const childComponent = createComponent(ChildComponent);

    console.log(3, currentComponent); // 여기는 ParentComponent이어야 하는데...

      return {
        element: `
            
                ${childComponent.element}
                count: ${count}
            
        `,
    };
}

결과는 아래와 같습니다.

1 {id: 'ParentComponent', stateIndex: 0}
2 {id: 'ParentComponent', stateIndex: 1}
3 {id: 'ChildComponent', stateIndex: 0}

눈에 띄는 부분은 마지막 3 {id: 'Todos', stateIndex: 0} 입니다. 분명 현재 컨텍스트는 ParentComponent이지만 currentComponent에는 자식 컴포넌트인 ChildComponent가 저장되어 있습니다. 물론 setState는 호출당시의 currentComponent 정보를 기억하고 있기 때문에 이후에 currentComponent 값이 변경돼도 잘 작동합니다. 그러나, currentComponent에 현재 컨텍스트와 다른 정보를 저장하고 있다면 추후에 문제가 생길 가능성이 있습니다. 또, 항상 자식 컴포넌트 호출이 상태 선언 이후에 나오도록 강제하고 있지 않기 때문에 자식 컴포넌트 호출 이후 상태를 선언한다면 해당 상태는 제대로 저장되지 않습니다. 그렇기 때문에 자식 컴포넌트를 호출하고 나면 다시 부모 컴포넌트로 돌아올 수 있도록 구현해주어야 합니다.

📍 자식 컴포넌트 렌더링 후 현재 컴포넌트로 돌아오기

자식 컴포넌트를 렌더링하고 현재 컴포넌트로 돌아오도록 하는 방법은 간단합니다.

src/core/component.js
```
export let currentComponent = null;
```

function createComponent(component) { currentComponent = { id: component.name, stateIndex: 0 };

const componentInstance = component();

return componentInstance; }

export default createComponent;

`createComponent`에서 `component`를 호출하고 있는데, 호출하기 전에 `currentComponent`를 변수에 저장합니다. 저장한 후에 `component`를 호출이 종료되면 `currentComponent`에 호출 이전에 저장해둔 값을 다시 돌려줍니다.
코드로 이해해보겠습니다.

- `src/core/component.js`

![](https://velog.velcdn.com/images/kim-jaemin420/post/3ff07815-6208-4cbf-8614-e88fb4722a2a/image.png)


`component`를 호출하기 전에 `previousComponent`라는 변수에 `currentComponent`를 할당합니다. 현재 컴포넌트를 호출하기 이전이니 `currentComponent`에는 부모 컴포넌트에 대한 정보가 들어있습니다. 호출이 종료하고 `currentComponent`에 `previousComponent`를 다시 할당해주면 이제 `currentComponent`에는 부모 컴포넌트가 됩니다.

이제 `ParentComponent` 어느 부분에서 `useState`를 호출하더라도 현재 컴포넌트 상태 배열에 잘 저장됩니다. 이제 useState를 구현할 준비가 되었습니다.

## ✅ useState 구현하기


앞서 컴포넌트 상태를 어떻게 저장해둘 것인지 설계를 해두었기 때문에 다음과 같이 작성할 수 있습니다. 

- `src/core/hooks/useState.js`

```js
import { currentComponent } from '../component.js';

const componentsState = {};

const useState = (initialValue) => {
    const { id, stateIndex } = currentComponent;

      const state = componentsState[id][stateIndex];
    const setState = () => {};

      return [state, setState];
};

export default useState;

얼추 모양이 잡혔습니다. 이제 componentsState객체에 상태 초기값들을 설정하고, setState 내부 구현만 하면 useState 완성입니다.

📍 useState 초기값 저장하기

useState를 호출할때 파라미터로 초기값을 전달하는데 그 초기값을 componentsState에 저장해보겠습니다. 매우 간단하기 때문에 바로 코드로 구현하겠습니다.

src/core/hooks/useState.js

useState를 호출한 컴포넌트가 componentsState에 등록되어 있지 않다면 빈 배열로 초기화 해줍니다. 이 빈 배열에 해당 컴포넌트의 상태들이 차곡차곡 저장되겠죠?

이후, 상태 배열의 stateIndex 값이 존재하지 않는다면 파라미터로 받은 initialValue로 초기화 해줍니다. 초기값 등록을 마쳤으니 이제 setState를 구현해봅시다.

📍 setState 구현하기

setState의 파라미터로 들어오는 값은 두 가지로, 바꾸려고 하는 새로운 값, 혹은 콜백 함수입니다. 두 가지 케이스에 대해 알아보겠습니다.

새로운 값인 경우
```
setState(5); // 상태를 숫자 5로 변경
```
이 경우 상태를 새로운 값으로 할당해줍니다.
콜백 함수인 경우
```
setState(previousState => previousState + 1); // 현재 상태에 1을 더한 값으로 상태를 업데이트
```
이 경우, setState는 콜백 함수를 호출하고, 이 함수의 반환값으로 상태를 설정합니다. 이 콜백 함수는 현재 상태를 인자로 받아 새로운 상태를 계산하는 데 사용됩니다.

두 가지 케이스를 고려하여 setState를 구현합니다.

변경된 값과 현재 상태 값이 다를 경우 상태를 변경하고 리렌더링합니다. 현재는 단순히 직접 비교를 통해 값을 변경하고 리렌더링 되고 있습니다. 객체나 배열의 경우 내용이 같더라도 참조값이 다르면 두 객체나 배열이 다르다고 평가됩니다. 추후 깊은 비교 등을 통해 개선할 수 있습니다.

✅ 정리

기존에 각 컴포넌트마다 상태를 선언하고 setState를 만드는 방법을 개선하고자 직접 useState를 구현해보았습니다. useState를 설계하고 구현함으로써 리액트의 useState 함수가 콜 스택에서 pop되더라도 어떻게 상태를 유지하고 변경할 수 있는지에 대해 이해해볼 수 있었습니다.

그러나 현재 구조에서는 상태가 변경될 때마다 전체 애플리케이션이 리렌더링되는 문제가 발생하고 있습니다. 하나의 컴포넌트에서 상태가 변경되면 그 컴포넌트와 관련이 없는 컴포넌트도 모두 리렌더링 됩니다. 이러한 문제를 해결하기 위해, 다음 포스트에서는 상태 변경이 발생한 컴포넌트와 그 자식 컴포넌트들만을 대상으로 하는 리렌더링 최적화를 시도해보도록 하겠습니다.

[바닐라 자바스크립트] 함수형 컴포넌트 만들기: 컴포넌트 생성

Tue, 31 Oct 2023 06:21:10 GMT

바닐라 자바스크립트는 웹 개발의 기본이며, 많은 프론트엔드 개발자들이 처음에 접하게 되는 언어입니다. 이에 따라 많은 초보 개발자들은 바닐라 자바스크립트를 통해 기본적인 웹 어플리케이션을 구축하게 됩니다. 그러나 대부분의 자료와 예제는 전통적인 클래스 기반의 컴포넌트를 사용하여 작성되어 있습니다. 현대의 프론트엔드 트렌드는 리액트와 같은 라이브러리에서 볼 수 있듯이 함수형 컴포넌트를 향하고 있습니다. 이러한 변화의 흐름 속에서, 저는 프로그래머스 데브 코스를 진행하며 바닐라 자바스크립트로 함수형 컴포넌트를 어떻게 효과적으로 구현할 수 있을지 고민하게 되었습니다.

이 글에서는 바닐라 자바스크립트만을 사용해서 간단한 todo App을 만드는 과정을 함께 탐색해보겠습니다.

✅ 함수형 컴포넌트

우리의 목표는 리액트의 함수형 컴포넌트와 유사하게 사용할 수 있도록 바닐라 자바스크립트로 컴포넌트를 구현하는 것이기 때문에 리액트에서 함수형 컴포넌트가 어떤 방식으로 사용되는지 알아보겠습니다.

function MyComponent () {
    return 내 컴포넌트입니다.;
}

export default MyComponent;

함수형 컴포넌트는 이름에서도 알 수 있듯이, 일반적인 함수로써 정의됩니다. 함수형 컴포넌트는 JSX (JavaScript XML) 또는 React Element를 반환하는 함수입니다. 함수형 컴포넌트의 장점 중 하나는 간결하고 읽기 쉽다는 것입니다. 이제, 바닐라 자바스크립트에서도 리액트의 함수형 컴포넌트와 유사하게 사용할 수 있도록 구현해보겠습나다.

✅ 컴포넌트 생성하기

리액트의 장점 중 하나는 JSX라는 문법을 사용하여 UI를 간결하게 표현할 수 있다는 것입니다. JSX는 자바스크립트 XML의 약자로, HTML과 유사한 문법을 가진 자바스크립트의 확장 문법입니다. 하지만 이것은 리액트와 Babel과 같은 트랜스파일러를 함께 사용했을 때 가능합니다.

바닐라 자바스크립트에서는 JSX와 같은 특별한 문법을 사용하지 않기 때문에 바로 JSX를 반환하는 것이 불가능합니다. Babel과 같은 트랜스파일러 없이 바닐라 자바스크립트로 컴포넌트를 정의하려면, 기본 자바스크립트 문법을 사용해야 합니다.

이런 한계 때문에 우리의 바닐라 자바스크립트 컴포넌트에서는 문자열 형태의 HTML을 반환하는 방식을 사용하려고 합니다.

function MyComponent () {
    return {
        element: `내 컴포넌트입니다.`;
    };
}

export default MyComponent;

위와 같이 바닐라 자바스크립트에서 컴포넌트를 정의하면, 리액트의 JSX처럼 직관적이고 선언적인 UI 표현이 조금 더 어려워질 수 있지만, 문자열 형태로 UI를 반환하는 이 방식은 기존의 createElement를 사용한 방식보다는 좀 더 직관적이고 선언적이라고 볼 수 있습니다.

📍 컴포넌트 렌더링 하기

이 방법을 사용해서 컴포넌트를 렌더링 해봅시다.

의도한대로 컴포넌트가 잘 렌더링됩니다. 현재는 테스트를 위해 script에 모든 코드를 작성했는데, 모듈을 사용하여 유지보수하기 편하도록 분할해보도록 하겠습니다.

디렉토리 구조

📦src
┣ 📂components    // component들이 속할 디렉토리
┃ ┗ 📜Todos.js
┗ 📜index.js   // entry point 이자, 렌더 함수 위치하는 곳

index.html
src/index.js

src/components/Todos.js

index.js는 애플리케이션의 엔트리 포인트 역할을 하는데, 현재 구조에서는 컴포넌트를 직접 불러와 렌더링하는 역할까지 담당하고 있습니다. 엔트리 포인트 역할을 하는 파일은 다른 파일과 의존성을 최소화해야 합니다. 현재 index.js는 여러 컴포넌트를 직접 불러와 렌더링하는 책임까지 지니고 있습니다. 이를 해결하기 위해 컴포넌트들의 렌더링 역할을 App.js 파일로 분리하겠습니다.

src/App.js

src/index.js

이로써, index.js는 애플리케이션의 시작점으로써의 역할에만 집중하게 되었고, 실제 컴포넌트 구성과 렌더링은 App.js가 담당하게 되었습니다. 이런 구조 변경으로 인해 애플리케이션의 모듈화가 향상되고, 각 파일의 역할이 더욱 분명해졌습니다.

파일의 역할은 분명해졌으나, 또 다른 문제점이 있습니다. 파일 분리 전에는 Todos 컴포넌트가 반환하는 내용을 바로 확인할 수 있어 Todos().element의 사용에 큰 문제가 없었습니다. 그러나, 파일을 분리한 후의 render 함수에서Todos().element 방식의 렌더링은 가독성이 떨어집니다. 파일이 분리되면서 각 컴포넌트의 반환값이 무엇인지 직접 확인하기 힘들어졌고, 그 결과 element가 무엇을 나타내는지 파악하기가 더 어려워졌습니다.

이를 개선하기 위해, 컴포넌트를 생성하는 전용 함수를 도입하는 것이 좋을 것 같습니다. 컴포넌트가 이 함수를 통해 생성된다면, 코드는 더 선언적이며 의미 파악도 쉬워질 것입니다.

✅ 컴포넌트 생성 함수 만들기

디렉토리 구조
```
📦src
┣ 📂components
┃ ┗ 📜Todos.js
┣ 📂core   // 관련된 핵심 로직, 훅, 생명주기 함수들을 보관
┃ ┗ 📜component.js
┗ 📜index.js
```
컴포넌트를 생성하는 함수는 컴포넌트를 렌더링할때 반드시 사용될 함수이고, 프로젝트 전반에서 사용될 예정이기 때문에 core 디렉토리에 위치시켰습니다.
src/core/component.js

여기서 createComponent는 매우 간단한 작업을 수행합니다. 주어진 컴포넌트를 받아서 호출하고, 그 결과를 바로 반환합니다.

이제 createComponent 함수를 사용하여 컴포넌트를 렌더링 해봅시다.

src/index.js

src/App.js

위 코드에서는 createComponent 함수를 이용하여 todosComponent를 생성하였습니다. 이후, 이 컴포넌트의 DOM 요소를 참조하여 app에 추가하고 있습니다. createComponent가 단순한 동작만 수행하지만, 그 사용을 통해 코드의 가독성과 의미가 향상된 것을 볼 수 있습니다.

우리의 프로젝트는 발전해나가면서 점점 더 복잡한 요구사항을 반영해야 할 상황을 맞이하게 됩니다. 특히 컴포넌트를 활용해보며 느낀 점은, 모든 상태를 컴포넌트 내부에 고정시키는 것은 제한적이라는 것입니다.

예를 들어 보겠습니다. 현재 Todos 컴포넌트는 내부 상태를 바탕으로 할 일 목록을 표현하고 있습니다. 그렇다면 만약 일상의 할 일과 업무의 할 일을 분리해서 표현하고 싶다면 어떻게 해야 할까요? 이를 위해서는 Todos 컴포넌트가 외부에서 전달받은 데이터, 즉 props를 기반으로 렌더링을 수행해야 합니다. 그러나 현재의 구조에서는 컴포넌트가 props를 전달받을 수 없습니다.

이번 단계에서는 컴포넌트가 props를 받아들일 수 있도록 업데이트하는 작업을 진행해보도록 하겠습니다.

📍 컴포넌트 props 추가하기

먼저, props를 추가하기 전에 리액트의 함수형 컴포넌트는 어떻게 props를 전달하고 받는지 간단히 살펴보겠습니다.

function ParentComponent() {
  return ;
}

function ChildComponent(props) {
  return {props.message};
}

리액트에서, 부모 컴포넌트는 JSX의 속성을 통해 자식 컴포넌트에 props를 전달합니다. 그런 다음 자식 컴포넌트는 이 props를 파라미터로 받아 사용할 수 있습니다. 이처럼 리액트는 JSX의 간결하고 선언적인 문법을 통해 props의 전달과 사용이 자연스럽게 이루어집니다.

그러나, 바닐라 자바스크립트에서는 이와 같은 JSX 문법을 사용할 수 없습니다. 대신, 우리는 함수의 arguments를 활용하여 props를 전달할 수 있습니다.

현재 createComponent 함수는 컴포넌트 생성을 담당하며, 이 함수를 통해 컴포넌트에 props를 전달할 예정입니다. createComponent 함수 내에서 컴포넌트를 호출할 때, props를 함께 넘겨주는 방식으로 구현하면 바닐라 자바스크립트 환경에서도 props를 효율적으로 관리할 수 있을 것입니다.

src/core/component.js

아주 간단하죠? 기존 코드에서 props를 추가로 받고 이를 컴포넌트에 주입합니다. 이를 활용하여 Todos 컴포넌트가 props로 받은 할 일 목록을 렌더링 하도록 변경하겠습니다.

src/App.js
src/components/Todos.js
결과

잘 적용된 것을 볼 수 있습니다.

현재 컴포넌트는 오로지 정적인 정보만을 표시하는 역할에 집중하고 있습니다. 그러나 웹 애플리케이션의 핵심은 사용자와의 상호작용에 있습니다. 이러한 동적인 상호작용을 가능하게 하기 위해서는 이벤트 핸들러의 바인딩이 필수적입니다.

다음 단계에서는 컴포넌트에 이벤트 핸들러를 연결하는 방법에 대해 알아보겠습니다.

✅ 이벤트 처리

📍 이벤트 바인딩

이벤트 처리에 집중하기 위해, 단순한 컴포넌트 구조로 다시 돌아가 보겠습니다. 아래 이미지와 같은 구조를 가진 컴포넌트를 구현해 보겠습니다.

변경할 컴포넌트들은 다음과 같습니다:

src/App.js

src/components/Todos.js

Todos 컴포넌트가 호출될 때, 내부의 코드는 위에서 아래 순서대로 실행됩니다. 만약 함수 내부에서 DOM을 참조하게 된다면 어떤 문제가 발생할까요?

function Todos({ todos }) {
  // 여기서 버튼 DOM을 참조한다면 어떻게 될까요?

  return {
    element: `
            
              ${todos.map(todo => `${todo}`).join('')}
            
            
          `,
  };
}

export default Todos;

위와 같이 함수 내부에서 DOM을 참조하려고 시도하면, 원하는 DOM 요소가 아직 생성되지 않았기 때문에 참조에 실패하게 됩니다. 그렇다면 어떻게 Todos 컴포넌트가 완전히 렌더링된 시점을 알 수 있을까요? Todos 컴포넌트를 호출하는 부모 컴포넌트는 Todos의 DOM 요소들이 렌더링된 시점을 정확히 알고 있습니다. 이 점을 활용하면, 부모 컴포넌트에서 Todos 컴포넌트의 DOM이 완전히 렌더링된 후에 이벤트 바인딩을 수행할 수 있습니다.

bindEvents라는 함수를 생성하여 DOM 참조 로직을 그 안에 포함시키고, 이 함수를 반환하도록 해 부모 컴포넌트에서 Todos 컴포넌트의 렌더링이 완료된 이후에 호출하도록 하겠습니다.

src/components/Todos.js

src/App.js

src/index.js

Todos 컴포넌트의 렌더링 시점은 App 컴포넌트가, App 컴포넌트의 렌더링 시점은 최상위인 index.js가 알고 있기 때문에 이벤트 바인딩 함수의 호출을 상위에 위임하고 있습니다. 이러한 구조는 다음과 같은 몇 가지 문제점을 가지고 있습니다.

먼저, 상하위 컴포넌트 간의 강한 종속성이 형성됩니다. 이로 인해 코드의 유지보수가 어려워지며, 하위 컴포넌트를 독립적으로 테스트하기도 힘듭니다. 또한 이런 종속성은 하위 컴포넌트의 재사용성을 저하시킵니다.

이 문제의 원인은 각 컴포넌트가 자신의 렌더링 시점을 알지 못하기 때문입니다. 현재의 구조에서는 변경이 생길 때 전체 app이 리렌더링되는 방식을 사용하고 있어, 개별 컴포넌트 단위의 렌더링 관리가 되지 않습니다. 그 결과, 각 컴포넌트는 자신이 언제 렌더링 되는지 알 방법이 없고, 그 렌더링 시점은 상위 컴포넌트가 알고 있게 됩니다.

이 문제를 해결하기 위해서는 컴포넌트 단위로 렌더링을 관리하는 최적화 방안을 적용할 필요가 있습니다. 각 컴포넌트가 자신의 렌더링 생명주기를 스스로 관리하게 되면, 상위 컴포넌트에 대한 의존성을 줄일 수 있습니다. 이에 대한 구체적인 방법은 추후에 다뤄 보도록 하겠습니다.

📍 이벤트 핸들러 함수 바인딩과 상태 변경

이어서 이벤트 핸들러 함수를 생성하여 할 일 추가 버튼을 눌렀을때 상태가 변경되도록 해보겠습니다. 우선 현재 상태를 변경하는 setState 함수를 구현해보겠습니다.

src/App.js

setState 함수로 인해 상태가 재할당 되므로, state 변수의 선언을 const에서 let으로 바꾸었습니다. 리렌더링이 발생할 때마다 App 컴포넌트가 다시 호출되기 때문에, 상태가 초기화되는 것을 방지하기 위해 상태를 함수 외부로 이동시켰습니다. 상태 변경을 Todos 컴포넌트에서도 가능하게 하기 위해, props를 통해 전달하였습니다. 다음으로, Todos 컴포넌트에서 상태를 변경하는 이벤트 핸들러를 구현해보겠습니다.

src/components/Todos.js

props를 통해 받은 상태 변경 함수를 이용하여 이벤트 핸들러에서 상태를 업데이트합니다.

하지만, 이러한 방식으로 상태를 관리하면 아래와 같은 다양한 문제점이 발생할 수 있습니다.

외부에서 state 변수를 직접 조작할 수 있는 구조는 예기치 않은 사이드 이펙트를 초래할 수 있습니다. 상태 관리는 원칙적으로 setState 함수를 통해서만 이루어져야 하나, 현재 구조에서는 여러 부분에서 상태를 수정할 가능성이 있습니다. 이렇게 되면 상태가 어디서 변경되었는지 추적하기가 어려워지고, 디버깅 역시 복잡해질 위험이 있습니다. 또한, 컴포넌트 내에서 상태를 활용하고 수정하다보면 렌더링 호출이 여러 곳에서 발생하게 됩니다. 이것은 렌더링의 정확한 시점을 파악하기 어렵게 만듭니다. 더불어, 현재 코드는 선언적이지 않아 setState의 작동 방식을 컴포넌트가 직접 알아야 하는 문제가 있습니다.

이런 문제점들을 극복하기 위해, React의 useState와 유사한 기능을 도입하는 것이 바람직해 보입니다.

바로 다음 포스트에서 useState를 직접 구현해보겠습니다!

[데브코스] 9.18 - 10.18 한달 회고

Mon, 23 Oct 2023 06:39:08 GMT

데브코스를 시작한지도 어느덧 한 달이 지났습니다. 데브코스 시작 전, 감사하게도 면접 기회를 얻게 되었고 9월 18일에 면접을 보게 되었습니다. 결국 면접에 떨어져 데브코스를 오게 되었는데, 많이 아쉬우면서도 지금 상태로 운 좋게 붙었다 하더라도 회사에 1인분으로, 역할을 잘 해낼지에 대한 의문과 걱정도 많았으리라 생각합니다. 데브코스 과정에서 다음과 같은 내용을 배웠고 그에 대한 느낀점입니다.

선언적 프로그래밍

데브 코스 강의 중 선언적 프로그래밍에 대한 주제가 나오게 되었습니다. 그동안 선언적 프로그래밍에 대해 제대로 이해하지 못해서 이번 기회에 알아보는 시간을 가졌습니다. 토스의 박서진님이 작성한 선언적인 코드 작성하기를 읽고 이해한 선언적 프로그래밍은 다음과 같습니다.

결과 혹은 원하는 것에 대해 설명하지만 그 모든 과정을 코드를 해석하는 과정에서 알 필요는 없습니다. 그러므로 의미를 알기 어려운 로직을 그대로 드러내지 않고 의미를 가지도록 추상화 하는 것이 선언적 프로그래밍이라고 이해했습니다. 따라서 서진님께서는 "선언적인 코드"를 추상화 레벨이 높아진 코드이다 라고 표현한 것 같습니다. 다음은 이에 대한 이해를 돕기 위한 코드입니다.

위 코드는 해석하는 과정에서 필요하지 않는 과정이 그대로 노출되어 있습니다. state를 순회하는 for문이나 돔을 생성하고 삽입하는 과정은 한 번에 의도를 파악하기 어려워 보입니다. 이러한 과정을 추상화를 통해 과정을 적절히 숨기고 의미를 부여한다면 가독성과 재사용성이 올라갈 것 같습니다.

function List() {
    const [state, setState] = useState([1, 2, 3, 4, 5]);

      return (
      
          ${state.map((content) => (
            {content}
        ))}
      
    );
}

위 코드를 보면 for문은 map을 사용함으로써 불필요한 과정이 숨겨진 것을 볼 수 있습니다. 또, JSX로 인해 돔이 어떤 구조로 생성되는지 한 눈에 파악할 수 있게 되었습니다. 코드를 이해해야 하는 입장에서 몰라도 되는 로직은 감춰지고 필요한 정보만 드러나 있어 빨리 파악할 수 있어졌습니다.

그러나, 무조건 추상화 하는 것이 좋은 방향은 아닙니다. 에어비앤비 클론 코딩을 진행했을때, 프로젝트 전반에서 사용되는 모든 버튼 컴포넌트를 하나의 컴포넌트로 추상화하여 사용하고자 했습니다. 여러 컴포넌트에서 사용하는 컴포넌트들을 각각 구현하는 것보다 하나의 컴포넌트를 사용하는 편이 atmoic한 컴포넌트이고 사용성이 좋을 것이라고 생각했습니다. 막상 common한 버튼 컴포넌트를 구현하고 보니, 버튼 크기, 색깔, 내용, 애니메이션 등 생각보다 너무 많은 정보들을 props로 전달해야 했습니다. 가독성과 사용성을 위해 추상화한 컴포넌트인데 오히려 가독성도, 사용성도 살리지 못했습니다. 아래 코드와 같이 사용해야 했습니다.

import { Button } from "./common";

function Home() {
    return (
        
               
    );
}

결국 추상화한 common Button은 폐기하게 되었습니다. 좋은 선언적 코드란 결국, 유지 보수하기 좋도록 추상화한 코드라는 것을 알 수 있습니다. 무엇을 고려하든 항상 읽기 좋고 이해하기 좋은가, 유지 보수 하기 좋은가가 우선이 돼야 한다는 것을 다시 한 번 느꼈습니다. 제가 만든 common Button의 패착은 너무 큰 단위의 컴포넌트를 추상화했기 때문이라고 생각합니다. 작은 단위의, 적은 일을 하는 컴포넌트 또는 함수를 추상화했을때 선언적 프로그래밍의 장점을 잘 활용할 수 있다고 생각합니다. 좋은 예시는 토스의 슬래시 라이브러리에서 많이 배웠습니다. 아래의 ImpressionArea 라는 컴포넌트는 작은 단위의 컴포넌트를 추상화하였습니다.

 { /* 보여지면 실행 */ }}>
  내가 보여지면 `onImpressionStart`가 호출돼요

ImpressionArea로 인해 해당 컴포넌트는 IntersectionObserverApi나 스크롤 핸들러 로직을 직접적으로 사용하지 않을 수 있습니다. 또한, 추상화한 컴포넌트는 어떤 영역이 보이는지 또는 숨겨졌는지에 따라 함수를 호출하는 간단한 일만 하고 있기 때문에 컴포넌트를 사용할때도 유지보수할때도 큰 불편함이 없어보입니다.

결론적으로 좋은 선언적인 코드란 작은 단위의 로직이나 컴포넌트를 유지 보수하기 좋게 추상화한 코드라고 생각했습니다.

코드를 언제 분리할 것인가

코드를 언제 분리할 것인가는 개발을 시작하면서 늘 하게 되는 고민입니다. 바닐라 자바스크립트로 todo App과 노션을 개발하면서 이에 대한 고민을 또 다시 하게 되었습니다.

먼저 todo App을 바닐라 자바스크립트로 구현했을 때 다음과 같은 상황이 있었습니다.

function App() {
    const [todos, setTodos] = useState([]);

      const todoFormComponent = createComponent(TodoForm, { setTodos });
    const todoListComponent = createComponent(TodoList, { todos, setTodos});

      return {
        element: `
            
                ${todoFormComponent}
                ${todoListComponent}
            
        `,
    }
}

App에서 todos에 대한 상태를 만들고 todos 상태를 변경할 수 있는 setter를 하위 컴포넌트의 props로 전달해 todos를 변경할 수 있게 했습니다. props로 setter만 전달하여 상태를 변경하면 코드가 더 간결해지고 편할거라 생각했으나 여기엔 여러 가지 문제가 있었습니다. 제가 간과한 것은 컴포넌트 책임입니다. 현재 todos 상태를 책임지고 있는 컴포넌트는 App입니다. 그렇기 때문에 App은 이 todos가 변경되고 사용되는 부분 또한 알고 있고 관리할 수 있어야 합니다. 만약 setTodos를 컴포넌트 props로 넘긴다면 이 todos가 하위 컴포넌트 내에서 어떻게 변경되는지 App은 알 수 없게 됩니다. 이러한 문제를 깨닫고 아래와 같이 사용하게 되었습니다.

function App() {
    const [todos, setTodos] = useState([]);

      const getTodos = () => { /* 여기서 setTodos 호출*/ };
    const addTodo = () => { /* 여기서 setTodos 호출*/ };
      const deleteTodo = () => { /* 여기서 setTodos 호출*/ };

      const todoFormComponent = createComponent(TodoForm, { addTodo });
    const todoListComponent = createComponent(TodoList, { todos, deleteTodo });

      return {
        element: `
            
                ${todoFormComponent}
                ${todoListComponent}
            
        `,
    }
}

여기서 저는 앞에서 나온 컴포넌트 책임에 대해 잘못 이해하고 todos 관련 로직을 분리해내는 것이 컴포넌트의 책임을 어겼다고 생각했습니다. 그러나, 이렇게 변경하면 또 아쉬운 점이 있습니다. 사실 App은 웹 애플리케이션의 엔트리 포인트 같은 역할을 하는 컴포넌트로 다른 컴포넌트를 렌더링하는 역할을 주로 하고 있습니다. 그런데, 지금은 todos라는 상태 또한 관리하고 있습니다. 오히려 todos 관련 로직을 따로 분리하게 되면 각자의 책임이 분리되어 App은 엔트리 포인트로서 단일 책임을 갖게 되고 todos 관련 로직은 useTodos 라는 훅으로 분리한다면 이 훅은 todos 책임만을 갖게 됩니다. 이렇게 어떤 코드를 분리할 것인가에 대한 고민을 하다 보니 컴포넌트의 책임과 선언적 프로그래밍에 대한 고민도 함께 하며 많은 것을 깨닫게 되었습니다.

이러한 고민을 하며 "코드를 언제 분리할 것인가"에 대한 저만의 기준이 필요하다고 느껴 정리를 해보았습니다. 지금 제가 깨달은 바를 통해 정리를 하자면 다음과 같은 상황에서 분리할 것 같습니다.

코드를 언제 분리할 것인가

반복되는, 의미를 가진 코드
반복되지 않더라도 그 자체로 의미를 가지고 있는 로직
추상화가 필요한 경우

지금까지 정말 많은 버전의 Todo를 만들었지만 구조와 책임에 대해 고민하며 만들었던 적은 없었던 것 같습니다. 어떤 것을 만드느냐는 중요하지 않고 어떤 고민을 하며 만드느냐가 중요하다는 것을 깨닫게 되는 시간이었습니다. 기능과 UI 구현보다는 보다 근본적인 것들에 대해 고민하는 시간을 데브코스에서 보내고 싶습니다.

쿠키, 세션, 웹 스토리지

Thu, 21 Sep 2023 08:38:11 GMT

HTTP의 특징과 쿠키와 세션을 사용하는 이유

쿠키와 세션을 사용하게 된 이유는 HTTP 프로토콜의 특징이자 약점을 보완하기 위해 사용합니다. 우선 HTTP 프로토콜의 특징에 대해 알아보겠습니다.

HTTP 프로토콜

HTTP는 TCP 기반으로 데이터를 주고 받는데 사용되는 프로토콜입니다. HTTP는 클라이언트와 서버 간에 데이터를 전송하고, 웹 페이지, 이미지, 동영상 같은 여러 가지 리소스를 요청하고 전송하는 역할을 합니다. HTTP 프로토콜은 몇 가지 특징이 있는데, 그 중 Connectionless와 Stateless에 대해 살펴보겠습니다.

1. Connectionless 프로토콜 클라이언트가 서버에 요청했을 때 그 요청에 맞는 응답을 보낸 후 연결을 끊는 처리방식입니다.

HTTP 1.1버전에서 커넥션을 계속 유지하고, 요청에 재활용하는 기능이 추가되었습니다. HTTP Header에 keep-alive 옵션을 주어 커넥션을 재활용할 수 있습니다.(keep-alive 옵션은 default 옵션입니다.)

개인적으로 궁금했던 점 Q: HTTP 프로토콜은 TCP 기반 통신이다. TCP는 연결형 통신인데 HTTP 프로토콜은 왜 Connectionless 한걸까? A: TCP 통신이 연결형 통신인 이유는 3-way handshake를 하기 때문이다. 3-way handshake는 연결을 설정하기 위해 신뢰성 있는 통신을 위한 초기 단계이다. 이 과정에서 클라이언트가 서버에 연결을 요청하고, 서버가 수락하는 과정을 거쳐 연결이 확립된다. 이를 통해 HTTP 프로토콜이 데이터를 주고 받을 준비를 마친다. HTTP는 요청을 보내고 응답을 받으면 연결을 유지하지 않기 때문에 TCP 기반임에도 Connectionless 합니다.

2. Stateless 프로토콜 커넥션을 끊는 순간 클라이언트와 서버의 통신이 끝나며 상태 정보는 유지하지 않는 특성이 있습니다. 클라이언트와 첫 번째 통신에서 데이터를 주고 받았다고 해도 두 번째 통신에서 이전 데이터를 유지하지 않습니다. 정보가 유지되지 않으니, 매번 페이지를 이동할 때마다 로그인을 해야 하거나 상품을 선택했는데 구매 페이지에서 선택한 상품의 정보가 없는 상황이 발생합니다.

따라서 이러한 특징을 보완하기 위해 쿠키와 세션을 사용하게 되었습니다. 쿠키와 세션의 가장 큰 차이점은 상태 정보의 저장 위치입니다. 쿠키는 클라이언트에 저장하고 세션은 서버에 저장합니다.

쿠키

쿠키는 클라이언트에서 저장하고 관리하는 데이터들이고, 만료 날짜를 설정한다면 브라우저를 닫아도 데이터를 유지할 수 있습니다. 서버에서 Set-Cookie를 응답 헤더로 내려주면 클라이언트는 이를 받아 저장합니다. 쿠키의 취약점은 XSS(Cross-Site-Script) 공격을 당할 수 있는 것입니다. 보안에 취약하기 때문에 중요한 개인 정보를 저장할 수 없습니다.

동작 순서

클라이언트가 페이지를 요청
서버가 쿠키 생성
생성한 쿠키 정보를 응답 Header에 담아 내려준다.
클라이언트는 받은 쿠키를 서버에 요청할때 요청 Header에 담아 보낸다.

사용 예시)

방문 사이트에서 로그인 시, "아이디와 비밀번호를 저장하시겠습니까?"
팝업창을 통해 "오늘 이 창을 다시 보지 않기" 체크

세션

세션도 쿠키처럼 클라이언트와 서버 간의 통신에서 사용자의 상태를 유지하는 데 사용됩니다. 쿠키는 클라이언트에서 저장하고 관리되는 반면, 서버는 클라이언트에게 session ID를 응답 Header를 통해 내려주고 실제 세션 정보는 서버측에 저장됩니다. 세션은 서버에 저장되기 때문에 과도한 세션 사용은 서버 부하를 초래할 수 있습니다. 이런 문제 때문에 최근엔 사용자 인증 문제를 JWT 토큰을 많이 사용하기도 합니다.

동작 순서

클라이언트가 페이지 요청
서버는 요청 Header의 Cookie를 확인하여 Session-ID를 보냈는지 확인
Session-ID가 존재하지 않는다면 Session-ID를 새로 생성하여 응답 내려준다.
클라이언트는 받은 id를 쿠키에 저장하고 요청시 요청 Header에 담아 요청
서버는 요청 Header를 통해 Session-ID를 확인하고 응답 처리

사용 예시)

화면 전환시 로그인 유지(유저가 로그아웃 하기 전까지)

웹 스토리지

웹 스토리지는 브라우저 내에서 데이터를 저장하고 관리할 수 있는 저장 공간으로 로컬 스토리지와 세션 스토리지가 있습니다. 쿠키는 약 4KB까지 저장 공간을 이용할 수 있지만 웹 스토리지는 약 5MB까지 저장 가능합니다. 또, 쿠키는 데이터를 String으로 관리되기 때문에 데이터를 사용하려면 따로 라이브러리를 사용하거나 직접 구현을 해야 하는 반면, 웹 스토리지는 key, value로 관리되고 getItem, setItem을 통해 쉽게 접근 가능합니다.

로컬 스토리지

로컬 스토리지는 브라우저에 반영구적으로 데이터를 저장하며, 브라우저를 종료해도 데이터가 유지됩니다. 브라우저 자체에 반영구적으로 데이터가 유지되지만 도메인이 다른 경우에는 로컬 스토리지에 접근할 수 없습니다.

세션 스토리지

세션 스토리지는 각 세션마다 데이터가 개별적으로 저장됩니다. 예를 들어, 브라우저에서 여러 개의 탭을 실행하면 탭마다 개별적으로 데이터가 저장됩니다. 세션 스토리지는 로컬 스토리지와 다르게 세션을 종료하면 데이터가 자동으로 제거되고, 같은 도메인이더라도 다른 세션이라면 데이터에 접근할 수 없습니다.

면접 관련 질문

쿠키와 세션에 대해 설명해주세요. 쿠키와 세션은 HTTP 프로토콜의 단점을 보완하기 위해 사용합니다. 쿠키는 클라이언트에 저장되고 만료 날짜를 설정한다면 브라우저가 종료돼도 데이터가 유지됩니다. 서버에서 쿠키를 만들어 응답 헤더에 Set Cookie로 내려주면 클라이언트는 이를 저장합니다. 쿠키의 단점은 XSS 공격에 취약하여 개인 정보를 저장할 수 없습니다. 반면에 세션은 정보가 서버측에 저장되기 때문에 인증 정보를 저장할 수 있습니다. 서버는 클라이언트에게 세션 id를 응답 헤더에 담아 내려주고 클라이언트는 세션 id를 쿠키에 저장하고 요청할때 요청 헤더에 담아 요청합니다. 세션 정보가 서버에 있다보니 사용자가 과도할 경우 서버에 부하가 있을 수 있습니다.
웹 스토리지에 대해 설명해주세요. 웹 스토리지는 브라우저 내에서 데이터를 저장하고 관리할 수 있는 저장 공간으로 로컬 스토리지와 세션 스토리지가 있습니다. 로컬 스토리지는 브라우저에 데이터가 반영구적으로 저장되며 브라우저를 종료해도 데이터가 유지됩니다. 또, 도메인이 같을 경우에만 로컬 스토리지에 접근할 수 있습니다. 반면 세션 스토리지는 각 세션별로 데이터가 개별적으로 저장됩니다. 세션 스토리지는 세션이 종료되면 데이터가 제거되고, 같은 도메인이더라도 다른 세션이라면 데이터에 접근할 수 없습니다.

호이스팅과 TDZ

Wed, 20 Sep 2023 09:09:30 GMT

1️⃣ 변수 호이스팅

var 키워드로 선언한 변수는 런타임 이전에 자바스크립트 엔진에 의해 암묵적으로 선언 단계와 초기화 단계가 한 번에 진행됩니다. 변수 선언문을 포함한 모든 선언문(함수 선언문, 클래스 선언문 등)은 모두 스코프 최상단으로 끌어올려진 것 처럼 작동합니다. 런타임 이전에 렉시컬 환경에 번수 식별자를 등록하고 var 같은 경우 undefined로 초기화까지 진행됩니다. 그러나 let 키워드로 선언한 변수는 선언 단계와 초기화 단계가 분리되어 진행됩니다. 앞서 말한 것처럼 선언문은 스코프 최상단으로 끌어올려진 것처럼 동작하기 때문에 렉시컬 환경에 변수 식별자를 등록하지만 초기화는 하지 않습니다. 초기화는 변수 선언문에 도달했을 때 실행되고 선언 이전에 접근시 reference Error가 발생합니다. 스코프 시작 지점부터 초기화 시작 지점까지 변수를 참조할 수 없는 구간을 일시적 사각지대(Temporal Dead Zone)라고 합니다.

2️⃣ TDZ

TDZ는 선언 전에 변수를 사용하는 것을 비 허용하는 개념상의 공간입니다. 다음의 그림을 통해 쉽게 이해할 수 있습니다.

var는 선언과 초기화가 동시에 되어 TDZ가 없는데, let과 const는 TDZ가 어떻게 생기는지 자바스크립트 엔진 코드를 통해 알아보겠습니다.

// var
var->AllocateTo(VariableLocation::PARAMETER, index);

// const
VariableProxy* proxy =
    DeclareBoundVariable(local_name, VariableMode::kConst, pos);
proxy->var()->set_initializer_position(position());

// let
VariableProxy* proxy =
    DeclareBoundVariable(variable_name, VariableMode::kLet, class_token_pos);
proxy->var()->set_initializer_position(end_pos);

var같은 경우 AllocateTo 메서드를 통해 선언과 동시에 메모리에 공간을 확보해 저장합니다. 반면, let과 const는 set_initializer_position 메소드를 통해 해당 코드의 위치를 의미하는 position 값만 정해줍니다. 선언은 되어 있지만 변수를 위한 메모리에 공간이 확보되지 않은 상태가 됩니다. 이 시점에 let, const 키워드로 생성된 변수들이 일시적 사각지대에 들어가게 됩니다.

3️⃣ 면접 질문 대비

1. 호이스팅에 대해 설명해주세요. 호이스팅은 자바스크립트에서 변수 선언문을 포함한 함수 선언문이나 클래스 선언문 같은 모든 선언문을 사용했을때 스코프 최상단으로 끌어올려진 것 처럼 작동하는 것을 말합니다. var 키워드를 사용한 변수 선언문을 예로 들었을 때, 런타임 이전에 선언 단계와 초기화 단계가 동시에 일어나 렉시컬 환경에 변수 식별자를 등록하고 undefined로 초기화까지 마칩니다. 그래서 선언 전에 에러없이 변수에 접근할 수 있습니다. 반면, let과 const는 런타임 이전에 초기화 단계가 진행되지 않아, 변수를 선언하기 전에 참조하면 reference Error가 발생합니다. 이 때문에 실제로 let과 const에서도 호이스팅이 발생하지만 발생하지 않는 것처럼 보입니다.

2. 그렇다면 TDZ에 대해서도 알고 계신가요? 앞서 설명드린 것처럼 let과 const는 스코프의 시작 지점부터 변수 선언문, 다시 말해 초기화 단계 시작 지점까지 변수를 참조할 수 없습니다. 스코프의 시작 지점부터 초기화 시작 지점까지 변수를 참조할 수 없는 구간을 TDZ 라고 합니다.

web server와 WAS

Tue, 19 Sep 2023 15:56:14 GMT

웹 서버와 웹 어플리케이션 서버(WAS)의 차이에 대해서 알아봅시다.

1️⃣ static pages VS dynamic pages

우선, 정적 페이지와 동적 페이지에 대해서 알아봅시다.

1️⃣ static pages

static pages는 바뀌지 않는 페이지로, 웹 서버는 파일 경로의 이름을 받고, 경로와 일치하는 file contents를 반환합니다. 항상 동일한 페이지를 반환합니다.

image, html, css javascript 파일과 같이 컴퓨터에 저장된 파일들
1️⃣ dynamic pages
dynamic pages는 인자에 따라 바뀌는 페이지로, 인자의 내용에 맞게 동적인 컨텐츠를 반환합니다.

2️⃣ 웹 서버와 WAS의 차이

2️⃣ 웹 서버

개념적으로 하드웨어와 소프트웨어로 구분됩니다.

하드웨어: 웹 서버가 설치되어 있는 컴퓨터
소프트웨어: 웹 브라우저 클라이언트로부터 HTTP 요청을 받고, 정적인 컨텐츠(html, css등)를 제공하는 컴퓨터 프로그램

2️⃣ 웹 서버의 기능

웹 서버는 HTTP 프로토콜을 기반으로, 클라이언트의 요청을 서비스하는 기능을 담당합니다. 웹 서버는 요청에 맞게 두 가지 기능을 할 수 있습니다.

정적 컨텐츠 제공: WAS를 거치지 않고 바로 리소스 제공
동적 컨텐츠 제공: 클라이언트 요청을 WAS에 보내고, WAS에서 처리한 결과를 클라이언트에게 전달

2️⃣ 웹 서버 종류

Apache, Nginx, IIS 등

2️⃣ WAS

웹 어플리케이션 서버로 DB 조회 및 다양한 로직 처리 요구시 동적인 컨텐츠를 제공하기 위해 만들어진 어플리케이션 서버입니다. HTTP를 통해 어플리케이션을 수행해주는 미들웨어입니다. WAS는 웹 컨테이너 또는 서블릿 컨테이너라고도 불립니다.

2️⃣ WAS 역할

was = 웹 서버 + 웹 컨테이너

웹 서버의 기능들을 구조적으로 분리하여 처리하는 역할을 합니다.

2️⃣ WAS의 기능

프로그램 실행 환경 및 DB 접속 기능 제공
여러 트랜잭션 관리 기능
업무 처리하는 비즈니스 로직 수행

2️⃣ WAS 종류

Tomcat, JBoss 등

3️⃣ 웹 서버가 필요한 이유

웹 서버에서는 정적 컨텐츠만 처리하도록 기능을 분배해서 서버 부담을 줄이기 위해 필요합니다.

웹 문서(HTML)를 클라이언트로 보낼 때, 이미지 파일과 같은 정적 파일은 함께 보내지 않습니다. 먼저 HTML 문서를 받고, 이에 필요한 이미지 파일들을 다시 서버로 요청해서 받아오는 것입니다. 따라서, 웹 서버를 통해서 정적인 파일을 어플리케이션 서버까지 가지 않고 앞단에서 빠르게 보낼 수 있습니다.

4️⃣ WAS가 필요한 이유

WAS를 통해 요청에 맞는 데이터를 DB에서 가져와 비즈니스 로직에 맞게 그때마다 결과를 만들어 제공하면서 자원을 효율적으로 사용할 수 있습니다.

사용자가 원하는 요청에 대한 결과물을 모두 미리 만들어 놓고 서비스하기에는 자원이 부족하기 때문에 웹 서버만으로는 무리가 있습니다. 따라서, WAS를 통해 요청이 들어올때마다 DB와 비즈니스 로직을 통해 결과물을 만들어 제공합니다.

5️⃣ WAS로 웹 서버 역할까지 처리할 수 있는 것 아닌가?

WAS는 DB 조회, 다양한 로직을 처리하는데 집중해야 합니다. 따라서 단순한 정직 컨텐츠는 웹 서버에게 맡겨 기능을 분리시켜 서버 부하를 방지해야 합니다. 만약 WAS가 정적 컨텐츠 요청까지 처리하면 부하가 커지고 동적 컨텐츠 처리가 지연되면서 수행 속도가 느려지게 되고 페이지 노출 시간이 늘어나는 문제가 발생할 수 있습니다.

6️⃣ 면접 대비

1. 웹 서버와 WAS에 대해 설명해주세요.

웹 서버는 웹 브라우저 클라이언트로부터 HTTP 요청을 받고 HTML, CSS 파일 같은 정적인 컨텐츠를 제공해주는 컴퓨터 프로그램입니다. 반면, WAS는 클라이언트가 DB 조회나 다양한 로직 처리를 요청할 경우 동적인 컨텐츠를 제공해주기 위한 어플리케이션 서버입니다. 정적인 컨텐츠에 대한 요청이 들어오면 웹 서버가 리소스를 제공해주고 동적인 컨텐츠에 대한 요청이 들어오면 웹 서버가 요청을 WAS에 보내고 WAS에서 처리한 결과를 클라이언트에 전달해줍니다. 웹 서버의 예시로는 Apache, Nginx 등이 있고 WAS는 TomCat, JBOss등이 있습니다.

2. 그렇다면 동적 컨텐츠를 제공하는 WAS만 사용하면 되는 것 아닌가요? 웹 서버가 필요한 이유에 대해 설명해주세요.

WAS에서 정적 컨텐츠 요청까지 처리하게 되면 부하가 커지고 동적 컨텐츠 처리가 지연되면서 수행 속도가 느려지게 되고 페이지 노출 시간이 늘어나는 문제가 있을 수 있습니다. 따라서 정적 컨텐츠는 웹 서버가 처리하여 기능을 분리시켜 서버 부하를 방지하는 것이 좋습니다.

출처 https://gyoogle.dev/blog/web-knowledge/Web%20Server%EC%99%80%20WAS%EC%9D%98%20%EC%B0%A8%EC%9D%B4.html

[slash] 모노레포로 된 라이브러리 뜯어보기

Tue, 16 May 2023 07:40:08 GMT

📕 slash의 모노레포 구성 살펴보기

📘 yarn berry

프로젝트 root에 .pnp.cjs가 있는 것을 보아 yarn berry를 사용하고 있는 것을 알 수 있었다. yarn berry는 모듈 설치시 node_modules가 아닌 .pnp.cjs 파일을 생성한다. .pnp.cjs 파일에는 모듈의 버젼과 저장된 위치, 참조하고 있는 모듈들이 기록된다. 또, slash는 .yarn/cache도 올라와 있는 것을 볼 수 있었다. .yarn/cache 파일을 깃으로 관리하게 되면 zero-install, 즉 의존성 설치 과정 없이 바로 사용할 수 있다. 프로젝트가 참조하고 있는 모듈들은 어떤 것인지 알고 싶어 .pnp.cjs 파일에서 dependencyTreeRoots를 찾아 보았다. 아 이런 것도 모듈로 만들어서 쓸 수 있구나 싶은 것들이 많았다. react, a11y, redirect 등 기존에 존재하던 것도, 존재하지 않는 것도 모듈을 만들어 사용하고 있었다.

📘 lerna

root에 lerna.json을 보고 lerna를 사용하여 만들었다는 것을 알았다. 원티드 프리온보딩 5월 모노레포 수업에서 turbo repo만 다루어서 lerna에 대해선 잘 몰랐는데 알고보니 turbo repo 보다 먼저 나왔다. 각각 뭐가 다른지 궁금해 비교표를 찾아보았다. 예상 외로 Nx가 가장 빠르고 확장 가능한 툴로 장점이 많았다. 이외에도 Nx와 Turborepo는 모두 캐싱 기능을 지원해서 빌드 측면에서 우수한 속도를 자랑하고, 의존성 그래프 시각화 기능을 통해 프로젝트의 구성 요소들이 서로 어떤 의존관계를 갖고있는 지 한눈에 파악이 가능하도록 해준다. 내 짧은 지식으로는 왜 slash가 lerna를 채택했는지 납득이 잘 가지 않았다. 추후 내 개인 프로젝트를 모노레포로 구성한다면, 나는 아마 yarn berry workspace를 쓰거나, Nx, Turbo repo 중에 선택하게 될 것 같다. 아니면lerna with Nx? (Nrwl이 lerna를 인수하여 Nx에 통합하고 개선하는 작업 중이며 lerna with Nx는 Turbo보다 5X 빠르다고 한다.)

출처: https://d2.naver.com/helloworld/7553804

📘 tsconfig

프로젝트 root에 tsconfig, eslint, prettier 설정 파일을 만들었다. tsconfig.build.json도 있었는데, exclude 설정을 통해 build에 제외시킬 파일을 미리 설정하여 효율적으로 build 하여 성능을 향상시킬 수 있다. root에 만들어둔 tsconfig 파일을 각 모듈에서 extends 하여 사용하고 있다.

📘 packages

packages 안에 모듈 파일을 단순 나열한 것이 아니라, react 관련 모듈과 아닌 것으로 나누어 분류했다. 훨씬 깔끔하고 찾아들어가기도 편해 보였다. 나중에 이 구조는 따라해봐야겠다. 비슷한 구조를 가지고 있는 라이브러리 중에 radix/ui도 있다. radix/ui는 packages> core + react로 구성했다.

📘 packages/react 모듈

이름만 봤을 땐 react 기본 훅을 한 번 더 감싼거라고 생각했는데, 그게 아니라 react 기본 훅을 사용한 커스텀 훅 모듈이었다. react 폴더 안에서도 또 components, hooks, utils로 나누어져 있다. hooks 안에는 디렉토리 구분 없이 useCallbackOne, useDebounce, useForceUpdate 같은 파일이 들어있었고, XX.en.md, XX.ko.md 파일로 커스텀 훅의 정의와 사용 방법을 적어놓았다. 설명을 다 적어두니 라이브러리 사용자 입장에선 엄청 편리하고 좋았다. 이것도 나중에 기억하고 써먹어야겠다. 그리고 각 파일의 테스트 코드도 있었다. 어떻게 테스트 코드를 짜야할지 막막할 때가 많았는데, 좋은 참고서가 될 것 같다. slash는 jest를 사용해 테스트 하고 있다.

평소 프로젝트를 만들 때, 스크린 리더 사용자에게만 보여주려고 할땐 a11y-hidden 스타일링을 적용해줬다. 괜찮은 방법에 대해서 많이 생각해봤는데 대안이 딱히 떠오르지 않아, 그냥 스타일을 줬었다. 그런데 토스는 ScreenReaderOnly이라는 훅을 만들어 사용하고 있었다. 이 방법이 가독성도 더 좋고 다른 설정도 추가할 수 있어 괜찮은 방법이었다. ScreenReaderOnly 이외에도 HiddenHeading이라는 스크린 리더 사용자가 헤더 기준으로 움직일 수 있게 숨겨진 헤딩 컴포넌트도 있다.

📘 packages/common 모듈

common에서 가장 눈에 띄고 궁금했던건 hangul이었다. 안에는 한글 처리에 대한 함수들이 있었다. josa 라는 이름의 어떤 단어의 적절한 조사를 붙여주는 함수, chosungIncludes라는 문자열에서 초성 일치 검색을 하는 함수 등이 있다. 발음 나는 그대로 파일 명을 작성한 것과 한글 처리에 대해 알아볼 수 있었다. 그 외에도 storage, validators 등 여러 가지 util이 많았다.

📘 CI/CD

slash는 CircleCI를 사용중이다. circleCI에 대해선 잘 모르는데 config.yml 파일을 들어가보니 github actions와 크게 달라보이진 않았다. config 파일에서 yarn install --immutable이 눈에 띄었는데, immutable 옵션을 사용하면 패키지 설치 과정에서 패키지의 버전이나 해시 값이 변경되지 않도록 보장한다고 한다.

[황준일]프레임워크 없이 만드는 SSR를 읽은 후기

Tue, 09 May 2023 04:12:35 GMT

[프레임워크 없이 만드는 SSR]을 읽고 SSR로 유명한 Next.js가 어떤 방식으로 SSR과 SSG를 하는지 알아보았다. SSG, SSR의 개념에서 build time이나 run time 등에 관한 개념이 나오므로 이 들의 개념을 먼저 알아보았다.

build time VS run time

build time이란?

build time, 혹은 build step은 어플리케이션 코드가 배포되기 위한 일련의 단계를 말한다. 어플리케이션을 빌드할 때, Next.js는 코드를 production에 최적화된 파일로 변환하여 서버에 배포하고 사용자가 사용할 수 있도록 만든다. 이 최적화된 파일에는 다음과 같은 것들이 포함된다.

정적으로 생성된 페이지의 HTML 파일들
server에서 렌더링될 페이지들의 JS code
client에서 interactive하게 만들어질 페이지들의 JS code
css file들

run time이란?

run time 혹은 request time은 어플리케이션이 빌드되고 배포된 후에, 사용자의 요청에 의해 어플리케이션이 실행되는 기간을 말한다.

번외) compile time이란?

compile time이란 프로그램을 컴파일하는 동안 소요되는 시간을 뜻한다. 여기서 compile이란 소스 코드를 기계어로 변환하는 과정을 말한다. (A언어 -> 컴파일 -> B언어로 변환하는 과정)

컴파일 시간은 개발자에게 중요한 요소 중 하나이다. 긴 컴파일 시간은 개발자의 생산성을 저하시킬 수 있고, 코드 변경 후 효괄르 바로 확인하기 어렵게 만들 수 있다. 따라서 개발자들은 컴파일 시간을 최적화하기 위해 다양한 방법을 사용하기도 한다.

참고) 컴파일 시간은 프로그램 실행 시간과는 별개의 개념이다. 컴파일 시간은 소스 코드를 변환하는 컴파일 과정에서 발생한 시간이고 실행 시간은 프로그램을 실행 시켜 실제로 동작하는 동안 소요되는 시간을 의미한다.

*참고)자바스크립트는 인터프리터 언어로 컴파일 언어가 아니다. * 자바스크립트는 컴파일 타임을 거치지 않는 인터프리터 언어이다. 하지만 v8엔진 같은 현대 자바스크립트 엔진은 일부 코드를 컴파일 하여 최적화 해준다. 따라서, 자바스크립트 자체는 인터프리터 언어이나, 자바스크립트 엔진은 컴파일을 해주고 있다.

번외) 런타임 에러와 컴파일 타임 에러

이 둘의 주요한 차이점은 오류가 발생하는 시점에 있다. 컴파일 타임과 런타임의 개념을 생각해 보면 이 둘의 차이점을 잘 알 수 있다. 컴파일러는 소스 코드를 분석하고 구문 오류, 타입 오류 같은 문법적으로 이상이 없는지 확인 하고 문제가 있다면 컴파일을 중단한다. 따라서 컴파일 타임 에러란, 문법적으로 이상이 없는지 검사하는 단계이다. 예를 들면 다음과 같은 경우를 들 수 있다.

compile time error

console.log(name}
// 문법에 맞지 않는 구문 사용

런타임 오류는 프로그램이 실행되는 도중에 발생하는 오류다. 런타임 오류는 컴파일 단계에서는 감지되지 않고 프로그램이 실행되는 동안 발생한다. 예를 들어, 예외 처리되지 않은 상황이나 메모리 오버플로우 등 다양한 상황에서 발생할 수 있다.

run time error
```
const a = 0;
const b = 1;
```

console.log(b / a); // 문법적으로 문제는 없으나 0으로 나눔


> 정리
- 컴파일 타임 에러 : 코드 컴파일 중 발생. 문법적 에러
- 런 타임 에러 : 프로그램 실행 중 발생. 실행 흐름이나 잘못된 동작 발생한 경우

## pre-rendering이란?
pre-rendering은 페이지를 미리 생성하여 정적인 HTML 파일로 변환하는 과정을 의미한다. pre-rendering은 서버 측에서 미리 페이지를 렌더링하여 정적 파일로 생성하거나, 빌드 시점에서 사전에 페이지를 렌더링하는 방식으로 이루어진다.

pre-rendering은 next.js와 같은 프레임워크에서 SSG(Static Site Generation) 또는 SSR(Server-side Rendering)과 함께 사용되는 기술이다. SSG에서는 **빌드 시점**에서 사전에 페이지를 렌더링하여 정적 HTML 파일을 생성하고, SSR에서는 요청 시점에 서버에서 페이지를 렌더링하여 동적으로 HTML을 생성한다.

## SSG란?
SSG는 사전에, build time에 정적인 HTML 파일을 생성하는 방식이다. SSG를 사용하면data를 사용하는 페이지 혹은 데이터를 사용하지 않은 페이지를 정적으로 생성할 수 있다. next.js에서는 데이터를 가져오기 위해 `getStaticProps` 또는 `getStaticPaths` 라는 메서드를 사용하여 빌드 시점에서 데이터를 가져오는 로직을 정의할 수 있다.

SSG는 사전에 페이지를 렌더링하여 정적인 HTML 파일로 생성한다. 이렇게 생성된 정적 파일은 서버에 배포되어 CDN(Content Delivery Network)을 통해 최종 사용자에게 제공된다. 정적 파일은 CDN의 캐싱 기능을 활용하여 성능을 향상시킬 수 있다.

## SSR이란?
페이지를 servier-side rendering 한다면, 페이지의 HTML은 매 요청마다 생성된다. 페이지를 server-side rendering 하기 위해서는 `getServerSideProps`라는 async 함수를 export 해야 한다. 매 요청마다 서버에서 이 함수를 호출할 것이다. 앞서 말한 `getStaticProps`와 얼핏 비슷한 것 같지만 `getServerSideProps`는 빌드 타임 대신에 매 요청시 호출된다는 것이 다르다.


## Next.js에서의 hydrate
- `packages/next/src/server/render.tsx`

```ts
//...
export async function renderToHTML(
    req: IncomingMessage,
    res: ServerResponse,
    pathname: string,
    query: NextParsedUrlQuery,
    renderOpts: RenderOpts,
): Promise {
  // ...

  const renderDocument = aysnc () => {
      // ...
    async function loadDocumentInitialProps(
        renderShell?: (_App: AppType, _Component: NextComponentType) => Promise
    ) {
           // ...
        const html = ReactDOMServer.renderToString(/*⭐️*/
            
                  
                      {renderPageTree(EnhancedApp, EnhancedComponent, {
                        ...props,
                          router,
                    })}
                  
              
        );
        return { html, head };
      }
  };
}

우선 서버에서 어떻게 HTML을 렌더링하고 있는지 살펴 보았다. /server/render.tsx에서 ReactDOMServer 메서드를 사용하여 렌더링하고 있었다. ReactDOMServer는 React component를 문자열로 변환하는 메서드를 제공한다. renderToString은 주어진 React 엘리먼트를 문자열로 변환해 완전히 렌더링된 HTML을 반환한다.

이어서 client쪽에선 어떻게 동작하는지 알아봤다.

packages/next/src/client/next.js

initialize({})
    .then(() => hydrate())
    .catch(console.error);

initialize()가 실행되고 hydrate()가 실행된다.

client/index.tsx

export async function initialize(opts: { webpackHMR?: any } = {}): Promise<{
assetPrefix: string;
}> {
  initialData = JSON.parse(document.getElementById('__NEXT_DATA__')!.textContent!);
    window.__NEXT_DATA__ = initialData;

    const prefix: string = initialData.assetPrefix || '';

    appElement = document.getElementById('__next__');
    return { assetPredix: prefix }; 
}

initialize()는 서버에서 렌더링한 HTML에서 __NEXT_DATA_를 id로 갖는 엘리먼트를 window 객체에 저장한다. 이 부분은 vanilla ssr에서 다음 부분과 일치한다.

/src/ssr.js
```
import { App } from "./components.js";
```

export const generateHTML = ({ todoItems }) => Todo List


      ${App(todoItems)}

;

```js

vanilla ssr에서 한 방법과 동일하게 Next.js에서도 서버에서 렌더링한 HTML을 window 객체에 담아 client에서도 사용할 수 있게 한 것을 알 수 있었다.

/clinet/index.tsx

export const hydrate(opts?: { beforeRender?: () => Promise }) {
  // ...
    const renderCtx: RenderRouteInfo = {
      App; CachedApp,
        initial: true,
        Component: CachedComponent,
        props: initialData.props,
        error: initialErr,
  };

    render(renderCtx):
}

hydrate()는 실행하려는 페이지의 에러를 validate하고 렌더링할 때 필요한 context를 render() 의 인자로 전달한다.

/clinet/index.tsx
```
let shouldHydrate: boolean = true;
```

function renderReactElement(domEl: HTMLElement, fn: (cb: () => void) => JSX.Element): void { // ... const reactEl = fn(shouldHydrate ? markHydrateComplete : markRenderComplete);

// ... if (shouldHydrate) { ReactDOM.hydrate(reactEl, domEl); shouldHydrate = false; } else { ReactDOM.render(reactEl, domEl); } }

```ts
ReactDOM.hydrate(element, container[, callback]);

그리고 ReactDOMServer로 렌더링된 HTML에 이벤트 리스터를 연결해준다. ReactDOM.hydrate()는 일반적으로 서버 사이드 렌더링(SSR)된 React 애플리케이션을 클라이언트에서 재사용할 때 사용된다. 서버에서 렌더링된 HTML과 클라이언트에서 생성된 React 컴포넌트를 일치시켜주는 역할을 한다. 즉, 서버에서 전달받은 HTML에 이미 렌더링된 상태가 포함되어 있으며, 클라이언트에서는 해당 HTML을 기반으로 컴포넌트를 초기화하여 이전에 렌더링된 상태를 유지한다.

이렇게 Next.js 내부에서 어떻게 hydrate 하는지 알아보았다. 블로그에서 vanilla js로 hydrate를 구현한 것과 크게 다르지 않게 구현되었다는 것을 알게 되었다.

[황준일]Vanilla Javascript로 React useState hook 만들기를 읽은 후기

Wed, 03 May 2023 09:27:43 GMT

컴포넌트가 여러 개일 때 useState 만들기

let currentStateKey = 0;
const states = [];

function useState(initialState) {
  const key = currentStateKey;

  if (states.length === currentStateKey) {
    states.push(initialState);
  }

  const state = states[key];

  const setState = newState => {
    states[key] = newState;
    render();
  };

  currentStateKey += 1;

  return [state, setState];
}

function Counter() {
  const [count, setCount] = useState(1);

  window.increment = () => setCount(count + 1);

  return `
    
      count: ${count}
      
    
  `;
}

function Cat() {
  const [cat, setCat] = useState('고양이');

  window.meow = () => setCat(cat + '야옹!');

  return `
    
      ${cat}
      
    
  `;
}

function render() {
  const $app = document.querySelector('#app');

  $app.innerHTML = `
    
      ${Counter()}
      ${Cat()}
    
  `;

  currentStateKey = 0;
}

render();

블로그 글에 생략된 코드가 있어 이해에 어려움이 있었다. 블로그 본문에는 useState 함수 내부에 const key = currentStateKey 선언부가 빠져있었다. 이 부분이 빠지게 되면 currentStateKey는 계속 0을 가리키게 되고 Cat에서 setState를 사용하더라도 Counter의 상태가 변경되게 된다.

하지만, useState 내부에 currentStateKey를 변수에 복사하게 되면, 다르게 동작한다. 현재 currentStateKey 값이 아닌, 컴포넌트가 처음 호출될 때 당시의 currentStateKey 값을 기억하고 사용하므로 정확하게 상태를 변경할 수 있다.

requestAnimationFrame은 태스크 큐에 들어가는가?

requestAnimationFrame은 setTimeout이나 setInterval과는 다르게 현재 디스플레이 환경에 맞춰 최적의 빈도로 실행한다. 내가 알고 있는 큐는 task queue와 micro task queue가 있는데, requestAnimationFrame은 어디에 속하기에 최적의 빈도로 실행되는 것일까.

일반적으로 이벤트 루프가 콜스택에 무엇을 넣어 처리할지 결정할때, microtask를 가장 먼저 처리한다고 한다. microtask로는 promise 등이 속한다. 또, setTimeout이나 setInterval 같은 timer 함수는 task queue에 속한다. microtask queue를 처리한 후에는 animation frame에 속하는 연산을 처리한다고 한다. 그러니까, queue는 microtasck queue, task queue, animation frame 이렇게 세 가지가 있는 것이다. 하지만 때로는 task queue에 있는 작업을 먼저 수행하기도 한다. 우선 순위는 animation frame이 먼저이지만, 초당 60프레임(혹은 주사율에 맞는)으로 보여주는 상황을 잘 충족하고 있다면 우선 순위를 task queue에게 양보하기도 한다.

[황준일]Vanilla Javascript로 상태 관리 시스템 만들기를 읽은 후기

Mon, 01 May 2023 09:35:39 GMT

observer pattern에 대한 이해

Obserber pattern은 객체의 상태 변화를 관찰하는 옵저버들의 목록을 객체에 등록해서 상태 변화가 발생할 때마다 메서드 등을 통해 객체가 직접 목록의 각 옵저버들에게 통지하도록 하는 디자인 패턴.

Object.defineProperty()

객체에 새로운 속성을 직접 정의하거나 이미 존재하는 속성을 수정한 후, 해당 객체를 반환한다.

Object.defineProperty(obj, attributeName, descriptor)

매개변수

obj : 속성을 정의할 객체
attributeName : 새로 정의하거나 수정하려는 속성의 이름 또는 Symbol
descriptor : 새로 정의하거나 수정하려는 속성에 접근하거나 추가하려는 동작

descriptor

descriptor는 데이터 서술자(data descriptors)와 접근자 서술사(access descriptors) 두 가지 형식을 취할 수 있다. 데이터 서술자는 값을 가지는 속성을 기술할 때 사용한다. 접근자 서술자는 getter-setter 함수를 한 쌍으로 가지는 속성을 기술할 때 사용한다. 서술자는 두 유형 중 하나여야 하며, 두 유형을 동시에 나타낼 순 없다. 데이터 서술자와 접근자 서술자는 모두 객체로, configurable, enumerable 이 두 가지 키를 선택적으로 가질 수 있다. configurable : 속성 값을 변경할 수 있고, 객체 삭제 가능하면 true. 기본 값은 false. enumerable : 객체 속성 열거 시 노출되면 true. 기본 값은 false.

데이터 서술자 데이터 서술자가 가질 수 있는 키는 다음과 같다.(선택적으로) value : 속성에 연관된 값. javascript 리터럴 값은 모두 사용할 수 있다. 기본 값은 undefined. writable : 할당 연산자로 속성의 값을 바꿀 수 있으면 true이다. 기본 값은 false.
접근자 서술자 접근자 서술자가 가질 수 있는 키는 다음과 같다.(선택적으로) get : 속성의 접근자로 사용할 함수. set : 속성의 설정자로 사용할 함수.

value또는 writable을 get 또는 set 키와 함께 가지고 있으면 오류 발생.

const obj = {};

Object.defineProperty(obj, 'a', {
    value: 37,
      writable: true,
      enumerable: true,
      configurable: true,
});
// 'a' 속성이 obj 객체에 존재하고 값은 37

const bValue = 38;

Object.defineProperty(obj, 'b', {
    get() {
        console.log(bValue);
          return bValue;
    },

      set(newValue) {
        bValue = newValue;
          console.log(bValue);
    },

      enumerable: true,
      configurable: true,
});
// 'b' 속성이 obj 객체에 존재하고 값은 38
// obj.b를 재정의 하지 않는 이상(set 하지 않는 이상)
// obj.b의 값은 항상 bValue와 동일함

vanilla javascript로 observer pattern 만들기

블로그의 코드를 잘게 뜯어서 이해해보자.

observable

const observable = storeObj => {
Object.keys(obj).forEach(key => {
  let _value = obj[key];
  const observers = new Set();

  Object.defineProperty(storeObj, key, {
    get () {
      if (currentObserver) observers.add(currentObserver);
      return _value;
    },

    set (value) {
      _value = value;
      observers.forEach(fn => fn());
    }
  })
})
return obj;
}

옵저버들의 목록을 저장할 객체 observers 생성한다. 중복으로 생성될 것을 방지하기 위해 Set 객체를 사용해준다.

const observable = storeObj => {
    // ...
  const observers = new Set();
    // ...
};

Object.definePropert의 getter를 사용하여 store 객체에 들어있는 상태에 접근할 수 있도록 한다.

const observable = storeObj => {
  //...
    Object.defineProperty(storeObj, key, {
      get() {
          return _value;
      },
  });
    // ...
};

옵저버 함수를 생성할 때마다 observers 객체에 등록해주는 로직이 반복되기 때문에 observers 객체에 옵저버 함수를 추가하는 로직을 getter에 넣는다.

let currnetObserver = null;

const observe = fn => { // currentObserver라는 변수로 현재 옵저브 함수를 등록 후 호출 currentObserver = fn; fn(); currentObserver = null; }

const observable = storeObj => { // ... Object.defineProperty(storeObj, key, { get() { if (currentObserver) observers.add(currentObserver);

          return stateValue;
    },
})
  // ...

};

`setter`에는 파라미터로 새로운 값을 받아 state를 변경해주고 `observers` 객체의 observer들을 모두 호출해 상태가 변경됐음을 알린다.
```js
//...
const observable = storeObj => {
      // ...
    get() {... },
    set(value) {
        _value = value;
         observers.forEach(fn => fn());
    },
};
//...

Flux Pattern

DOM에서 observer pattern을 붙여 간단한 store를 만들어 사용할 수 있다. 여기에 Flux pattern을 붙인다면 Redux나 Vuex가 된다.

Flux의 가장 큰 특징은 단방향 데이터 흐름이다.

Action 어떤 이벤트가 발생했을 때 그 이벤트에 대한 정보를 가진 액션 객체를 만들어 Dispatcher에게 전달한다.

Dispatcher 들어오는 Action 객체를 받아 데이터를 어떻게 바꿔줄 것인지, 어떤 행동을 할지 결정하는 곳.

Store 데이터, 즉 상태를 가지고 있는 곳.

View 우리가 알고 있는 보여주는 View의 역할.

데이터의 흐름은 다음과 같다.

Dispatcher => Store
Store => View
View => Action
Action => Dispatcher

Vuex

actions, mutations, state를 묶어서 store라고 보면 된다.
state를 변화시킬 수 있는 것은 오직 mutations다.
actions는 backend api를 가져온 다음에 mutations를 이용하여 데이터를 변경한다.
state가 변경되면 state를 사용 중인 컴포넌트를 업데이트한다.

Redux 만들기에서 frozenState를 반환하는 이유

src/core/Store.js
```
const createStore = (reducer) => {
  const state = observable(reducer());

  const frozenState = {};

    Object.keys(state).forEach(key => {
      Object.defineProperty(frozenState, key, {
          get: () => state[key],
      });
  });

    // ...생략

    const getState = () => frozenState;

    return { getState, dispatch };
};
```
실제 state를 반환하는 것이 아닌 frozen state를 만들어 반환하는 이유를 생각해보았다. observable이 반환한 결과인 state는 getter와 setter가 모두 등록된 객체이다. 이 객체를 반환하게 되면 dispatcher 뿐만 아니라 직접적으로 상태를 할당하여 변경할 수 있게 된다. 이를 방지하게 위해 getter만 설정된 frozen state를 반환해 dispatcher로만 상태를 변경할 수 있게 했다.

`Observable`과 `observer`를 사용할 때 고려해야 할 것들

1.최적화

상태가 변경되어 render를 해야한다. 그런데 변경된 상태가 이전 상태와 값이 똑같은 경우는 어떻게 해야할까?
```
state.a = 1;
state.a = 1;
state.a = 1;
state.a = 1;
```

이런 경우 다시 렌더링 되지 않도록 방어로직이 필요하다.

export const observable = obj => {
    Object.keys(obj).forEach(key => {
        let _value = obj[key];
          const observers = new Set();

          Object.defineProperty(obj, key, {
            get() {
              // ...
            },
              set(value) {
                  // 원시타입, 객체 타입으로 나누어 값이 같은지 검사.
                if (_value === value) return;
                  if (JSON.stringify(_value) ===JSON.stringify(value)) return;
                  //...
            }
        })
    })
};

그런데, Set, Map, WeekSet, WeekMap 같은 것들은 JSON.stringify로 변환되지 않는다. 이런 경우 추가적인 검사 로직이 필요하다.

동일한 Set의 리렌더링 방지하기

new Set()을 JSON.stringify로 변환하면 모든 Set은 {}로 변환되어 모두 동일하게 판별된다. 동일한 Set인지 판별하기 위해 함수를 따로 만들었다.

src/observer.js 동일한 set인지 확인하는 함수

const isSameSet = (set1, set2) => {
  if (!(set2 instanceof Set && set1 instanceof Set)) return false;

   if (set1.size !== set2.size) return false;
   const haveEverySameElement = [...set1].every(element => set2.has(element));

   if (haveEverySameElement) return true;
};

const observable = obj => {...};

observable 함수 내에 적용
```js
const observable = obj => {
    // ...
      return new Proxy(obj, {
    get(target, name) {
      //...
    },
    set(target, name, value) {
      if (target[name] === value) return true;

      if (JSON.stringify(target[name]) === JSON.stringify(value)) return true;

      if (isSameSet(target[name], value)) return true;

      target[name] = value;
      observerMap[name].forEach(fn => fn());

      return true;
    },
  });
};

이렇게 추가하니 앞에 있는

if (JSON.stringify(target[name]) === JSON.stringify(value)) return true;

배열, 객체 검사 로직에 항상 true로 걸리는 문제가 있어, 배열 객체 검사도 하나의 함수로 분리해주었다.

src/observer.js

const isSameObject = (object1, object2) => {
if (object1 instanceof Set || object2 instanceof Set) return false;

if (JSON.stringify(object1) === JSON.stringify(object2)) return true;
};

Map, WeakSet, WeakMap도 이와 같은 방식으로 방어 로직을 짤 수 있을 것 같다.



### 2. 연속으로 변경되는 상태

여러 가지 상태가 연속적으로 변경되는 경우에는 어떻게 해야 좋을까?

```js
state.a = 1;
state.b = 2;

단순히 console.log를 찍는 경우라면 상관없지만, 브라우저에 DOM으로 렌더링 되는 경우라면 이야기가 다르다. 이럴 때 requestAnimationFrame과 debounce를 이용하여 한 프레임에 한 번만 렌더링 되도록 만들어 주어야 한다.

requestAnimationFrame이란?

requestAnimationFrame은 setTimeout처럼 동작하지만 mozilla에 의해 개선된 function이다.

requestAnimationFrame은 다음과 같은 순서로 동작한다.

브라우저에게 수행하기를 원하는 애니메이션을 알린다.
다음 렌더링(다음 리페인트)가 진행되기 전에 해당 애니메이션을 업데이트 하는 함수를 호출하게 한다. requestAnimationFrame은 리렌더링 되기 전에 실행할 콜백함수를 인자로 받는다.

requestAnimationFrame() 함수는 보통 1초에 60회 호출되지만, 일반적으로 대부분의 브라우저에서는 W3C의 권장사항에 따라 호출 횟수가 디스플레이 주사율과 일치하게 된다.

쉽게 말해서, requestAnimationFrame은 1프레임에 1회 호출된다. 보통 1초에 60프레임이다.

setTimeout을 쓰지 않는 이유

그렇다면 익숙한 setTimeout을 사용하지 않는 이유는 뭘까. 비슷하게 동작하는데 requestAnimationFrame을 사용하는 이유에 대해서 알아 보았다.

setTimeout과 requestAnimationFrame의 가장 큰 차이점은 다음과 같다. 우선 setTimeout은 정확한 시간에 맞춰 콜백 함수를 호출하지 않는다.

const foo = () => console.log('foo');
const bar = () => console.log('bar');

setTimeout(foo, 0);
bar();

이 코드를 실행해보면 foo는 0초 후에 콘솔에 찍히지 않는다. 먼저 setTimeout 함수가 실행되면 콜백 함수 foo를 호출 스케줄링하고 종료되어 콜 스택에서 pop된다. 이후 bar가 호출 되어 콜 스택에 들어감과 동시에 콜백 함수 foo가 태스크 큐에 푸시되는 것이 동시에 일어난다. 이 예제는 지연 시간이 0이지만, 지연 시간이 4ms 이하인 경우 최소 지연 시간이 4ms가 지정된다. 따라서, delay를 0초로 설정했음에도 불구하고 항상 4ms의 지연 시간을 갖는다. 또한, 지연 시간이 지났음에도 현재 콜스택에 실행 중인 함수가 있다면 대기해야 한다.

setTimeout을 사용하지 않는 이유를 정리하면 다음과 같다.

정확한 시간에 호출되지 않을 수 있다.
setTimeout은 브라우저에서 일어나는 일을 고려하지 않는다. 페이지가 비활성화 되어 있을 때도 CPU를 독차지 하고 있을 수 있다.
setTimeout이 원할 때 화면을 업데이트 한다. 열악한 브라우저의 경우, repaint 하는 동안 setTimeout으로 인해 또 다시 repaint 될 수 있다.

반면, requestAnimationFrame은 미리 지정된 시간에 repaint 하는 것이 아니라, 브라우저가 다음 repaint 할 때 예약한다. 브라우저의 상황에 맞게 동작을 예약할 수 있는 것이다. 정리하면 requestAnimationFrame은

브라우저에서 애니메이션을 최적화할 수 있다.
비활성 탭의 애니메이션이 중지되므로 CPU를 보다 효율적으로 사용할 수 있다.
배터리 친화적이다.

Optimize Javascript execution에서는 자바스크립트 실행 최적화를 위해 아래와 같이 권장한다.

시각적 업데이트를 위해 setTimeout 또는 setInterval을 사용하지 말 것. 대신 항상 requestAnimationFrame을 사용할 것.
오래 실행되는 JavaScript를 기본 스레드에서 Web Workers로 이동할 것.
마이크로 작업을 사용하여 여러 프레임에 걸쳐 DOM을 변경할 것.
Chrome DevTools의 타임라인 및 JavaScript 프로파일러를 사용하여 JavaScript의 영향을 평가할 것.

적용하기

requestAnimationFrame과 debounce를 사용하여 직접 적용해보자.

어떻게 동작하는지 먼저 이해하기.

const debounceFrame = (callback) => {
  let currentCallback = -1;

    return () => {
        // 이전에 등록된 callback이 있다면 취소
      cancelAnimationFrame(currentCallback);
        // 1프레임 뒤에 실행되도록 한다.
        currentCallback = requestAnimationFrame(callback);
  };
};

debounceFrame(() => console.log(1)); debounceFrame(() => console.log(2)); debounceFrame(() => console.log(3)); debounceFrame(() => console.log(4)); debounceFrame(() => console.log(5)); // 이것만 실행된다.

여러 번 debounceFrame 함수가 실행된다는 건 여러 번의 상태가 변경되어 render 함수를 호출되는 경우라고 생각할 수 있다.
여러 번 render 함수가 호출될 때, 하나하나 반영되지 않고 제일 마지막으로 호출된 것만 실행하도록 해야 한다.

```js
const debounceFrame = (callback) => {
    let currentCallback = -1;

     return () => {
        cancelAnimationFrame(currentCallback);
          currentCallback = requestAnimationFrame(callback);
    };
};

const observe = fn => {
      // fn은 렌더를 일으키는 것과 관련있는 함수이다.
    currentObserver = debounceFrame(fn);
      fn();
      currentObserver = null;
};

이렇게 상태가 변경될 때마다 렌더링 되는 것이 아니라, 1프레임 당 한 번만 렌더링 되기 때문에 최적화에 도움이 된다.

3.Proxy

Proxy를 사용하는 것은 성능보다는 가독성에 더 도움이 된다. Proxy는 이전에 사용하던 Object.defineProperty를 대신하여 사용할 수 있다. Object.defineProperty는 IE를 지원하기 위해 사용하는 API이다. 최신 브라우저에서는 Proxy를 사용한다면 더 쉽게 Observable을 만들 수 있다.

const observable = obj => {

  const observerMap = {};

  return new Proxy(obj, {
    get (target, name) {
      observerMap[name] = observerMap[name] || new Set();
      if (currentObserver) observerMap[name].add(currentObserver)
      return target[name];
    },
    set (target, name, value) {
      if (target[name] === value) return true;
      if (JSON.stringify(target[name]) === JSON.stringify(value)) return true;
      target[name] = value;
      observerMap[name].forEach(fn => fn());
      return true;
    },
  });

}

Proxy란?

Object.defineProperty와 비슷하게 한 객체에 대한 기본 작업을 가로채고 재정의하는 프록시를 만들 수 있다. Proxy는 두 매개변수를 받는다.

target: 프록시할 원본 객체
handler: 가로채는 작업과 가로채는 작업을 재정의하는 방법을 정의하는 객체

사용 예시

const target = {
message1: "hello",
message2: "everyone"
};

const handler2 = { get(target, prop, receiver) { return "world"; } };

const proxy2 = new Proxy(target, handler2);

`target` 객체의 속성을 가로채는 `get()` 처리기를 사용했다.

- 결과
```js
console.log(proxy2.message1); // world
console.log(proxy2.message2); // world

[황준일]Vanilla Javascript로 웹 컴포넌트 만들기를 읽은 후기

Thu, 13 Apr 2023 13:22:56 GMT

render VS mounted

컴포넌트를 분할하면서, 원래 render 메서드 하나로만 관리하다가 render 메서드와 mounted 메서드를 분리했다. render와 mounted를 분리한 이유가 뭘까? render 안에서 mounted가 호출된다. 만약 특정 돔에 하위 컴포넌트를 추가해야 할 때 특정 돔이 만들어지지 않았을 수 있기 때문에

처럼 미리 존재해야할 돔을 미리 렌더링 되어야 한다. 이 과정을 render에서 하고 나중에 추가돼야할 컴포넌트는 mounted에서 렌더링 된다.

this

this binding이 필요한 이유

src/App.js

class App extends Component {
  mounted() {
    new Items($items, {
      /*
      filteredItems,
      toggleItem: toggleItem.bind(this),
      */![](https://velog.velcdn.com/images/kim-jaemin420/post/b680d4f5-6fd4-4d50-a70e-edc8d982c752/image.png)

      deleteItem: deleteItem.bind(this),

    })
  }

  deleteItem(seq) {
    const items = [...this.state.items];

    items.splice(items.findIndex(item => item.seq === seq), 1);
    this.setState({ items });
  }
}

export default App;

여기서 deleteItem, toggleItem 메서드에 this를 바인딩해주는 이유가 뭘까?

- `src/components/Items.js`
```js
class Items {
    setEvent() {
      const { deleteItem, toggleItem } = this.props;

      this.addEvent('click', '.deleteBtn', ({target}) => {
        deleteItem(Number(target.closest('[data-seq]').dataset.seq));
      });
    }
}

export default Items;

Items 컴포넌트에서 this.props.deleteItem으로 접근 가능하다. 그리고 deleteItems 안에서는 this.state.items를 참조하고 있다. this는 함수를 호출하는 형태에 따라 바인딩이 달라진다.

호출 방식에 따른 this

일반 함수처럼 호출: window
메소드로 호출: 메서드를 호출한 객체
생성자 함수 호출 : 생성자 함수가 (미래에) 생성할 인스턴스

처음 글을 읽을때, this binding을 왜 꼭 해줘야하는지 이해가 안돼서 binding 해주지 않고 this.props로 넘겨줘봤다.

이때, Items에서 호출하게 되면, deleteItem를 일반 함수 호출하듯이 호출했으므로 deleteItem 메서드 안에서 참조하는 this는 window 객체를 가리키고 있을거라고 예상했다.

src/App.js

class App {
  mounted() {
    new Items($items, {
      deleteItem,
      //...
    })
  }

  deleteItem() {
    // this???
  }
}

export defualt App

```js
class Items {
    setEvent() {
      const { deleteItem, toggleItem } = this.props;

      this.addEvent('click', '.deleteBtn', ({target}) => {
        deleteItem(Number(target.closest('[data-seq]').dataset.seq));
      });
    }
}

그러나 실제로 window 객체가 찍히는게 아니라 undefined가 찍히는 것을 볼 수 있었다.

strict mode일 경우 일반 함수로 호출 시 this는 undefined가 바인딩 되는데, 따로 strict mode를 설정하지 않았는데 undefined가 되는게 이해가 가지 않았다. 알고 보니 module을 사용하면 자동으로 strict mode가 되기 때문에 this가 undefined로 잡히는 것을 알 수 있었다.

그렇다면, Items에서 일반 함수가 아닌 this.props.deleteItem()으로 호출했을때 deleteItem 메서드 안에서의 this는 어떤 것을 가리키게 될까? 이 경우에 this는 당연히 this.props를 가리키게 된다.

deleteItem 메서드안에서 필요한 this는 this.props객체가 아니라 App 생성자 함수가 만들어낸 인스턴스 객체이다. 이렇게 메서드를 어떻게 호출되냐에 따라 this가 변경되어 혼동을 준다. 또 다른 컴포넌트에서 deleteItem 메서드를 호출시켜 App의 상태를 변경시키므로 this binding 없이는 App의 상태를 변경할 방법이 없다. 따라서 꼭 binding을 해줘야 한다는 것을 알 수 있었다.

this binding을 하고 메서드를 내 맘대로 호출하면?

this binding을 해주어도 함수를 내 마음대로 호출하면 어떻게 될지 궁금해졌다.

src/App.js

class App {
  mounted() {
    new Items($items, {
      deleteItem: deleteItem.bind(this),
      //...
    })
  }

  deleteItem() {...}
}

export defualt App

- `src/components/Items.js`
```js
class Items {
    setEvent() {
      this.addEvent('click', '.deleteBtn', ({target}) => {
        this.props.deleteItem(Number(target.closest('[data-seq]').dataset.seq));
      });
    }
}

this.props.deleteItem()으로 호출했음에도 불구하고 bind 해준 this가 찍히는 걸 알 수 있다.

[원티드] 프론트엔드 프리온보딩 1월 후기

Thu, 13 Apr 2023 13:22:33 GMT

프리온보딩을 수강하며 알게된 것들

emotion을 써보자

이번 프로젝트에는 emotion을 사용했다. 그동안 styled-component, tailwind, scss 등을 사용해봤는데 emotion을 사용해본적은 없어서 경험해보고 싶었기도 하고 emotion이 styled-component보다 빠르기도 해서 선택하게 되었다.

emotion-css-mode의 렌더링 속도가 4위를 차지했다. 물론 inline style 방식만 월등히 빠르지만 그 이외 것도 styled-component보다 앞섰다. 퍼포먼스 면에서도 아주 미세하지만 emotion이 앞선다.

렌더링 속도 표에서 놀라웠던건, react with inline styles의 속도가 아주 빠르다는 것이었다. react를 처음 배웠을때 inline style을 사용하면 렌더링될때마다 style 객체를 다시 계산하여 성능 이슈가 생기기 때문에 inline style을 지양하라고 배웠다. 그런데 속도 비교를 보니, 리렌더 속도나 mount time 모두 아주 빨랐다. 이제 생각해보니 styled 함수를 호출하고 객체를 생성하고 import, export 하는 시간보다는 단순 객체를 계산하는 시간이 더 빠를 것 같다는 생각이 들었다.

stitches 발견! style 라이브러리를 찾다가 stitches를 알게 되었다. 사용방법은 Emotion이나 styled-component와 크게 다르지 않은데 속도가 비교가 안될만큼 빨랐다. 다음 프로젝트때 한 번 사용해보면서 알아보는 것도 좋을 것 같다.

출처:

react query 적용기

react query를 써봤다고 할 수 있나

개발 동아리 활동을 하면서 react query를 한 번 사용해 본 적이 있다. 깊게 알아보고 사용한건 아니었고, 요즘 react query를 많이 사용한다, 캐싱을 알아서 해주기 때문에 편리하다 등의 장점으로 가볍게 사용해봤다. 1월 프리온보딩 수업을 듣고 내가 얼마나 가볍게 알고 사용하는지, 또 사실 react query를 써본게 아니라는 걸 알게 되었다.

왜 react query인가?

프론트엔드 개발을 할 때 항상 고민되는 것 중 하나가 state이다. 어떻게 해야 상태관리를 잘할 수 있는가를 늘 고민하고 상태 관리를 하기 위해 상태 관리 매니저를 많이 사용한다. 그 중 가장 유명한 상태 관리 매니저는 redux이다. 리덕스를 통해 복잡한 상태를 하나의 스토어로 관리할 수 있다. 그런데, 서버로부터 받은 데이터를 리덕스 스토어에 저장하는 것이 리덕스에서 추구하는 진실한 정보의 원천(Single source of truth)에 부합하는가를 고민해볼 필요가 있다. 기존에 api 요청을 통해 서버에서 데이터를 가져오면 진실한 정보의 원천인 redux store에 넣어 두고, 그 데이터를 업데이트 하며 사용했다. 그러나 store는 진짜 진실한 정보의 원천일까?

그럴 수도 있고 그렇지 않을 수 있다. 하지만 대부분의 경우 서버 데이터가 서버를 떠나 store에 저장되는 이상 store는 원본이 아니라 서버 데이터의 복사본일 뿐이다. 우리는 서버로부터 받아온 데이터의 최신 여부를 따지는 매커니즘인 HTTP 캐시를 알고 있다. 이 개념을 비동기 호출하는 여러 데이터들에서도 적용해볼 수 있다. react query, swr 등의 캐시 패러다임의 라이브러리가 stale-while-revalidate를 채택하고 있다.

왜 react query가 필요한지 정리하면 다음과 같다.

서버로부터 데이터를 받아 store에 저장하게 되면 저장된 데이터는 dispatch된 시점에 캡쳐(capture)된 데이터가 저장된다.
호출된 시점에서 서버 데이터와 클라이언트에 저장된 데이터는 같겠지만 다시 호출되기 전까지는 같다는 것을 보장할 수 없다. 따라서, 진실한 정보의 원천에 위배되며 리덕스는 데이터 캐싱에 적합하지 않다.데이터가 필요할때마다 api를 호출하고 그 비용을 줄일 수 있는 react query를 사용하면 진실한 정보의 원천에 보다 가까워질 수 있다.

query key는 배열로

query key는 문자열, 배열 모두 가능했으나 React query V4 이후 query key는 배열만 가능하다. 문자열이 되더라도 배열로 쓰는 것이 휴먼 에러도 줄이고 유지보수면에서도 좋으니 배열을 사용하자.

query key 배열 구조

배열로 query key를 생성할때 가장 일반적인 것부터 점차 가장 구체적인 것으로 나열한다.

['todos', 'list', { filters: 'all' }]
['todos', 'list', { filters: 'done' }]
['todos', 'detail', 1]
['todos', 'detail', 2]

이 구조를 사용하면 하나의 특정 목록을 무효화하거나 todos와 관련있는 모든 query key를 무효화할 수 있다. 그런데, 이렇게 일일이 배열을 직접 넣어주는 방법도 마찬가지로 유지보수를 어렵게 만든다. 그렇기 때문에 기능 하나당 하나의 query key factory를 만들어 쓰는 것이 좋다.

const todoKeys = {
  all: ['todos'] as const,
  lists: () => [...todoKeys.all, 'list'] as const,
  list: (filters: string) => [...todoKeys.lists(), { filters }] as const,
  details: () => [...todoKeys.all, 'detail'] as const,
  detail: (id: number) => [...todoKeys.details(), id] as const,
}

todoKeys라는 하나의 객체 안에 각각의 key가 등록되어 있기 때문에 여전히 독립적으로 접근이 가능하다.

query key 파일을 어디에 위치시킬까?

query key를 어디에 위치해야 할지 고민이 많았다. 처음엔 hooks/queries 안에 넣으려다가 여러 가지 커스텀 훅 사이에 query 파일이 들어있으면 다른 사람이 봤을 때 더 찾기 어려울 것 같은 느낌이 들어 고민 끝에 consts/query.ts 파일을 만들어 그 안에 TODOS_KEYS 객체를 생성했다.

📦hooks
 ┣ 📂queries
 ┃ ┣ 📜index.ts
 ┃ ┣ 📜...todo 관련 커스텀훅
 ┣ 📜index.ts
 ┣ 📜...일반적인 커스텀훅

그런데, Kent C.Dodds의 코로케이션을 통한 유지 관리 가능성을 읽고나니 consts/query.ts에 생성한게 좋은 생각은 아니었던 것 같다. 일단 기능에 따라 query key 파일의 구분 없이 하나의 query.ts라고 명시한 것은 유지보수적으로 좋지 않다. 또, consts는 전역적으로 재사용성이 있는 변수를 담아야 하는데 query key는 query custom hook에서만 사용되기 때문에 디렉토리 위치도 맞지 않았다. Tkdodo님의 블로그에서 feature 디렉토리에 각각의 queries.ts 파일을 만들어 관리하는 것을 추천했으나, 지금 내 디렉토리 구조가 다음처럼 분산되어 있어 그 방법은 적용하기 힘들었다.

- src
  - features
    - Profile
      - index.tsx
      - queries.ts
    - Todos
      - index.tsx
      - queries.ts

<현재 내 디렉토리 구조>

📦src
 ┣ 📂components
 ┣ 📂consts
 ┣ 📂hooks
 ┣ 📂pages
 ┣ 📂...생략

결국 고민 끝에 hooks/queries 하위에 todos라는 디렉토리를 만들고 그 안에 todo query key 파일과 다른 todo 관련 커스텀 훅을 넣는 것이 제일 낫다고 결론내렸다.

invalidateQueries를 쓰지 않았다면 react query를 써봤다고 하지말자.

useMutation을 사용하면 데이터가 변경된다. 이때 따로 refetch하는 함수를 호출할 필요가 없이, 호출할 대상이 stale하다고 알려주면 된다.(ex. 캐시에게 모진 말 하기 : 너 상했어..) 쿼리의 상태는 쿼리 키를 중심으로 관리되는데, 이 쿼리 키는 Mutation에서 사용할 수 있다.

function useUpdateTodo() {
  return useMutation({
    mutationFn: updateTodo,
    onSuccess: () => {
       queryClient.invalidateQueries({ queryKey: TODO_KEYS.list() });
    },
  });
}

mutation 이후에 어떤 쿼리 키가 상했는지 알려주어야 한다.

invalidateQueries VS refetch

invalidateQueries로 상했다고(stale) 알려주는 것과 그냥 refetch를 호출하는 것이 뭐가 다른지 궁금해져서 찾아봤다. invalidation은 더 "똑똑한" refetching이다. refetch는 쿼리에 대한 observer가 없더라도 항상 refetch를 실행할 것이다. 반면에, invalidation은 그냥 다음 번에 observer가 마운트 될 때 refetch할 수 있게 상했다고만 표시하는 것이다. 먄약 퀴리에 active된 observer가 있다면 이 둘의 차이는 없다.

출처: https://github.com/TanStack/query/discussions/2468

react query에서 optimistic updates 사용해보기

optimistic updates란?

optimistic update란 직역하면 낙관적 업데이트이다. 보통 프론트에서 서버로 POST 요청을 하고 서버에서 내려준 response를 프론트가 받아 UI를 업데이트 한다. 반면 optimistic update는 이와 다르게 접근한다. 프론트가 보낸 요청을 "성공했다치고" 서버에서 응답을 받기 전에 UI를 미리 업데이트 한다. 사람들은 눈을 깜빡이는 것처럼 반응하는 인터페이스를 선호한다. 과거에는 버튼이 클릭됐을때 비활성화 하여 이를 충족시켰으나, 요소를 비활성화 하는 것은 사용자에게 통제할 수 없는 수동적 기다림을 의미하므로 optimistic UI는 비활성화 상태를 통째로 건너뛰어 기다림 대신에 낙관적인 결과로 소통한다.

처음엔 응답을 받기 전에 UI를 미리 업데이트 하는게 오히려 유저에게 혼란을 줄 것이라고 생각했다. 하지만, API가 안정적이고 예측가능한 수준이며, 프론트엔드가 UI에 적절한 액션을 취하는 한, 유저가 처음에 취한 행동에 대한 응답으로 오류가 뜰 확률은 상당히 낮다고 한다. "Denys Mishunov"에 의하면 오류 상황은 1-3%에 머무른다고 한다. 97-99%의 성공 응답을 확신할 수 있다면, optimistic updates가 유저에게 혼란을 줄 확률은 적을 것이다.

optimistic updates는 즉각적인 사용자 피드백이 필요한 작은 mutations에서 매우 효과적이다.

react query로 optimistic updates 구현해보기

const usePostTodo = () => {
  const queryClient = useQueryClient();

  return useMutation(createTodo, {
    onMutate: async (newTodo) => {
      await queryClient.cancelQueries({ queryKey: TODO_KEYS.lists() });

      const previousTodos = queryClient.getQueryData(TODO_KEYS.lists());

      await queryClient.setQueryData>(
        TODO_KEYS.lists(),
        (oldTodo) => oldTodo && [...oldTodo, newTodo]
      );

      return previousTodos;
    },

    onError: (error, newTodo, previoustTodos) => {
      queryClient.setQueryData(TODO_KEYS.lists(), previoustTodos);
    },

    onSettled: () => {
      queryClient.invalidateQueries(TODO_KEYS.lists());
    },
  });
};

onMutate: useMutation의 query 함수인 createTodo가 실행되기 전에 호출된다.
cancelQueries: 혹시 발생할지도 모르는 refetch를 취소하여 데이터가 꼬이지 않게 한다.
실패했을때 보여줄 이전 데이터를 미리 저장해둔다.
setQueryData: 서버 응답이 오기 전에 UI를 미리 업데이트 해둔다.
에러 발생하면 이전 데이터로 다시 setQueryData 해준다.
OnSettled에서 실패했든 성공했든 상했다고 알려 서버 데이터와 동기화해준다.

optimistic updates 아무때나 쓰지말자.

react query 공식 홈페이지를 보고 todo app에서 새 todo를 등록할때 optimistic updates를 적용했다. 적용후 에러 상황을 만들어 롤백되는 것을 보니 새로운 todo가 등록됐다 바로 사라졌다. optimistic updates를 쓰면 더 나은 사용자 경험을 제공한다 했는데, 이 경우는 전혀 그런 것 같지 않았다. optimistic updates는 언제 써야 적절한 것인가를 고민해보게 되었다.

optimistic updates는 다음과 같은 경우에 사용해야 한다.

성공 또는 실패 응답 이상을 기대할 수 없는 이분법적인 요소들에 적용한다.(좋아요, 별표 또는 저장된 검색에서)
optimistic updates를 적용하는 곳은 인터페이스의 다른 부분에 연결되어서는 안된다. : 여러 테이블에 데이터를 함께 저장하는 경우, 하나라도 실패하면 전체 API가 실패로 처리되기 때문에 실패 확률이 높다.
API 응답 시간은 매우 빨라야 한다.
API 성공률은 100%에 가까워야 한다.

때때로 사용자는 지연을 예상한다 만약, 글을 비공개에서 공개로 전환하는 작업이나 결제 또는 예약을 하는 경우를 생각해보자. 단순한 버튼을 누르는 것일지라도 사용자는 중요한 작업이라고 생각하기 때문에 진행이 지연될 것을 예상한다. 글을 비공개 하는 즉시 작업이 이루어지거나 결제 버튼을 누르는 즉시 결제가 완료되는 즉각적인 피드백은 오히려 사용자를 불신하게 만든다. 이러한 작업들에는 optimistic updates 사용을 지양하자.

출처:

typescript를 써보자

객체의 key와 value를 타입으로 변환하기

어떤 변수의 타입이 string이 아닌 특정한 문자열로 타입을 좁히려고 하니, const 상수를 새로 만들고 그 상수로 객체를 참초하여 value를 사용해야 했다. 그때 객체의 key 혹은 value에 대한 타입을 알아야 했다. 타입스크립트의 keyof 와 typeof 를 사용하여 객체에 대한 타입을 알아낼 수 있었다.

typeof 연산자 : 객체 자체를 타입으로 변환

typeof : 객체 데이터를 객체 타입으로 변환해주는 연산자

변수로 선언한 객체는 당연히 타입으로 사용할 수 없다. 만약 선언한 객체에 들어있는 key, value 구조를 그대로 가져와 독립된 타입으로 사용하고 싶다면 객체 이름 앞에 typeof 키워드를 명시해주면 된다.

const person1 = {
    name: 'jaemin',
    age: 28,
    job: 'unemployed',
};

// person1 객체를 타입으로 변환
type Person = typeof person1;

const person2: Person = {
    name: 'calmdown man',
      age: 40,
      job: 'youtuber',
};

함수 또는 클래스도 typeof 연산자를 사용하여 타입으로 변환할 수 있다.

keyof 연산자 : 객체 타입에서 key를 타입으로 변환

keyof : 객체 타입에서 key들만 뽑아 유니온 타입으로 만들어주는 연산자

type Person {
    name: string;
    age: number;
    married: boolean;
}

type PersonKey = keyof Person;
// type PersonKey = name | age | married

const name: PersonKey = 'name';
const age: PersonKey = 'age';
const married: PersonKey = 'married';

만약 특정 객체의 key들만 뽑아오고 싶다면 아래와 같이 사용할 수 있다.

const person = {
    name: 'jaemin',
      age: 28,
      married: false,
};

type Person = keyof typeof person;
// type Person = "name" | "age" | "married" 

const name: Person = 'name';
const age: Person = 'age';

객체 타입에서 value를 타입으로 변환

다음은 객체에서 value 값들만 뽑아 유니온 타입으로 만들어주는 방법이다.

const person = {
    name: 'jaemin',
      age: 28,
      married: false,
};

type PersonValue = typeof person[keyof typeof person];
// type PersonValue = string | number | boolean

person 객체 value들의 type이 아니라 리터럴 값을 가지고 싶다면 아래와 같이 사용할 수 있다.

const person = {
    name: 'jaemin',
      age: 28,
      married: false,
} as const;

type PersonValue = typeof person[keyof typeof person];
// type PersonValue = false | "jaemin" | 28

typescript에서 d.ts 파일 사용하기

객체의 value의 type을 변환할때 매번 typeof obj[keyof typeof obj] 이렇게 적는건 불편하기도 하고 가독성이 떨어지기도 한다. 재사용할 수 있게 utils 파일에 넣으려고 하다가 typescript에서 제공하는 d.ts 파일에 대해 알게 되었다.

ambient module: import export 없이 전역에서 가져다 쓸 수 있는 기능

axios instance 만들어 쓰기

axios.create

모든 요청에 포함되는 공통된 config 설정이 있기 때문에 공통 config가 들어가있는 axios instance를 만들어 사용하는게 좋다고 생각했다.

const axiosInstance = axios.create({
    baseURL: import.meta.env.VITE_BASE_URL,
    timeout: 10000,
    headers: { 'Content-Type': 'application/json' },
  });

axios의 timeout 값이 필요한 이유는 서버의 네트워크에 문제가 생겨 서버 통신이 지연될때 timeout 값으로 설정한 시간이 지나면 서버와의 연결을 즉시 중단한다. timeout 값을 5000(5초)로 설정했다면 5초가 지나도 서버로부터 정상적인 응답을 받지 못하는 경우 네트워크가 중단됩니다. 만약 timeout을 설정하지 않았다면 클라이언트는 계속 서버에 연결을 유지하고 응답을 기다리게 된다. 이때 방문자가 많을 경우, 즉 서버에 요청이 많은 상태라면 과부하 등의 이유로 서버가 다운되는 등 더 큰 문제가 발생할 수 있다. 따라서 적절한 timeout 시간을 설정하여 에러 메시지를 보여주는 등의 설정이 필요하다. timeout 값이 너무 짧으면 방문자가 접속하지 못하는 문제가 있을 수 있다. 대부분 5초에서 10초 사이의 값을 사용하지만 서버 환경 및 네트워크 상황을 고려하여 설정할 필요가 있다.

여기까지 하고 난 후 axios.create가 무엇을 반환하는지 궁금해졌다. return 값을 찍어봐도 함수가 찍혀 자세히 알기가 어려워 axios 코드를 까봤다.

axios interceptors

axios.interceptors.request

local storage에 token이 있다면 headers에 포함하여 보내야 했다. 이것도 매 요청마다 확인하는 로직이 반복할테니 interceptos.request에 token을 검사하는 로직을 넣어 반복을 줄이고 관심사를 분리하기로 했다.

axiosInstance.interceptors.request.use(
    (config) => {
      const token = getLocalStorage(ACCESS_TOKEN);

      if (config.headers) (config.headers as AxiosHeaders).set('Authorization', token);

      return config;
    },
    (error) => Promise.reject(error)
  );

axios.interceptors.response

서버에서 응답으로 내려주는 데이터가 다음과 같아서 렌더링에 필요한 데이터를 사용하려면 response.data.data로 접근해야 했다.

{
  config: ...,
  data: { data: Array(7) },
  headers: ...,
  request: ...,
  status: ...,
  ...
}

react query를 도입하기 전에는 대부분의 요청의 then절에서 response.data.data를 적어주었으나, react query를 사용하고 커스텀 훅에서 .data.data로 접근하려니 가독성이 떨어진다고 생각해, interceptors.response에서 데이터를 가공하기로 했다.

src/api/base.ts

const createApiMethod =
(axiosInstance: AxiosInstance, method: Method) =>
(config: AxiosRequestConfig): Promise => {
  axiosInstance.interceptors.response.use((response) => {
    return response.data;
  });

  return axiosInstance({
    ...config,
    method,
  });
};

const api = { get: createApiMethod(axiosInstance, HTTP_METHODS.GET), post: createApiMethod(axiosInstance, HTTP_METHODS.POST), patch: createApiMethod(axiosInstance, HTTP_METHODS.PATCH), put: createApiMethod(axiosInstance, HTTP_METHODS.PUT), delete: createApiMethod(axiosInstance, HTTP_METHODS.DELETE), };

createApiMethod라는 함수 내부에서 interceptors.response 로직을 넣어주었고 각 메서드마다 createApiMethod를 호출하는 구조로 작성했다. 내가 예상한건 axios instance에 interceptors.response가 한 번만 등록되는 것이었는데 실제로 그렇게 동작하지 않았다. 처음엔 잘 동작하다가 그 이후로 response에 response.data 들어오거나 undefined가 돌어왔다. 
axios를 뜯어보니 responseInterceptorChain 배열에 interceptor가 push되고 promise chaining으로 연산됐다. 지금 코드를 보면 get, post, patch, ..등을 호출될때마다 interceptors.response.use를 호출하고 chain 배열에 push 된다. 첫 번째 파라미터인 (response) => response.data는 fulfilled 될때 호출되고 있었기 때문에 response에 undefined가 들어오는 오류가 있었던 것이다.
```ts
// pseudo code
chain = [
  // ...생략,
  onResponseFulfilled1, onResponseRejected1,
  onResponseFulfilled2, onResponseRejected2
];

promise = Promise.resolve(config)
             // ... 생략
             .then(onResponseFulfilled1, onResponseRejected1)
             .then(onResponseFulfilled2, onResponseRejected2)

그렇다면 이제 호출될때마다 interceptor가 등록되는게 아니라 처음 인스턴스가 생성될때 한 번만 등록되도록 해야 했다.

src/apis/base.ts

const axiosInstance = axios.create({
  baseURL: import.meta.env.VITE_BASE_URL,
  timeout: 10000,
  headers: { 'Content-Type': 'application/json' },
});

axiosInstance.interceptors.request.use( (config) => { const token = getLocalStorage(ACCESS_TOKEN);

  if (config.headers) (config.headers as AxiosHeaders).set('Authorization', token);

  return config;
},
(error) => Promise.reject(error)

);

axiosInstance.interceptors.response.use( (response: AxiosResponse) => { console.log(response);

  return response.data;
},
(error) => Promise.reject(error)

);

// ... 이외 다른 함수 생략

base 파일 내부에 instance create 함수와 interceptor들을 선언했다. 이렇게 하면 문제를 해결할 수 있지만 전역에 드러나는게 신경쓰여 즉시실행함수로 감싸주었다.

```ts
const axiosInstanceWithInterceptors = (() => {
  const axiosInstance = axios.create({
    baseURL: import.meta.env.VITE_BASE_URL,
    timeout: 10000,
    headers: { 'Content-Type': 'application/json' },
  });

  axiosInstance.interceptors.request.use(
    (config) => {
      const token = getLocalStorage(ACCESS_TOKEN);

      if (config.headers) (config.headers as AxiosHeaders).set('Authorization', token);

      return config;
    },
    (error) => Promise.reject(error)
  );

  axiosInstance.interceptors.response.use(
    (response: AxiosResponse) => {
      console.log(response);

      return response.data;
    },
    (error) => Promise.reject(error)
  );

  return axiosInstance;
})();

axios custom instance의 request, response type

typescript 숙련도도 높지 않고 axios custom instance를 직접 만들어 사용한 적도 없다보니 요청들의 request, response 타입을 어디서 잡아줘야 할지 막막했다. response들의 type이 unknown 으로 잡히다보니 response.data로 참조할 수 없었다. then절에서 response 타입을 일일이 명시해주는 방법이 먼저 떠올랐지만 내가 봐도 가독성이 떨어졌고 기존 axios instance 처럼 타입을 명시해줬으면 했다.

axios.get(url)

고생 끝에 알아낸 방법... 내가 만들어낸 요청 메서드들은 createApiMethod를 호출하여 만들어진다. 이 함수 내부에서 제네릭을 사용하면 메서들르 호출할때 전달한 타입이 request, response에 전달될 수 있었다.

src/apis/base.ts

const createApiMethod =
(axiosInstance: AxiosInstance, method: Method) =>
//  제네릭으로 전달 (T: request type, K: response type)
(config: AxiosRequestConfig): Promise => {
  return axiosInstance({
    ...config,
    method,
  });
};

const api = { get: createApiMethod(instance, HTTP_METHODS.GET), post: createApiMethod(instance, HTTP_METHODS.POST), patch: createApiMethod(instance, HTTP_METHODS.PATCH), put: createApiMethod(instance, HTTP_METHODS.PUT), delete: createApiMethod(instance, HTTP_METHODS.DELETE), };

``` 제네릭으로 전달할 수 있다는걸 몰라 며칠 고민했다. 제네릭 공부 좀 할걸...

소감. 찐후기

개발을 배우고 수도 없이 만들어봤던 todo였지만 이번 todo는 만들면서 다양한 고민을 해보게 되었다. 그동안 혼자 하는 프로젝트들은 큰 고민없이 내 맘대로 짰었는데 이번에는 혼자 하는 프로젝트지만 네이밍, 구조, 가독성에 대해 고민해가며 만들었다. 물론 혼자 하다보니 고민하는 시간이 무한정 길어지기도 해서 다음 프로젝트 때는 기한에 맞춰 완성하는 것을 연습해볼 필요가 있다고 느꼈다. 이번에 가장 인상 깊었던 경험은 처음으로 라이브러리 코드도 열어보았다는 것이다. 많은 선배님들이 라이브러리 까보면서 공부해라 라고 하셨을땐 코드를 보기만 해도 어렵고 이해도 안가서 나같은 짜바리는 아직 그럴 단계가 못된다고 생각하고 넘겼다. 그런데, 막연히 axios create나 interceptors가 어떻게 돌아가는지 궁금해서 코드를 열어보니 생각보다 어렵지 않았고 내 코드에서 어떤 결과물이 반환되는지 예상할 수 있게 되었다. 내가 사용한 방법들이 문제 해결에 있어 최선의 방법은 아니겠지만 이런 경험을 해봤다는 것 자체로 만족스러웠다.

[웹] OAuth

Tue, 10 Aug 2021 08:57:24 GMT

요즘 다양한 웹 사이트에서는 현재의 웹 사이트에서 사용자에 대한 인증을 요구할 때, 외부 서버에서 이미 인증되어 있는 정보를 전달받아 현재 웹 서버에 인증을 하는 방식을 지원하고 있습니다. 이 때 사용되는 프로토콜이 OAuth 프로토콜입니다. 이러한 방식은 사용자에게 웹 사이트마다 인증을 해야 하는 불편한 작업을 줄여 보다 편리한 웹 서비스를 제공합니다.

프로토콜 : A 시스템과 B 시스템의 통신을 원할하게 수용하도록 해주는 통신 규약, 약속

2007년 처음으로 Oauth 1.0의 초안이 발표되었고 그 뒤로는 사람들에게 많이 알려지게 되었습니다. 그러나 점점 커져가는 네트워크 시장에서 한계가 나타나기 시작했고 2012년 Oauth 2.0을 새롭게 제시하였습니다. 현재 우리가 사용하고 있습니다.

Oauth 2.0에서 크게 바뀐 점은 다음과 같습니다.

모바일 어플리케이션에서도 사용이 용이
반드시 HTTPS를 사용하기에 보안 강화
Access Token의 만료기간이 생김

또, Oauth 2.0의 인증 방식은 크게 4가지입니다.

Authorization Code Grant
Implicit Grant
Resource Owner Password Credentials Grant
Client Credentials Grant

각 인증 방식에는 장단점이 존재합니다. 가장 많이 쓰이는 Authorization Code Grant 방식을 예로 들어 동작 순서를 알아봅시다.

Resource Owner : 일반 사용자, User

Client : 우리가 관리하는 어플리케이션 서버(User 아님!)
Authorization Server : 권한을 관리하는 서버입니다. Access Token, Refresh Token을 발급, 재발급 해주는 역할을 합니다.
Resorce Server: Oauth2.0을 관리하는 서버(Google, Facebook, Naver 등)의 자원을 관리하는 서버입니다. 주의할 점은 우리가 만드는 서버의 자원을 관리하는 곳이 아닙니다. Oauth2.0 관리 서버의 자체 API를 의미합니다.

Resource Owner(사용자)가 Client(우리 서버)에게 인증 요청을 합니다.
Client는 Authorization Request를 통해 Resource Owner에게 인증할 수단(ex Facebook, Google 로그인 url)을 보냅니다.
Resource Owner는 해당 Request를 통해 인증을 진행하고 인증을 완료했다는 신호로 Authorization Grant를 url에 실어 Client에게 보냅니다.
Client는 해당 권한증서(Authorization Grant)를 Authorization Server에 보냅니다.
Authorization Server는 권한증서를 확인 후, 유저가 맞다면 Client에게 Access Token, Refresh Token, 그리고 유저의 프로필 정보(id 포함) 등을 발급해줍니다.
Client는 해당 Access Token을 DB에 저장하거나 Resource Owner에게 넘깁니다.
Resource Owner(사용자)가 Resource Server에 자원이 필요하면, Client는 Access Token을 담아 Resource Server에 요청합니다.
Resource Server는 Access Token이 유효한지 확인 후, Client에게 자원을 보냅니다.
만일 Access Token이 만료됐거나 위조되었다면, Client는 Authorization Server에 Refresh Token을 보내 Access Token을 재발급 받습니다.
그 후 다시 Resource Server에 자원을 요청합니다.
만일 Refresh token도 만료되었을 경우, Resource Owner는 새로운 Authorization Grant를 Client에게 넘겨야합니다. (이는 다시 사용자가 다시 로그인 하라는 말입니다.)

** 여기서 2편의 Access Token + Refresh Token 편을 보신 독자분들이라면 인증 과정이 유사하다는 것을 알 수 있습니다. Access Token, Refresh Token을 이용한 인증 방식은 한 서버에서 모두 관리하는 반면, 여기 OAuth에서는 Authorization Server에서 인증+권한 관리를 하고 Resource Server에서는 자원에 대한 관리만 합니다.

** 다시 한 번 강조하지만 Oauth 2.0 은 우리가 이전에 봤던 (사용자-서버) 구조가 아닌 (사용자 - 서버 - Oauth 서버) 입니다. 우리가 만들 서비스들의 인증을 돕기 위한 서비스가 바로 OAuth입니다. Resource Server는 우리의 서버가 아닌 Oauth를 관리하는 서버의 일부임을 명심하세요.

자 여기까지라면 왜 OAuth를 알아야하는지 궁금하실 겁니다. 왜냐하면 SNS 로그인을 제공하는 Google, Facebook, Naver 등은 모두 OAuth2.0 프레임워크를 통해 로그인 API를 제공하기 때문입니다!

이제 SNS 로그인 동작방식에 대해 알아보도록 하겠습니다. SNS 로그인은 간단하게 봤을 때 OAuth2.0 + 서버 인증(세션/쿠키 , 토큰기반 인증)으로 구성됩니다.

본 설명은 페이스북 로그인을 예로 들겠습니다. 또한 OAuth2.0에 사용되는 명칭은 이해하기 쉽게 바꿔서 설명하도록 하겠습니다.

사용자(Resource Owner)가 서버에게 로그인을 요청합니다.
서버는 사용자에게 특정 쿼리들을 붙인 페이스북 로그인 URL을 사용자에게 보냅니다.
사용자는 해당 URL로 접근하여 로그인을 진행한 후 권한증서(code)를 담아 서버에게 보냅니다.
서버는 해당 권한 증서를 Facebook의 Authorization Server로 요청합니다.
서버는 권한 증서를 확인 후, Access Token, Refresh Token, 유저의 정보(고유 id 포함) 등을 돌려줍니다.

** 여기서 프로필 이미지나 이메일 주소, 이름 등을 얻을 수도 있는데 이는 초기에 관리자가 권한 설정을 어디까지 하느냐에 따라 다릅니다. 페이스북 이름에 대해서만 접근할 수 있는 권한을 설정하면 이름 값만 Authorization Server에서 돌려줄 것입니다.

받은 고유 id를 key값으로 해서 DB에 유저가 있다면 로그인, 없다면 회원가입을 진행합니다.
로그인이 완료되었다면 세션/쿠키 , 토큰기반 인증 방식을 통해 사용자의 인증을 처리합니다.

** 우리가 만들 서버에서 OAuth를 이용하기 위해서는 사전에 OAuth에 등록하는 과정이 필요합니다. 등록 후 APP_ID와 CLIENT_ID 등을 보내야 OAuth 에서는 어느 서비스인지를 알 수 있습니다.

** 페이스북 로그인을 인증을 이용하는 경우, 대부분은 Resource Server(페이스북 자체 API)를 사용하지 않습니다. 따라서 Access Token, Refresh Token은 실제로 쓰이지 않습니다. 우리의 서버에서 access token을 검증할 수도 없을 뿐더러 인증의 수단으로 활용하기엔 부족한 점이 많습니다. 따라서 보통 7번 절차처럼 Authorization Server로 부터 얻는 고유 id값을 활용해서 DB에 회원관리를 진행합니다.

🗒 Reference

https://tansfil.tistory.com/60?category=475681

https://velog.io/@undefcat/OAuth-2.0-%EA%B0%84%EB%8B%A8%EC%A0%95%EB%A6%AC

세션과 쿠키, 그리고 JWT

Mon, 09 Aug 2021 10:08:14 GMT

웹의 기본, 세션과 쿠키 그리고 JWT에 대해서...

📌 HTTP 요청

현재 모바일이나 웹 서비스에서 가장 많이 사용하고 있는 통신은 HTTP 통신입니다. HTTP 프로토콜 환경에서 서버는 클라이언트가 누구인지 확인해야 합니다. HTTP 프로토콜은 connectionless하고 stateless한 특징이 있기 때문입니다.

Connectionless 클라이언트가 요청을 한 후 응답을 받으면 연결을 끊어버리는 특성

Stateless 통신이 끝나면 상태를 유지하지 않는 특성 연결이 끊는 순간 클라이언트와 서버의 통신이 끝나며 상태 정보는 유지하지 않는 특성이 있다.

이러한 http 통신의 특징 때문에 요청하는 대상이 누군지 구별할 필요가 있습니다. 그런데, 사용자 계정정보를 요청에 담아보내는 방식은 보안에 굉장히 취약합니다. 따라서 나온 방식이 세션/쿠키 입니다.

📌 세션과 쿠키

순서를 살펴보면 다음과 같습니다.

사용자가 로그인합니다.
서버에서는 계정정보를 읽어 사용자를 확인한 후, 사용자의 고유한 ID값을 부여하여 세션 저장소에(주로 Redis를 사용) 저장한 후, 이와 연결되는 세션 ID를 발급받습니다.
사용자는 서버에서 해당 세션 ID를 받아 쿠키에 저장한 후, 인증이 필요한 요청마다 쿠키를 헤더에 실어 보냅니다.
서버에서는 쿠키를 받아 세션 저장소에서 대조를 한 후, 대응되는 정보를 가져옵니다.
인증이 완료되고 서버는 요청에 맞는 데이터를 보내줍니다.

세션 쿠키 방식은 기본적으로 세션 저장소를 필요로 합니다.(주로 Redis 사용) 세션 저장소는 로그인을 했을 때 사용자의 정보를 저장하고 열쇠가 되는 세션 ID값을 만듭니다. 그리고 HTTP 헤더에 세션 id를 실어 사용자에게 보냅니다. 그러면 사용자는 세션 id를 쿠키로 보관하고 있다가 인증이 필요한 요청을 보낼 때 쿠키와 함께 보냅니다. 웹 서버에서는 세션 저장소에서 세션 id를 받고 저장되어 있는 정보와 매칭시켜 인증을 완료합니다.

※ 세션과 쿠키의 차이 세션 : 서버에서 가지고 있는 정보 쿠키 : 사용자에게 발급된 세션 id를 저장하기 위한 공간
※※ 쿠키만으로 인증을 사용한다는 말은 서버의 자원을 사용하지 않는다는 말입니다. 이는 클라이언트가 인증 정보를 책임지게 되는건데, 보안에 매우매우 취약합니다. 따라서 보안과는 상관없는 장바구니나 자동로그인 설정 같은 경우에 사용됩니다. 결과적으로 인증의 책임을 서버가 지게 하기 위해서 세션을 사용합니다. (서버를 해킹하는게 더 어렵기 때문입니다.) 사용자는 쿠키를 이용하고, 서버에서는 쿠키를 받아 세션의 정보를 접근하는 방식으로 인증합니다.

세션/쿠키 방식의 장점

보안 측면에서 안정적입니다.

세션/쿠키 방식은 기본적으로 쿠키를 매개로 인증을 거칩니다. 쿠키에 담긴 세션 id는 세션 저장소에 저장되어 있는 사용자 정보를 얻기 위한 열쇠입니다. 따라서 쿠키가 담긴 HTTP 요청이 노출되더라도 쿠키 자체는 유의미한 값을 가지고 있지 않습니다. 중요한 정보들은 서버 세션에 있기 때문입니다.

서버 자원에 접근하기 용이합니다.

각각의 사용자는 고유한 id를 발급받게 됩니다. 따라서 서버에서는 쿠키 값을 받았을 때 회원정보를 확인할 필요없이 어떤 회원인지 알 수 있어 서버의 자원에 접근하기 쉽습니다.

세션/쿠키 방식의 단점

세션 하이재킹 공격에 취약

쿠키는 의미있는 정보가 없기 때문에 안전합니다. 그러나, 만약 A 사용자의 쿠키를 해커가 가로채서 HTTP 요청을 보내면 서버의 세션 저장소에서는 A 사용자의 정보를 뿌려줄 수 있습니다. (세션 하이재킹 공격)

이는 HTTPS를 사용해 요청 자체를 탈취해도 안의 정보를 읽기 힘들게 하거나, 세션에 유효시간을 넣어주는 방식으로 해결할 수 있습니다.

서버 부하⬆️

서버에서 세션 저장소를 사용합니다. 따라서 서버에 추가적인 저장공간을 필요로 하게 되고 자연스럽게 서버 부하도 높아질 것입니다.

📌 JWT 토큰 기반 인증

JWT 토큰 구성 요소

JWT는 세션/쿠키와 함께 많이 쓰이는 인증 방식입니다. JWT는 인증에 필요한 정보들을 암호화시킨 토큰을 말합니다. 세션/쿠키 방식과 유사하게 사용자는 Access Token을 HTTP 헤더에 실어 서버에 보냅니다.

토큰을 만들기 위해서 Header, Payload, Verify Signature가 필요합니다. 해커가 토큰을 조작하여 A 사용자의 데이터를 훔쳐보고 싶다고 가정하겠습니다. 그래서 payload에 있던 A의 ID를 인코딩한 후 토큰을 서버로 보냅니다. 그러면 서버가 검사했을 때 payload는 A 사용자 정보지만 verify signature는 해커의 payload를 기반으로 암호화되었기 때문에 유효하지 않는 토큰으로 간주됩니다. 따라서 해커는 SECRET KEY를 알지 못하는 이상 토큰을 조작할 수 없습니다.

JWT 인증 방식

사용자가 로그인을 합니다.
서버에서는 계정정보를 읽어 사용자를 확인한 후, 사용자의 고유한 ID값을 부여한 후, 기타 정보와 함께 Payload에 넣습니다.
JWT 토큰의 유효기간을 설정합니다.
암호화할 SECRET KEY를 이용해 Access Token 발급합니다.
사용자는 Access Token을 받아 저장한 후, 인증이 필요한 요청마다 토큰을 헤더에 실어 보냅니다.
서버에서는 해당 토큰의 Verify Signature를 SECRET KEY로 복호화한 후, 조작 여부, 유효기간을 확인합니다.
검증이 완료된다면, payload를 디코딩하여 사용자의 ID에 맞는 데이터를 가져옵니다.

세션/쿠키 방식과 가장 큰 차이점은 세션/쿠키는 세션 저장소에 유저의 정보를 넣는 반면, JWT는 토큰 안에 유저의 정보를 넣는다는 점입니다. 클라이언트 입장에서는 HTTP 헤더에 쿠키를 실느냐, 토큰을 실느냐의 차이만 있지만, 서버 측에서는 인증을 위해 암호화를 하느냐, 별도의 저장소를 이용하느냐 하는 차이가 있습니다.

JWT 장점

추가 저장소가 필요하지 않습니다.

세션/쿠키는 별도의 저장소 관리가 필요한 반면, jwt는 발급한 후 검증만 하면 되기 때문에 추가 저장소가 필요하지 않습니다. 이는 stateless한 서버를 만드는 입장에서는 큰 장점입니다. stateless는 어떠한 별도의 저장소도 사용하지 않는, 즉 상태를 저장하지 않는 것을 의미합니다. 이는 서버를 확장하거나 유지, 보수하는데 유리합니다.

확장성이 뛰어납니다.

토큰 기반으로 하는 다른 인증 시스템에 접근이 가능합니다. 예를 들어 Facebook으로 로그인, 구글 로그인 등은 모두 토큰을 기반으로 인증을 합니다. 이에 선택적으로 이름이나 이메일 등을 받을 수 있는 권한도 받을 수 있습니다.

JWT 단점

한 번 발급한 JWT는 돌이킬 수 없습니다.

세션/쿠키의 경우 만일 쿠키가 악의적으로 이용된다면, 해당하는 세션을 지워버릴 수 있습니다. 하지만 JWT는 한 번 발급되면 유효기간이 완료될 때 까지 계속 사용이 가능합니다. 따라서 악의적인 사용자는 유효기간이 지나기 전까지 정보를 털어갈 수 있습니다.

※해결책※ 기존의 Access Token의 유효기간을 짧게 하고 Refresh Token이라는 새로운 토큰을 발급합니다.

Payload 정보가 제한적입니다.

Payload는 따로 암호화되지 않기 때문에 디코딩하면 누구나 정보를 확인할 수 있습니다. 따라서 유저의 중요한 정보들은 Payload에 넣을 수 없습니다.

JWT 길이가 깁니다.

세션/쿠키 방식에 비해 JWT의 길이가 깁니다. 따라서 인증이 필요한 요청이 많아질수록 서버의 자원낭비가 발생하게 됩니다.

Refresh Token과 Access Token

앞서 말한 JWT의 문제점의 해결방법이었던 Refresh Token에 대해 알아보겠습니다. Access Token을 통한 인증 방식의 문제는 제 3자에게 탈취당할 수 있습니다. Access Token의 유효기간을 줄인다면 사용자는 그때마다 다시 로그인을 해야 합니다. 반대로 유효기간을 늘리면 토큰을 더 오래 사용할 수 있어 보안에 취약합니다. 이때 Refresh Token을 사용하여 해결할 수 있습니다.

Refresh Token은 Access Token과 똑같은 형태의 JWT입니다. 처음에 로그인했을 때 Access Token과 동시에 발급되는 Refresh Token은 긴 유효기간을 가지면서, Access Token이 만료됐을 때 새로 발급해주는 열쇠가 됩니다.

예를 들어, Refresh Token의 유효기간은 2주, Access Token의 유효기간을 1시간이라고 가정하겠습니다. 사용자는 1시간 동안 자유롭게 api 요청을 하다가 이후에 Access Token이 만료됩니다. 그러면 Refresh Token이 만료되기 전까지 새로 Access Token을 발급받을 수 있습니다.

** Access Token은 여전히 탈취당할 수 있습니다. 그러나, 토큰이 유효한 시간이 짧기 때문에 기존보다 더 안전합니다. ** Refresh Token의 유호기간이 만료되면 사용자는 다시 로그인해야 합니다. Refresh Token 역시 탈취의 위험이 있기 때문에 유효기간을 적절히 설정해야 합니다. (보통 2주)

Refresh Token을 사용한 JWT 인증 과정

사용자가 로그인합니다.
서버에서는 DB에서 회원을 조회합니다. 3-4. 로그인이 완료되면 Access Token과 Refresh Token을 발급합니다. 이때 일반적으로 회원 DB 혹은 별도의 저장소에 Refresh Token을 저장해둡니다.
클라이언트는 Refresh Token을 저장소에 저장하고 Access Token을 헤더에 실어 요청을 보냅니다. 6-7. 서버에서 Access Token을 검증하고 데이터를 응답해줍니다.

시간이 흘러 Access Token이 만료됩니다.

클라이언트는 같은 방식으로 Access Token이 담긴 헤더와 함께 요청을 보냅니다. 10-11. 서버는 Access Token이 만료됨을 확인하고 권한없음으로 응답해줍니다.

** 반드시 서버에서 토큰 만료를 확인할 필요는 없습니다. 클라이언트에서 토큰의 Payload를 통해 유효기간을 알 수 있습니다. 따라서 프론트엔드단에서 API 요청을 보내기 전에 토큰이 만료됐다는 것을 알고 재발급 요청을 할 수도 있습니다.

클라이언트는 Refresh Token과 Access Token을 함께 서버로 보냅니다.
서버는 받은 Access Token이 조작되지 않았는 지 확인하고 Refresh Token과 사용자의 DB에 저장되어 있던 Refresh Token을 비교합니다. 토큰이 동일하고 유효기간이 지나지 않았다면 새로운 Access Token을 발급해줍니다.
서버는 새로운 Access Token을 헤더에 담아 응답을 해줍니다.

Refresh Token의 장점과 단점

장점

기존의 Access Token만 사용할 때보다 안전합니다.

단점

구현이 복잡합니다. 검증 프로세스가 길어져 구현이 조금 더 힘들어졌습니다.
Access Token이 만료될 때마다 새롭게 발급하는 과정에서 생기는 HTTP 요청 횟수가 많아졌습니다. 이는 서버의 자원 낭비로 귀결됩니다.

🗒 Reference

https://medium.com/@d971106b/%EC%82%BD%EC%A7%88%EA%B8%B0%EB%A1%9D-%EB%A1%9C%EA%B7%B8%EC%9D%B8-api-%EC%9E%91%EC%84%B1-jwt-refresh-token-access-token-http-only-92570160fa1c

[Next] Next.js 시작하기

Sun, 01 Aug 2021 05:26:26 GMT

Next.js 시작하기

📌 프로젝트 Setup

Next.js는 create-next-app을 이용하여 어플리케이션을 생성하는 것을 권장합니다. create-next-app은 set up에 필요한 것들을 자동적으로 준비해줍니다. 만약 타입스크립트를 사용하고 싶다면 --typescript 플래그를 사용하세요.

npx create-next-app
# 혹은
yarn create next-app

npx create-next-app --typescript
# 혹은
yarn create next-app --typescript

만약 기존 프로젝트에 next를 추가한다면 다음과 같이 할 수 있습니다. next, react, react-dom을 설치해주세요.

npm install next react react-dom
# 혹은
yarn add next react react-dom

package.json을 열고 scripts를 수정해주세요.

"scripts": {
  "dev": "next dev",
  "build": "next build",
  "start": "next start",
  "lint": "next lint"
}

📌 Pages

Next.js는 **pages**개념을 기반으로 구축되었습니다. 어플리케이션의 페이지들은 pages 디렉토리 안의 js, jsx, ts, tsx 파일 안의 리액트 컴포넌트를 렌더링합니다. Next는 pages 디렉토리 안의 파일들을 코드 스플리팅된 컴포넌트로 만들어주므로 디렉토리 이름은 항상 pages여야 합니다.

각각의 페이지들의 라우트 이름은 파일 이름과 연관이 있습니다. 예를 들어, pages디렉토리 안에 about.js 파일이 있다면 라우터 이름은 /about이 됩니다. 동적으로 바뀌는 라우트 또한 사용할 수 있습니다. pages/posts/[id].js 파일 이름을 이런식으로 작성하면, 동적으로 변하는 라우터를 만들 수 있습니다. posts/1, posts/2.. 등이 가능합니다.

어플리케이션을 구동하기 위해 npm run dev 혹은 yarn dev를 실행합니다. http://localhost:3000에 들어가면 보이는 화면은 pages/index.js 파일입니다.

📌 Pre-rendering

기본적으로 Next.js는 모든 페이지를 미리 렌더링(pre-rendering)합니다. react는 최초에 비어있는 HTML 하나만 서버에서 받은 후 모든 것을 클라이언트 사이드에서 렌더링하는 반면, Next.js는 미리 각 페이지들의 HTML을 생성해둡니다. 이렇게 되면, Pre-rendering으로 인해 검색 최적화와 더 나은 성능을 가져올 수 있습니다.

두 가지 형식의 Pre-rendering

Next는 Static Generation과 Server-side Rendering 두 가지 형태의 pre-rendering이 있습니다. 이 둘은 페이지들의 HTML을 언제 생성하느냐에 따라 다릅니다.

Static Generation (추천)

HTML을 build 할 때 생성하고 요청할때 이를 재사용합니다.

Server-side Rendering

요청할 때마다 HTML을 생성합니다.

중요한 점은, 여러분이 어떤 방식으로 pre-rendering 할 것인지 정할 수 있습니다. 대부분의 페이지는 Static Generation 방식을 사용하고 다른 것들은 서버 사이드 렌더링 방식을 사용해서 하이브리드 next app을 만들 수 있습니다.

static generation 방식은 추가적인 작업 없이 CDN에서 캐시할 수 있기 때문에 next는 이 방식을 추천합니다. 이 두 가지 pre-rendering 방식과 함께 react처럼 클라이언트 사이드 렌더링을 사용할 수도 있습니다.

CDN이란? CDN은 서버와 사용자 사이의 물리적 거리를 줄여 웹 페이지의 로드 지연을 최소화하는, 촘촘히 분산된 서버로 이루어진 플랫폼입니다.

Static Generation은 어플리케이션을 build 할 때 생성한다고 했습니다. next에서는 데이터가 있을때도, 그리고 데이터가 없을 때도 정적으로 페이지를 만들 수 있습니다. 각각의 경우를 통해 알아봅시다.

data fetching이 없을 때 Static Generation

기본적으로 next는 데이터를 가져오지 않고 static generation을 사용하여 페이지를 미리 렌더링합니다.

function About() {
  return About
}

export default About

data fetching을 하지 않는다면 문제될 게 없어보입니다. data fetching이 있는 경우는 어떨까요?

data fetching이 있을 때 Static Generation

어떤 페이지들은 pre-rendering을 위해 데이터를 가져와야 합니다. 데이터를 가져오는 경우는 크게 두 가지가 있고 각각의 경우에, next가 제공해주는 함수를 사용할 수 있습니다.

페이지의 내용이 외부 데이터에 의존한다 => getStaticProps 사용
페이지의 경로가 외부 데이터에 의존한다 => getStaticPaths 사용

1. 페이지의 내용이 외부 데이터에 의존

function Blog({ posts }) {
  return (
    
      {posts.map((post) => (
        {post.title}
      ))}
    
  )
}

export default Blog

props로 정보를 받아 렌더링 해주는 컴포넌트가 있다고 할때, pre-render를 하기 전에 데이터를 받아와야 합니다. 이때 getStaticProps를 사용할 수 있는데 이 함수는 build 타임에 호출되고 받아온 데이터를 Pre-render 할 때 전달해줍니다.

function Blog({ posts }) {
  // posts 렌더링
}

// 이 함수는 build time에 호출됩니다.
export async function getStaticProps() {
  // 외부 api 호출
  const res = await fetch('https://.../posts')
  const posts = await res.json()

  // { props: { posts } }를 반환함으로써,
  // `posts`를 build time에 prop으로 받을 수 있습니다.
  return {
    props: {
      posts,
    },
  }
}

export default Blog

2. 페이지의 경로가 외부 데이터에 의존

앞서 말했듯이 next에서는 동적 라우트를 사용해서 페이지를 만들 수 있습니다. 예를 들어, pages/posts/[id].js 라는 파일을 생성하고 posts/1 주소로 접근한다면 id를 1로 인식하여 페이지가 렌더링됩니다.

이 paths가 동적으로 받아온다면 다음과 같이 쓸 수 있습니다.

// getStaticPaths도 build 타임에 호출됩니다.
export async function getStaticPaths() {
  const res = await fetch('https://.../posts')
  const posts = await res.json()

  const paths = posts.map((post) => ({
    params: { id: post.id },
  }))

  // { fallback: false}는 다른 라우터는 404여야 한다는 것을 뜻합니다.
  return { paths, fallback: false }
}

pages/posts/[id].js에서 getStaticProps를 사용하여 특정 id 값을 props로 받도록 합니다.

function Post({ post }) {
  // posts 렌더링
}

export async function getStaticPaths() {
  // ...
}

export async function getStaticProps({ params }) {
  const res = await fetch(`https://.../posts/${params.id}`)
  const post = await res.json()

  return { props: { post } }
}

export default Post

Server-side Rendering

만약 Server-side Rendering을 사용한 페이지라면, 매 요청마다 HTML이 생성됩니다. server-side rendering을 사용하고 싶은 페이지에서 getServerSideProps라는 비동기 함수를 export하면, 서버는 이 함수를 요청이 올때마다 호출합니다.

function Page({ data }) {
  // 데이터 렌더링
}

// 이 함수는 매 request마다 호출됩니다
export async function getServerSideProps() {
  // 외부 API로부터 데이터를 가져옵니다
  const res = await fetch(`https://.../data`)
  const data = await res.json()

  // props를 통해 데이터를 넘겨줍니다(getStaticProps와 유사)
  return { props: { data } }
}

export default Page

Static Generation 방식과 비슷하지만 다른 점은 getStaticProps는 빌드 타임에 호출되고 getServerSideProps는 매 요청마다 호출된다는 것입니다.

📌 언제 Static Generation을 사용해야 할까요?

next는 가능하면 Static Generation을 사용하는 것을 권장합니다. CDN으로부터 받은 데이터를 한 번만 빌드할 수 있다면 모든 요청마다 서버에서 렌더링하는 것보다 훨씬 빠르고 적은 리소스를 사용할 수 있기 때문입니다.

마케팅 페이지, 블로그 포스트, 이커머스 상품의 리스트, 도큐먼트 페이지 등 많은 타입의 페이지에서 Static Generation을 사용할 수 있습니다.

스스로에게 물어봅시다. "사용자의 요청 전에 이 페이지가 pre-render 될 수 있는가?" 이 질문의 대답이 YES라면, Static Generation을 통해 퍼포먼스와 SEO 측면으로 많은 이점이 생길 것입니다.

반면, 사용자 요청 이전에 pre-render 할 수 없다면 Static generation은 좋은 생각이 아닙니다. 여러분의 페이지의 데이터가 자주 업데이트 되고 페이지의 컨텐트가 매 요청마다 바뀌는 경우가 여기에 해당됩니다. 이런 경우, 다음 두 가지 방법이 있습니다.

Static Generation과 Client-side Rendering 함께 사용 : 페이지의 일부분을 pre-rendering 하지 않고 그 부분을 client-side에서 자바스크립트 코드를 동작시켜 구성할 수 있습니다.
Server-side Rendering 사용: 모든 요청마다 페이지를 pre-render 할 수 있습니다. 이 방법은 CDN에 의해 페이지가 캐싱될 수 없기 때문에 느리지만 항상 최신 상태를 유지합니다.

📋 Reference

https://nextjs.org/docs/basic-features/pages

[react]Virtual DOM이란? | What is Virtual DOM?

Tue, 13 Jul 2021 11:05:09 GMT

Virtual DOM이란?

Virtual DOM은 말 그대로 가상 돔입니다. 그런데, 가상 돔이 왜 필요할까요? 이를 이해하기 위해서는 브라우저의 작동 방식에 대해 알아볼 필요가 있습니다.

📌 브라우저 작동 방식

"브라우저 엔진"과 "렌더링 엔진"은 뭘까요?

그림에서 알 수 있듯이 브라우저 엔진은 사용자 인터페이스와 렌더링 엔진 사이의 동작을 제어해주는 엔진입니다. 렌더링 엔진은 HTML documents와 웹 페이지의 리소스들을 브라우저에 시각적으로 출력해줍니다.

브라우저가 화면에 그리는 과정

요청과 응답

여러분이 어떤 링크를 누르거나 URL에 주소를 입력하고 엔터를 누르면 그 페이지에서 HTTP 요청이 이루어지고 해당 서버에서 HTML document를 응답으로 줍니다. (이 사이에 정말 많은 것들이 일어납니다.)

HTML 파싱과 DOM 생성

브라우저는 HTML 소스코드를 파싱하고 돔 트리를 생성합니다. 이 돔 트리는 데이터를 표현한 것인데, 여기에는 HTML 태그들에 해당하는 노드와 태그 사이의 텍스트 청크들에 해당하는 텍스트 노드가 들어가 있습니다. 돔 트리의 루트 노드는 입니다.

CSS 파싱과 CSSOM 생성

브라우저 렌더링 엔진은 HTML을 처음부터 한 줄씩 순차적으로 파싱하여 DOM을 생성합니다. DOM을 생성해 나가다가 CSS를 로드하는 link 태그나 style 태그를 만나면 DOM 생성을 일시 중단합니다. 그리고 link 태그의 href 어트리뷰트에 지정된 CSS 파일을 서버에 요청하여 로드한 CSS 파일이나 style 태그 내의 CSS를 해석하여 CSSOM(CSS Object Model)을 생성합니다. 이후 CSS 파싱을 완료하면 HTML 파싱이 중단된 지점부터 다시 파싱하기 시작해서 DOM을 생성합니다.

렌더 트리 생성

렌더링 엔진은 서버로부터 응답된 HTML과 CSS를 파싱하여 각각 DOM과 CSSOM을 생성합니다. 그리고 DOM과 CSSOM은 렌더링을 위해 렌더 트리로 결합됩니다. 렌더 트리는 돔 트리의 일종이지만 완전히 동일하진 않습니다. 렌더 트리는 스타일 정보를 알고 있어서 만약 당신이 div을 display: none;으로 숨겼다면 이는 렌더 트리에 표현되지 않습니다. 즉, 화면에 렌더링되지 않는 노드들은 포함되지 않습니다.

완성된 렌더 트리는 각 HTML 요소의 레이아웃(위치와 크기)을 계산하는 데 사용되며 브라우저 화면에 픽셀을 렌더링하는 페인팅 처리에 입력됩니다.

📌 Reflow & Repaint

리플로우는 문서의 일부 또는 전체를 다시 렌더링할 목적으로 문서에 있는 요소의 위치와 형상을 다시 계산하는 것을 말합니다. 가끔 문서의 단일 요소를 리플로우 하려면 상위 요소와 그 뒤에 오는 모든 요소를 리플로우 해야할 수도 있습니다.

리페인트는 이름에서 알 수 있듯이 요소의 가시성에 영향을 주지만 레이아웃에는 영향을 미치지 않는 것들을 다시 그리는 것을 말합니다. (테두리, 색깔, 등을 말합니다.)

렌더 트리를 구성하는 데 사용된 입력 정보를 변경하면 리플로우, 리페인트 둘 중 하나 또는 모두 발생할 수 있습니다. 리플로우와 리페인트는 비용이 많이 들 수 있고 안좋은 사용자 경험을 줄 수 있으며 UI가 느려질 수 있습니다.

📌 Virtaul DOM VS Real DOM

DOM이 변경될 때마다 브라우저는 CSS를 다시 계산해야 하며 레이아웃을 수행하고 웹 페이지를 다시 칠해야 합니다. (실제 돔에서는 이렇게 동작합니다.)

이 시간을 최소화하기 위해 Ember는 key/value observation 기술을 사용하고 앵귤러는 dirty checking을 사용합니다. 이 기술을 사용하면 바뀐 돔 노드만 업데이트 하거나, 앵귤러의 경우 더럽혀진 노드(바뀐 노드를 말합니다.)만 업데이트할 수 있습니다.

그러나, 브라우저는 화면을 다시 그리는데 걸리는 시간을 단축하기 위해 충분히 똑똑해졌습니다. 시간을 단축하는 것은 별로 중요해지지 않게 됐습니다. 이제는 리페인트를 발생하는 돔의 변화를 최소화하고 하나로 묶어서 처리하는 것이 중요해졌습니다.

DOM 변화를 줄이고 일괄 처리하는 전략은 바로 virtual dom에 있습니다.

📌 Virtual DOM은 정말 빠른가요?

react는 실제 DOM의 복사본을 메모리에 저장합니다. DOM을 수정하면 먼저 이러한 변경 사항을 메모리 내 DOM에 적용합니다.(이것 또한 가상돔입니다.) 그런 다음 diffing 알고리즘으로 변화한 부분을 파악합니다. 마지막으로, 변경 사항을 일괄 처리하고 호출을 통해 한 번에 실제 돔에 적용합니다. 따라서, 리플로우와 리페인트를 최소화합니다.

그렇다면, virtual dom은 정말 빠를까요? virtual dom이 real dom과 비교했을 때 절대적으로 빠른 것은 아닙니다. 단지, 변경 사항을 최소화하고 하나로 묶어 한 번에!! real-dom에 적용하는 것 뿐입니다.

📋 Reference

⌜모던 자바스크립트 딥 다이브⌟

[웹팩]웹팩이란? | 웹팩이 하는 일과 필요한 이유

Tue, 06 Jul 2021 06:38:58 GMT

웹팩이 하는 일과 필요한 이유

📌 웹펙이란?

웹팩은 리액트를 배우고 있다면 다들 한 번쯤 들어봤을 프레임워크입니다. 그렇다면 웹팩은 무슨 일을 하는걸까요?

웹팩은 최신 프론트엔드 프레임워크에서 가장 많이 사용되는 모듈 번들러입니다. 웹펙에서 모듈이란, 웹 애플리케이션을 구성하는 모든 자원을 말합니다. HTML, CSS, Javascript, Images, Font 등 파일 하나하나가 모두 모듈입니다.

결국, 웹팩은 모듈을 번들링 해주는 모듈 번들러입니다. 그렇다면 모듈 번들링은 뭘까요?

📌 모듈 번들링이란?

웹 애플리케이션을 구성하는 몇십, 몇백 개의 자원들을 하나의 파일로 병합 및 압축 해주는 동작을 모듈 번들링이라고 합니다.

📌 웹팩의 등장 배경

웹팩이 등장한 이유는 크게 3가지입니다.

파일 단위의 자바스크립트 모듈 관리의 필요성

웹 개발 작업 자동화 도구

웹 애플리케이션의 빠른 로딩 속도와 높은 성능

🔍 파일 단위의 자바스크립트 모듈 관리의 필요성

자바스크립트의 변수 유효 범위는 기본적으로 전역 범위를 갖습니다. 이 때문에 서로 다른 모듈에서 같은 이름의 변수를 사용한다면, 서로가 서로를 의도치 않게 변경할 수 있습니다.

이렇다 보니 파일 단위로 변수를 관리하고 싶고 자바스크립트를 모듈화하고 싶어지는데, 이전까지는 AMD, CommonJS와 같은 라이브러리를 사용했습니다.

그렇다면 AMD, CommonJS와 웹팩의 차이점은 뭘까요?

AMD VS CommonJS VS Webpack

AMD 방식은 Requirejs, CommonJS 방식은 Browserify가 인기가 많았습니다. Requirejs는 콜백 함수를 통해 모듈들을 전달받는 구조였기 때문에 모듈이 많아질수록 관리하기가 힘들었고, Browserify는 node.js로 코드를 작성해야 했기 때문에 모듈이 많아지면 node.js를 다루는 상황이 많아져 모듈 관리를 하나로 유지하고 싶었습니다.

반면, 웹팩은 AMD와 CommonJS를 동시에 지원하고, 기본적으로 부분을 캐싱하여 변경점만 번들링하는 방식이기 때문에 속도가 빠르고 테스터 런너와의 연동도 훨씬 좋습니다.

🔍 웹 개발 작업 자동화 도구

이전에는 프론트엔드 개발 업무를 할 때 가장 많이 반복하는 작업은 코드를 수정하고 저장한 뒤 새로 고침을 누르는 것이었습니다. 그래야 화면에 변경된 내용을 볼 수 있었습니다.

이외에도 웹 서비스를 개발하고 웹 서버에 배포할 때 아래와 같은 작업들을 해야 했습니다.

HTML, CSS, JS 압축
이미지 압축
CSS 전처리기 변환

이러한 일들을 자동화 해주는 도구들이 필요했고, 이전에는 Grunt와 Gulp 같은 도구들이 등장했습니다.

Grunt VS Gulp VS Webpack

Grunt와 Gulp는 Task Runner이고, 웹팩은 Package Bundler입니다.

Task Runner : 반복 가능한 특정 작업을 자동화 Package Bundler : 종속성을 가진 애플리케이션 모듈을 정적인 소스로 재생산합니다.

Gulp는 종속성 관리를 할 수 없지만 웹팩은 종속성 관리가 가능하고 이는 규모가 큰 프로젝트에서 빛을 발합니다. 또, 웹팩 커맨드를 실행할 때 --watch 옵션을 주면 변경 내용을 감시해서 적용할 수 있습니다.

🔍 웹 애플리케이션의 빠른 로딩 속도와 높은 성능

일반적으로 5초 이내에 웹 사이트가 표시되지 않으면 대부분의 사용자들은 해당 사이트를 벗어나거나 집중력을 잃게 됩니다.

그래서 웹 사이트의 로딩 속도를 높이기 위해 많은 노력들이 있었습니다. 그 중 대표적인 방법이 브라우저에서 서버로 요청하는 파일 숫자를 줄이는 것입니다. 파일 숫자를 줄이기 위해 파일들을 압축하고 병합하는 작업을 진행했습니다.

뿐만 아니라 초기 페이지 로딩 속도를 높이기 위해 나중에 필요한 자원들은 나중에 요청하는 레이지 로딩이 등장했습니다.

웹팩은 기본적으로 자원이 필요할 때, 그 때 그 때 요청하자는 철할을 갖고 있습니다. 웹팩의 코드 스플리팅 기능을 이용하여 원하는 모듈을 원하는 타이밍에 로딩할 수 있습니다.

📎 Reference

https://joshua1988.github.io/webpack-guide/guide.html

thalassophilia.log

tanstack query 오픈소스 기여 후기

[데브코스] 11.19 - 12.18 한달 회고

vue 사용후기

Pinia 적용

useFetch 구현

후기

프로젝트 후기

[바닐라 자바스크립트] 함수형 컴포넌트 만들기: 렌더링 최적화, 컴포넌트 단위 렌더링

✅ 컴포넌트 단위 렌더링

📍 계획

📍 기존 코드 확인

✅ 1. 컴포넌트 생성시 div로 감싸 렌더링

✅ 2. 새로운 render 함수 구현

✅ 3. useState에서 사용할 currentComponent에 정보 추가

✅ 컴포넌트 단위 렌더링 확인

컴포넌트 단위 렌더링

[바닐라 자바스크립트] 함수형 컴포넌트 만들기: useState 만들기

✅ 프로젝트 세팅

✅ useState에서 상태 저장 방법

📍 컴포넌트의 상태 저장하기

📍 컴포넌트의 이름과 stateIndex 초기값

✅ 컴포넌트 렌더링 과정과 현재 컨텍스트 기억하기

📍 중첩된 컴포넌트 렌더링 과정

📍 자식 컴포넌트 렌더링 후 현재 컴포넌트로 돌아오기

📍 useState 초기값 저장하기

📍 setState 구현하기

✅ 정리

[바닐라 자바스크립트] 함수형 컴포넌트 만들기: 컴포넌트 생성

✅ 함수형 컴포넌트

✅ 컴포넌트 생성하기

📍 컴포넌트 렌더링 하기

✅ 컴포넌트 생성 함수 만들기

📍 컴포넌트 props 추가하기

{props.message}

✅ 이벤트 처리

📍 이벤트 바인딩

📍 이벤트 핸들러 함수 바인딩과 상태 변경

[데브코스] 9.18 - 10.18 한달 회고

선언적 프로그래밍

코드를 언제 분리할 것인가

쿠키, 세션, 웹 스토리지

HTTP의 특징과 쿠키와 세션을 사용하는 이유

HTTP 프로토콜

쿠키

세션

웹 스토리지

로컬 스토리지

세션 스토리지

면접 관련 질문

호이스팅과 TDZ

1️⃣ 변수 호이스팅

2️⃣ TDZ

3️⃣ 면접 질문 대비

web server와 WAS

1️⃣ static pages VS dynamic pages

1️⃣ static pages

1️⃣ dynamic pages

2️⃣ 웹 서버와 WAS의 차이

2️⃣ 웹 서버

2️⃣ 웹 서버의 기능

2️⃣ 웹 서버 종류

2️⃣ WAS

2️⃣ WAS 역할

2️⃣ WAS의 기능

2️⃣ WAS 종류

3️⃣ 웹 서버가 필요한 이유

4️⃣ WAS가 필요한 이유

5️⃣ WAS로 웹 서버 역할까지 처리할 수 있는 것 아닌가?

6️⃣ 면접 대비

[slash] 모노레포로 된 라이브러리 뜯어보기

📕 slash의 모노레포 구성 살펴보기

📘 yarn berry

📘 lerna

📘 tsconfig

📘 packages

📘 packages/react 모듈

📘 packages/common 모듈

📘 CI/CD

[황준일]프레임워크 없이 만드는 SSR를 읽은 후기

[바닐라 자바스크립트] 함수형 컴포넌트 만들기: 렌더링 최적화, 컴포넌트 단위 렌더링

`Observable`과 `observer`를 사용할 때 고려해야 할 것들