react

Intro시작하기에 앞서 두 개의 코드 스니핏을 보여드리겠습니다. 어떤 차이가 있을까요?참고로 Counter 컴포넌트의 로직은 같습니다. 이번 글에서 다룰 내용은 아래 두 코드의 차이에 대한 설명입니다. 바로 맞추신 분들은 자신있게 뒤로가기를 누르셔도 됩니다.// 1️⃣ 삼항 연산자function Scoreboard() { const [isPlayerA, setIsPlayerA] = useState(true); return ( {isPlayerA ? ( ) : ( )} { setIsPlayerA(!isPlayerA); }}> Next player! );}// 2️⃣ && 연..

Intro리액트 공식 문서의 Escape Hatches메뉴에 5가지의 effect에 대한 문서가 있습니다. 이 개념을 위해 이렇게 많은 설명이 필요한걸까요? useEffect에서 effect는 무엇을 의미할까요? 제대로 사용하기 위한 첫 걸음은 정확한 멘탈 모델을 세우는 것입니다. 많은 문제가 여기에서 출발합니다. 그리고 이 문제들을 해결하는 쉬운 방법은 lint의 경고를 준수하는 것입니다.function Page({ url }) { const { items } = useContext(ShoppingCartContext); const numberOfItems = items.length; useEffect(() => { logVisit(url, numberOfItems); // 🔴 린트 ..

IntrouseState에서 useReducer로, 상태 공간을 줄이는 설계 React에서 폼 UI를 구현할 때 가장 흔한 접근은 여러 개의 useState를 조합하는 방식입니다.const [answer, setAnswer] = useState('');const [error, setError] = useState(null);const [status, setStatus] = useState('typing'); 이 세 가지 값만 보더라도 폼의 상태를 표현하는 데 필요한 정보는 충분해 보입니다.하지만 이 구조에는 한 가지 중요한 문제가 있습니다.논리적으로 불가능한 상태가 “가능”해진다UI 관점에서 다음 상태는 명백히 모순입니다.status === 'success' 인데 error !== nullstatus =..

Intro프론트엔드 개발자라면 한 번쯤 이런 상황을 겪어보셨을 겁니다.오, 이 컴포넌트랑 저 컴포넌트 모양이 비슷하네. 그냥 공통 컴포넌트로 빼자. 당장에는 좋은 판단처럼 보이지만, 겉보기의 유사성만으로 추상화를 하게 되면 시간이 흘러 여러가지 책임이 혼재된 몬스터 모듈이 되기 쉽습니다. 따라서 같은 이유로 수정되는 코드가 명확한 책임의 범위를 가질 때 추상화를 해야합니다. 좀 풀어서 이야기하면 이 모듈이 수정되어야 하는 이유는 하나이여야 하며 그러기 위해서는 모듈의 책임이 명확해야 합니다. 여러가지 역할을 책임지게 되면 모듈이 수정되는 이유가 많아지게 되고 관리가 어려워집니다. 모듈의 책임이 모호하거나 책임의 범위가 넓어도 어디까지를 이 모듈의 책임으로 봐야할지 혼동되면서 모듈이 비대해집니다. 이번 글..

IntroFeature-Sliced Design(FSD)을 이야기할 때 흔히 “어디까지 나눌 것인가”에 집중합니다.하지만 실제로 유지보수 비용을 결정짓는 요소는 폴더의 개수가 아니라 의존성의 형태와 영향 범위입니다.이 글에서는 다음 질문에 답하려 합니다.변경이 발생했을 때, 의존 관계에 있는 코드들이 같은 위치에 모여있는가? (co-location)해당 변경의 영향 범위를 구조적으로 제한하고 있는가영향 범위가 명확해졌을 때, 계층 이동이 자연스럽게 일어나는가시나리오로 보는 “응집된 의존성”장바구니(cart) 페이지를 예로 들어보겠습니다.페이지 내부에 캡슐화된 구조pages/cart ├─ ui │ ├─ CartPage │ ├─ CartSummary │ └─ FreeShippingNotice └─ mo..

Intro 위 사진은 리액트 공식 홈페이지 메인 화면입니다. 여기서 주목해야 하는 것은 library라는 표현입니다.React를 라이브러리라고 하는 이유는 UI를 어떻게 구성할지에만 집중하고, 애플리케이션의 전체 구조나 흐름을 강제하지 않기 때문입니다.라우팅, 상태 관리, 데이터 패칭 같은 핵심 요소를 자체적으로 포함하지 않고 선택을 개발자에게 맡깁니다.즉, 이러한 자율성으로 인해 시간이 지날수록, 서로 다른 목적의 로직이 한 파일에 뒤섞인 구조를 만들기 쉽습니다.특히 UI 로직과 비즈니스 로직이 구분되지 않은 코드는, 당장은 잘 동작하지만 시간이 흐를수록 기술 부채가 되기 쉽습니다.아래 코드는 실제 현업에서 매우 흔하게 볼 수 있는 예시입니다.// @feature/user/ui/user-invite-d..

들어가며 기능만 쌓다가 어느 순간 FCP가 너무 느려진 걸 체감하게 됐습니다.연말에 묵힌 때를 지울 겸 메인 번들 최적화 작업을 진행했고 그 과정을 공유합니다.1. SideEffects 필드미사용 모듈(dead code, 죽은 나뭇잎)을 제거하는 것을 죽은 나뭇잎을 제거하는 것에 비유하여 tree shaking이라고 합니다. 트리쉐이킹을 위해선 미사용 코드를 제거했을 때 문제가 없음을 모듈 번들러에 알려야 하는데 그 필드가 바로 sideEffects 필드입니다. 이 맥락에서 말하는 대표적 side-effects로는 아래와 같은 상황들이 있습니다.CSS 가져오기전역 객체를 수정하는 폴리필글로벌 이벤트 리스너를 등록하는 라이브러리프로토타입 체인을 수정하는 코드💡 사이드 이팩트는 하나 이상의 export를..

서론이제는 표준처럼 취급되는 react-query에 대해 이야기해볼까 합니다.이 도구를 왜 쓰는걸까요? 이 도구가 어떤 문제를 책임지고 있을까요? 처음 도구가 공개된지 꽤 시간이 지난 지금 여전히 이 도구의 존재 의미는 유효할까요? 이 글은 다음 개발자를 대상으로 합니다:왜 쓰는지 다른 개발자에게 설명하기 어려운 개발자학원에서 React Query쓰라고 해서 쓰는 개발자기존 프로젝트에서 사용해서 별 고민없이 쓰는 개발자.Zustand 등 전역 스토어로 서버 데이터를 다루던 개발자서버 상태와 클라이언트 상태를 명확하게 구분하고, React Query가 왜 등장했고 지금 어떤 가치를 제공하는지 정리해봅니다.1. Client State vs Server State리액트 쿼리는 전역 상태로 포괄적으로 분류되던 ..