```javascript
import { useRouter } from 'next/router'

export default function IndexPage({ time }) {
  const router = useRouter()

  const refreshServerSide = () => {
    router.replace(router.asPath)
  }

  return (
    <>
      <div>Server Side Props Request Time: {time}</div>
      <button onClick={refreshServerSide}>Refresh Server Side</button>
    </>
  )
}

export async function getServerSideProps(context) {
  const currentDateTime = new Date().getTime()
  return {
    props: { time: currentDateTime },
  }
}
```

`getServerSideProps` 의 동작을 상상해본다면 아래와 같을 것이다.

https://yceffort.kr/2020/03/nextjs-02-data-fetching#4-getserversideprops

1. `getServerSideProps`가 있는 사이트 방문
2. nextjs가 `getServerSideProps`를 호출하여 HTML 파일 생성
3. HTML 파일을 사용자가 내려받고, 리액트가 클라이언트에서 처리 (rehydration)

그러나 한가지 nextjs에서 `getServerSideProps`를 클라이언트 사이드에서 처리하는 경우가 있다. 아래와 같은 시나리오를 상상해보자.

1. 유저가 이미 사이트에 있고, next.js의 `Link`를 클릭하여 서버사이드 렌더링 된 페이지에 방문
2. nextjs가 `getServerSideProps`를 서버에 호출하는데, 이전 처럼 HTML파일을 내려주는 대신에 단순히 데이터를 json으로 클라이언트에 전송
3. 리액트가 해당 json을 initial props로 브라우저에서 새 페이지를 렌더링

이 와 같은 과정이 위 예제 코드에서 이루어지고 있다.

최초 페이지 진입시에는 이렇게 완성된 html을 내려준다.

```javascript
<div id="__next">
    <div>Server Side Props Request Time:
      1611794984243</div><button>Refresh Server Side</button>
</div>
```

위 코드로 새로고침하면, 아래와 같은 json데이터만 받는다.

```json
{ "pageProps": { "time": 1611795117182 }, "__N_SSP": true }
```

> `__N_SSP`는 server side props이라는 뜻이다. https://github.com/vercel/next.js/blob/e819e00d0c0b2d9cd851c2c7215af1211c561932/packages/next/next-server/lib/constants.ts#L39

nextjs의 좋은 점 중 하나는 `getServerSideProps`를 일종의 api 호출처럼 사용할 수도 있다는 것이다. 위에서 사용했던 `router.asPath`는 현재 페이지의 위치를 반환한다. 여기서는 `/` 일 것이다. 이 페이지로 리다이렉트 시켜달라는 뜻은, 즉 page에 해당 데이터를 json으로 내려달라는 말과 동일하다.그리고 `push` 대신 `replace`를 사용하여 히스토리 스택에 쌓이는 것도 방지하였다.

만약 이 경우에 로딩 스피너를 걸어둬야 한다면 어떻게 할까?

```javascript
const [loading, isLoading] = useState(false)

const refreshServerSide = () => {
  router.replace(router.asPath)
  isLoading(true)
}

useEffect(() => {
  isLoading(false)
}, [time])
```

`useEffect` 훅에 서버사이드 props를 넣어주었다.

그리고 이렇게 넘겨 받은 서버사이드 props를 고치고 싶다면, 아래와 같이 처리해주면 된다.

```javascript
export default function IndexPage({ time }) {
  const [currentTime, setCurrentTime] = useState(time)
  //...
}
```

항상 감사하십시오 and I also, nextjs 조아

Nextjs에서 Server Side props를 새로고침하기

nextjs 10.0.0이 릴리즈 되었다. 내가 좋아하는 오픈소스 중 하나 이기 때문에, 릴리즈 노트를 읽어보면서 당장 내 블로그에 적용해보았다. 그리고 적용하면서 어떤게 바뀌었는지 하나씩 확인해보려고 한다.

- 릴리즈노트: https://nextjs.org/blog/next-10

## 빌트인 이미지 컴포넌트, 그리고 자동 이미지 최적화

이미지는 마크업과 함께 웹에서 큰 트래픽을 유발하는 범인중 하나다. 이러한 이미지를 최적화 하기 위해, `next/image` 라는 전용 이미지 컴포넌트를 적용하였다. 브라우저에서 `Webp`가 사용 가능하다면, 해당 이미지를 변환해서 적은 용량으로 내려주고, 동시에 lazy loading도 해준다고 한다.

### 대상 이미지

![blog profile](./images/profile.png)

### 적용전

```typescript
const AuthorPhoto = styled.image`
  display: inline-block;
  margin-bottom: 0;
  border-radius: 50%;
  background-clip: padding-box;
  width: 75px;
  height: 75px;
  cursor: pointer;
`

return <AuthorPhoto alt={name} src={photo} />
```

```html
<img
  alt="yceffort"
  src="/profile.png"
  class="Author__AuthorPhoto-sc-1ywmx02-0 fMrwt"
/>
```

```bash
accept-ranges: bytes
access-control-allow-origin: *
age: 1331855
cache-control: public, max-age=0, must-revalidate
content-disposition: inline; filename="profile.png"
content-length: 30710
content-type: image/png
date: Wed, 28 Oct 2020 02:05:42 GMT
etag: W/"078a2ad86a1350e007d801e7f74b073ed415e5bdd60a60e5b65b9fafe972af03"
server: Vercel
status: 200
strict-transport-security: max-age=63072000
x-content-type-options: nosniff
x-frame-options: DENY
x-vercel-cache: HIT
x-vercel-id: icn1::chhv4-1603850742953-91ba1434fc9c
x-xss-protection: 1; mode=block
```

### 적용후

그리고 이를 `next/image`로 아래와 같이 바꿨다.

```typescript
import Image from 'next/image'

const AuthorPhoto = styled(Image)`
  display: inline-block;
  margin-bottom: 0;
  border-radius: 50%;
  background-clip: padding-box;
  width: 75px;
  height: 75px;
  cursor: pointer;
`

// width와 height를 지정해줘야 한다.
return <AuthorPhoto alt={name} src={photo} width={75} height={75} />
```

```html
<img
  alt="yceffort"
  data-src="/_next/image?url=%2Fprofile.png&amp;w=320&amp;q=75"
  data-srcset="/_next/image?url=%2Fprofile.png&amp;w=320&amp;q=75 320w"
  class="Author__AuthorPhoto-sc-1ywmx02-0 fMrwt"
  style="visibility: visible; height: 100%; left: 0px; position: absolute; top: 0px; width: 100%;"
  src="/_next/image?url=%2Fprofile.png&amp;w=320&amp;q=75"
  srcset="/_next/image?url=%2Fprofile.png&amp;w=320&amp;q=75 320w"
/>
```

```bash
accept-ranges: bytes
access-control-allow-origin: *
age: 276
cache-control: public, max-age=0, must-revalidate
content-disposition: inline; filename="profile.png"
content-length: 18898
content-type: image/webp
date: Wed, 28 Oct 2020 02:06:37 GMT
server: Vercel
status: 200
strict-transport-security: max-age=63072000; includeSubDomains; preload
x-content-type-options: nosniff
x-frame-options: DENY
x-robots-tag: noindex
x-vercel-cache: HIT
x-vercel-id: icn1::q6js7-1603850797310-7e6bd3beb3f0
x-xss-protection: 1; mode=block
```

일단 이미지가 눈에 띄게 lazy loading이 되었고 (나중에 떴고) 이미지 사이즈도 webp를 사용하면서 눈에 띄게 줄어든 모습이다. 구글 크롬팀에서 이미지 성능을 향상 시킬 수 있는 리액트 컴포넌트를 만들 수 있도록 도와주었다고 하는데, 나중에 소스 코드를 보는 것도 재밌을 것 같다.

## 국제화 라우팅

당장 내가 쓸 일이 있을지는 모르겠지만, 언어별 라우팅을 지원한다. 그리고 최신 브라우저가 지원하는 `Accept-language`헤더를 기반으로 언어 감지를 할 수 있는 기능도 추가되었다고 한다.

```javascript
// next.config.js
module.exports = {
  i18n: {
    locales: ['en', 'nl'],
    domains: [
      {
        domain: 'example.com',
        defaultLocale: 'en',
      },
      {
        domain: 'example.nl',
        defaultLocale: 'nl',
      },
    ],
  },
}
```

## 성능 분석

nextjs를 사용하는 웹 어플리케이션의 성능을 분석할 수 있는 도구를 지원한다.

https://nextjs.org/analytics

당장은 vercel만 지원하는 것 같은데(?) 운좋게도(?) 블로그가 vercel로 서빙되고 있기 때문에 당장 시도해보러 갔다.

![analytics](./images/analytics1.png)

![analytics](./images/analytics2.png)

(점수가 깎이는 것은 아마도 메인페이지의 페이지 전환 버튼 때문인 것 같다. 현재 타이틀 제목 길이에 따라서 페이징 버튼이 위아래로 일관되지 못하게 움직이는 버그가 있다.)

일단 모양새와 제공데이터는 구글 라이트 하우스와 비슷한데, 차이가 있다면 page 별로 데이터도 지원한다는 것이다. 다만 서두에도 말한 것 처럼 vercel을 써야만 누릴 수 있는 기능이라 🤔 근데 라이트 하우스에 비해 크게 차별점도 없다면...

## 커머스 키트 제공

https://nextjs.org/commerce

Next.js가 본격적으로 돈을 벌 만한 비즈니스를 시작하는 것 같다. 간단하게 말헤 next.js로 커머스 사이트를 만들 수 있는 도구를 제공한다고 한다.

## 리액트 17 지원

react 17을 지원한다. breaking change가 없으므로 바로 적용 가능하며 react를 import 하지 않아도 사용할 수 있는 jsx transform 기능도 사용할 수 있게 되었다.

https://reactjs.org/blog/2020/09/22/introducing-the-new-jsx-transform.html

## getStaticProps, getServerSideProps 빠른 새로고침

이제 해당 두 함수에서 코드 변화가 일어나면, 자동으로 새로고침을 지원한다고 한다. 이게 안되었다는 걸 이제 알았는데(??????) 해보니까 잘된다.

## 써드 파티 리액트 컴포넌트에서 css 임포트 가능

```javascript
import DatePicker from 'react-datepicker'
import 'react-datepicker/dist/react-datepicker.css'
```

이를 바탕으로, 단일 컴포넌트 레벨에서 CSS 코드 스플리팅이 가능해졌다. 자세한 내용은 https://nextjs.org/docs/basic-features/built-in-css-support

## `href` 자동화

이전까지, 다이나믹 라우팅을 사용하기 위해서 `next/link`에서 `href` `as`를 넣어 주어야 했다.

```html
<link href="/categories/[slug]" as="/categories/books" />
```

여기서 `as`는 실제 브라우저 URL 바에서 보이는 주소인데, 이전까지는 `href`와 `as`를 아래와 같이 따로 넣어주어야 했다.

```javascript
const pids = ['id1', 'id2', 'id3']
{
  pids.map((pid) => (
    <Link href="/post/[pid]" as={`/post/${pid}`}>
      <a>Post {pid}</a>
    </Link>
  ))
}
```

그러나 나를 비롯해서 많은 개발자들이 `as`의 사용에 대해서 혼란이 있었던 것 같다. (`as`를 넣어야 하는데 까먹는 다든지) 그래서 `as`가 더이상 필요없어졌다고 한다. 이제는 기존에 `as`에 넣었던 값을 `href`에 넣어주면 된다. 그게 훨씬 더 이전의 리액트나 HTML경험에서도 자연스러워 보인다.

## `@next/codemod` cli

nextjs 에서 기능이 deprecated 되는 등의 대규모 코드 베이스 변경이 필요한 경우에 사용할 수 있는 툴이다. codemode는 소스 코드 업데이트를 위해 프로젝트에서 실행할 수 있는 자동화 코드 변경 툴이다.

https://nextjs.org/docs/advanced-features/codemods

## `getStaticPaths`에 블로킹 fallback 추가

`getStaticProps` 와 `getStaticPaths`에 `fallback` 속성이 추가되어 있었다. 이 속성은 최초에는 정적 페이지 (fallback 페이지)를 제공하고, 이후 요청 시에는 완전히 렌더링된 콘텐츠를 제공할 수 있도록 도와주는 기능이었다. 그러나 몇몇 개발자들이, 사용자가 페이지를 처음 요청할때는 사전 렌더링을 차단할 수 있는 옵션을 요구했었나 보다. (나또한 fallback 페이지를 보여주는 것이 사용자들에게 안좋은 사용자 경험을 제공한다고 생각했다. ) 그래서 `blocking`옵션이 추가되었다.

```javascript
export function getStaticPaths() {
  return {
    fallback: 'blocking',
  }
}
```

이 옵션을 추가하면, fallback 페이지를 보여주는 대신에, 그냥 최초 렌더링이 서버에서 내려올 때 까지 기다린다.

## 결론

여러가지로 nextjs는 정말로 잘 관리되고 있는 리액트 SSR 프레임워크다. 단순히 nextjs 뿐만 아니라 여러가지로 nextjs를 중심으로 다양한 생태계를 만들어 가려는 것이 보인다.

모질라나 webpack 등 순수하게 기부로 운영되고 있는 대규모 오픈소스 프로젝트들이 코로나 시국이 닥치면서 생존 문제에 직면한 것을 보고 마음이 안타까웠다. 이러한 문제를 vercel도 알고 있는 듯, 여러가지로 수익화를 하려는 노력이 보였다. `vercel`, `next commerce` 등의 비즈니스를 통해서, 단순히 기부에 의존하는 것이 아니라 다각도로 생존에 대해 고민하고 있는 것이 보인다. 개인적으로 다 잘되었으면 하는 바람이다.

회사를 옮기면서 nextjs는 업무에서는 더 이상 쓰지 못하고 있지만 (ㅠㅠ) 블로그나 개인 프로젝트에서는 나름 적극적으로 사용하고 있었다. 심지어 지금 하고있는 nextjs conf 도 꼬박 꼬박 잘챙겨보고 있다. (미리 신청해서 티켓도 받아놨었는데 어디간지 모르겠네)

전 회사 사람들은 next github에 issue 도 올려서 contribute도 했는데 아직도 나는 가져다 쓰고 구글링 하기에 바쁘다 😇

같은, 그리고 연차도 더 많은 개발자로서 부끄럽지 않을 수가 없는 일이다. 조만간 오픈소스에 기여할 날도 오기를 바라며 열심히 공부를 해야겠다.


Nextjs 10 릴리즈 및 적용 후기

## Table of Contents

예전부터 블로그는 내가 직접 만든 적이 없고, 사람들이 만들어 놓은 템플릿에 마크다운만 얹는 식으로 운영했었다. 그러다 보니 무언가 수정이 필요할 때 마다 코드를 잘모르니 땜빵식으로 수정하게 되고, 블로그에 대한 애정도 부족하지 않았나 싶다.

## 1. 나는 왜 Next.js로 갔나

이전까지 쓰던 블로그는 static site generator로 Gatsby 기반으로 운영되고 있었는데, 나 뿐 만 아니라 많은 사람들이 여러가지로 불편함을 느끼고 있는 분위기 였다. 🤔

https://cra.mr/an-honest-review-of-gatsby/

https://jaredpalmer.com/gatsby-vs-nextjs

나의 경험과 섞어서 gatsby가 안좋았던 경험을 이야기 하자면

- 정적 사이트를 만들 뿐인데 GraphQL은 너무 무겁고 쓸모가 없다. 개인적으로 블로그 운영하면서도 써본적이 없다.
- gatsby만의 생태계, gatsby-plugin-\*\*\*에 너무 의존적이다. 버그가 있어도 수정이 어렵고, 대부분의 플러그인이 관리도 잘 안되고 있었다.
- 디버깅이 어려웠다. Gatsby 내부의 graphql 및 webpack 등등으로 인해 추상화가 있는대로 되어 있어서 디버깅 하기가 정말 쉽지 않았다.
- GraphQL, 그리고 마크다운과 혼재되어 있는 이미지 빌드 등 각종 작업으로 인해 빌드가 너무 오래 걸렸다. (그래서 대부분의 경우에 나는 빌드 결과를 확인하지 않고 머지했다.)

## 2. 스펙

기존 개발 스택은 아래와 같다.

- gatsby
- graphql
- react
- javascript
- flow
- SCSS

바뀐 개발 스택은 아래와 같다.

- nextjs
- remark
- rehype
- react
- typescript
- styled component

굳이 혼자 쓰는 프로젝트에 타입스크립트가 필요가 있겠냐만은, 이제 자바스크립트 생태계 자체가 많이 타입스크립트 쪽으로 기우는 것 같아서 함께 썼다.

마크다운을 HTML로 만들기 위해 `remark`와 `rehype`를 썼고, `SCSS`는 그냥 별로 안좋아해서 (내 jsx 에 클래스명이 덕지덕기 붙어있는게 너무 보기 힘들다) `styled component`로 넘어갔다.

## 2. 이사 과정

### 1) nextjs

nextjs에서 정적 사이트를 만들기 위해서 중요한 것은 `getStaticProps` 와 `getStaticPaths`다.

https://yceffort.kr/2020/03/nextjs-02-data-fetching#2-getstaticprops

https://yceffort.kr/2020/03/nextjs-02-data-fetching#3-getstaticpaths

`getStaticPaths`는 빌드시에 가능한 다이나믹 path를 결정하고, `getStaticProps`는 페이지 로딩 시에 서버사이드에서 내려올 props를 결정한다.

### 2) 마크다운 파일 읽어오기

내 마크다운 파일은 `/content/posts/articles`에 존재하고 있다. gatsby에서는 이것을 graphql로 처리하지만, nextjs에서는 그런 것이 없기 때문에 직접 파일시스템에 접근해서 재귀적으로 모든 `.md`파일을 찾아와서 [frontMatter](https://github.com/jxson/front-matter)로 읽어 왔다. 그리고 이렇게 읽어 온 마크다운을 HTML로 변환해주어야 한다. 이를 위해 [unified](https://github.com/unifiedjs/unified), [remark](https://github.com/remarkjs/remark) [rehype](https://github.com/rehypejs/rehype) 를 사용했다.

### 3) flow를 타입스크립트로 변환하기

이 과정이 젤 쉬웠다.

### 4) SCSS를 styled component로 변환

워낙 디자인 감각이 없는 대다가, SCSS에 postCss에 lostGrid 까지 사용되어 있어서 개인적으로 제일 고통스러운 과정이었다. 일일이 CSS를 보면서 적용했다.

## 3. 난관

### 1) Dynamic Path

내 블로그 글들을 nextjs dynamic path 문법으로 작성하면 다음과 같다.

```bash
- /[year]/[month]/[day]/[title]
- /[year]/[month]/[title]
```

그래서 아래와 같이 pages 디렉토리를 설정해주었는데

```bash
- /[year]/[month]/[day]/[title].tsx
- /[year]/[month]/[title].tsx
```

`day`와 `title`이 겹치면서 빌드가 되지 않았다. koa를 쓰면 라우팅 순서대로 타기 때문에 상관없지만, 여기까지 와서 koa를 쓰고 싶지 않아서 (...) 결국 아래와 같이 만들었다.

```bash
- /[year]/[month]/[day]/[title].tsx
- /[year]/[month]/[day]/index.tsx
```

이렇게 하면 세번째 path가 `day`로 동일해지기 때문에, 더이상 에러가 나지 않는다. 다만 `index.tsx`에서 `day`가 아니라 `title`이라는 사실을 염두해두고 개발에 해야한다.

### 2. 마크다운 파서

내 마크다운은 다음과 같은 기능을 반드시 제공 해야만 했다.

- toc 자동생성
- latex 문법 지원
- heading link
- raw html 지원 (iframe 등). 어차피 글은 나만 쓰기 때문에 상관없다.
- 코드 하이라이팅

이를 완벽하게 지원하기 위하여 참으로 많은 삽질을 거쳤다. 특별한 노하우가 있는게 아니고 그냥 삽질의 과정이 었다. 약간의 시간을 거친 끝에, 잘 만들었다.

https://yceffort.kr/2020/07/math-for-programmer-chapter2-3-rational-irrational-real-number

### 3. 사이트맵

사이트맵도 gatsby에서는 graphql로 잘 만들어줬지만, 여기서는 내가 다 만들어야 했다.

### 4. 리다이렉트

`/categories` url이 존재하는지도 몰랐는데, 있긴 있더라. 그래서 이것들을 다 리다이렉트 시켰다. `next.config.js`에서 다 처리할 수 있다.

```javascript
module.exports = {
  async redirects() {
    return [
      {
        source: '/tag/:tag',
        destination: '/tag/:tag/page/1',
        permanent: true,
      },
      {
        source: '/category/:tag',
        destination: '/tag/:tag/page/1',
        permanent: true,
      },
      {
        source: '/categories',
        destination: '/tags',
        permanent: true,
      },
    ]
  },
}
```

## 3. 결과

일단 빌드 시간이 엄청나게 빨라졌다.

![gatsby](./images/gatsby-build.png)

7분 가까이 빌드에 소요되었었다. ㅠㅠ

```bash
16:54:32.265  	Running "npm run build"
...

16:56:13.131  	success Rewriting compilation hashes - 0.006s
16:59:23.076  	success Building static HTML for pages - 7.784s - 655/655 84.15/s
16:59:24.034  	success Generating image thumbnails - 275.708s - 2434/2434 8.83/s
```

정적파일 빌드 하는데 3분이 넘게 걸렸고, 쓸데 없이 이미지 썸네일 만드는데에 5분까지 걸렸다.

![nextjs](./images/nextjs-build.png)

빌드도 빨라지고, 빌드 결과물도 기존 232.34mb에서 29.02mb로 다이어트 할 수 있었다. (nextjs는 다이나믹 path에 대해서 모두 빌드해두는 것이 아니라, 최초 페이지 접근 요청이 올 때만 빌드하고, 이 후 접근엔 이전에 빌드해둔 페이지를 보여준다.)

또한 기존에 찾기가 너무 어려웠던 mathjax 문법 오류도 다 고칠 수 있었다.

### github issue & board

https://github.com/yceffort/yceffort-blog-v2/projects/1

https://github.com/yceffort/yceffort-blog-v2/issues?q=is%3Aissue+is%3Aclosed+label%3A%22%F0%9F%91%B7%E2%80%8D%E2%99%82%EF%B8%8F+Next.js%22

(볼 때 마다 느끼지만, 깃헙 라벨링 정말 이쁘다)

## 4. 아쉬운점

- CSS를 옮기면서 약간 생각 없이 그냥 가져온 부분들이 많다. CSS에 대해 더 분석할 필요가 있을 듯
- nextjs는 정적이미지를 `public`디렉토리에서 서빙해야되는데, 이거 때문에 이미지를 다 이 디렉토리로 옮겨 왔다. 그러다 보니 글 쓰는 과정 마크다운 프리뷰에서 이 이미지들을 제대로 볼 수 가 없었다. dev 환경에서 볼 수 는 있지만, dev 에서 .md 파일에 대해서는 HMR이 안되었다. 향 후 아이디어가 필요해 보인다.
- 일부 type이 없는 패키지가 있었는데, 맘이 급해서 `@ts-ignore` 로 무시하고 갔다. `@mapbox/rehype-prism` `remark-slug` 시간 나는대로 만들어야겠다.

## 5. 개선 예정 사항

- 글 오른쪽 하단 플로팅 버튼으로 글 최상단에 올라갈 수 있는 기능
- algolia를 활용한 검색 (디자인까지 건드려야 되서 매우 귀찮을 듯)
- 조금 더 예쁜 about, contact


어영부영했지만 보람은 있었다

yceffort

nextjs

Nextjs에서 Server Side props를 새로고침하기

Nextjs 10 릴리즈 및 적용 후기

블로그 gatsby에서 nextjs로 옮긴 이야기