mirabo01 님의 블로그

React Query를 프로젝트에 도입한 이후,가장 체감이 컸던 부분은 비동기 요청의 상태를 눈으로 바로 확인할 수 있게 된 것이었습니다.하지만 그 상태가 화면에만 머물면,정작 사용자는 아무런 피드백을 받지 못합니다.버튼을 눌렀는데 아무 일도 안 일어나는 듯한 상황,“잘 눌린 건가?” 싶은 그 2~3초의 공백이 UX를 망칩니다.그래서 이번에는 React Query와 Toast 알림 시스템을 연결해사용자에게 명확한 피드백을 주는 방법을 정리해봤습니다.단순한 기능이지만 체감은 확실하다처음 React Query를 썼을 땐, 로딩 스피너 하나면 충분하다고 생각했습니다.그런데 사용자가 서버 응답을 기다리는 동안무언가 ‘눈에 띄는 반응’이 없으면“버그인가?” “멈췄나?” 같은 불안감을 느끼는 걸 자주 봤습니다.실무..

React Hook Form을 쓰다 보면 결국 마주치게 되는 단계가 있습니다.“이제 폼 데이터를 서버에 보내야 하는데, 어디서 API 요청을 처리하지?”이 지점에서 React Query를 함께 사용하면 폼과 서버 간의 흐름이 놀랄 만큼 깔끔해집니다.이 강의에서는 React Hook Form의 handleSubmit과 React Query의 useMutation을 결합해,폼 제출 시 비동기 요청을 어떻게 구조적으로 다룰 수 있는지 정리해보겠습니다.예전엔 이렇게 했다가 코드가 엉망이 됐다처음에는 React Hook Form만 쓰고, fetch나 axios로 직접 요청을 보냈습니다.const onSubmit = async (data) => { try { const res = await axios.pos..

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..