지난 포스팅에서 SWR 을 사용하는 주된 이유인 캐싱에 대해 알아보았는데, 간혹 캐시 데이터가 화면을 렌더링 할 때 불편하게 작용할 때가 있다. 페이지에 따라서 캐시된 데이터가 아닌 최신의 데이터를 보여줘야 하는 경우가 있다. 이런 경우라면 지난 포스팅에서 알아보았듯 no cache, no store 설정을 통해 캐쉬화 되는 것을 막을 수 있다. 어떠한 페이지는 캐싱을 활용하는것이 훨씬 유리한 경우도 있다. 변화가 거의 없는 블로그 포스팅 글이나, 테이블의 페이지내이션 시 각 페이지별 데이터 들은 사용자가 수시로 확인하는 데이터이기 때문에, 확인할 때마다 데이터를 받아오는것은 손해라고 할 수 있겠다. 반면, 평소에는 캐싱이 유리하였다가 특정 이벤트 시 최신의 데이터가 필요할 상황이 있다. 즉, 즉각적으로..
저장하고자 하는 의류들의 데이터를 서버에 잘 저장하였다면, 저장된 데이터를 사용자에게 잘 보여주는 것 역시 중요할 것이다. 저번 포스팅까지 ItemForm.tsx 컴포넌트를 구현하면서 저장하는 add 페이지와 details 페이지에서의 데이터 수정 과정에 대해서 다루어보았다. 이제 실제 의류들의 목록을 유저에게 보여주는 페이지를 구상하기 위해(이를 앞으로 Store 페이지라고 하겠다) 코드를 작성하기 전 고려해야 할 부분들에 대해서 생각해보았다. 이번 포스팅은 고려했던 사항들 중 데이터에 대한 페이지네이션을 구현할 때 기존 offset 방식이 아닌 cursor 개념으로 접근하려 하였는지에 대해서 다뤄보고자 한다. 일정 수량의 데이터를 서버로부터 가져올 때 흔한 커뮤니티의 게시판을 생각해보면, 아래에 페이..
이제 마지막으로 Add 페이지에서 의류를 데이터에 저장할 때와, Details 페이지에서 데이터를 수정하여 데이터베이스에 저장하는 과정에 대해서 포스팅하고자 한다. 이번 포스팅을 마지막으로 Add, Details 페이지에 대한 구현 과정도 마무리 하려고 한다. 전체 테이블 구조도 데이터 저장은 테이블을 잘 확립하였다면 어렵지 않다. 시퀄라이즈의 테이블 관계가 잘 맺어져 있다면 알아서 잘 저장되기 때문이다. 기본적으로 현재 구성된 테이블관계는 복잡하지 않다. 의류의 전반적인 데이터를 나타내는 테이블이 있고, 각 의류마다 저장되는 여러장의 이미지를 저장하는 테이블, 의류의 카테고리마다 입력된 실측 데이터를 저장하는 테이블로 구성되어있다. 한개의 의류를 저장할 때 여러개의 이미지가 있을 수 있다. 따라서 의류..
앞서서 이미지를 서버에 업로드하고, multer 를 통해 이미지를 저장한 다음, vision AI 를 통해서 현 이미지를 분석하여 이미지의 주소와 분석결과를 클라이언트에서 받아 Preview Card 를 렌더했었다. 그리고 그 전 이미 의류이름과 가격 등등 입력값들을 React-Hook-Form 을 통해서 관리하고 있었고, 이제 실제 데이터베이스에 입력값을 저장할 일만 남아있다. 그리고 저장된 의류 데이터를 수정할 수 있어야 했기에 기존 입력 데이터를 불러와 input 창에 기입되어 있는 상태로 렌더하는 경우도 고려해야했다. 정리해보자면, 받아온 이미지 주소와 함께 React-hook-form 에서 관리하는 입력값들을 서버 데이터베이스에 저장 상세 페이지에서 정보를 수정하고자 할 경우, 수정 이벤트 발생..
이미지를 업로드 하는 방법에 대한 고민을 해결하였으니, 이제 실제 이미지를 서버에 업로드 하면서 추가적으로 구현하고 싶은 목표를 이루도록 해보자. 목적에 맞는 의류 이미지를 업로드 할 수 있도록 가이드 하는 방법 이번 프로젝트에서 이미지는 중요한 역할을 한다고 생각한다. 실제 유저가 어떤 의류가 저장됬는지 가장 한눈에 살펴볼 수 있는 것이 이미지이고, 그렇기 때문에 의류를 저장하기 전에 Preview 를 보여주는것은 기본이며, 개인적으로는 혹여나 실수로 전혀 관련없는 이미지를 제출해버리는 것을 방지해주는 것도 좋지 않을까 생각했다. 의도는 좋으나 방법이 떠오르질 않았는데, 이미지를 파악해서 컴퓨터가 알아서 이미지를 분석해서 이 이미지는 의류인지 아닌지를 파악하는것을 지금 내가 직접 코드를 작성하기에는 무..
지난 포스팅때는 React-Hook-Form 을 활용하여 Add 페이지와 Detail 페이지 내에서 활용될 입력 컴포넌트 ItemForm 을 구현하였다. 구현하는 과정에서 의류 카테고리에 따라 실측 입력폼을 렌더해야 하는 문제에 대한 고민과 이를 해결하고자 어떤식으로 코드를 구상하였는지도 다루어 보았다. 다만, 아직 ItemForm 에서 해결해야 할 문제들이 남아있는데, 크게 3가지 정도라 할 수 있겠다. 의류에 대한 정보를 수정하고 싶을 때, 수정 버튼을 누르면 ItemForm 내 기존 의류의 정보가 기입되어있어야 하며, 수정하여 변경할 수 있어야 한다 중요한 부분이 이미지를 업로드 하는 과정인데, 우선 이미지 업로드 버튼 뿐 아니라 웹사이트 내에서는 이미지를 드래그에서 업로드 하는 방식도 추가하고 싶..
입력 폼은 웹페이지를 구성할 때 빠지지 않고 포함되며, 그렇기에 html 내 input 의 type 들 역시 기본적인 입력부터 시작하여 number, tel, select, color, file 등등 다양하게 존재한다. 상황마다 달라지겠지만 기본적으로는 이메일과 비밀번호를 입력하는 로그인부터, 유저의 다양한 정보들을 한번에 전송해야 하는 입력폼을 생성해야할 때도 존재한다. 진행중인 closet 프로젝트에도 입력폼은 반드시 포함되었어야 했는데, 당연하게도 로그인 및 회원가입때의 입력폼과, 프로젝트의 핵심이라 할 수 있는 의류들의 정보들을 입력하게 될 add 페이지와 입력했던 의류정보를 수정하게 될 detail 페이지에서 사용될 입력폼이 필요했고, 그렇기에 좀 더 입력폼을 구현하는데 수월한 방법이 없을 까 ..
Nest.js 를 통해서 각 페이지의 레이아웃을 설정하는 것은 간단하다. _app 에서 공통으로 들어갈 레이아웃을 설정해주면 모든 페이지에 레이아웃이 작용하게 된다. 다만 상황에 따라서 페이지마다 다른 레이아웃을 적용해야할 수도 있다. 예를 들자면 상단 Nav 컴포넌트를 Login 페이지에 포함시키고 싶지 않다면, Login 페이지는 이에 맞는 레이아웃이 적용이 되어야 한다. 하지만 _app 에서 레이아웃을 적용시킨다면 Login 페이지까지 레이아웃이 적용되어버린다. 편하게 레이아웃을 적용하려고 하는 노력이 오히려 불편한 상황을 야기한다! 다행이도 Next.js 는 이러한 상황을 고려하여 각 페이지에 따른 subLayout 을 적용할 수 있도록 설정 할 수 있는데, 이번 프로젝트를 진행하면서 Login ..
