브라우저는 최적의 사용자 UX 위해, 상세 페이지에서 '뒤로 가기'를 했을 때 이전 스크롤 위치를 자동으로 복원하는 기능을 갖추고 있다. 덕분에 사용자는 리스트의 탐색 흐름을 끊김 없이 이어갈 수 있으며, 이를 기술적으로 지원하기 위해 history.scrollRestoration API를 지원한다.페이지 간 경계가 명확한 SSR환경이면 모르겠지만 SPA은 구조적으로 브라우저가 스크롤을 복구하려는 시점과 리액트가 화면을 그리는 시점이 어긋나서 race Condition이 발생하는지 스크롤이 엉뚱한 곳으로 튀는 현상이 있다. 때문에 SPA 환경에서는 스크롤 복구 로직을 따로 구하는 경우가 많다.내가 쓰는 스크롤 복구 방법우선 브라우저의 복구 Api를 안쓰겠다고 설정해준다. 복구 값은 auto가 기본 값이기 때문에 manual로 수동으로 변경하겠다고 설정해둔다. if ("scrollRestoration" in window.history) { window.history.s

React는 Virual DOM을 이용한 최적화 방식의 랜더링을 지원하는 프레임워크이다. Fiber의 핵심은 조각내어 실행하게 되어 동시성 랜더링 ( Concurrent Rendering )을 이용하여 Suspense 컴포넌트 바운더리로 활용 되거나 브라우저 랜더링 최적화를 하면서 우선순위 랜더링의 기준을 정하여 더 좋은 사용자 경험을 가능하게 하는 핵심 패러다임이다.이 번 글은 Fiber의 핵심 기능인 Automatic Batching, Concurrent Rendering에 대해 정리해보고자 한다.test….# React Fiber16버전 이전에는 Fiber가 아닌 Stack 개념으로 처리 되었다. Stack은 작업이 실행 된다면 도 중에 멈출 수 가 없다. 만약에 핸들러를 통해 상태가 변경되거나 하여 매우 무거운 작업을 진행한다고 가정해보자. 만약 작업 중이지만 사용자는 onclick 같은 사용자 입력을 했다고 가정한다면 이전의 작업을 처리 중이기 때문에 무 응답일 가능성이 매

컴퓨터는 데이터를 어떻게 구분하나?우리가 매일 마주하는 데이터는 참 다양한 얼굴을 하고 있다. 데이터는 각자 다른 모습으로 이미지, 사운드, 영상, 텍스트 등 여러가지 모습으로 표현된다. 하지만 컴퓨터의 시야에서는 모든 파일은 0과 1의 나열일 뿐이다. 여기에 더해 각 나라 등 수 백가지 언어로 소통하고 있다.그렇지만 컴퓨터는 이 모든 데이터의 형식을 0과 1의 행렬로 표현한다. 어떻게 컴퓨터는 데이터를 구분하고 표현하는 지에 대해 HTTP 통신 기준으로 “Content-Type”과 “UTF-8” 인코딩에 대해 정리해보려 한다.“UTF-8”의 역할컴퓨터는 0과 1의 bit로 모든 것을 표현한다. 이 데이터가 문자나 데이터들을 규칙에 의해 생성 되었는지를 판단하고 매핑하여 문자를 반환하는 형식을 사용한다. 과거에는 ASCII를 사용하였고 7bit로 표현 가능한 문자의 수는 128개이며 숫자와 알파벳을 표현한 비트 스트림 형식의 데이터 자료구조이다. 현대 시대의 언어의 다양성, 그리고

Next.js :: SuspenseSuspense 바운더리는 React 18버전 공식 출시 이후 Concurrent Rendering 방식을 통해 도입된 기능이다. React에서 이 Suspense 바운더리는 비동기 함수의 상태를 받아 Suspense의 fallback을 반환하게 되고, 이후 상태가 성공하거나 실패하게 되면 자식 컴포넌트들을 렌더하게 된다.Next.js에서도 Suspense는 유용하게 쓰인다. 사실 클라이언트의 경우에는 SWR이나 RTK같은 라이브러리가 프로미스 상태에 따라 너무 좋은 인디케이터를 지원하기 때문에 클라이언트에서는 근래 잘 쓰이지 않는 추세다. 다만 Next.js의 서버 컴포넌트의 Suspense는 스트리밍을 도입함에 따라 서버에서도 인디케이터를 제공할 수 있어 더 유용하게 사용할 수 있다. 해당 포스팅은 클라이언트와 서버에서의 Suspense 실행을 복습하고 원리를 이해하는데 도움이 될 것이다.클라이언트 : SuspenseNext.js의 클라이언트 컴

희소 배열은 어떻게 저장될까?JS의 배열은 V8 엔진에 의해 Packed, Holey로 구분되어 메모리에 저장되게 된다. Packed는 근접한 메모리에 연속성으로 반영되기에 메모리의 순서대로 인덱스를 반영하면 되지만 Holey Array의 경우는 희소배열이기 때문에 떨어져 있는 인덱스 들을 Hash Table을 이용한 참조를 통해 메모리를 효율적으로 사용할 수 있다.실질적으론 Packed 처럼 사용할 수 있는 장점이 있다. 이를 좀 더 이해하기 위해 JS 배열에서 사용하는 Hash Table을 구현해보며 이해하기로 한다.Holey 해시테이블 구현해시테이블은 보통 버킷을 2의 제곱수 크기로 시작한다. 대부분의 라이브러리가 초기값으로 쓰는 8개 버킷을 사용하기에 나도 8로 구현하기로 한다. 각 버킷은 [K,V] 쌍을 담는 배열로, 충돌이 발생하면 동일 버킷 내부 배열에 추가하는 체이닝 방식을 따른다. 따라서 keyMap의 타입은 다음과 같다.private keyMap: Array<Arr

한입 크기로 잘라 먹는 Next.js프론트엔드에서 React를 다룬다면 이제 TypeScript와 함께 Next.js는 사실상 필수로 여겨지는 프레임워크다.Next는 React의 한계를 보완하고 성능을 극대화할 수 있는 강력한 도구다.나는 1년 전 Udemy에서 “한입 Next.js” 강의를 수강했고, 정환 님은 강의에 따라 학습을 완주목표로 챌린지를 진행하시는데 나는 “한입 챌린지 2기 - Next”에 참여한 경험이 있다.그때 수많은 개념과 실습을 통해 큰 성장을 했고, 지금도 그 경험은 내 개발 공부의 중요한 자산으로 남아 있다.그런 가운데 이번에 이정환 님의 Next.js 책 집필 소식을 듣게 되었고, 서평단에 선정되어 누구보다 먼저 책을 접할 기회를 얻었다. 단순히 복습이 아니라, 강의에서 배운 지식을 다시 구조적으로 정리하고 싶다는 기대감으로 책을 받아 보았다📌 본 포스팅은 강의 경험이 있는 상태에서 책을 접한 시점을 기준으로 서평하였다는 점 참고바란다.Udemy - 한입

ArrayArray는 JavaScript를 넘어 대부분의 프로그래밍 언어에서 가장 기초적인 자료구조이다. 객체나 원시 값을 순서대로 저장하고, 반복 작업을 처리하거나 다른 자료구조를 만드는 기본적인 틀로 사용된다.보통 개발을 처음 배울 때는 Array를 단순히 "[]"로 묶여 있는 값들의 집합 정도로만 생각한다. 그리고 주로 map이나 forEach로 데이터를 뿌리는 용도로만 사용하지, 내부적으로 메모리가 어떻게 할당되고 관리되는지는 잘 모르는 경우가 많다.이번 포스팅에서는 JavaScript 엔진이 배열을 구성할 때 메모리를 어떻게 효율적으로 사용하는 지에 대해 정리해 보려고 한다.배열의 메모리 할당모든 프로그래밍 변수들은 메모리에 할당이 되어 진다. 원시인지, 객체 인지에 따라 스택, 힙으로 나뉘게 된다. 주로 리스트 형식으로 많이 사용하기 때문에 주로 객체 배열을 구성하게 된다.배열은 기본적으로 “Object” 이다. Array는 index라는 key를 가진 Object며 자연

Web Vitals, 프론트엔드의 필수 역량프론트엔드 개발자에게 Web Vitals는 더 이상 '알면 좋은 교양'이 아닌, 반드시 갖춰야 할 '필수 역량'이다.웹페이지는 단순히 CSS의 플로우에 따라 순서대로 페인팅되어 사용자에게 제공되지 않는다. JavaScript는 동적으로 DOM을 조작하고, 수많은 API는 데이터를 요청하며, CDN에서는 거대한 이미지와 동영상을 불러온다.Web Vitals은 사용자의 UX를 구글이 객관적으로 평가하기 위해 정의한 기준으로 수치를 측정하고 방해 요소들을 미리 파악하여 개선하여 사용자 UX와 성능을 개선할 수 있게 해주는 중요 지표이다.간단하지만 치명적인 예시 하나를 살펴보자.좀 극단적인 예로 초기 히어로 페이지의 배너 이미지로 WebP나 JPG 대신, 30MB짜리 PNG 파일을 그대로 사용했다고 가정해 보자. 이미지 로딩은 비동기로 처리되기에 다른 영역은 먼저 페인트될 수 있다. 하지만 정작 사용자의 시선이 가장 먼저 머무는 핵심 배너는, 거대

브라우저 랜더링어떤 언어로 웹 개발을 하든, 모든 웹페이지들은 브라우저를 통해 사용자에게 페이지를 제공하게 된다. 브라우저 들은 최종적으로는 CSS, HTML의 형태로 페이지 그리게 되며 랜더링 파이프라인을 따른다. 파이프 라인에 따른 화면을 그리는 페인팅 작업은 비싼 비용의 작업이며 현 프론트엔드 시장은 프레임워크 등을 사용하여 브라우저 페인팅의 자원을 절약하는 것이 트랜드이다. 때문에 이 랜더링과 프론트엔드 라이브러리를 더 효율적으로 사용하기 위해서는 브라우저 랜더링을 이해하는 것이 우선이다. 때문에 브라우저 랜더링의 파이프라인과 React가 브라우저 랜더링이 미치는 영향에 대해 정리해본다.브라우저 랜더링 : HTML 과 CSS는 트리를 구성한다.브라우저 랜더링은 기본적으로 CSS와 HTML만으로 페이지를 그린다. HTML은 뼈대를 이야기하며 CSS는 이 뼈대에 가시적 효과를 주는 스타일링 언어이다. 브라우저는 코드를 인터프리터 형식으로 순차적으로 코드를 읽으며 트리 구조를 구성