내가 NextJs를 마이그레이션 하려 했던 이유

NextJs로 마이그레이션 하게 된 이유?

 5월경부터 React로 했던 프로젝트를 Nextjs로 마이그래이션하며 작업을 하며 업그레이드를 하고 있습니다. SSR에 대한 개념은 어느 정도 알고 있었지만 NextJs가 13버전으로 바뀌고 나서의 자료 찾기가 쉽지는 않았지만 열심히 구글링하면서 해결해 왔습니다. 그러던 와 중 어떤 글을 읽고 생각나서 한번 이런 주제로 글을 작성하게 되었습니다.

 많은 곳에서 NextJs에 대해 SSR에만 주목하는 경향의 글들이 많았고 나도 그것에 주목했던 것이 사실입니다.

사실 React에서도 SSR를 도입할 수 있는 설정들이 있다.(물론 까다롭다고 한다.)

사용자 경험을 향상시키자

 기존에 제작했던 프로젝트입니다. 위의 gif에서 확인할 수 있듯이 제니(blackpink)에 대한 data는 서버에서 fetching해오는 방식이며, 클라이언트에서 가져오는 것입니다. 그렇기 때문에 데이터를 가져오는데 시간이 걸리며 layout shifting도 심하게 일어난 것을 확인 할 수 있었습니다.

 결론적으로 CSR방식이 아닌 SSR을 사용하여 초기 로딩 사용자 경험을 향상 시킬 필요성이 있었습니다.

 NextJs에는 컴포넌트를 sever와 client로 구분하고 있습니다. client 컴포넌트의 경우 우리가 이미 알고 사용하고 있는 리액트 단에서의 컴포넌트라고 생각하면 됩니다. 반면 서버 컴포넌트는 nodeJS환경에서 실행되며 서버단에서 처리를 하는 컴포넌트 입니다. 그렇기 때문에 서버 컴포넌트를 도입하여 서버 컴포넌트 단에서 데이터를 fetching을 하고 하위 클라이언트 컴포넌트로 뿌려주게 되면 더 효율적인 사용자 경험을 줄 수 있게 됩니다.

import CalendarContainer from "@/component/calendarPage/CalendarContainer";
import { getIdolInform } from "@/utils/API/SSGSetting";

export interface CalendarPageProps {
  searchParams: { idol: string };
}

/**서버컴포넌트*/
async function CalendarPage({ searchParams }: CalendarPageProps) {
  const idolName = searchParams.idol;
  
  /**dataFetching axios기반*/
  const idolData = await getIdolInform(idolName);

  return (
    <main>
    /**CalenDarContainer의 경우 클라이언트 컴포넌트*/
      <CalendarContainer idolData={idolData} />
    </main>
  );
}
export default CalendarPage;

 앞서 설명한 것과 같이 처리하였습니다. 실제로도 웹사이트에서 변동이 많이 없는데이터는 서버 컴포넌트에서 처리해주는 것이 효율적입니다.

  - 현재 마이그레이션 진행 중인 NextJs프로젝트
위와 같은 처리과정을 통해 초기 로딩 속도를 높여 사용자 경험을 향상시킨 것을 확인 할 수 있습니다.

third-party-library React

 진행하는 프로젝트에서 위처럼 초기로딩이 중요한 부분이 많았기 때문에 앞서 얘기 했듯이 SSR위주로 주목했던 것이 사실입니다. NextJs 공식 홈페이지에서는 NextJs를 React를 이용한 Web application을 만들기 위한 framework라고 소개하고 있습니다. library인 React와는 차이가 있다는 뜻입니다.

 기존의 React는 library로 다른 JS framework와 비교되어 왔습니다. React는 철저하게 UI적인 부분을 다루는 부분이 많다고 평가되고 있고 이 때문에 다른 부분을 third-party library를 사용하였습니다. 이로 인해 다양한 library조합이 탄생하였고 이로 인한 생태계도 커졌습니다. 저 또한 상태관리나 ui와 관련된 여러 라이브러리를 사용한 경험이 있습니다. 하지만 이 것은 독이 될 수도 있습니다.

• 많은 third-party library를 사용하다 보니 react와의 궁합이나 third-party library와의 궁합이 보장되지 않습니다.
• 그렇기 때문에 개발 방식에서의 어느 정도 차이가 보이고 best pratice가 부족합니다.

React생태계 한계를 탈피한 NextJs

 다음은 nextJs 공식문서에서 제시하고 있는 점들 입니다. nextJs는 외부 library에 의존적인 React에서 벗어나 Next자체에서 여러 기능을 제공합니다.

자체 폴더 기반의 라우팅방식, 서버 컴포넌트를 통한 데이터 fetching방식, oauth를 통한 인증/결제 시스템 그리고 웹 성능 최적화를 위한 기능(Next/image, Next/Font 등) 등을 제공하며 개발자에게 보다 좋은 솔루션을 제공합니다.

다른 라이브러리와의 궁합

 초기 nextJs로 마이그레이션을 적용할 때 문제가 CSS를 다루는데 있어서 문제가 생겼었습니다. 이유는 Styled-Component와 Chakra UI를 적용하는 데 있어서 스타일 적용이 안되는 점이였는데요.

Chakra UI는 React에서 빠르게 스타일링하는 솔루션을 제공하는 라이브러리이지만 NextJs에서 간혹 flash Issue가 발생하였습니다. 이는 알려진 문제로 Chakra UI측에서도 해결을 위해 노력하고 있다고 합니다.

 css-in-js방식인 styled-component와 emotion 또한 SSR환경에서 제대로 작동하지 않는 모습을 보여줍니다. 이에 대한 내용 또한 공식 문서에서 확인할 수 있었습니다. 완벽하게 이유는 알 수 없지만 제가 생각한 이유로는 이러합니다.

css-in-js방식은 클라이언트 측에서 스타일을 동적으로 생성하고 적용하는 방식입니다. 하지만 서버 측에서 이를 실행시키게 되면 브라우저 환경이 아니기 때문에 브라우저 측에 대한 지원이 잘 되지 않는 것 같습니다.

 이러한 이유로 nextJs측은 tailwind와의 궁합을 추천하고 있습니다. tailwind는 순수 css파일을 기반으로 생성해주기 때문에 JS에 의존하지 않아도 됩니다.

nextJs를 install하는 과정에서 아예 Tailwind CSS를 사용여부를 물어보고 있을 정도로 궁합이 잘 맞는 것을 나타내고 있습니다.

 이렇게 궁합이 맞더라도 사실 css-in-js방식을 SSR에서 사용할 수 있는 솔루션들이 생겨나고 있고 실제로도 도입되고 저도 사용했습니다.(tailwind도입보다 기존에 쓰던 방식이 편한것도 사실...) 또한 css library 뿐만아니라 다른 library들 또한 SSR환경에서의 솔루션이 생겨나고 있긴 합니다. 하지만 아직까지는 NextJs에서 제공하고 있는 기능 등과 추천하는 library를 사용하는 것이 효율적인 퍼포먼스를 내기에는 적합해 보입니다.

마치며...

 nextJs는 사실 위에서는 더 소개하지 않은 막강한 기능들이 더 존재합니다. 좀 더 라이브한 앱을 만들기 위한 다양한 최적화 기능들뿐만 아니라 Front-end뿐만 아니라 Back-end에서 모두 사용가능한 Isomorphic Javascript로 지칭되고 있습니다.

 또한 프로젝트 진행에 있어 React앱 기반에서의 라이브러리 선택에 있어서 선택 폭을 줄여주는데 보다 줄여 줄 수 있을지도 모릅니다.

Reference
https://json.media/blog/proper_understading_of_nextjs
https://xionwcfm.tistory.com/329
https://babycoder05.tistory.com/entry/Nextjs-TypeScript-Tailwind-CSS-%EC%8B%9C%EC%9E%91%ED%95%98%EA%B8%B0-Tailwind-CSS-%EC%9E%A5%EB%8B%A8%EC%A0%90

👍올바른 피드백은 언제든지 환영입니다~!