기능 요구사항은 '신고하기 버튼 클릭시 신고하는 폼으로 이동하기' 였는데, 이 최소 기능만을 구현하고 테스트해보니 사용자 입장에서 신고하는 폼에 필요한 양식들을 작성하기 위해서는 기존 페이지가 변경되지 않는 것이 사용자 경험에 더 좋을 것 같았습니다. 그래서 팀원들과 논의 후 신고하는 폼은 새 탭으로 열리게 하고, 기존 페이지는 이동없이 유지하도록하면서, 기존 기획/디자인에서 있었던 토스트는 삭제하는 방향으로 수정했습니다. 새 탭으로 열리게 하는 것은 다음 코드와 같이 자바스크립트 window 객체의 open 함수로 간단하게 구현할 수 있었습니다.'use client'export default function Page({ params: { userId, messageId },}: { params: {..

사용자가 접근 가능한 최대 라우터는 /messagebox/[userId]/[type]/[messageId]/[options] 인데, 마지막 경로 [options]는 병렬 라우팅으로 생성하고 경로 가로채기를 통해 페이지 상위에 띄우는 방법으로 구현한 페이지와 쪽지에 대한 피드백을 보낼 수 있는 reaction 페이지가 있어서 경로에 맞춰 기능을 구분해야 했습니다. 처음에 단순히 router.back()으로 해결하려 하니 사용자 입장에서 고려했을 때 의도한 바로 뒤로가기가 되지 않던 문제가 있어서, 사용자 경험을 개선하기 위해 복잡한 내비게이션 로직을 관리하고 특정 경로에서 뒤로가기 기능을 구현하기 위한 커스텀 훅을 개발했습니다. 아래는 router.back() 이었을 때 현상입니다https://youtu...

이전에 투두태스크 프로젝트를 진행하던 팀 저장소를 fork해와서 개인 레포에서 AWS Amplify로 배포했는데, 변경 사항을 양쪽에 다 push 해줘야 했던 번거로움을 느꼈던 경험이 있었습니다.Amplify로 진행했을 때 들었던 게 Next.js로 배포를 한다고 하면 vercel이 같은 회사라서 연동이 쉽고 CICD를 잘 구축해둬서 많이 사용한다는 말을 들은 적이 있었습니다.웹서버 구축에 어려움을 느끼고 있던 때 Vercel로 어렵지 않게 하면 안되나? 싶어서 해보았는데, 작업을 끝내고 찾아보니까 Vercel을 웹서버로 사용하는 게 가능할 수는 있지만 Vercel의 서버리스 한계와 성능을 고려하지 못했다는 것을 깨달았고, 이후 AWS EC2와 Nginx를 사용해서 웹서버를 구축하는 방향으로 변경했습니다..

이전에 offset 기반 무한스크롤을 구현했을 때는 스크롤 이벤트를 사용해서 뷰포트를 감지하고 데이터를 추가로드하도록 했었는데, 자바스크립트 문서를 쭉 읽어보다가 페이지 내에 각 요소가 각각의 목적(광고, 레이지 로딩, 무한 스크롤 등)의 이유로 scroll 이벤트를 리스닝하기 때문에 이에 상응하는 콜백이 무수히 실행될 수도 있고 이는 메인 스레드에 큰 부하를 줄 수 있다는 것을 알게 되었습니다. 그래서 다른 구현 방법을 알아보다가 타겟 요소와 뷰포트의 교차점을 비동기적으로 관찰해서 요소가 뷰포트에 포함되는지 아닌지 구별하는 기능을 제공하는 Intersection Observer API를 알게 되었습니다. 스크롤 이벤트와 비교했을 때 throttling/debouncing이 불필요하다는 점, 비동기 처리..