행복한 시지프

서문안녕하세요. React OOP 시리즈 2번째 글을 작성합니다. 이번 글은 OOP 에서 중요한 개념인 접근제어(access control)에 대해서 알아보고, 이를 기반으로 전역상태 관리 라이브러리의 인터페이스를 분석하고, 사용 방향을 제안하려고 합니다. OOP 에서 접근제어(access control)우리는 왜 설계를 잘 하려고 할까요? 설계를 하는 이유는, 변경을 관리하기 위해서 입니다. 한번 쓰고 없어질 프로젝트라면, 객체지향이니, 함수형이니, 신경쓰지 않고, 동작하는 코드를 짜면 그만이겠죠. 그러나 유지보수 비용을 낮추기 위해 설계가 필요하며, 그 중 대표적인 패러다임으로 객체지향 프로그래밍이 있습니다. OOP 에서 변경을 제어하는 대표적인 방법론이 접근 제어(access control) 입니다..

서언안녕하세요. React OOP(Object-Oriented Programming) 시리즈 1번째 글을 씁니다. React 에 객체지향 원칙을 적용하는 과정을 쓸 것입니다. 객체지향은 객체들간의 역할, 책임, 협력을 잘 명시하여 유지보수를 높이는 방법론입니다. React 에서 함수 컴포넌트도 객체이고, 여러 도메인 로직도 모두 객체일 것입니다. 객체지향 프로그래밍 원칙을 지키면서, 각각의 컴포넌트가 어떤 역할과 책임을 갖고, 상호간에 어떻게 상호작용 할지 고민해보려고 합니다. 오늘은 React 로 OOP 원칙을 지키는 것에 익숙해지기 위해서, 익히 알려진 Anti-Pattern 에 대해 말하고자 합니다. 바로 “setState props 를 지양하기” 입니다. OOP 에서 setter 를 노출시키는 것..

서언 안녕하세요. 최근에 퀄리티 높은 프론트엔드 제품을 만드는 것에 관심이 많은데요. 사소해보이는 디테일을 얼마나 능숙히 처리하느냐가 프론트엔드 개발자의 실력 척도 중 하나라고 생각했어요. 저는 여러 원칙들을 세우고 있지만, 오늘은 중복호출 (aka 따닥)을 방지하는 완벽한 방법을 탐구해볼 것입니다. 문제인식 서비스를 개발하다가, 중복호출이 발생해서 여러 문제가 발생하는 경우가 있습니다. 결제 요청이 2번 들어갈 수도 있고, 게시물 작성이 2번 될 수도 있고, 댓글이 2번 써질 수도 있습니다. 이로 인해 비즈니스적으로도 영향을 미칠 수도 있습니다. 작게는 서버 에러 수가 많아져서, noisy 해질 수 있죠. 이만큼 중요도가 높고, 프론트엔드 퀄리티에 큰 역할을 한다고 생각했는데요. 실제로 저도 명확한 해..

서언 ErrorBoundary 는 하위 컴포넌트에서 발생하는 자바스크립트 에러를 잡아서 fallback UI를 보여주는 React 컴포넌트 입니다. 하지만 하위에 존재하는 컴포넌트에서 에러가 발생한다고 하여, 모든 에러를 잡아주는 것은 아닙니다. React 공식문서에는 다음과 같은 에러는 ErrorBoundary가 포착할 수 없다고 합니다. 과연 저것은 암기해야하는 것들일까요? 그렇지 않습니다. JavaScript 와 React를 잘 이해하고 있다면 당연한 현상입니다. 이 글에서는 에러바운더리가 특정 에러를 포착하지 못 하는 원리를 설명해보려고 합니다. 목차 [사전지식] 실행 컨텍스트와 예외처리 Case1. 이벤트 핸들러 Case2. 비동기적 코드 Case3. 서버 사이드 렌더링 Case4. 자식에서가 ..

서언안녕하세요. React CleanCode 첫 번째 주제로 Composition(합성)을 다룹니다. 최근에 회사에서 많은 코드를 작성하면서 느끼는 것이 있었는데요. 바로 프론트엔드가 다루어야할 관심사가 너무나 많다는 것입니다. 크게는 UI 로직(단순 UI, 애니메이션 로직, 하드코딩적인 요소), 서버 로직(데이터 패칭, 업데이트 로직, 유저 인증인가 로직, 로딩처리, 에러처리), 로그 등 이 있습니다. React를 사용하며 이러한 관심사를 잘 분리하지 않는다면, 스파게티 코드가 된다는 것을 체감했습니다. 그러면 어떻게 관심사의 지옥에서 벗어날 수 있을까요? 즉 관심사를 어떻게 잘 분리해야 할까요? 관심사 분리는 보통 함수(클래스) 분리를 통해 이루어집니다. React에서 함수의 실체는 훅, 컴포넌트, ..

더보기 서언 React v18 부터 Suspense가 API call에 따른 Loading 상태를 표현할 수 있게 되었습니다. 그에 따라, react-query, swr 같은 data fetching library가 Suspense를 지원하고 있습니다. suspense 옵션만 true로 설정해주면, API 요청 훅이 알아서 내부 처리를 통해 Suspense를 동작시킵니다. 이로써 로딩을 선언적으로 보여줄 수 있게 되었고, ErrorBoundary 조합과 함께라면 컴포넌트는 Success 케이스만 표현하면 되었습니다. 이런 혁신에 대해서는 잘 인지하고 있었지만, Suspense의 위험성에 대해서는 인지하지 못 했습니다. 특히 저희 서비스는 잘못된 Suspense 사용으로 어플리케이션 로딩 성능 저하를 겪었..

서언 현재 꼭꼭 서비스를 운영하고 있습니다. 안정적인 서비스 운영, 보다 나은 유저 경험을 제공하기 위해 (1) 섬세하고, (2) 빈틈 없는 에러 처리가 필수라는 생각이 들었습니다. (1) 섬세하다는 것은 상황에 맞는 에러를 적절히 보여 준다는 것을 의미하고, (2) 빈틈 없다는 것은 모든 API 요청에 에러 케이스를 고려한다는 것을 의미합니다. 그러면 고민이 심화됩니다. (1) 에러를 어떤 기준으로 분류하여 처리할 수 있을까? (2) 모든 요청에 에러를 붙인다면, 반복을 줄일 수 없을까? 이를 고민하여 나름대로 에러를 분류해보았고, ErrorBoundary(에러 경계) 라는 도구를 활용해 선언적이고 추상화된 에러 처리를 시도해보았습니다. 본 글은 에러 처리 전략, ErrorBoundary를 다룹니다. ..

react-app(web server)을 배포하기 위하여 vercel이나 netlify와 같은 무료 호스팅 툴을 이용하여 웹 사이트를 배포할 수도 있지만, 트래픽 제한이 있기 때문에 언젠가 AWS 클라우드를 빌려 배포해야할 순간이 올 것입니다. 클라우드 / http 에 대한 정보는 기술하지 않고, 배포 방법에 집중하여 기술하겠습니다.AWS에 문외한인 프론트엔드 개발자를 위해 씁니다. 전체적인 순서는 다음과 같습니다.(1편 - 웹 사이트 배포)1. AWS 가입2. 인스턴스 생성3. 인스턴스에 접근하여 AWS 컴퓨터 로컬 환경 조작4. build 후 웹 사이트 띄우기 (2편 - Custom 도메인과 연결 - with 가비아)1. port 없애기 (3000 -> 80)2. 가비아에서 Name Server 연결..