<소스 참고>
https://github.com/kimtaru/commerce_by_next13
프롤로그
리액트를 사용한지 오래되어 가물가물 하기도 하고,
최근 새로운 버전(13)이 출시된 Next.js를 통하여 간단하게 커머스를 구현해보고자 합니다.
레퍼런스 사이트 (와이즐리) : https://wiselycompany.com/
와이즐리는 제가 실제로 매우 애용하는 웹사이트입니다.
와이즐리를 선택한 이유
- UI가 심플하고 직관적이라서
- PHP기반의 웹사이트라서 -> Next.js로 구현 후 사용성 비교를 위해
시작하기전에..
1. 최대한 공식문서에 기반하여 구현하고자 하였습니다.
2. 저는 영어를 잘 못해요
공식문서에 기술된 내용을 제 나름대로 의역했습니다.
번역이 정확하지 않더라도 양해해주세요.
3. 어려운 용어 사용안함
편안하게 읽을 수 있도록 최대한 쉽게 작성했습니다.
4. 웹사이트 구축에 관련이 적은 부분은 설명 생략하였음
시작해볼까요?
공식사이트 둘러보기
next.js 공식사이트를 접속합니다.
https://nextjs.org/
매우 다양한 서비스들이 Next.js를 기반으로 만들어져 있네요
(틱톡, 노션, 트위치 등..)
Docs
Getting started
어느 공식문서에나 있는 문구 Getting started를 클릭하시면
첫번째로 아래와 같은 문구가 나옵니다.
(Next.js 13버전이 출시되었으니 가이드를 참조하라는 말과 함께..)
Next.js 13버전의 새로운 특징인 App directory(Beta)에 대해 소개하고 있습니다.
기존 Next.js의 pages directory(stable)도 함께 사용할 수 있으며,
App directory에 대해 자세한 가이드를 얻고 싶다면 별도로 마련된 beta docs로 접근해야 합니다.
"MacOS, Windows, Linux와 같은 운영체제, 14.6.0이상의 노드가 설치되어 있어야 합니다."
현재 저는 MacOS와 함께 Node 16.5.0이 설치되어 있습니다.
문서상에는 create-next-app을 사용하는 Automatic Setup방식과 직접 next를 설치하는 Menual Setup방식을 소개하고 있습니다.
어떤 것을 진행함에 있어 2가지 이상의 방법이 있을 때 대부분 권장되어지는 방식이 있는데요, 이때 recommend 라는 단어에 주목하면 됩니다.
문서에서 권장하는 방식은 Automatic Setup 방식 이네요.
프로젝트 생성 디렉토리를 설정 후 터미널에서 다음과 같은 명령어를 입력하면 됩니다.
- 프로젝트 이름은? official_docs
- 타입스크립트 사용하는지? No
- ESLint 사용하는지? Yes
Next.js는 타입스크립트 기반의 프레임워크라 타입스크립트를 사용하는 것을 권장합니다. 포스팅에서는 빠른 코드작성과 피드백을 위해 No를 선택했습니다.
3개의 질문에 답하면 프로젝트 설치가 됩니다.
IDE(Visual Studio Code)로 프로젝트를 오픈하니 아래와 같이 잡혀있네요
package.json
{
"name": "official-docs",
"version": "0.1.0",
"private": true,
"scripts": {
"dev": "next dev",
"build": "next build",
"start": "next start",
"lint": "next lint"
},
"dependencies": {
"eslint": "8.28.0",
"eslint-config-next": "13.0.5",
"next": "13.0.5",
"react": "18.2.0",
"react-dom": "18.2.0"
}
}scripts의 명령어를 보면
dev, build, start, lint 총 4개의 명령어가 설정되어 있네요
npm run [명령어]를 통해 실행할 수 있습니다.
npm run dev : 로컬에서 개발서버 실행
개발서버가 localhost의 3000번 포트로 실행되었네요.
접속해 보도록 합니다.
Next.js의 환영인사를 받으셨다면 잘 따라오신 겁니다.
Pages
Next에서 Pages 폴더는 Convention(협약)입니다.
반드시 이름이 Pages이기로 프레임워크 내부에서 약속 되어 있습니다.
한번 바꿔볼까요?
pages를 not_pages로 바꾸니 404(페이지 찾을 수 없음)이 뜨네요.
그 이유를 문서에서 아래와 같이 설명하고 있습니다.
Next에서 page는 pages 디렉토리 안에 있는 리액트 컴포넌트 입니다
(js, jsx, ts, tsx 파일로부터 export되는..)
각 페이지는 각 파일의 이름을 기반으로 라우팅됩니다.(의역)
pages 폴더안에 about.js라는 리액트 컴포넌트를 만들면
about이라는 페이지가 되며 {domain}/pages/about 이라는 url로 접근할 수 있다는 의미입니다.
계속해서 다이나믹 라우팅에 대해서 설명하는 모습도 보이네요
pages/posts/[id].js 라는 페이지를 만들고 url을 post/1로 했을 때 id를 1로 동적할당 할 수 있다는 내용이고 자세한 설명은 Dynamic Routing문서를 참조하라고 적혀 있습니다.
그보다 중요한 건 아래부터입니다.
Pre-Rendering
단어만 보자면 '사전에 렌더링을 해둔다.' 정도일 것 같은데 이게 어떤 의미일까요?
기본적으로 Next는 모든 페이지를 사전 렌더링하며,
HTML 생성이 클라이언트 자바스크립트에 의해 동작하지 않는다고 하네요.
(React는 HTML을 자바스크립트에서 생성하죠! -> jsx)
const page = () => {
return <h1>I'm HTML!</h1>
}미리 생성된 HTML은 SEO(검색 엔진 최적화)에 더 나은 결과를 가져다 준다고 합니다.
-> 미리 준비된 페이지의 정보를 검색엔진에 제공 가능함
미리 생성된 HTML은 페이지를 완전히 동작시킬 수 있는 최소한의 자바스크립트 코드와 함께 브라우저에 띄워지는데,
이 프로세스를 하이드레이션 이라고 한다 하네요.
Static Generation? Server-side Rendering?
Next 진영에서는 두 가지 방법의 Pre-Rendering 방식을 설명하고 있습니다.
바로 Static Generation 방식과 Server-side Rendering 방식입니다.
Static Generation : 빌드 시에 HTML이 생성되며 이후 재생성하지 않음
Server-side Rendering : 요청 할 때 마다 HTML을 서버에서 생성한다.
여기서 또 Recommend라는 단어를 볼 수 있네요.
넥스트 진영에서는 Static Generation 방식을 권장하고 있습니다.
Static Generation은 HTML생성이 빌드할 때 이루어 지는 것입니다.
(npm run build 할 때!)
npm run dev, 즉 개발을 하실 때는 안됩니다.
외부에서 데이터를 가져올 필요가 없는(단순 페이지) 경우
빌드시에 HTML이 기본적으로 생성됩니다.
하지만 외부의 서버(백엔드)에서 데이터를 가져와서 보여줘야 하는 경우
'getStatic'으로 시작하는 함수를 사용해야 합니다.
- 페이지 상의 데이터를 서버에서 가져오는 경우 : getStaticProps
- 페이지의 Path를 서버에서 가져오는 경우 : getStaticPaths (대부분 getStaticProps와 같이 사용된다.)
지금은 해당 함수를 사용하지 않고, 사용할 수도 없습니다.
아직 서버가 없어서 External data가 없기 때문입니다.
(샘플 데이터를 제공하는 OpenAPI가 있지만 추후에 다루니 지금은 필요 없습니다.)
넥스트 문서에서는 친절하게
어떤 상황에서 어떤 Pre-Rendering 방식을 채택해야 하는지
알려주고 있습니다.
아래의 상황에서 Static Generation 방식을 채택하세요.
- 마케팅 페이지
- 블로그 포스트/포트폴리오
- 이커머스의 상품 리스트
- 도움 문서
문서는 스스로 질문을 해보라고 하네요 ㅋㅋ
"사용자 요청전에 페이지를 미리 렌더링할 수 있는가?"
만약 그렇다면 Static Generation을 하셔야 합니다.
위에 있는 케이스의 컨텐츠는 잘 변하지 않는 데이터입니다.
이커머스의 상품리스트 같은 경우는 변할 가능성이 꽤 있지만
신상품이 잘 추가되지 않는 커머스라면 가능하겠죠
반대로 사용자 요청전에 미리 페이지를 생성할 수 없는 경우엔 Server-Side Rendering 방식을 선택해야 한다고 하네요. (데이터가 수시로 업데이트 되는, 요청할 때 마다 다른 데이터를 수신할 경우 입니다)
예를 들면 주식/증권 데이터가 될 수 있겠네요? 주식의 가치는 시시각각으로
변하니까요.
Because Server-side Rendering results in slower performance than Static Generation, use this only if absolutely necessary.
끝으로 문서는 성능의 최적화를 위해서 정말로 필요할 때만 SSR을 쓰고
그게 아니라면 SSG방식을 채택할 것을 권장하며 마무리가 됩니다.
SSG/SSR은 Next.js가 가진 핵심 컨셉입니다.
이해가 조금 부족하셨다면 공식문서를 더 참조하셔도 좋고요
댓글을 달아주셔도 좋습니다.
다음편을 잘 준비해볼게요. 감사합니다!
