🧐 들어가며: 타입 문법이 갑자기 어려워지는 순간 TypeScript를 쓰다 보면 처음에는 string, number, boolean 정도만 알아도 꽤 많은 코드를 작성할 수 있습니다. const name: string = "taewok"; const age: number = 20; const isAdmin: boolean = false; 그런...

🧐 들어가며: 애니메이션은 왜 어렵게 느껴질까요? React에서 애니메이션을 만들다 보면 처음에는 간단해 보입니다. 버튼에 hover 효과를 주거나, 모달이 열릴 때 살짝 나타나는 정도는 CSS transition으로도 충분합니다. 하지만 조금만 복잡해지면 고민이 생깁니다. 컴포넌트가 사라지기 전에 exit 애니메이션을 보여주고 싶을 때 ...

🧐 들어가며: 단순히 setTimeout을 쓰면 안 될까요? 태그 Overflow UI를 구현하던 중이었습니다. 부모 영역의 크기에 따라 태그가 줄바꿈되는지 계산하기 위해 각 태그의 offsetTop을 측정해야 했습니다. 그런데 이상하게도 어떤 순간에는 측정값이 예상과 다르게 나왔어요. 처음에는 이렇게 바로 측정했습니다. useLayoutEff...

🧐 들어가며: 모달이 하나일 때와 여러 개일 때는 달라요 이번 프로젝트에서는 여러 모달을 전역에서 관리하기 위해 Zustand 기반의 모달 시스템을 사용하고 있습니다. 처음에는 단일 모달을 여닫는 정도의 구조였습니다. 예를 들어 로그인 모달을 열고, 닫기 버튼을 누르면 닫히는 단순한 방식이었어요. 하지만 서비스가 커지면서 모달을 하나만 관리하는 ...

🧐 들어가며: 태그가 많아지면 카드 높이가 흔들려요 카드 UI를 만들다 보면 태그 목록을 자주 다루게 됩니다. 예를 들어 이런 형태예요. #소꿉친구 #장난스러움 #츤데레 #학교 #청춘 #짝사랑 #일상 문제는 태그 개수가 많아질수록 카드 높이가 들쭉날쭉해진다는 점이었어요. 카드 목록에서는 높이가 어느 정도 일정해야 화면이 정돈되어 보이기 때문에...

🧐 들어가며: 폼 상태 관리 다음에는 검증 구조가 복잡해져요 이전 글에서는 React Hook Form을 사용해 회원가입 폼과 캐릭터 생성 폼의 상태를 관리한 경험을 정리했습니다. React Hook Form은 입력값, 에러, 동적 배열, isDirty 같은 폼 상태를 하나의 흐름으로 다룰 수 있게 해줍니다. 하지만 폼이 커질수록 또 다른 문제가 ...

🧐 들어가며: 폼은 생각보다 많은 책임을 가져요 프론트엔드에서 폼은 단순한 input 모음처럼 보이지만, 실제 서비스에서는 꽤 많은 책임을 가집니다. 입력값 저장, 유효성 상태, 에러 메시지, 파일 업로드, 동적 리스트, 미리보기, 페이지 이탈 방지까지 모두 폼과 연결됩니다. 필드가 몇 개 없을 때는 useState만으로도 충분하지만, 폼이 커지는...

🧐 들어가며: 서버에서 가져온 데이터를 클라이언트에서도 다시 요청해야 할까요? Next.js App Router를 사용하면 서버 컴포넌트에서 데이터를 미리 가져온 뒤 화면을 렌더링할 수 있습니다. 첫 화면에 필요한 데이터를 서버에서 준비할 수 있기 때문에 초기 로딩 경험을 개선하는 데 유리합니다. 하지만 클라이언트 컴포넌트에서 같은 데이터를 use...

🧐 들어가며: 화면 크기보다 컴포넌트 크기가 더 중요할 때 반응형 UI를 만들 때 가장 익숙한 도구는 미디어 쿼리입니다. @media (min-width: 768px) { /* tablet 이상 스타일 */ } 미디어 쿼리는 브라우저의 뷰포트 너비를 기준으로 스타일을 바꿉니다. 대부분의 레이아웃에서는 충분히 유용합니다. 하지만 컴포넌트 기...

🧐 들어가며: 작성 중인 폼을 그냥 떠나면 안 될 때 게시글 작성, 캐릭터 생성, 결제 정보 입력처럼 시간이 오래 걸리는 화면에서는 사용자가 실수로 페이지를 떠나는 상황을 막아야 합니다. 특히 작성 중인 내용이 저장되지 않았는데 뒤로가기를 누르거나 다른 링크를 클릭하면, 사용자는 입력한 내용을 잃어버릴 수 있습니다. 예전 Next.js Pages...