히스토리 스택은 완전한 스택은 아니다.여기서 완전한 스택이란, 중간에 껴있는 데이터를 보기 위해서 위에 쌓인 모든 데이터를 pop해야만 하는 스택을 의미한다. History API 히스토리 API는 기본 중의 기본이다. 실제로 리액트나 Next.js 에서 제공하는 히스토리 관련 함수들도 결국 아래의 3가지 API를 래핑해서 제공하는 것 뿐이다. 해당 API를 잘만 이용하면,fetch만 이용하여 SPA를 구성할 경우 발생하는 앞으로가기/뒤로가기가 제대로 구현이 안되는 상황을 해결할 수 있다. 한번 히스토리 이력을 관리해보면서 해당 API에 대한 이해를 높여보자. 1. history.pushState 세션 기록에 새 항목을 추가한다. 즉 히스토리 스택을 쌓는다. document.addEventListener..

캐싱은 서버가 하지 않는다. 브라우저가 한다. 서버는 오직 캐싱 정책만 알려준다. 이를 위해 HTTP의 헤더를 이용한다. HTTP의 헤더의 내용은 널리 알려준 필드들과, 커스텀 필드를 넣을 수 있다. 브라우저 - 서버가 서로 통신하는 상황을 상상해보자.브라우저는 이미 구현된 소프트웨어고, 널리 알려진 헤더에 대한 동작들도 구현되어있다. 이로 인해 아래의 행동에 대한 응답이 달라진다. 1 ) http://localhost:3000/version.json 를 주소창에 입력하고 엔터하는 경우 : 200(from disk) 2 ) http://localhost:3000/version.json 최초 요청 이후 새로고침 하는 경우 304 3) http://localhost:3000/version.json 에서 강..

탄스탁 쿼리(기존 리액트 쿼리였으나, 리액트 전용 라이브러리가 아닌 범용 라이브러리로 확장되면서 이름이 변함)해당 라이브러리는 서버의 상태를 간단하게 관리할 수 있도록 도와주는 라이브러리 입니다. 가장 핵심적인 기능은 "서버 상태와 클라이언트 상태의 동기화" 입니다.이를 위해 특정 시간(staleTime)이 지나거나, 특정 조건(revalidateQueries)이 발동되면 refetch가 일어납니다.(여기서 refetch는 서버로부터 데이터를 가져오는 것을 의미해요.) 그 외에 API 요청과 관련하여 편리한 기능들도 제공해주곤 합니다.- 옵션 객체를 통해 API 요청이 실패했을 경우 자동으로 retry할 수 있도록 할 수도 있고,- 쿼리키에 따라 데이터를 캐싱해두어 새로운 요청(중복 요청)이 일어나지 않..

하이드레이션 에러는 오직 "클라이언트 컴포넌트" 에서만 일어납니다.리액트의 하이드레이션 에러를 이해하기 위해, 서버 컴포넌트와 클라이언트 컴포넌트 그리고 하이드레이션 기법에 대한 이해가 필요해요.하이드레이션 기법"물을 주다" - "촉촉하게 하다" 라는 의미로, 메마른 클라이언트 컴포넌트에 이벤트 등 JS 로직을 불어 넣어주는 과정이에요.즉, 서버에서 만들어진 HTML에 클라이언트의 JS 로직을 붙이는 과정입니다. (이벤트 핸들러/ 혹은 리액트의 상태 등) 참고로 서버 환경에서는 브라우저가 존재하지 않으니, 브라우저에서만 실행될 수 있는 코드들은 사용할 수 없습니다.이벤트핸들러, webAPI나, useState, useEffect 등의 코드들은 서버 컴포넌트에서는 사용할 수 없습니다. 서버 컴포넌트서버에서..

답은 NO. 그 이유에 대해서 차근 차근 설명해보고자 합니다. CSS는 전역 스코프를 갖는다.CSS는 기본적으로 전역적인 스코프를 가집니다. 순수한 css를 다시 떠올려보면 쉽게 그 이유를 알 수 있습니다. Click me 순수한 css는, html의 태그로 css 파일들을 불러오거나, 태그 안의 텍스트 엘리먼트에 직접 적어 넣습니다. 이렇게 가져온 css의 클래스네임을 인식하여, 필요한 요소에 스타일링을 위해 클래스네임을 집어 넣는 구조죠. 그래서 캐스케이딩 규칙(우선순위 법칙)에 따라, 동일한 클래스명을 갖는 경우에는 우선 순위가 더욱 높은 클래스명이 적용되고이로 인해 스타일링이 꼬이는 일이 비일비재하게 발생했습니다. 클래스명을 겹치지 않게 구현하려니 머리 아팠고요. 이를 간단하게..

리액트의 Reconciliation은 UI를 업데이트 할 때, 리액트가 실제 DOM을 효율적으로 업데이트 하는 핵심 알고리즘입니다.리액트를 공부하다보면 리액트의 파이버 아키텍쳐, Virtual DOM을 들어보셨을텐데요. Fiber Architecuture는 리액트16에 도입되어 Reconcilation 엔진을 재구성하여 탄생했고, Vitrual DOM은 Reconciliation 과정을 위해 필요한 재료입니다. 아주 간략히 Reconciliation 과정을 설명하면 아래와 같습니다. 1. 실제 DOM을 복사해둔 형태인 Virtual DOM을 유지한다.2. 변경 사항이 생기면 Diffing 알고리즘을 통해 이전 Virtual DOM 트리와 새로운 Virtual DOM 트리를 비교한다.3. 비교 과정 후 ..

개발자도구에서 엘리멘트 탭을 열어보면 리렌더링 될 때마다 자주색으로 번쩍이는 부분을 볼 수 있어요. 이와 비슷하게 React Dev tools를 사용하면 Highlights 기능이 존재하긴 하는데, 이는 함수형 컴포넌트의 재호출(리렌더링)을 표시해주는 것일 뿐이지 실제 DOM 요소의 변경을 온전히 반영하는 것은 아닙니다. 즉, DOM 요소의 변경을 Highlights 기능이 전부 포함하여 반영되지만, 모든 리렌더링 자체를 개발자도구가 강조 표시를 하며 나타내지는 않습니다. 당연하죠. 원천을 따르는건 개발자 도구 쪽이고, 리액트는 그 위에서 도는 거니까요. 여튼 오늘은 개발자도구의 Element 탭 강조 표시를 톺아보는 시간을 가져보도록 하겠습니다. 그 전에, 오늘 설명에 활용할 코드를 보여드릴게요.exp..

requestAnimationFrame(이하 raf)는 웹 애니메이션을 최적화하는데 사용되는 webAPI 입니다.웹 애니메이션을 사용하기 위한 방법으로 setInterval이나 반복적인 setTimeout을 사용할 수도 있지만, raf에 비해서는 성능이 좋지 않습니다. 오늘은 그 이유에 대해 알아보며, raf에 대한 이해를 깊게 가져가는 시간을 가져봅시다. 들어가기에 앞서이번 아티클에서는 단순히 사용 방법 뿐만 아니라 원리도 다룰 것이기 때문에 여러가지 개념에 대한 지식이 필요합니다.프레임, 이벤트 루프(+싱글 쓰레드 개념), CPU와 GPU의 차이, 브라우저 렌더링 과정(reflow&repaint) ... 전부 설명하기엔 너무 양이 많아지니, 해당 아티클에 필요에 따라 언급하는 방식으로 넘어갈게요. 그..

흔히들 zustand는 state가 바뀔 경우, 해당 state를 구독하고 있는 컴포넌트에서만 리렌더링이 일어날 것이라고 생각하는데 이는 반은 맞고 반은 틀린 말입니다. 즉 zustand에서 store를 만들고 해당 store에 있는 값(state 혹은 function) 일부를 select해서 가져오면 가져온 값에 대해서만 리렌더링이 일어날 것이라고 착각하곤 하는데 이를 잘 잡고 가야 합니다.  결론부터 말하자면, Zustand는 Store의 참조가 바뀔 때 리렌더링을 유발합니다.제가 겪은 트러블 슈팅을 소개하면서 간단히 이해해봅시다.  트러블 슈팅 과정 (기존)아래는 기존의 store 선언입니다. createStore API가 아닌 create API를 사용해 store 하나를 만들어두었습니다. imp..