⚠️ Hydration failed because the server rendered HTML didn't match the client.
As a result this tree will be regenerated on the client.
This can happen if a SSR-ed Client Component used
- A server/client branch 'if (typeof window !== 'undefined')'.
- Variable input such as 'Date.now()' or 'Math.random()' which changes each time it's called.
- Date formatting in a user's locale which doesn't match the server.
- External changing data without sending a snapshot of it along with the HTML.
- Invalid HTML tag nesting.
It can also happen if the client has a browser extension installed
which messes with the HTML before React loaded.
See more info here: https://nextjs.org/docs/messages/react-hydration-error
탭마다 고정된 레이아웃이 있어서 공용 컴포넌트로 만들어서 RootLayout에 추가했다. 그랬더니 하이드레이션 에러
개발자가 기능 구현에만 ‘딱’ 집중할 수 있도록 필요한 모든 프로그래밍적 재원을 지원하는 ‘기술의 조합’
React.js가 가지고 있는 기능을 확장, 웹 애플리케이션 개발에 필요한 다양한 기능과 구조를 제공한다.
💡 6가지 원칙
1. out-of-the-box functionality requiring no setup : 별도의 설정 없이 바로 사용할 수 있는 기능을 제공
2. JavaScript everywhere + all functions are written in JavaScript : JavaScript를 통해 모든 작업을 수행
3. automatic code-splitting and server-rendering : 서버에서 렌더링을 수행하여 초기 로딩 속도를 개선
4. configurable data-fetching : 개발자가 필요에 따라 다양한 방식으로 데이터를 패칭
5. anticipating requests : 사용자가 원하는 것이 무엇인지를 먼저 예측 = 요구사항 예측
6. simplifying deployment : 애플리케이션을 쉽게 배포
다양한 렌더링 기법
SSG(Static Site Generaton)
fetch한 데이터는 영원히 변치 않아요. 계속 컴포넌트를 갱신할 필요가 없어요.
서버에서 페이지를 렌더링하여 클라이언트에게 HTML을 전달하는 방식
최초 빌드시에만 생성
첫 페이지 로딩 시간이 매우 짧아(TTV) 사용자가 빠르게 페이지를 볼 수 있음
정적인 데이터에만 사용
마이페이지 처럼 데이터에 의존하여 화면을 그려주는 경우 사용 불가
이전에 SSG를 구현하기 위해서는 예전 getStaticPaths 가 필요했지만 13 버전에서는 generateStaticParams 함수로 바뀌었다. App Route 등장
// (1) 첫 번째 방법 : 아무 옵션도 부여 x
const SSG = async () => {
const response = await fetch(`https://randomuser.me/api`);
const { results } = await response.json();
const user: RandomUser = results[0];
}
// (2) 두 번째 방법 : force-cache
const SSG = async () => {
const response = await fetch(`https://randomuser.me/api`, {
cache: "force-cache",
});
const { results } = await response.json();
const user: RandomUser = results[0];
}
// 결과 : 아무리 새로고침을 하여도 동일한 페이지만 출력
ISR(Incremental Static Regeneration)
fetch한 데이터는 가끔 변해요. 일정 주기마다 가끔씩만 컴포넌트를 갱신해줘요.
정적 페이지를 먼저 보여주고, 필요에 따라 서버에서 페이지를 재생성하는 방식
설정한 주기만큼 페이지를 계속 생성
정적 페이지를 먼저 제공하므로 사용자 경험이 좋으며, 콘텐츠가 변경되었을 때 서버에서 페이지를 재생성하므로 최신 상태를 (그나마) 유지
동적인 콘텐츠를 다루기에 한계
마이페이지 처럼 데이터에 의존하여 화면을 그려주는 경우 사용 불가
// (1) 첫 번째 방법 : 옵션 추가
const ISR = async () => {
const response = await fetch(`https://randomuser.me/api`, {
next: {
revalidate: 5,
},
});
const { results } = await response.json();
const user: RandomUser = results[0];
}
// (2) 두 번째 방법 : page.tsx 컴포넌트에 revalidate 추가
// src>app>rendering>page.tsx
import ISR from "@/components/rendering/ISR";
import React from "react";
export const revalidate = 5;
const RenderingTestPage = () => {
return (
<div>
<h1>4가지 렌더링 방식을 테스트합니다.</h1>
<ISR />
</div>
);
};
export default RenderingTestPage;
// 결과 : 주어진 시간에 한 번씩 갱신
SSR(Server Side Rendering)
fetch한 데이터는 실시간으로 계속 바뀌어요. 컴포넌트 요청이 있을 때 마다 데이터를 갱신해서 최신 데이터만 제공해야 해요.
빌드 시점에 모든 페이지를 미리 생성하여 서버 부하를 줄이는 방식
빠른 로딩 속도(Time To View)와 높은 보안성을 제공
SEO 최적화 좋음, 실시간 데이터 사용
마이페이지 구성 가능
요청할 때 마다 페이지를 만들어야 하며, 콘텐츠 변경 시 전체 사이트를 다시 빌드 해야하므로 서버 과부하 가능성
// (1) 첫 번째 방법 : no-cache 옵션
const SSR = async () => {
const response = await fetch(`https://randomuser.me/api`, {
cache: "no-cache",
});
const { results } = await response.json();
const user: RandomUser = results[0];
}
// 결과 : 요청이 있을 때 마다 지속해서 갱신
CSR(Client Side Rendering)
fetch한 데이터는 실시간으로 계속 바뀌어요. 컴포넌트 요청이 있을 때 마다 데이터를 갱신해서 최신 데이터만 제공해야 해요.
브라우저에서 JavaScript를 이용해 동적으로 페이지를 렌더링하는 방식
사용자와의 상호작용이 빠르고 부드러움
서버 부하가 적음
첫 페이지 로딩 시간(Time To View)이 김
JavaScript가 로딩되고 실행될 때까지 페이지가 비어있어 검색 엔진 최적화(SEO)에 불리
// (1) 첫 번째 방법 : “use client” 옵션
“use client”
const SSG = () => {
const [user, setUser] = useState<RandomUser | null>(null);
useEffect(() => {
const fetchUser = async () => {
const response = await fetch(`https://randomuser.me/api`);
const { results } = await response.json();
setUser(results[0]);
};
fetchUser();
}, []);
if (!user) {
return <div>로딩중...</div>;
}
}
// 결과 : 요청이 있을 때 마다 지속해서 갱신
✍🏻 렌더링 기법 표 정리
구분
빌드
SEO
응답 시간
최신 데이터
SSG
길다
좋음
짧다
아님
ISR
길다
좋음
짧다
아닐 수 있음
SSR
짧다
좋음
길다
맞음
CSR
짧다
안좋음
보통
맞음
Next.js 프로젝트 생성
npx create-next-app@latest
Link
Next.js는 <Link>라는 리액트 컴포넌트를 제공합니다. <Link>태그는 기본 HTML의 <a>태그를 확장한 개념
1. prefetching을 지원
- 뷰포트(현재 보이는 부분)에 링크가 나타나는 순간 해당 페이지의 코드와 데이터를 미리 가져오는 프리페칭 기능을 지원
❓ 사용자의 마우스가 링크 위에 mouseover 되는 순간 네트워크 요청이 생긴다는 것일까?
💡 렌더링된 링크가 사용자의 뷰포트 내에 나타나는 순간,
Next.js는 해당 페이지의 데이터와 필요한 자원(예: JavaScript 파일)을 미리 가져오기 시작
2. client-side navigation 지원
- 브라우저가 새 페이지를 로드하기 위해 서버에 요청을 보내는 대신
클라이언트 측에서 페이지를 바꾸어 주기 때문에 페이지 전환 시 매우 빠른 사용자 경험(UX)을 제공
- 필요한 JSON 데이터만 서버로부터 가져와서 클라이언트에서 페이지를 재구성하여 렌더링
요청된 데이터의 URL에서 쿼리 파라미터를 가져온다. supabase에서 range라는 범위 속성을 제공해준다.
(page - 1) * limit, page * limit - 1) 는 만약 페이지가 2, 리밋이 10일 경우 (2-1) * 10 = 시작 인덱스, 2 * 10 - 1 = 끝 인덱스 이렇게 한다면 시작 인덱스는 10, 끝 인덱스는 19가 된다. 하나의 페이지마다 10개의 데이터를 보여주는 것!
`/api/review?product_id=${productId}&page=${page}&limit=${limit}` //요청 url
const { searchParams } = new URL(request.url); //상대 경로는 URL 객체에서 직접 설정
const productId = searchParams.get('product_id'); // 쿼리 파라미터에서 product_id 가져오기
const page = Number(searchParams.get('page')) || 1; // 페이지 번호
const limit = Number(searchParams.get('product_id')) || 10; // 리뷰 10개씩
페이지네이션을 구현할 때 총 리뷰 개수를 알아야 전체 페이지 수를 계산할 수 있다. 사용자 경험으로 보았을 땐 사용자가 특정 페이지를 선택했을 때, 그 페이지가 유효한지 확인할 수 있다. 만약 총 데이터 수가 25개이고 페이지당 리밋이 10개라면 2.5페이지가 나와야하는데 이때 Math.ceil() 사용해 정수로 바꿔주면서 3페이지로 올림처리한다.
const { count: totalReviews, error: countError } = await supabase
.from('reviews')
.select('*', { count: 'exact' }) // 총 행 수 계산 => 반환, count 속성에 총 리뷰 수
.eq('product_id', productId);
if (countError) {
return NextResponse.json({ error: countError.message }, { status: 400 });
}
const totalPages = Math.ceil((totalReviews || 0) / limit); // 총 페이지 수 계산
응답 값
데이터 패칭
쿼리키에 데이터를 저장해줬다. fetch를 사용해서 API엔드포인트에 GET요청을 보내고, 응답을 JSON으로 변환해서 반환해준다. 여기서 productId는 리뷰를 가져올 특정 상품의 id이다.
페이지네이션 ui는 shadcn을 사용했다. shadcn은 쓰면 쓸수록 좋은 것 같다. 간단하고 예쁘고..~
PaginationPrevious는 현재 페이지가 1보다 클때 이전 페이지로 이동할 수 있다.
PaginationNext는 리뷰 총 페이지보다 작을 때 다음 페이지로 이동할 수 있다.
Array.from은 reviewData.totalPages 만큼 배열을 생성한다. 현재 총 페이지는 2페이지이다. onClick={() => handlePageChange(index + 1)} 클릭한 페이지 번호를 인자로 받아서 현재 페이지를 변경한다. isActive={currentPage === index + 1} 현재 페이지와 클릭한 페이지 번호가 일치하면 active한 상태를 보여준다.
프로젝트를 하면 할수록 내가 맡은 기능에 빈틈이 보여 계속 수정하게된다. 에러로직이나 선택한 상품이 없는 하단에 상품 개수가 보인다던가. 특정 상품만 체크하고 수량을 올렸더니 체크가 모두 활성화된다던가 이런 빈틈들이 잘보이고 유저테스트 이후로 기능 구현을 섬세하게 해야한다는게 얼마나 중요한지 뼈저리게 느꼈다ㅎ 오늘은 체크한 상품들을 선택 삭제하는 기능 구현을 해보려고한다!!
DeleteButton.tsx
선택 삭제 버튼을 따로 만들어주었다. 선택 삭제를 염두해두고 상품 삭제하는 로직이 있는 커스텀 훅을 만들어놓아서 코드를 간단하게 짤 수 있었다. 여기서 마주친 문제.. 처음 코드를 쓸 때 map을 사용했었다.
그런데 생각해보니까 map은 새로운 배열을 반환하는데 상품을 삭제하는데 굳이? 새 배열을 반환할 필요가 있을까 생각이 들었다. 괜한 메모리 낭비같았다 그래서 다른 메서드를 구글링하다가 forEach 가 적합하겠다고 생각했다 분명 배운건데 코드짤 땐 생각이 안날까,,
forEach와 map의 차이점 → 새로운 배열 생성 반환여부
forEach()
함수는 배열의 각 요소를 순회하며 주어진 함수를 호출합니다. 각 요소에 대해 함수를 호출할 때, 해당 요소의 값, 인덱스, 그리고 원본 배열을 인수로 넘겨줍니다. 주어진 함수는 배열의 크기만큼 반복 실행되며, 배열 요소의 개수에 따라 콜백 함수가 호출되는 횟수가 결정됩니다.
forEach() 함수는 반환 값이 항상 undefined 입니다. 새로운 배열을 생성하지 않습니다.
map()
map() 함수는 배열을 순회해서 각 요소를 콜백 함수로 적용해서 처리해 모은 새로운 배열을 반환하기 위한 함수입니다.
map() 함수에 전달되는 콜백 함수는 "각 요소를 변환하여 새로운 배열로 매핑(mapping)하는 역할을 한다"라고 말합니다. 이렇게 매핑된 결과를 새로운 배열로 반환하기 때문에 이 함수의 이름이 "map"으로 정해졌습니다.
아래 코드는 디테일 페이지에서 특정 상품의 데이터를 가져오는 부분이다. 원래는 상세 정보와 리뷰 탭이 없었는데 UT를 진행하면서 리뷰가 있었으면 좋을 것 같다는 피드백이 많아서 구현하게 되었다. UT를 해볼 기회는 없었는데 이번에 해보게 되어서 너무 좋았다(?) 피드백을 받고 수정하는데 테스트 전보다 완성도 높은 작업물이 나올 것 같다.
그런데 여기서 문제. 저 리뷰 탭에 리뷰의 개수가 보여야하는데 저 개수만 보여주려고 리뷰 데이터를 패치해야하는 상황이 생겼다. 라우터 핸들러로 만들어놓긴 했지만 저 개수를 띄우려고 코드를 몇줄 이상 써야하는게 비효율적이라고 생각이 들었다. 구글링하다가 supabase join 기능이 있다고해서 참고했다. supabase 초반에 사용할 때 들었던 기능 같은데, 프로젝트에서 써먹어본건 최종까지와서다.. 막상 기억이 잘 안나서 사용하지 못했다,, 이제라도 알아서 다행이다^.~
