더취페이 프로젝트

놀랍게도 해당 제목은 chatGPT가 결정해줬습니다. 이 마음을 표현할 수 있는 건 애니st 제목밖에 없을거라고 생각했는데 역시나 정답이었다. 이번 시리즈는 제목을 이렇게 가볼까 합니다.제목에서 알 수 있듯이 부트캠프와 프로젝트를 동시에 시작해서 현재 2달 째에 돌입했

이번 프로젝트에서 가장 특징적이라고 할만한 부분은 Next.js를 사용해 기존 CSR 방식에서 SSR 방식으로 프로젝트를 구현한다는 것이라고 생각한다. Next.js가 React 프레임워크라고 하고 React를 써봤다면 금방 적응할 수 있다라는 얘기를 많이 들었어서 프

일반적으로 웹에 링크를 추가할 때는 <a\> 태그를 많이 사용한다. 하지만 Next.js는 <a\> 태그 대신 **<Link\>라는 Next.js의 컴포넌트를 사용**해야 한다. <Link\> 컴포넌트를 사용한다고 해서 마크업이 달라지는 것은 아니다. 아래 코드에서 <

Next.js를 처음 접했을 때 Routing을 제일 먼저 배우고 다음으로 배웠던 게 Image 컴포넌트였다. Image 컴포넌트는 img 태그를 사용했을 때보다 이미지 최적화라는 장점이 뚜렷하다고 한다. 하지만 사용해보니 불편한 게 정말 많았던 것 같다. 화질 저하

배포를 하기 전에 여러 내용들을 추가했어야 하긴 하는데, 오늘 배포 후에 기억이 소멸되지 않기 위해 배포 기록부터 하고자 한다. 배포는 S3와 CloudFront를 통해서 진행했다.S3 (Simple Storage Service):AWS의 파일 저장 서비스로 HTML,

S3+Cloud Front로 배포하면서 발생했던 추가 오류들에 대해 정리를 하려고 한다.정리를 하기 전에 Next.js로 정적 배포를 결정하는 건 정말 생각을 여러 번 하고 결정해야 할 것 같다고 생각이 들었다. 정적 배포를 결정하면서 Next.js의 이점을 제대로 이

S3+CloudFront 정적 배포의 억까에서 거의 해방이 되었지만... 아무래도 정적 배포를 하는 것은 이래저래 불편한 것도 많고, 나중에도 후회할 수 있을 법해서 팀원을 진지하게 설득하고... 고민하고 해서 Vercel로 배포를 다시 하기로 결정했다.정적배포를 위해

HTTP 프로토콜의 특성이자 약점을 보완하기 위해서 쿠키 또는 세션을 사용하게 되는데 이번 프로젝트에서는 쿠키를 사용하기로 했다. 그래서 세션에 대한 설명은 생략하고 쿠키에 대한 간단한 정리와 프로젝트에서 사용한 universal-cookie 라이브러리와 구현 방법에

소셜 로그인으로 한참 삽집을 하고 겨우겨우 해결했다. 소셜 로그인은 네이버와 카카오를 구현했고, 아무래도 보안적인 측면에서 프론트에서 소셜 로그인을 진행하기보다는 서버에서 소셜 로그인을 진행해주고 반환된 결과 값을 받는 것으로 해결했다. 즉, 이 게시글에서는 소셜 관련

상품을 주문하기 위해서는 배달 주소지가 필요하다. 프로젝트에서는 배달 주소지를 5개까지 저장할 수 있도록 구현해주어야 했다. 배달 주소는 마이페이지에서 확인할 수 있는데, 새로고침 시에도 데이터를 유지하기 위해 redux-persist를 통해 세션에 저장해두었다. 추후

이번에 구현되어야 하는 부분은 팝업창에서 데이터를 전달받고 전달하는 과정이었다.페이지에서 팝업창이 뜰 때 제공되어야 하는 데이터가 있을 수도 있고, 팝업창에서 처리된 내용을 전달받아서 페이지에서 적용을 해야하는 경우도 있다. 해당 경우는 같은 도메인 내에서 진행되기 때

유저 기능이 다 끝난 줄 알고 다른 기능을 구현하던 도중에 브라우저 탭 간에 데이터 공유가 되질 않고 있어서 자동로그인 API가 호출되고 있다는 걸 알게 되었다. 탭 간에 데이터를 공유할 필요가 있을까? 하는 의견이 있었지만, 해당 부분을 신경쓰지 않는다면 자동로그인을

프로젝트를 시작하기 전부터 다음 프로젝트에서는 꼭 사용해보고 싶었던 스택 중 하나가 React Hook Form이었다. 이전 프로젝트에서는 웹 표준 등을 전혀 생각하지 않고 구현 하나만을 목표로 두었는데 그 중에서 제일 구현만 생각했다라고 느껴질 법한 부분이 form과

이번 프로젝트에서도 이미지 업로드를 구현하게 되었다. 이전에 프로젝트에서는 백엔드에 formData를 전달해 백엔드가 S3로 업로드하는 방식으로 진행했었다. 그렇게 진행한 이유로는 잘 몰라서가 가장 크다. 그때 당시에는 AWS에 대해서 아예 무지했기 때문에 팀원 분들께

프로젝트에서 사용자의 본인인증을 휴대폰인증으로 구현했다. 회원가입 시 휴대폰 인증을 해야만 가입을 할 수 있고, 소셜 로그인으로 가입한 경우 휴대폰 인증을 거친 뒤에만 정상적으로 서비스 이용이 가능했다. 처음에는 휴대폰 인증을 거치지 않은 회원은 일부 서비스를 이용할

결제를 구현해야 하기 때문에 필수적으로 사용자의 주소를 입력받아야 했다. 주소를 직접 입력하는 게 아닌 당연히 우편번호 서비스를 이용해 주소를 입력받기로 했고, 우편번호 서비스 중에 다음이 가장 UI도 깔끔하고 구현하기도 간단해서 다음 우편번호 서비스로 구현하게 되었다

결제(주문) 페이지를 구현하면서 구현했던 코드들 중에 기록할만한 코드들 위주로 정리하고자 한다.코드들은 현재 기능 구현을 1순위로 구현하다보니 리팩토링 및 코드 정리 과정이 일부 진행되지 않은 부분들이 있다. 코드 작성법보다 우선적으로 기능을 어떻게 구현했느냐에 맞춰서

오늘은 작업하면서 발생했던 error 중에 Hydration 관련해서 발생한 error의 2가지 상황에 대해서 정리하겠다. 에러는 둘 다 Hydration failed because the initial UI does not match what was rendered

프로젝트가 공동구매를 특징으로 하는데 조건이 추가된 공동구매를 진행하기로 했다. 그것은 이제 펀딩의 특징을 조금 추가한 것이다! 최소 구매 수량이 달성되어야 공동구매를 진행하는 느낌으로 기획했다. 실제 서비스할 부분은 아니지만 업체가 저렴하게 판매하기 위해서는 명분이

이전 게시글에서는 상품 Link UI였고, 이번에는 상세페이지 UI인데 특별히 어려운 부분은 없지만 처음 구현해본 부분이 있어서 오래 기억하기 위해 기록한다.다음과 같이 UI를 구현했는데, 수량을 입력하는 부분을 다음과 같이 -/+ 버튼이 포함된 input으로 구현하게

오늘은 의외로 아직까지 구현 안 해봤던 아코디언 토글에 대해서 정리해보려고 한다.자주 물어보시는 질문 페이지에서 질문/답변 형태로 정~말 많이 쓰이는데 이런 서비스를 구현해본 적이 없어서 그런가 아코디언 토글을 처음 구현해봤다. 의외로 간단하고 해서 정리하기는 뭐하지만

이전 프로젝트에서 별점을 구현해본 적이 있다. 그때는 0.5점 단위로 간단하게 별점을 구현해봤는데, 이번 프로젝트에서는 0.1 단위도 굉장히 중요한 요소이기 때문에 0.1 단위까지 모두 표시되는 별점을 구현해보기로 했다.또 commerce이기 때문에 후기라는 기능이 필

상품 상세페이지를 구현할 때 관련 header(nav)가 사라지지 않고 상단에 붙어 원하는 영역을 선택해 빠르게 이동할 수 있도록 구현하고 싶었다. 처음 생각한 방식은 상품정보/후기/문의 중 선택한 값에 따라 렌더링을 다르게 해주는 것이었는데, 일반적인 쇼핑몰들을 참고

회원가입과 같은 form을 구현하면서 가장 거슬렸던 것 중에 하나가 브라우저의 자동완성으로 input의 값을 입력하면 background color가 변경된다는 것이다. 프로젝트 main color와 비슷하길래 팀원 분이 유효성 검사가 통과되면 background co

상품 카테고리를 구현하다보면 li 중복 코드들이 정말 많이 늘어난다. 동작하는 것도 모두 동일하게에 하나로 합쳐주고 싶어서 방법을 생각해보다가 과제를 하면서 좋은 방법을 알게 돼서 해당 방법으로 수정한 기록을 정리하고자 한다.카테고리를 상수화해두는 것이다. 카테고리

신용카드 결제를 위해 포트원 API를 이용하였다. 실제 서비스가 아니기 때문에 가맹점이 아니라 테스트 모드로만 이용을 할 수 밖에 없지만, 테스트모드라고 해서 기능 구현에 문제가 생기는 건 아니고 실제 거래가 진행되는 것도 아니기 때문에 오히려 좋다고 생각이 되었다.결

초기 프로젝트 기획 당시에는 스켈레톤 UI는 구현하지 않으려고 했었다. 아무래도 기획 당시에 너무 많은 것들을 구현해야 했어서 이 부분까지 신경쓰면서 UI를 진행할 수 없을 것 같다는 생각이 팀원들의 주 의견이었기 때문이다.하지만, 프로젝트 마무리에 가까워지면서 프로젝

이번 프로젝트에서도 커뮤니티를 구현하게 되었는데 커뮤니티를 구현하면서 가장 아쉬웠던 점이 textarea로는 게시글을 작성하는 것밖에 할 수 있는 게 없고, 이미지를 업로드를 한다고 하면 이미지의 시작과 끝에 두는 식으로 밖에 할 수 없었다. 이를 해결해주기 위한 게

React Quill로 입력한 내용은 HTML 형식이기 때문에 그대로 출력할 경우, 태그까지 함께 출력된다. 이를 해결하기 위해서 dangerouslySetInnerHTML를 사용한다.dangerouslySetInnerHTML은 브라우저 DOM에서 innerHTML을

더취페이에서 상태들을 다양한 곳에 저장하고 있다. 여기서 필요한 isLoggedIn, access 등은 redux-persist로 session에 저장한다. 마이페이지 같은 회원들만 접근이 가능해야 하는 페이지를 접근 제어하기 위해서는 아주 간단하게 사용할 수 있는 방

commerce 상세페이지들을 보면 대부분 상품 상세 정보에서 이미지를 사용한다. 그리고 이 이미지들은 height가 굉장히 긴 편이다. 그런 경우 상세정보가 궁금하지 않고 다른 것이 궁금한 사용자들에게 스크롤을 많이 해야 원하는 내용을 볼 수 있다는 불편함이 생긴다.

프로젝트에서 검색 기능이 기획되어 있었다. 초기 기획에서는 유사 단어들까지 체크해서 검색되는 데이터를 다양하게 하여 퀄리티를 높여보자! 했으나, 마지막에 구현되는 기능이다보니 기간적으로 일정이 무리가 될 것 같기도 하고 백엔드 팀원이 줄어들었기 때문에 부담이 되어 일치

React Quill을 통해 게시글을 구현하다보니 이미지 업로드에서 문제가 발생했다. 이전 게시글에서 언급했듯이 프로젝트에는 업로드한 이미지들을 별도 영역에서 관리하고 대표 이미지를 설정하거나 editor 외부에서도 사진을 삭제할 수 있는 기능을 제공하고 있다.

React Quill을 이용해 커뮤니티 게시글을 구현했으나 heading 값에 게시글이 영향을 받지 않고 있다는 걸 알게 됐다. 생각해보니 HTML을 렌더링하고 있긴 했지만, tailwindCSS를 사용하다보니 h 태그의 style의 설정이 모두 reset 되지 않았을

relogin과 reissue API에서는 cookie에 있는 refresh token을 이용하도록 설계되었다. 하지만, 백엔드 측에서 쿠키 값이 조회가 되지 않는다는 오류를 받게 되었다. 이슈를 해결하면서 생각보다 쿠키에 대해 잘 모르고 있었다는 생각이 들었기에 오래

프로젝트를 마무리하고 다른 프로젝트를 준비하면서 웹 레퍼런스들을 참고하고 있었는데 login 페이지 URL에 redirect query가 있었다. 저 query의 용도는 무엇일까 확인해보니 내가 로그인 페이지를 오기 전 어느 페이지에 위치해있었는지를 나타내는 것이었다.

이전 게시글을 통해 Proxy 서버에 대해 찾아보던 중 다음과 같은 내용을 보게 되었다. 지금까지 다음과 같이 구현해두었는데....??????????????????? Next.js에 대해 정말 잘 모르고 있구나를 실감하고 급하게 해당 부분 로직을 수정하였다. 그리고 잊