export const END_POINT = {
HOME: `/api/home`,
POST: '/api/post',
CALENDAR: '/api/calendar',
SLIDE: '/api/slide',
GRID: '/api/grid', // 그리드 방식 전체 인증 데이터 조회
GRID_BY_UPLOADER: '/api/grid/uploader', // 업로드별 조회
UPLOADER_GRID: '/api/grid/:userId', // 특정 업로더의 전체 인증 데이터 조회
} as const;
그리드 페이지 내에서 업로드별 조회와 특정 업로드의 인증 데이터 페이지를 구별하기 위해서 페이지 컴포넌트 및 다른 컴포넌트들의 식별자 명을 수정하였습니다.
일관성있는 디자인과 컴포넌트 구조를 위해 그리드 레이아웃 컴포넌트를 생성하여 분리하였습니다.
확인할 목록:
api 관련 내용
전체 인증 데이터 조회 / 특정 업로더의 전체 인증 데이터 조회 는 현재 무한 스크롤링으로 구현이 됩니다. 이와 관련해서 api 설계는 페이지네이션이 필요합니다.
api에서 쿼리 스트링으로 current page값을 넘겨주고 해당되는 데이터를 받아와야합니다.
클라이언트에서 mock API를 생성하여 무한스크롤을 구현하였습니다. pageSize 값(한 페이지에 들어가는 데이터 개수)을 30개로 두어 진행하게 되면 웹 기준에서의 첫 렌더링에서 부터 두개의 페이지를 페칭하게 되는 경우가 발생합니다.
이를 미연에 방지하기위해 api 설계시 pageSize 를 최소 40~50개로 잡아야할 것 같습니다.
관련 문서
Closes #75
변경사항:
grid 페이지에 사용되는 api 를 호출합니다.
그리드 페이지 내에서 업로드별 조회와 특정 업로드의 인증 데이터 페이지를 구별하기 위해서 페이지 컴포넌트 및 다른 컴포넌트들의 식별자 명을 수정하였습니다.
일관성있는 디자인과 컴포넌트 구조를 위해 그리드 레이아웃 컴포넌트를 생성하여 분리하였습니다.
확인할 목록:
api 관련 내용
전체 인증 데이터 조회 / 특정 업로더의 전체 인증 데이터 조회 는 현재 무한 스크롤링으로 구현이 됩니다. 이와 관련해서 api 설계는 페이지네이션이 필요합니다.
api에서 쿼리 스트링으로 current page값을 넘겨주고 해당되는 데이터를 받아와야합니다.
클라이언트에서 mock API를 생성하여 무한스크롤을 구현하였습니다. pageSize 값(한 페이지에 들어가는 데이터 개수)을 30개로 두어 진행하게 되면 웹 기준에서의 첫 렌더링에서 부터 두개의 페이지를 페칭하게 되는 경우가 발생합니다. 이를 미연에 방지하기위해 api 설계시 pageSize 를 최소 40~50개로 잡아야할 것 같습니다.
웹 기준에서 갯수(pageSize = 30 기준)가 에매한 상황
개발 시 기술명세서(피그잼)에 기록해둔 내용