ODR(On Demand Revalidation) getStaticProps: 빌드 시 최초 한번만 실행 됨. 그래서 데이터가 담긴 HTML이 생성 됨. 아래처럼 revalidate를 쓰면 페이지가 최신인지 아닌지 판단 가능. nextjs 내부의 타이머가 20초로 맞춰지고, 그 때 까진 모든 사용자에게 같은 페이지를 보여줌. 20초 이후에 방문자가 오면 그 사람에게 역시 같은 페이지를 보여주고, nextjs 내부에서 새 버전의 페이지를 만듦. 그래서 그 다음 방문자에게 새 버전을 보여줌. 역시 로딩이 필요없지.
아니면 특정 액션 이후에 revalidate를 동작케 할 수 있다. api 폴더 내에 revalidate.ts를 만들고 .env에 나만의 TOKEN을 저장한다. 그리고 api/posts에서 post를 작성 할 때, 특정 TOKEN을 포함한 URL로 request를 날려주면 revalidate.ts에서 토큰을 비교해서 revalidate를 해준다.
ISR(Incremental Static Regenertion) 그럼 동적인 페이지들도 정적페이지로 만들수는 없을까? (/products/[id] 페이지의 동작방식에서 구현함.) getStaticPaths에서 paths에 빈 array를 넘기면 됨. 그러면 아래 사진처럼 products폴더 안에 빨간 박스 부분 없이 build됨. 그리고 /products/1로 최초 request가 오면, 1.html을 생성한다. 그 다음 request에는 이미 생성된 HTML을 주게 되니 로딩없이 바로 페이지가 렌더링된다. 이렇게 incremental하게 static 페이지를 generate하는 방식여서 ISR이라고 부른다.
여기서 fallback 옵션을 어떤 것을 주느냐에 따라 페이지를 생성할 동안 사용자에게 어떤 화면을 보여줄지 정할 수 있다. true,'blocking',false
export const getStaticPaths: GetStaticPaths = () => {
return {
paths: [], //페이지 빌드 할 때 아무런 HTML페이지도 미리 생성하지 않는다는 뜻. 그러나 사용자의 요청에 따라 미리 만들어지기 시작할꺼고, 여기서 fallback이 활용된다.
fallback: true,
//GetStaticProps or GetStaticPaths이 있는 페이지에 왔을 때, HTML이 아직 없으면,
//유저를 잠깐 blocking하고 그동안 백그라운드에서 페이지를 만들어서 유저를 줌.
//blocking 할동안 유저는 아무것도 못보지
//이는 딱 한번만 일어남. 기본적으로 SSR임.
//false면 어떤 페이지든 프로젝트의 빌드과정에서 만들어지는 것만이 가질 수 있는것. 추가하지못함
//그래서 이 경우 404 return됨
//true면 page generate될 때 까지 무언갈 보여줌
};
};
1. fallback: true router에 접근해서 router.isFallbck이라는 변수를 이용해서 페이지 생성 동안 대신 보여줄 html을 지정해준다.
참고로 ISR 이면 위 코드에서 GET방식의 /api/products/ 컨트롤러는 필요 없겠지. 이미 생성된 페이지를 보여주기 때문에. POST는 데이터 변경해야 하기 때문에 필요하고.
2. fallback: false 404 페이지가 리턴됨. 프로젝트가 build 될 때 생성된 페이지들만 보여준다는 뜻임.
3. fallback: 'blocking' GetStaticProps or GetStaticPaths이 있는 페이지에 왔을 때, HTML이 아직 없으면, 유저를 잠깐 blocking하고 그동안 백그라운드에서 페이지를 만들어줌. blocking 할동안 유저는 아무것도 못봄. 이는 딱 한번만 일어남. 기본적으로 SSR임.
참고 할 것들. ISR은 user의 정보에 의존적인 페이지(account,profile,dashboard 등)에는 적합하지 않음. 사용자별로 페이지를 만들어 놓는게 불가능하니까. 이 때는 그냥 normal fetching을 사용해야 함.
그리고 SSR(getServerSideProps)은 DB가 빠르면 고려해볼만 하다. 다만 blank 페이지를 보게되겠지.
20.7 Code Challenge community/[id] 부분을 getStaticProps, getStaticPaths, 그리고 fallback을 사용해서 HTML로 만들어봐. 필요할 때, revalidate도 해야하고. 궁금해요 기능을 위해서 SWR도 해야 함. profile/index에서 사용했었음. 이거 똑같이 하면 됨.
페이지를 렌더링하는 방법들 1. CSR - 완성된 초기 html먼저 보여줌, ReactJS가 데이터 알아서 불러오고. 2. SSR - all or nothing, 완성된 HTML 보여주고, ReactJS는 필요없음.(getServerSideProps) 3. 빌드 될 때 파일 미리 생성해두기(getStaticProps, getStaticPath), interaction없는 static page(F&Q 같은 곳)에 사 - 직전 포스트의 내용
이제는 페이지 불러 올 때 getServerSideProps없이도 로딩상태를 완전히 안보여줄 수 있다.
20.1 ISR part One ISR사용하면 로딩 안보이고, 서버에서 렌더링 할 필요 없음(getServerSideProps사용 안함). 페이지 즉시 불러 올 수 있음. 유저가 페이지 열면 서버단에서 렌더링 되는게 아님. 이미 랜더링 된 상태.
getStaticProps()의 return 객체에 revalidate에 시간(초)을 넣으면 그 시간마다 페이지가 다시 빌드 됨.
import { unified } from "unified";
import remarkParse from "remark-parse/lib";
import remarkHtml from "remark-html";
getStaticPath를 통해 파일 읽고, 파일 이름 읽어서 params에 {slug:name} 객체를 전달한다. 이것들을 페이지로 만들어주세요~하는거지
그러면 getStaticProps에서 context객체를 통해 위 params에 접근 가능하게 되고, 슬러그 id들을 접수 받고, 이 슬러그(post)들을 HTML로 바꿔주고 화면을 그린다. 아래 사진 참고.
아래는 결과물
19.14 Inner HTML ReacJS는 위처럼 받은 데이터가 html태그여도 그냥String으로 받는다. 보안에 상당히 취약하기 때문이다. 댓글로 <script>태그를 넣어 사용자 정보를 빼올 수도 있다. 그러니 이를 막아놨다. 다만 위 경우, data source를 신뢰 할 수 있기 때문에 dangerouslySetInnerHTML이라는 옵션을 사용하면 된다. dangerouslySetInnerHTML은 브라우저 DOM에서 innerHTML을 사용하기 위한 React의 대체 방법,__html 키로 객체를 전달한다.
참고, css파일에서 @apply를 사용하면 tailwind 문법 사용가능하다.
19.15 Recap getStaticProps가 잘 동작하는지 보려면, .next 폴더 지우고 build다시 해야 함. getStaticProps처럼 페이지 빌드할 때 미리 다 해놓는걸 Backend or CRM or Admin pannel 이라고 부른다(?)
유저에게 화면을 어떻게 보여줄지는 두가지로 나뉜다. 1. 다 로딩되면 한번에 보여주자. SSR (server side rendering) 2. 로딩 전에 뭐라도 보여주자. CSR (client side rendering)
1번 방식을 구현하려면 getServerSideProps()를 사용하면된다. 페이지에서 getServerSideProps(서버 측 렌더링)라는 함수를 export 하면 Next.js는 getServerSideProps에서 반환된 데이터를 사용하여 각 요청에서 이 페이지를 미리 랜더링한다고함.
useSWR을 안쓰고 index.tsx에 getServerSideProps()를 다음과 같이 넣어주면 서버에서 먼저 실행한다. 그럼 잘 작동하는데 이 때 useSWR의 다양한 기능을 못씀. static optimization이나 cache 못함. 그리고 getServerSideProps() 실행 도중 에러나면 아무것도 보지 못한다.
import Document, { Head, Html, Main, NextScript } from "next/document";
class CustomDocument extends Document {
render(): JSX.Element {
console.log("Document is running");
return (
<Html lang="ko">
<Head>
<link
href="https://fonts.googleapis.com/css2?family=Noto+Sans+KR&display=swap"
rel="stylesheet"
/>
</Head>
<body>
<Main></Main>
<NextScript></NextScript>
</body>
</Html>
);
}
}
export default CustomDocument;
//NextJS앱의 html 뼈대를 짜주는 역할
//안의 Main은 Nextjs가 앱 컴포넌트를 랜덩링 해주는 것.
//HTML 뼈대를 짜주는 역할을 하는 파일이라 서버에서 단 한번 실행 됨.
//<Main>안에서 _app.tsx가 들어간다.
_document.tsx의 역할. 이 페이지는 단 한번 렌더링 됨. 그리고 아래 html은 크롤라나 bot이 올 때 이미 완성되어있다. SEO에 좋다.
아래는 위치
_document.tsx
NextJS의 폰트 최적화는 구글 폰트에 한정되어있기 때문에 구글폰트 링크를 써야 함. 어떻게 최적화 해줄까? 개발자모드에선 확인 안됨. 빌드해야 함
일단 구글폰트를 불러오는 링크(<linkhref="https://fonts.googleapis.com/css2?family=Noto+Sans+KR&display=swap"rel="stylesheet"/>)에는 폰트를 불러올 링크들이 또 있다. 따라서 빌드 시에 이 링키들을 열어서 한군데 모아줌. 그러니 이미 폰트들을 불러와 두는거지. 두단계를 건너 뛴다고 보면 되나? 꽤나 도움이 될듯하다.