9/19 - BannerSection API 연결

bannerSection

컴포넌트 설계

bannerSection은 어떻게 보면 디자인적인 부분의 한 요소일 뿐이지만, 이 프로젝트를 하면서 나의 큰 관심사 중 하나였다.

bannerSection 구상

구상은 비행기 이미지에 섬네일 사진만을 결합하고, 비행기가 지정된 방향으로 흐르는 방식으로 구상하였다.

사용자가 관심있는 비행기를 hover 나 click 시에 자세히 확인할 수 있는 방식이다.

그러나 고민되는 부분이 몇 가지 있었다.

1. 해당 섹션의 width는 어떻게 설정되어야 하는가?
2. 글을 불러오는 기준은 어떻게 되는가?
3. 글을 불러오는 방식과 해당 컴포넌트를 구성하는 방식은 어떻게 되는가?

이 3가지의 고민을 오랫동안 해왔고, 나름 정리한 내용을 작성해보려고 한다.

 

1. 해당 섹션의 width는 어떻게 설정되어야 하는가?

중요한 부분은 아니겠지만,

우선 해당 페이지에서 컨트롤 + 스크롤로 조정가능한 화면 배율을 100퍼보다 낮게 낮추면

브라우저 화면 크기 비율로 작성된 부분은 조금 부자연스러워 지는 경향이 있었다.

예시) recommendedSection

3번째 섹션의 비행기가 양 옆으로 붙어, 디자인이 통일되어 보이지 않고 부자연스러워 보인다.

이런 문제 때문에, width는 고정 pixel로 설정해두어야겠다고 생각했다.

 

결론 ) 일반 사용자의 브라우저 화면 크기인 1920px에 가깝게 설정

 

2. 글을 불러오는 기준은 어떻게 되는가?

이 부분은 서비스 관점에서는 중요한 부분 같다.

초기에 기획한 경우, 글로 정리되어 있지는 않았지만 로그인된 사용자의 경우 `선호 태그` 위주로 우선 보여주도록 기획하였다.

하지만 우선적으로 비 로그인 유저를 기본으로 생각하기로 하였다.

이유는 소개 글을 올리기 위해 로그인하는 유저들은 있겠지만, 굳이 소개 글을 보기 위해 로그인 할 유저는 로그인할 만큼의 메리트가 아직은 없기 때문에, 비 로그인 상태로 보는 사용자가 많다고 생각하기 때문이다.

 

결론 ) 비 로그인 유저 기준, 최신글 기준으로 소개 글을 불러오도록 한다.

 

3. 글을 불러오는 방식과 컴포넌트 구성 방식

이 부분은 지금 개발 과정에 있어서 중요한 부분이다.

이 부분을 가장 많이 고민한 것 같고, 다음 개발때는 이런 컴포넌트 기능은 기획과 설계 부분에서 먼저 설계해 두어야 겠다는 것을 느꼈다 (...)

 

우선 방식을 고민하기 앞서, Next.js 를 사용하며 알게된 점을 기준으로 고민해야했다.

나는 Next.js 의 큰 장점인 SSR 활용을 극대화 하고 싶어서 Server Component 에서 API를 활용하여 내용을 불러오도록 할 것이다. ( server component에서 api를 활용하면 server 단에서 통신이 바로 이루어지기 때문에 효율적이라고 생각 )

 

컴포넌트의 구성은 다음과 같다.

bannerSection이 존재하는 메인페이지 app/page.tsx (server compnent) 에서 API를 활용하여 소개 글을 fetch 하도록 한다.

→ app/page.tsx에서 fetch 한 데이터를 직렬화를 통해 client component인 bannerSection에 전달한다.

→ 전달받은 데이터를 통해 비행기 내용을 구성한다.

 

처음에는 흐르던 비행기가 끝에 도달할 경우, 더 로딩되도록 구상했었다.

하지만, Server Component는 사용자의 동적인 움직임, 즉 클라이언트 상의 이벤트를 통해 추가적인 동작을 기대할 수 없다는 점을 유의했다.

즉, 비행기가 끝에 도달하는 경우는 클라이언트 상의 이벤트이고, 해당 이벤트는 app/page.tsx 즉 Server Component 에서 추가적인 API 요청을 그때 보낼 수는 없다고 생각했다.

 

그러므로 추가적으로 내용을 불러오는 부분은 bannerSection 에서 따로 구성하도록 하였고,

1차적으로 개발할 부분은 server component인 app/page.tsx 에서 약 40개 가량의 소개 글을 불러와 bannerSection 의 각각의 bannerList 에 반절 씩 전달한 내용을 통해 구성하도록 하려한다.

 

결론 ) 메인 페이지에서 40개 가량의 글 로딩. wrap 너비 설정 후 한 줄의 List가 20개 가량의 글을 부여받음.

컴포넌트 구현

React - 무한 롤링 슬라이드(배너) 구현하기 :: 개발 흔적 남기기 (tistory.com)

React - 무한 롤링 슬라이드(배너) 구현하기

윗 글을 참고하여 구현하였다.

Next JS 13 적용해보기 - 데이터 불러오기 Data Fetching 편 (tistory.com)

Next JS 13 적용해보기 - 데이터 불러오기 Data Fetching 편

우선 목업 데이터를 연결하기 위해 Next.js 13 의 Data Fetching 방식에 대해 먼저 찾아봤다.

[Next js] SSR, SSG, ISR 이해하기 (velog.io)

[Next js] SSR, SSG, ISR 이해하기

SSR, SSG, ISR의 내용의 이해는 윗 글을 참고했다.

Next.js 13 버전으로 올라가면서, 기존에 사용하던 getStaticProps() 방식 등이 기존 fetch() 메소드로 대체할 수 있게되었다.

대신에 fetch() 의 cache 등의 속성을 통해 SSR, SSG, ISR 의 방식을 구현할 수 있게되었다.

 

아래 표로 각 방식의 정의와 방법을 정리해봤다.

이름	기능	Fetching 방법
SSR ( Server Side Rendering )	서버에서 페이지를 렌딩하여 클라이언트에 전달하는 방법. Next.js의 SSR은 사용자가 페이지 요청을 할 때마다 해당 페이지를 새롭게 렌더링 하는 것이다. 그러므로 Fetching 하는 데이터가 빈번하게 바뀔 때 사용된다. fetch(	fetch(URL, {   cache : "no-store" })
SSG ( Static Site Generation )	사용자 요청에 따른 것이 아닌, 서버 빌드 시에 페이지를 미리 생성해 놓는 방법. Next.js에서는 기본 값으로 사용되며, 다시 빌드하지 않는 이상 데이터를 다시 Fetching해도 페이지가 변경되지 않는다.	fetch(URL, {   cache : "force-cache" }) // 기본 값
ISR ( Incremental Static Regeneration )	서버 빌드 시에 페이지를 생성하고, 일정 시간마다 새로 렌더링 하는 방법.	fetch(URL, {   next: {     revalidate: 숫자(초)   } })

목업 데이터를 연결하기 위해,

저번에 작성해둔 api 주소로 연결하기 위하여 Fetcher.ts 파일을 구성해보았다.

// @/utils/api/Fetcher.ts

import { TypeIntroductionPostList } from '@/types/interfaces/introductionPost.interface';

// 환경변수
const DOMAIN = process.env.DOMAIN;
const PORT = process.env.PORT;

/*
introductionPosts
*/

/**
 * 페이지에 맞는 소개 글 리스트를 받아옵니다.
 * @returns Promise<TypeintroductionPostList[]>
 */
export async function getIntroductionPostsList(
  page: number = 0
): Promise<TypeIntroductionPostList[]> {
  const response = await fetch(
    `http://${DOMAIN}:${PORT}/api/introduction-posts`,
    {
      cache: 'no-store',
    }
  );

  return response.json();
}

그 다음 server component 에서 해당 함수 호출 후, 값이 받아와졌는지,

그리고 client component로 값을 props로 전달 시에 제대로 넘겨 받아지는지 console.log로 확인해 보았다.

결과는 다음과 같았다.

 

server component 부분

terminal 결과

server component는 서버 단에서 실행되므로, console.log의 결과가 terminal에 나타나게 된다.

결과가 정상적으로 나타났으므로, api 연결이 성공적으로 됐음을 알 수 있었다.

 

client component 부분

브라우저 개발자도구 콘솔 결과

client component는 클라이언트 단에서 실행되므로, console.log의 결과가 사용자 브라우저에 나타나게 된다.

결과가 정상적으로 나타났으므로, server component에서의 props가 성공적으로 전달되었음을 알 수 있었다.