Frontend

이벤트에 응답하기이벤트 핸들러는 클릭, 마우스 호버, 폼 입력, 포커스 등사용자 상호작용에 반응해 실행되는 사용자 정의 함수이다.React에서는 JSX에 함수를 전달하는 방식으로 이벤트를 처리한다.이벤트 핸들러 추가하기export default function Button() { function handleClick() { alert("You clicked me"); } return I don't do anything;}위 코드에서 handleClick은 이벤트 핸들러이다.이벤트 핸들러의 특징 ✍️보통 컴포넌트 내부에서 정의된다handle로 시작하고 이벤트 이름을 뒤에 붙이는 경우가 많다JSX에는 호출이 아니라 전달한다onClick={handleClick} // ✅onClick={ha..

리스트 렌더링 (Rendering Lists)React에서는 배열 데이터를 기반으로 JSX를 반복 렌더링하는 경우가 매우 많다.이 과정에서 map()을 사용해 리스트를 만들 수 있었고, 이때 key의 중요성을 함께 이해하게 되었다 🧠배열을 데이터로 렌더링하기const people = [ "Creola Katherine Johnson: mathematician", "Mario José Molina-Pasquel Henríquez: chemist", "Mohammad Abdus Salam: physicist", "Percy Lavon Julian: chemist", "Subrahmanyan Chandrasekhar: astrophysicist",];export default function Lis..

조건부 렌더링 정리 (React)React에서 조건에 따라 JSX를 렌더링하는 방법은 여러 가지가 있다.공식 문서에서는 상황에 맞게 다양한 패턴을 사용하라고 권장하고 있으며, 각 방식마다 쓰임새가 명확히 다르다 ✍️아래는 실제로 사용하면서 정리한 조건부 렌더링 선택 기준이다.1️⃣ 조건부로 JSX 반환하기 (if / return)function Item({ name, isPacked }) { if (isPacked) { return {name} ✅; } return {name};}가장 직관적인 방식이다.조건에 따라 완전히 다른 JSX를 반환해야 할 때 사용하기 좋았다.조건 분기가 명확할 때 👍JSX 구조가 크게 달라질 때 👍early return 패턴으로 읽기 쉬웠다2️⃣ 조건부로 null..

🧠 Tanstack Query 캐싱 메커니즘 이해하기React Query(Tanstack Query)는 서버 상태 캐싱을 통해 불필요한 네트워크 요청을 줄이고,사용자 경험을 개선해준다.이번 글에서는 쿼리의 생명주기와 캐싱 메커니즘을 실제 예제를 통해 정리해봤다.🔄 쿼리 생명주기 한눈에 보기fetching → fresh → stale → inactive → deleted 각 상태는 쿼리가 언제 패칭되고, 언제 재사용되며, 언제 메모리에서 제거되는지를 결정한다. 🔄 Fetching서버에 데이터 요청을 보내고 있는 상태다.아직 응답을 받지 못해 캐시 데이터가 없거나 갱신 중이다.✅ Fresh서버에서 받아온 데이터가 신선하다고 판단되는 상태다.staleTime 이내의 데이터로, 리페칭 없이 그대로 사용된다..

InMyDay문제 배경체험 수정 페이지(ExperienceEditPage)에서이미 예약이 존재하는 일정을 삭제한 상태로 수정 요청을 보내면,백엔드에서 “예약된 일정은 삭제 불가” 에러를 반환했다.에러 자체는 정상적으로 처리되었지만,문제는 그 이후 UI 상태였다.서버에서는 삭제가 실패했는데프론트엔드 UI에서는 일정이 이미 삭제된 것처럼 유지됨결과적으로 사용자는“삭제가 된 건지, 안 된 건지”를 판단할 수 없는 상태에 놓이게 됐다.즉, 에러는 발생했지만 UI가 서버 상태로 복구되지 않는 문제였다.🔍 원인 분석이 문제는 단일 원인이 아니라서버 / 캐시 / 로컬 상태 / UI 컴포넌트 상태가 동시에 어긋난 구조에서 발생했다.구분원인1Mutation 실패 후 onError에서 UI 복구 로직이 없었음2React..

InMyDayExperienceEditPage 뒤로가기 이탈 감지 로직 안정화체험 수정 페이지(ExperienceEditPage)에서 폼 작성 중 뒤로가기를 클릭하면 이탈 확인 모달을 노출하도록 구현했다.초기 구현에서는 정상 동작하는 것처럼 보였지만, 테스트 과정에서 뒤로가기 이탈 감지가 한 번만 동작하는 문제가 발견됐다.🧩 문제 배경ExperienceEditPage에서 다음과 같은 흐름을 의도했다.폼 수정(isDirty 상태) 중 뒤로가기 클릭→ 이탈 확인 모달 표시“아니오” 클릭 시 페이지 유지이후 다시 뒤로가기를 눌러도 동일하게 이탈 모달 표시하지만 실제 동작은 달랐다.뒤로가기 첫 번째 클릭 → 이탈 모달 정상 표시“아니오” 클릭 후 다시 뒤로가기 → ❌ 이탈 모달 미표시즉, 이탈 감지가 1회만 ..

문제는 그 다음이었다 😶combine까지 정리하고 나서다음으로 자연스럽게 이어진 게 아래의 미들웨어였다.immersubscribeWithSelectorpersistdevtools한두 개도 아니고, 여러 개가 한 번에 등장했다.각각에 대한 설명은 있었지만, 처음엔 이런 느낌에 더 가까웠다.“개념 설명은 듣긴 했는데, 크게 와닿지는 않는다.” Zustand를 처음 접한 상태에서미들웨어까지 한 번에 이해하기엔정보량이 생각보다 많았다.불변성을 관리해준다는데, 지금 당장 체감은 잘 안 됐고 🤷‍♀️특정 값을 구독한다고 하는데, 언제 써야 할지 감이 안 왔고상태를 저장한다는 것도 그냥 옵션처럼 느껴졌고devtools는 있으면 좋겠지만 필수처럼 보이진 않았다 🧩정리하면 첫인상은 이랬다.👉 “없어도 동작은 할 ..

왜 굳이 combine을 쓰는 걸까?Zustand를 쓰다 보면state랑 action을 한 객체 안에 다 때려 넣는 방식이 가장 먼저 떠오른다.export const useStore = create((set) => ({ count: 0, increase: () => set(...)}));​ 처음엔 이게 제일 직관적이고 문제도 없어 보인다.근데 상태가 조금만 늘어나고, 타입스크립트를 같이 쓰기 시작하면 store 타입 정의가 점점 귀찮아지기 시작했다.😑그래서 Zustand에서 제공하는 미들웨어 중 하나인 combine을 공부해보기로 했다. combine은 뭘 해주는 미들웨어일까?combine은 한 줄로 요약하면 이거다.타입 추론 + 역할 분리를 동시에 도와주는 미들웨어combine을 사용하면state..