mirabo01 님의 블로그

React Hook Form을 쓰다 보면 금세 이런 고민이 생깁니다."검증 로직이 자꾸 길어지네?", “백엔드에서 유효성 검증도 하는데, 클라이언트는 또 따로 써야 하나?”저도 예전엔 minLength, pattern 같은 옵션으로만 검증을 처리했는데,폼이 복잡해질수록 코드가 점점 흩어지고 관리가 어려워졌습니다.그때 알게 된 게 zod였습니다.React Hook Form과 찰떡궁합으로 쓰이는 스키마 검증 라이브러리죠.처음엔 조금 생소했지만, 지금은 거의 모든 폼에 붙여서 씁니다.예전엔 이런 식으로 썼다처음에는 React Hook Form의 기본 옵션만으로 폼을 검증했습니다.이 방식이 나쁜 건 아닙니다.단순한 폼에서는 딱 이 정도만으로 충분하죠.하지만 회원가입, 결제, 설정 관리처럼 폼 필드가 열 개 이상..

React로 폼을 만들다 보면 “입력값이 제대로 들어갔는지”, “에러 메시지를 언제 보여줄지”, “제출할 때 상태가 맞는지” 등생각보다 챙겨야 할 게 정말 많습니다.저도 초창기에는 useState로 모든 input 값을 관리했는데,폼이 조금만 커져도 코드가 금세 복잡해지더군요.그런데 React Hook Form을 쓰고 나서부터는 폼 관리가 한결 편해졌습니다.특히 입력값 검증, 초기값 세팅, 제출 이벤트를 일관된 방식으로 다룰 수 있어서실무에서 가장 자주 쓰는 훅 중 하나가 됐습니다.예전엔 useState만으로 버텼던 시절처음엔 단순히 이렇게 코드를 짰습니다.const [email, setEmail] = useState('');const [password, setPassword] = useState('')..

React로 개발을 하다 보면 ‘로딩’과 ‘에러’는 정말 피할 수 없는 친구들입니다.처음엔 단순히 isLoading이나 isError 같은 조건문으로 해결하려고 하지만,프로젝트가 커질수록 코드가 꼬이고 화면이 깜빡이는 현상도 생기죠.저도 예전에 대시보드 페이지를 만들 때,데이터가 많아지니까 로딩 상태 처리만으로도 코드가 한참 복잡해졌던 기억이 있습니다.그때 처음 알게 된 개념이 바로 Suspense와 Error Boundary였습니다.이걸 몰라서 한참 헤맸던 시절React에서 데이터를 불러올 때 대부분 이렇게 시작합니다.const { data, isLoading, isError } = useQuery(['user'], fetchUser);이런 구조는 직관적이지만,페이지 곳곳에서 로딩 상태를 처리해야 하다..

리액트를 조금이라도 써본 사람이라면 언젠가 꼭 부딪히는 개념이 있습니다.바로 라우팅(Routing) 입니다.“컴포넌트는 잘 나누겠는데, 페이지 이동은 어떻게 하지?”이 고민은 대부분의 리액트 입문자가 한 번쯤 겪습니다.오늘은 React Router v6를 기준으로,리액트에서 페이지 전환이 실제로 어떻게 동작하는지,그리고 실무에서 어떤 식으로 구성하면 좋은지제가 직접 프로젝트에서 겪은 경험을 바탕으로 정리해보려 합니다.React Router란?리액트는 기본적으로 “싱글 페이지 애플리케이션(SPA)” 구조입니다.즉, 페이지가 전환돼도 브라우저가 새로고침되지 않습니다.React Router는 이 SPA 구조 안에서URL을 기반으로 다른 컴포넌트를 보여주는 역할을 합니다.결국 라우터의 핵심은“URL에 따라 어떤..

React를 조금 다뤄본 사람이라면 useEffect를 안 쓸 수 없습니다.API 호출, 이벤트 등록, 타이머 설정, 외부 상태 동기화 등 거의 모든 “부수효과(Side Effect)” 처리가 이 훅에 들어갑니다.하지만 많은 초보자들이 useEffect를 ‘렌더링 직후 실행되는 함수’ 정도로만 이해하고 있어서,원치 않는 무한 루프나 타이밍 꼬임을 겪곤 합니다.이번 글에서는 useEffect가 정확히 언제, 어떻게 동작하는지React의 렌더링 흐름과 연결해가며 구체적으로 설명하겠습니다.useEffect는 언제 실행되는가React 컴포넌트는 다음 순서로 실행됩니다.렌더링(Render): 컴포넌트 함수가 실행되어 Virtual DOM 생성커밋(Commit): 변경된 부분이 실제 DOM에 반영이후에 useEff..

리액트를 좀 써보다 보면, ‘렌더링이 왜 이렇게 자주 일어나지?’ 혹은 ‘이 함수가 왜 또 호출되지?’ 같은 궁금증이 생깁니다.이건 단순히 코드의 문제가 아니라 React의 렌더링 메커니즘을 제대로 이해하지 못해서 생기는 자연스러운 현상입니다.이번 글에서는 React 내부의 렌더링 구조를 실제 동작 흐름 중심으로 풀어보겠습니다.React의 렌더링 사이클이란React는 UI를 함수처럼 다룹니다.“상태(state)가 바뀌면 함수가 다시 실행되고, 그 결과를 UI로 보여주는 구조”입니다.이 과정을 크게 세 단계로 나누면 다음과 같습니다.렌더(Render)컴포넌트 함수가 다시 실행되어 React Element 트리를 새로 만듭니다.커밋(Commit)새로 만들어진 React Element를 실제 DOM에 반영합니..

React를 조금이라도 써봤다면 “리렌더링”이라는 단어를 수도 없이 들었을 겁니다.리렌더링은 React의 핵심 동작이자, 동시에 가장 큰 성능 병목이 되기도 합니다.이번 글에서는 실제 프로젝트에서 리렌더링 때문에 성능이 떨어졌던 경험을 바탕으로,그 원인을 어떻게 파악하고 최적화했는지 정리했습니다.성능이 떨어지는 진짜 이유React는 상태(state)나 props가 변경되면 컴포넌트를 다시 렌더링합니다.이건 의도된 동작이지만, 규모가 커지면 불필요한 렌더링이 눈덩이처럼 불어납니다.예를 들어 이런 상황을 본 적 있을 겁니다.하나의 상위 컴포넌트가 있고, 그 안에 수십 개의 하위 컴포넌트가 있는 구조에서상태가 변경되면, 전혀 관련 없는 하위 컴포넌트들까지 모두 다시 그려지는 현상 말이죠.제가 실제로 작업하던 ..

프로젝트가 커질수록 “상태”는 점점 복잡해집니다.서버에서 가져온 데이터도 있고, 클라이언트 내부에서만 쓰는 상태도 있죠.문제는 이 둘을 한데 섞어버리면 유지보수가 어려워진다는 겁니다.그래서 저는 요즘 대부분의 프로젝트에서React Query + Zustand 조합을 기본 구조로 사용합니다.서버 상태는 React Query가, 클라이언트 상태는 Zustand가 관리하게 분리하는 방식입니다.두 라이브러리는 서로 간섭하지 않으면서, 필요한 시점에 자연스럽게 연결됩니다.React Query는 “서버 상태 관리자”React Query는 서버와 관련된 모든 데이터를 담당합니다.API 요청, 캐싱, 리패치, 에러 처리 같은 서버 중심의 상태를 자동으로 관리해주죠.예를 들어, 게시글 목록을 불러온다고 가정해봅시다.im..

React에서 전역 상태를 관리할 때 보통 세 가지 선택지가 있습니다.Context API, Redux, 그리고 최근 많이 쓰이는 Zustand.그중에서도 Zustand는 “단순함”으로 승부하는 라이브러리입니다.처음 Zustand를 접했을 땐,‘이게 전역 상태 관리라고 할 수 있나?’ 싶을 정도로 코드가 간단했습니다.하지만 몇 번 프로젝트에 적용해보니,이 단순함이 얼마나 강력한 장점인지 알게 됐습니다.왜 Zustand인가Context API는 좋은 도구지만,컴포넌트 트리 깊숙이 들어간 상태를 자주 갱신할 때 성능 문제가 생길 수 있습니다.Redux는 기능은 강력하지만 설정이 복잡하고 코드가 장황해지기 쉽죠.Zustand는 그 중간 지점에 서 있습니다.가볍고 빠르며, 보일러플레이트 코드가 거의 없습니다.설..

React 18이 나오면서 가장 크게 달라진 개념 중 하나가 바로 **비동기 렌더링(Concurrent Rendering)**입니다.이전까지는 데이터가 오기 전까지 화면이 멈추는 게 당연했는데,이제는 React가 렌더링 중에도 다른 작업을 병렬로 처리하면서더 부드럽고 자연스러운 사용자 경험을 만들 수 있게 됐죠.그 중심에는 Suspense와 Error Boundary라는 두 가지 기능이 있습니다.이 둘은 단순히 로딩 스피너를 보여주는 역할을 넘어서,React 애플리케이션의 “안정성과 부드러움”을 책임지는 핵심 기술입니다.Suspense, 그동안 몰랐던 진짜 역할Suspense를 처음 봤을 때는 단순히“데이터 로딩 중일 때 대체 화면을 보여주는 도구” 정도로만 생각했습니다.하지만 실제로 써보면 그 이상의 ..