mirabo01 님의 블로그

1. 리스트 렌더링이란?리액트에서 배열 데이터를 화면에 표시하려면단순히 하나씩 나열하는 대신 **반복문(map)**을 이용해 렌더링합니다.예를 들어, 사용자 목록을 렌더링한다고 가정해봅시다.function UserList() { const users = ['기범', '지수', '민준', '수현']; return ( {users.map((user) => ( {user} ))} );}이렇게 하면 users 배열의 각 요소가 형태로 출력됩니다.리액트는 map()의 반환값을 자동으로 인식해, JSX 요소 리스트로 변환합니다.하지만 여기서 중요한 점은 — 모든 반복된 요소에는 key가 필요하다는 것입니다.2. Key 속성이 필요한 이유리액트는 Virtual DO..

1. 리액트에서의 이벤트 처리란?HTML에서는 클릭 이벤트를 처리할 때 이렇게 작성합니다.버튼하지만 리액트에서는 이벤트를 문자열이 아닌 함수로 전달합니다.또한 HTML의 이벤트 이름은 소문자지만,리액트에서는 **CamelCase(낙타 표기법)**으로 작성해야 합니다.function App() { function handleClick() { alert('클릭되었습니다!'); } return 버튼;}즉, HTML의 onclick → React의 onClick,onchange → onChange 처럼 표기 방식이 달라집니다.2. 이벤트 객체(Event Object)이벤트가 발생하면 리액트는 이벤트 정보를 **SyntheticEvent(합성 이벤트)**라는 형태로 전달합니다.이는 브라우저 간의 차이를..

1. 생명주기(Lifecycle)란?리액트에서 컴포넌트는 생성되고, 업데이트되고, 사라지는 흐름을 가지고 있습니다.이 과정을 **컴포넌트의 생명주기(Lifecycle)**라고 부릅니다.쉽게 말하면, 리액트 컴포넌트도 사람처럼“태어남 → 변화함 → 사라짐”의 과정을 겪는다는 뜻입니다.이 생명주기를 이해하면 다음과 같은 일들을 더 효율적으로 처리할 수 있습니다.API 데이터를 컴포넌트가 처음 렌더링될 때 불러오기특정 상태가 바뀔 때만 실행되는 로직 제어컴포넌트가 사라질 때 정리(clean-up) 작업 수행2. 클래스형 컴포넌트의 생명주기 메서드리액트 초창기에는 클래스형 컴포넌트에서 생명주기 메서드를 사용했습니다.아래 코드는 기본적인 구조를 보여줍니다.import React, { Component } from..

요즘 개발자들 사이에서 Cursor 2.0 이야기가 많이 들리더군요. 예전 버전에서도 꽤 괜찮다는 평가가 있었는데, 이번 업데이트는 확실히 ‘다른 단계’에 올라섰다는 느낌입니다.저도 관련 소식을 찾아보다가, “이건 그냥 코드 자동 완성이 아니라, 진짜로 개발 과정을 함께하는 도구”라는 생각이 들었어요. 이번 글에서는 Cursor 2.0이 어떤 방향으로 바뀌었는지, 그리고 실제로 우리가 느낄 수 있는 변화가 무엇인지 차분히 정리해봤습니다.완전히 새로워진 에이전트 중심 구조 이번 Cursor 2.0의 핵심은 ‘에이전트 중심(Agent-first)’ 구조입니다. 이전에는 AI가 입력한 코드 맥락 안에서 추천을 주거나 리팩토링을 도와주는 정도였다면, 이제는 여러 AI 에이전트가 실제로 협업하면서 코드를 만들어가..

비동기 요청을 처리하다 보면 이런 순간이 자주 있습니다.좋아요 버튼을 눌렀는데, 반응이 1~2초 늦게 오는 경우요.사실 요청이 성공했는지 실패했는지는 중요하지 않습니다.사용자는 그저 ‘눌렀을 때 바로 반응이 오는가’를 체감할 뿐입니다.이걸 해결하는 핵심 개념이 바로 **옵티미스틱 업데이트(Optimistic Update)**입니다.React Query를 쓰면 이걸 정말 간단하게 구현할 수 있습니다.서버의 응답을 기다리지 않고,UI가 “먼저 결과를 보여주는” 구조입니다.예전엔 이렇게만 생각했습니다초반엔 단순히 버튼을 누르면 로딩 스피너를 띄우고,응답이 오면 상태를 바꾸는 식으로만 코드를 짰습니다.const handleLike = async () => { setIsLoading(true); await a..

React Query를 쓰다 보면 정말 자주 부딪히는 문제가 있습니다.“상세 페이지에서 데이터를 수정했는데, 목록 페이지는 그대로다.”처음엔 단순히 새로고침으로 해결했지만,프로젝트 규모가 커질수록 이런 불일치가 UX를 크게 해칩니다.특히 관리자 페이지나 대시보드처럼데이터가 여러 컴포넌트에 동시에 뿌려지는 구조에서는이 문제를 제대로 잡지 않으면 서비스 전체가 불안정해집니다.이번 글에서는 React Query로한 곳에서 데이터가 바뀌면 모든 관련 화면이 즉시 반영되는 구조를어떻게 구현했는지 정리해보려 합니다.페이지마다 상태가 따로 놀던 시절React Query를 도입하기 전에는데이터를 컴포넌트별로 useEffect와 useState로 관리했습니다.useEffect(() => { axios.get('/api..

리액트 프로젝트를 하다 보면,“리스트에서 상세 페이지로 넘어갈 때 로딩이 살짝 걸리는” 그 순간이 늘 아쉽습니다.데이터가 많지 않아도, 네트워크 요청이 새로 일어나니까사용자는 매번 짧은 ‘멈춤’을 경험하게 됩니다.저는 이 문제를 해결하기 위해 여러 가지 방법을 써봤는데,그중 가장 확실하게 체감된 게 바로 React Query의 prefetch 기능이었습니다.말 그대로 “사용자가 클릭하기 전에 데이터를 미리 가져오는” 기법이죠.처음엔 단순히 캐시가 오래 남는 줄 알았다React Query의 캐시를 익히면서 “데이터가 남아 있으니 괜찮겠지”라고 생각했습니다.하지만 캐싱은 ‘한 번이라도 가져온 적이 있는’ 데이터에만 적용됩니다.즉, 아직 들어가보지 않은 페이지의 데이터는 여전히 로딩이 필요합니다.그걸 해결해주..

React Query를 써본 사람이라면 한 번쯤 이런 경험이 있을 겁니다.목록 페이지에서 디테일 페이지로 갔다가 뒤로 돌아오면,목록이 다시 로딩되면서 화면이 살짝 깜빡이는 현상.성능 문제는 아닌데, 이 작은 깜빡임이 서비스 완성도를 확 떨어뜨립니다.저도 초반엔 단순히 “UX가 살짝 어색하네” 정도로 넘겼는데,결국 이걸 해결하려면 React Query의 캐싱 동작을 이해하는 게 핵심이었습니다.왜 깜빡이는 걸까React Query는 기본적으로 데이터를 캐싱합니다.그런데 캐시라고 해서 무조건 영구 저장되는 게 아닙니다.데이터는 staleTime과 cacheTime에 따라 언제든지 만료될 수 있습니다.staleTime: 데이터가 ‘신선한(fresh)’ 상태로 유지되는 시간cacheTime: 데이터가 ‘비활성화된..

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