[WIP] CardList Pagination 구현하기

코드잇 구현과제.. api 연결이 익숙하지 않아서 힘들닷

 

 

목차

1. 어떤 파일들이 있는가

2. API

    2-1. api.ts

    2-2. products.ts

    2-3. useProducts.ts

3. useProducts.ts

4. Components

    4-1. ItemCard.tsx

    4-2. ItemList.tsx

    4-3. Pagination.tsx

    4-4. AllProducts.tsx

5. Trouble Shooting

    5-1. 리렌더링 시 깜빡거림

    5-2. next/image를 사용할 수 있을까

    5-3. apis/에도 products.ts, type/에도 products.ts인데 이래도 되나

    5-4. 현재 types/products.ts에는 body에 담긴 내용중에서도 당장 필요한 것만 작성했는데 그냥 ?붙여서 전부 작성하는 게 좋을까?

    5-5. ProductsResponse 타입명 이대로도 괜찮은가

    5-6. UseProductResult에 products, totalCount는 ProductsResponse의 구조랑 겹치는데 나눠서 작성하는 게 맞나?

---

1. 어떤 파일들이 있는가

현재 구현을 완료한 상태이다.

그런데 계속 안되는 것들을 수정하면서 하다보니 너무.. 모든 것들이 정리가 안되고 헷갈리는 상태여서 정리하는 글.

기술 스택	타입 정의	API	Components
⋅ Next.js ⋅ TypeScript ⋅ Axios	products.ts  export interface Product {    id: number;    name: string;    price: number;    favoriteCount: number;    images: string;  }	⋅ api.ts ⋅ products.ts ⋅ useProducts.ts	⋅ ItemCard.tsx ⋅ ItemList.tsx ⋅ Pagination.tsx ⋅ AllProducts.tsx

 

---

2. API

1. api.ts

공통 API 클라이언트 설정을 하는 파일이다.

// 1. axios 라이브러리 불러오기
import axios from 'axios';

// 2. axios 인스턴스 생성
const api = axios.create({
  baseURL: 'https://example.vercel.app',
  timeout: 5000,
  headers: {
    'Content-Type': 'application/json',
  },
});

// 3. 응답 인터셉터 등록
api.interceptors.response.use(
  (res) => res.data,
  (err) => Promise.reject(err),
);

export default api;

// 1. axios 라이브러리 불러오기

axios를 불러왔다.

 

// 2. axios 인스턴스 생성

axios.create()로 api를 axios 인스턴스로써 생성하고, 인스턴스가 상속할 기본값들을 지정했다.

baseURL	⋅ 이 인스턴스로 수행하는 요청들은 상대경로(/)만 지정해도 baseURL을 결합하여 최종 요청 URL이 구성된다.
timeout	⋅ 요청이 응답을 받기까지 최대 5초로 설정하여, 5초를 초과하면 요청을 취소하고 에러를 발생시킨다.
headers	⋅ 이 인스턴스로 전송되는 모든 요청의 기본 헤더를 지정한다. ⋅ 여기서 지정한 헤더는 서버에 JSON 바디를 보낼 때 일반적으로 사용하는 MIME 타입이다.

 

// 3. 응답 인터셉터 등록

인터셉터는 모든 응답(성공/실패)에 대해 통일된 전후처리를 가능하게 한다. (공통 에러 처리, 응답 변환, 인증 만료 처리 등)

당장은 필요 없으나 일단 작성해둬봤다.

(res)	⋅ 응답 성공 콜백 ⋅ 서버로부터 응답 객체(res) 대신 그 안의 data 필드만 반환하도록(res.data) 한다. ⋅ axios의 표준 응답 객체는 { data, status, headers, ... } 형태이나, 대부분의 앱은 data만 사용하기 때문이다.
(err)	⋅ 응답 실패 콜백 ⋅ 응답 에러가 발생했을 때 인터셉터에서 Promise.reject()로 에러를 재전달한다. ⋅ 이렇게 하면 인터셉터 이후의 try, catch에서 에러를 일관되게 잡을 수 있다. ⋅ Promise.reject(err)는 Rejected Promise를 반환하는 표준 JS 방식이다.

 

 

2. products.ts

products 관련 API 요청 함수를 정의한 파일이다.

// 1. 정의한 타입 및 api 불러오기
import { Product } from '@/types/product';
import api from './api';

const END_POINT = '/products/';

// 2. 응답형태 타입 정의
interface ProductsResponse {
  list: Product[];
  totalCount: number;
}

// 3. getProductsList 함수 선언 
export const getProductsList = (option = {}):Promise<ProductsResponse> => {
  return api.get(END_POINT, {
    params: option
  });
}
// 4. getTargetProduct 함수 선언  
export const getTargetProduct = (productId:number)=>{
  return api.get(`${END_POINT}${productId}/`);
}

// 1. 정의한 타입 및 api 불러오기

정의한 Product 타입과 api를 불러온다.

또한 API 경로(엔드포인트)를 상수로 선언했다.

 

// 2.  응답형태 타입 정의

getProductsList가 반환할 데이터의 타입을 정의했다.

• list: Product[] → Product 객체 배열로, 실제 API에서 상품 목록이 들어오는 필드
• totalCount : number → 전체 상품 수 (페이징을 위해 필요)

응답형태 타입은 swagger ui에서 확인하고 작성했다.

"list": [ ... ], "totalCount"를 뱉음

 

 

// 3. getProductsList 함수 선언 

option = {}	⋅ 기본값이 빈 객체인 매개변수로, 쿼리 파라미터를 전달받는다. ⋅ Swagger에 따르면 page, pageSize, orderBy, keyword 이렇게 네 가지를 받을 수 있다.
반환형 타입 Promise<ProductsResponse>	⋅ 이 함수가 ProductsResponse 타입의 값을 포함한 Promise를 반환할 것을 선언한다. ⋅ 또한 Promise를 붙였으므로 비동기적 동작을 함도 나타낸다.
return값	⋅ api.get()으로 GET 요청을 보낸다. ⋅ 첫번째 인수: 최종 URL로, api의 baseURL과 결합되어 https://.../products/가 최종 형태이다. ⋅ 두번째 인수: 쿼리스트링으로 변환될 파라미터를 전달한다.     { params: { page: 2 } } 형태라면, 자동으로 ?page=2로 변환된다.

 

 

// 4. getTargetProduct 함수 선언 

productId: number를 인자로 받는다.

인자로 받은 productId는 api.get()으로 요청을 보낼 때 템플릿 리터럴로 구성하여 보낸다.

현재로써는 아직 사용하지 않고 선언만 해둔 거여서 반환타입을 명시하지 않았다. (추후 명시 필요)

 

 

---

3. useProducts.ts

useProducts.ts는 양이 좀 많아서 API에 안넣고 따로 뺐다.

코드가 좀 길어서 그냥 나눠서 순서대로 정리해보겠다.

1. 필요한 파일들 불러오기

"use client";

import { getProductsList } from "@/apis/products";
import { useState, useEffect, useRef } from "react";
import { Product } from "@/types/product";

클라이언트 컴포넌트로 동작하도록 지정한다. 훅 내부에서 브라우저 전용 api( useState, useEffect .. )를 사용하기 때문이다.

또한 훅에서 필요한 파일들을 불러왔다.

• getProductsList : 백에서 상품 목록을 GET하는 API 호출 래퍼
• use@@ : 상태, 사이드이펙트, 레퍼런스 관리
• Product : 상품 객체 구조

2. 훅 파라미터 타입 정의 (훅한테 먹일 거)

interface UseProductsParams {
  page?: number;
  pageSize?: number;
  orderBy?: "recent" | "favorite";
  search?: string;
}

훅에 파라미터로 전달할 타입을 정의했다. Swagger 문서에 따라 작성했다.

swagger

3. 훅 반환 객체 타입 정의 (훅이 뱉을 거)

interface UseProductResult {
  products: Product[];
  totalCount: number;
  loading: boolean;
  error: Error | null;
}

훅이 반환할 객체의 타입을 정의했다.

객체 바디인 list, totalCount를 포함해서 loading, error도 추가로 정의했다.

 

4. useProducts 선언

export const useProducts = ({ 
  page,
  pageSize,
  orderBy,
  search
} : UseProductsParams): UseProductResult => { ...

UserProductsParams 타입을 받도록 선언했으며, 반환값으로 UseProductResult 타입을 가지도록 했다.

파라미터들의 초기값을 서버에서 보장하기 때문에 초기값 지정을 하지 않았다.

 

 

5. 변수 및 setter 선언

const [products, setProducts] = useState<Product[]>([]);
const [totalCount, setTotalCount] = useState(0);
const [loading, setLoading] = useState(true);
const [error, setError] = useState<Error | null>(null);

 

products, totalCount	⋅ 실제 보여줄 데이터와 총 개수
loading	⋅ 초기 로딩(초기 마운트 시) 여부 ⋅ true로 초기화하여 마운트 시 로드가 있음을 명확히 함
error	⋅ 에러 객체

 

 

6. fetchProducts 정의

fetchProducts는 try, catch, finally를 가진다. 각 파트별로 나눠서 정리하자.

 

try

// fetchProducts() : 상품 불러오기
  const fetchProducts = async (initial = false) => {
    if (initial) setLoading(true);
    setError(null);
    try {
      const res = await getProductsList({
        page,
        pageSize,
        orderBy,
        search,
      });

      // 데이터 매핑
      const list = (res.list ?? []).map(
        (p: Product): Product => ({
          id: p.id,
          name: p.name,
          price: p.price,
          favoriteCount: p.favoriteCount,
          images: p.images?.[0],
        }),
      );
  // 데이터 상태 업데이트
  setProducts(list ?? []);
  setTotalCount(res.totalCount ?? 0);
}

• fetchProducts는 실제 API 호출을 담당한다.
  initial 플래그로 초기로드(true)인지, 아니면 재요청(false)인지 구분한다.
• setError(null)로 요청 하기 전에 기존 에러를 초기화 한다.

getProductsList()

• axios 요청하는 함수인 getProductsListfh API를 호출한다.
• 파라미터로 쿼리(page, pageSize, orderBy, search)들을 전송한다.

mapped

• getProductsList로 호출해서 응답받은 값이 res에 있다. res에 들어있는 데이터를 우리가 사용할 변수에 매핑해줘야 한다.
• 바디를 보면 "list" 배열 안에 매핑할 데이터들이 들어있었으므로 res.list(비었다면 빈 배열[])의 데이터를 Product에 매핑한다.

 

catch, finally

catch (err) {
  if (err instanceof Error) setError(err);
  else setError(new Error("Unknown error"));
} finally {
  setLoading(false);
}
};

catch로 에러 처리를 하고, finally로 요청 완료 시 loading을 false로 세팅한다.

 

7. 마무리

  // initialParams의 각 값이 변경될 때마다 fetch
  useEffect(() => {
    fetchProducts();
  }, [page, pageSize, orderBy, search]);

  // refetch
  const refetch = async () => {
    await fetchProducts();	// refetch는 false
  };

  return { products, totalCount, loading, error };
};

 

useEffect()로 위에서 정의한 fetchProducts를 호출한다.

파라미터값이 달라질 때마다 호출한다.

 

리렌더링을 위한 refetch를 정의해서 리턴값에 포함시킨다.

 

 

---

4. Components

1. ItemCard.tsx

본문

2. ItemList.tsx

본문

3. Pagination.tsx

본문

4. AllProducts.tsx

본문

 

 

---

5. TroubleShooting

1. 리렌더링시 깜빡거림

이전에는 try문을 시작할 때 항상 setLoading(true)가 실행되도록 되어있었다.

이 때의 React 동작 순서를 살펴보자.

1. 처음 페이지 렌더(products가 비어있음. 또한 loading도 true로 초기화되어 있음)
2. fetchProducts() 호출하여 데이터 요청 → setLoading(true)
   → React가 리렌더링
   → 화면에서 기존 카드 DOM을 제거 (빈 상태)
3. 데이터 도착 → setProducts(list) + setLoading(false)
   → React가 도착한 데이터로 리렌더링
   → 카드 UI가 새로 그려짐

화면의 첫 렌더링이 완료된 후 loading은 finally문에서 false 상태가 된다.

하지만 페이지네이션으로 리렌더링을 할 때마다 loading을 true로 바꿀때마다 React가 기존 DOM을 초기화하고 재렌더링을 하며 깜빡임이 발생하게 되는 것이다.

 

그렇다면 if (initial) setLoading(true)를 작성하면 어떻게 될까?

우선 가장 처음 페이지를 로드했을 때는 loading이 true일 것이다. (처음에 그렇게 초기화했기 때문)

하지만 그 뒤로 페이지를 새로고침하는 것이 아니라면 loading은 false상태가 된다.

 

1. 초기 렌더 (loading = true)
2. 데이터 도착 → setProducts(list) + setLoading(false)
   → 카드 UI 렌더링
   
3. 페이지네이션 등으로 refetch → initial = false
   → setLoading(true)가 호출되지 않음
   → 기존 카드 UI 그대로 유지하고 데이터만 교체
   → React는 DOM 일부만 갱신하여 깜빡임이 없음
   

이렇게 loading 상태를 강제로 true로 돌리지 않게하여 깜빡임을 지웠다.

 

❗그런데 이렇게 loading 상태를 지워도 괜찮을까??

이렇게 하면 개발자도구에서 네트워크에 throttling을 걸었을 때 사용자가 데이터의 로딩 여부를 확인할 수 없다.

페이지네이션으로 페이지를 넘겨도 아무런 액션 없이 데이터가 도착할 때까지 이전 데이터만 띄우기 때문이다.

 

✅ 이 부분은 사실 이전에 다른 과제 플젝에서 다룬 적이 있다.

여기서는 로딩을 아예 쓰지도 않았군

skeleton 작업을 추가로 하는 것이다.

전에 카카오 블로그에서 스켈레톤을 무조건적으로 띄우면 오히려 깜빡이는 느낌을 주어 피로감을 줄 수 있다는 것을 보고 작성했던 것이다.

컴포넌트 마운트 후 0.2초간은 skeleton을 보이지 않으나, 0.2초가 넘으면 스켈레톤을 보인다.

스켈레톤을 띄우고 기다리는동안 데이터가 로드되면 데이터를 그대로 보이는 거다.

 

훅에서는 스켈레톤을 보일지 여부만 알려주고 보여주는건 UI에서 맡게되는데,

그걸 생각하면 사실 loading이 다시는 true로 될 수 없는 저 코드의 구조도 문제가 있다.

(저 때는 데이터를 몽땅 불러와서 문제가 발견되지 않았다.)

 

이 부분은 스켈레톤을 구현한 후, 체크하면서 다시 다뤄봐야겠다. 일단 지금은 깜빡임을 해결하긴 했다.

 

2. next/image를 사용할 수 있을까

 

 

 

 

참고

https://axios-http.com/docs/intro

Getting Started | Axios Docs