본문 바로가기

웹 프론트엔드

 (17)
React에서 중복호출(aka. 따닥)을 막는 완벽한 방법 서언 안녕하세요. 최근에 퀄리티 높은 프론트엔드 제품을 만드는 것에 관심이 많은데요. 사소해보이는 디테일을 얼마나 능숙히 처리하느냐가 프론트엔드 개발자의 실력 척도 중 하나라고 생각했어요. 저는 여러 원칙들을 세우고 있지만, 오늘은 중복호출 (aka 따닥)을 방지하는 완벽한 방법을 탐구해볼 것입니다. 문제인식 서비스를 개발하다가, 중복호출이 발생해서 여러 문제가 발생하는 경우가 있습니다. 결제 요청이 2번 들어갈 수도 있고, 게시물 작성이 2번 될 수도 있고, 댓글이 2번 써질 수도 있습니다. 이로 인해 비즈니스적으로도 영향을 미칠 수도 있습니다. 작게는 서버 에러 수가 많아져서, noisy 해질 수 있죠. 이만큼 중요도가 높고, 프론트엔드 퀄리티에 큰 역할을 한다고 생각했는데요. 실제로 저도 명확한 해..
React CleanCode #2. UI Variation에 유연하게 대응하기 서언 안녕하세요. React CleanCode 2번째 시리즈로 찾아왔습니다. 저는 토스 공동구매 팀에서 약 1년간 커머스 제품을 운영해왔는데요. 제품이 디벨롭 되면서, 상품 컴포넌트는 더욱 복잡해지고, 많은 Variation 이 생겼어요. 그러면서 일명 스파게티 코드를 만들게 되었어요. 사용처에서 유연하게 사용이 어렵고, 장애 확률이 높고, 새로운 기능 추가가 어려웠어요. 이를 유지보수하기 쉬운 코드로 리팩터링한 경험을 공유하려고 해요. UI Variation에 고통 받고 계신 분들이 읽으면 도움이 될 것입니다. 목차 컴포넌트가 스파게티가 되어가는 과정 개선 방향성 개선 언제 사용하면 좋은가요? 마치며 부록 : Compound component pattern 인가요? 컴포넌트가 스파게티가 되어가는 과정 ..
ErrorBoundary 가 포착할 수 없는 에러와 그 이론적 원리 분석 서언 ErrorBoundary 는 하위 컴포넌트에서 발생하는 자바스크립트 에러를 잡아서 fallback UI를 보여주는 React 컴포넌트 입니다. 하지만 하위에 존재하는 컴포넌트에서 에러가 발생한다고 하여, 모든 에러를 잡아주는 것은 아닙니다. React 공식문서에는 다음과 같은 에러는 ErrorBoundary가 포착할 수 없다고 합니다. 과연 저것은 암기해야하는 것들일까요? 그렇지 않습니다. JavaScript 와 React를 잘 이해하고 있다면 당연한 현상입니다. 이 글에서는 에러바운더리가 특정 에러를 포착하지 못 하는 원리를 설명해보려고 합니다. 목차 [사전지식] 실행 컨텍스트와 예외처리 Case1. 이벤트 핸들러 Case2. 비동기적 코드 Case3. 서버 사이드 렌더링 Case4. 자식에서가 ..
React CleanCode #1, 합성으로 관심사를 분리하기 서언 안녕하세요. React CleanCode 첫 번째 주제로 Composition(합성)을 다룹니다. 최근에 회사에서 많은 코드를 작성하면서 느끼는 것이 있었는데요. 바로 프론트엔드가 다루어야할 관심사가 너무나 많다는 것입니다. 크게는 UI 로직(단순 UI, 애니메이션 로직, 하드코딩적인 요소), 서버 로직(데이터 패칭, 업데이트 로직, 유저 인증인가 로직, 로딩처리, 에러처리), 로그 등 이 있습니다. React를 사용하며 이러한 관심사를 잘 분리하지 않는다면, 스파게티 코드가 된다는 것을 체감했습니다. 그러면 어떻게 관심사의 지옥에서 벗어날 수 있을까요? 즉 관심사를 어떻게 잘 분리해야 할까요? 관심사 분리는 보통 함수(클래스) 분리를 통해 이루어집니다. React에서 함수의 실체는 훅, 컴포넌트,..
혹시 무분별하게 Suspense 를 사용하고 계신가요? (react-query) 더보기 서언 React v18 부터 Suspense가 API call에 따른 Loading 상태를 표현할 수 있게 되었습니다. 그에 따라, react-query, swr 같은 data fetching library가 Suspense를 지원하고 있습니다. suspense 옵션만 true로 설정해주면, API 요청 훅이 알아서 내부 처리를 통해 Suspense를 동작시킵니다. 이로써 로딩을 선언적으로 보여줄 수 있게 되었고, ErrorBoundary 조합과 함께라면 컴포넌트는 Success 케이스만 표현하면 되었습니다. 이런 혁신에 대해서는 잘 인지하고 있었지만, Suspense의 위험성에 대해서는 인지하지 못 했습니다. 특히 저희 서비스는 잘못된 Suspense 사용으로 어플리케이션 로딩 성능 저하를 겪었..
A use case of Function Overloading in TypeScript (useRef, remove null/undefined) 서언 TypeScript에는 Function Overloading 기능이 있습니다. 이번에 Function Overloading의 강력함을 깨닫고, 이를 공유하고자 아티클을 씁니다. 함수 오버로드가 왜 필요한지 이해하고, useRef 예시와 저희 프로젝트에 적용해본 예시를 설명드리겠습니다. 타입스크립트에서 함수 오버로딩이 왜 필요한가? 자바스크립트는 인자의 개수 제한, 인자의 타입 제한이 없습니다. 코드 예시를 보겠습니다. function add(a, b, c) { if (b) { if (c) { return a + b + c; } return a + b; } return a; } console.log(add(1, 2, 3)); // 6 console.log(add(1, 2)); // 3 console...
ErrorBoundary로 Toast, ErrorFallback 등 공통적인 에러를 처리해보자 서언 현재 꼭꼭 서비스를 운영하고 있습니다. 안정적인 서비스 운영, 보다 나은 유저 경험을 제공하기 위해 (1) 섬세하고, (2) 빈틈 없는 에러 처리가 필수라는 생각이 들었습니다. (1) 섬세하다는 것은 상황에 맞는 에러를 적절히 보여 준다는 것을 의미하고, (2) 빈틈 없다는 것은 모든 API 요청에 에러 케이스를 고려한다는 것을 의미합니다. 그러면 고민이 심화됩니다. (1) 에러를 어떤 기준으로 분류하여 처리할 수 있을까? (2) 모든 요청에 에러를 붙인다면, 반복을 줄일 수 없을까? 이를 고민하여 나름대로 에러를 분류해보았고, ErrorBoundary(에러 경계) 라는 도구를 활용해 선언적이고 추상화된 에러 처리를 시도해보았습니다. 본 글은 에러 처리 전략, ErrorBoundary를 다룹니다. ..
Context API를 활용하여 선언적으로 Toast 띄우기 서언 Context API는 쓰는 사람에 따라서 다양한 방식으로 사용됩니다. 그 이유는 Context API에서 전역적인 상태를 선언할 수 있고, 동시에 컴포넌트도 반환 해줄 수 있기 때문입니다. Context API 사용 예시를 찾아보면, 대부분 상태를 전역적으로 제공하는 역할을 하고, children을 그대로 반환해주는 형태를 많이 볼 수 있습니다. 하지만 컴포넌트를 반환할 수 있다는 특징을 활용하면 Toast, Modal, Loading 같은 UI를 선언적으로 사용할 수 있지 않을까 고민하였습니다. 이번 글은 [꼭꼭 팀]이 Context API를 사용하여 상태를 가진 UI를(Toast) 선언적으로 보여주는 방법에 대해 설명드리고자 합니다. 먼저 명령적인 Toast 사용을 알아보고, 하나씩 개선해나가..
선언병합을 활용하여 CSS in JS의 theme 타입 추론하기 이번 글은 TypeScript와 styled-components나 emotion을 함께 사용할 때, theme의 타입을 추론하는 방법을 다룹니다. 그 방법은 간단하지만, 숨겨진 원리가 있습니다. 방법을 먼저 설명한 후, 원리를 설명하도록 하겠습니다. theme 타입 추론하기 emotion, styled-components를 사용하면 아래와 같이 theme을 선언하고, ThemeProvider에 theme을 props로 넣어줍니다. // index.tsx const theme = { primary_500: '#FF5622', primary_400: '#FF7020', primary_300: '#FF9620', primary_200: '#FFB25B', primary_100: '#FFC17B', }; roo..
컴파일과 폴리필의 차이점 분석 (babel, polyfill) 서언 웹 생태계에서 JavaScript는 브라우저와 뗄 수 없는 관계입니다. JavaScript는 매번 새로운 버전을 출시합니다. 그러면 브라우저는 최신 문법을 이해할 수 없게 됩니다. 만일 브라우저가 빠르게 대응한다고 하더라도, 사용자가 최신 브라우저를 사용할 것이라는 보장이 없습니다. 그러므로 브라우저가 최신 문법을 이해하도록 만들기 위해서 개발자가 노력을 가해야 합니다. 이때 사용할 수 있는 카드가 Compile 입니다. Compile의 중요성은 널리 알려진 것 같습니다. 하지만 Compile만으로 해결할 수 없습니다. Compile 만큼 중요한 것이 Polyfill 입니다. 이 글은 Compile과 Polyfill의 차이점과 그 역할에 초점을 맞춥니다. 컴파일이란? ES6+ 자바스크립트 코드를 E..

티스토리툴바