50% 확률로 reject 되는 아래와 같은 함수가 있다고 가정해보자.

```javascript
async function resolveOrReject() {
  // 1초를 그냥 기다린다.
  await new Promise((_) => setTimeout(_, 1000))

  // 50% 확률로 true false
  const randomResult = Boolean(Math.round(Math.random()))

  if (randomResult) {
    return 'good'
  } else {
    throw Error('bad')
  }
}
```

## 그냥 호출

```javascript
async function a() {
  try {
    resolveOrReject()
  } catch (e) {
    return 'caught!'
  }
}
```

이 경우 `a()`는 1초를 기다리지 않고 언제나 `undefined`를 `fulfilled` (이행) 할 것이다. 우리가 여기에서 `await` 하거나 껼과를 기다리지 않으므로, 실패했을 경우에 대해서 처리를 할 수가 없다. 대부분 이런 코드는 실수일것이다.

## await

```javascript
async function b() {
  try {
    await resolveOrReject()
  } catch (e) {
    return 'caught!'
  }
}
```

이 함수의 경우에는 항상 1초를 기다리며, `undefined`가 오거나 `caught`가 올 것이다. `resolveOrReject`의 결과를 기다리기 때문에, 실패 했을 경우 `catch` 블록을 실행할 수 있게 되었다. 그러나 실패하지 않았을 경우에는 이 값을 가지고 아무것도 하지 않는다.

## return

```javascript
async function c() {
  try {
    return resolveOrReject()
  } catch (e) {
    return 'caught'
  }
}
```

이 경우에도 마찬가지로 1초를 기다리며, 성공할 경우 `good` 이 오고, 실패할 경우에는 `caught`가 오는 것이 아니고 그냥 에러가 던져진다. 따라서 실패할 경우엔 `catch` 블록에 들어가지 않는다는 것을 알 수 있다.

## return await

```javascript
async function d() {
  try {
    return await resolveOrReject()
  } catch (e) {
    return 'caught'
  }
}
```

1초를 기다리며, `good`이 오거나 `caught`가 오게 된다. `resolveOrReject`의 결과를 기다리므로, 에러가 났을 때는 `catch` 블록으로 , 이행이 되었을 경우 정상적으로 결과를 리턴한다.

위 함수를 나누면 이렇게 볼 수 있다.

```javascript
async function d() {
  try {
    // resolveOrReject 의 결과를 기다리며, 결과를 변수에 넣는다.
    const result = await resolveOrReject()
    // 만약 위에서 에러가 던져졌다면, catch 블록으로 넘어간다.
    // 그렇지 않으면, 결과를 리턴한다.
    return result
  } catch (e) {
    return 'caught'
  }
}
```

**이 것은 어디까지나 `try ... catch` 블록에서만 유효하다.** 그 외의 영역에서는 `return await`은 의미하다. `async` 함수 내에 있는 `return await`은 프로미스를 기다렸다가 결과가 나올때까지, 현재의 함수를 콜스택에 넣어두며, 외부 promise가 resolve 되기전에 추가로 마이크로 태스크가 생기게 된다. 따라서 `try ... catch` 블록이 아니라면 단순히 `return something`으로 처리하면 된다.

https://github.com/eslint/eslint/blob/master/docs/rules/no-return-await.md


try catch 블록에서는 동작이 다르네

no return, await, return, await return 의 차이

50% 확률로 reject 되는 아래와 같은 함수가 있다고 가정해보자.
<pre class="language-javascript"><code class="language-javascript">async function resolveOrReject() {
 // 1초를 그냥 기다린다.
 await new Promise((_) => setTimeout(_, 1000))

 // 50% 확률로 true false
 const randomResult = Boolean(Math.round(Math.random()))

 if (randomResult) {
 return 'good'
 } else {
 throw Error('bad')
 }
}
</code></pre>
<h2 id="그냥-호출">그냥 호출</h2>
<pre class="language-javascript"><code class="language-javascript">async function a() {
 try {
 resolveOrReject()
 } catch (e) {
 return 'caught!'
 }
}
</code></pre>
이 경우 <code>a()</code>는 1초를 기다리지 않고 언제나 <code>undefined</code>를 <code>fulfilled</code> (이행) 할 것이다. 우리가 여기에서 <code>await</code> 하거나 껼과를 기다리지 않으므로, 실패했을 경우에 대해서 처리를 할 수가 없다. 대부분 이런 코드는 실수일것이다.
<h2 id="await">await</h2>
<pre class="language-javascript"><code class="language-javascript">async function b() {
 try {
 await resolveOrReject()
 } catch (e) {
 return 'caught!'
 }
}
</code></pre>
이 함수의 경우에는 항상 1초를 기다리며, <code>undefined</code>가 오거나 <code>caught</code>가 올 것이다. <code>resolveOrReject</code>의 결과를 기다리기 때문에, 실패 했을 경우 <code>catch</code> 블록을 실행할 수 있게 되었다. 그러나 실패하지 않았을 경우에는 이 값을 가지고 아무것도 하지 않는다.
<h2 id="return">return</h2>
<pre class="language-javascript"><code class="language-javascript">async function c() {
 try {
 return resolveOrReject()
 } catch (e) {
 return 'caught'
 }
}
</code></pre>
이 경우에도 마찬가지로 1초를 기다리며, 성공할 경우 <code>good</code> 이 오고, 실패할 경우에는 <code>caught</code>가 오는 것이 아니고 그냥 에러가 던져진다. 따라서 실패할 경우엔 <code>catch</code> 블록에 들어가지 않는다는 것을 알 수 있다.
<h2 id="return-await">return await</h2>
<pre class="language-javascript"><code class="language-javascript">async function d() {
 try {
 return await resolveOrReject()
 } catch (e) {
 return 'caught'
 }
}
</code></pre>
1초를 기다리며, <code>good</code>이 오거나 <code>caught</code>가 오게 된다. <code>resolveOrReject</code>의 결과를 기다리므로, 에러가 났을 때는 <code>catch</code> 블록으로 , 이행이 되었을 경우 정상적으로 결과를 리턴한다.
위 함수를 나누면 이렇게 볼 수 있다.
<pre class="language-javascript"><code class="language-javascript">async function d() {
 try {
 // resolveOrReject 의 결과를 기다리며, 결과를 변수에 넣는다.
 const result = await resolveOrReject()
 // 만약 위에서 에러가 던져졌다면, catch 블록으로 넘어간다.
 // 그렇지 않으면, 결과를 리턴한다.
 return result
 } catch (e) {
 return 'caught'
 }
}
</code></pre>
이 것은 어디까지나 <code>try ... catch</code> 블록에서만 유효하다. 그 외의 영역에서는 <code>return await</code>은 의미하다. <code>async</code> 함수 내에 있는 <code>return await</code>은 프로미스를 기다렸다가 결과가 나올때까지, 현재의 함수를 콜스택에 넣어두며, 외부 promise가 resolve 되기전에 추가로 마이크로 태스크가 생기게 된다. 따라서 <code>try ... catch</code> 블록이 아니라면 단순히 <code>return something</code>으로 처리하면 된다.
<a href="https://github.com/eslint/eslint/blob/master/docs/rules/no-return-await.md">https://github.com/eslint/eslint/blob/master/docs/rules/no-return-await.md</a>

## ECMAScript 언어 명세 상의 차이

- `undefined`: 변수에 값이 할당되지 않았을 때 사용된다. https://tc39.es/ecma262/#sec-undefined-value primitive value used when a variable has not been assigned a value

- `null`: 의도적으로 어떤 객체의 값이 비어 있다는 것을 나타낼 때 사용된다. primitive value used when a variable has not been assigned a value primitive value that represents the intentional absence of any object value

다른 언어와 다르게, 두개의 non-value가 있는 것은 자바스크립트 설계의 실수라고 한다. 그러나 이것이 지금까지 사용되고 있는 것은 자바스크립트가 구버전과의 호환성을 절대로 깨뜨리지 않는 다는 원칙이 있기 때문이다. [비슷한 사례로 `typeof null`이 있다.](https://2ality.com/2013/10/typeof-null.html)

자바스크립트가 많은 영감을 받은 자바에서는, 변수의 정적 타입에 따라 값을 초기화 한다.

- 객체 타입의 변수는 `null`로 초기화 한다.
- 원시 타입의 변수는 각자의 초기 값으로 초기화 한다. 숫자의 경우 0 이다.

자바스크립트의 경우에는, 변수가 객체가 될 수도 있고, 원시값이 될 수도 있다. 그러므로 만약 `null`이 "객체가 아니다" 라면, 자바스크립트는 "객체도 아니고 원시값도 아닌" 초기 값이 필요해 진다. 그것이 바로 `undefined` 다.

## undefined가 나오는 경우

```javascript
// 초기 값을 주지 않은 경우
let var

// 객체에서 정의 하지 않은 속성에 접근하는 경우
const obj = {}
obj.prop

// 함수의 리턴이 없는 경우
function func() {}
assert.equal(func(), undefined)

// 리턴은 있는데 아무것도 안하는 경우
function func() {
  return
}
assert.equal(func(), undefined)

function func(x) {
  assert.equal(x, undefined)
}

// 정의 되지 않은 파라미터
func()

undefined?.prop
null?.prop
```

## null이 나오는 경우

```javascript
// 프로토타입의 종점
Object.getPrototypeOf(Object.prototype) // null

// 정규식
/a/.exec('x') // null

// JSON은 undefined를 지원 하지 않는다.
JSON.stringify({a: undefined, b: null}) // "{"b":null}"
```

## undefined와 null을 특별하게 처리하는 연산자

### 함수 파라미터의 기본값

함수 파라미터의 기본값은 두가지 경우에서만 사용된다.

- 파라미터가 존재하지 않는 경우
- 파라미터의 값이 `undefined`인 경우

```javascript
function func(arg = 'abc') {
  return arg
}
console.log(func()) // abc
console.log(func(undefined)) // abc
console.log(func(null)) // null
```

### 분해연산자의 기본값과 undefined

위의 기본값 예제와 동일하게 동작한다.

```javascript
const [a = 'a'] = [] // a
const [b = 'b'] = [undefined] // b
const { prop: c = 'c' } = {} // c
const { prop: d = 'd' } = { prop: undefined } //d
const [e = 'e'] = [null] // null
const { prop: f = 'f' } = { prop: null } // null
```

### 옵셔널 체이닝

값이 nullish한 경우 (`null` `undefined`) `undefined`를 리턴한다.

```javascript
function getProp(obj) {
  return obj?.prop
}
getProp({ prop: 123 }) // 123
getProp(undefined) // undefined
getProp(null) // undefined
```

### undefined, null, nullish coalescing (null 병합 연산자)

`||` 와는 다르게 `nullish` 한 값에 대해서만 대응한다.

```javascript
undefined ?? 'default value' // default value
null ?? 'default value' // default value
0 ?? 'default value' // 0
'' ?? 'default value' // ''
```

null 병합 할당 현산자인 `??=` 도 마찬가지로 동작한다.

## 결론(?)

명시적으로 값이 없다는 걸 나타내고 싶다면, `null`을 쓰는게 좋다. `undefined`는 기본값 할당, JSON에서 생략되는 등 의도치 않은 동작을 나타낼 수 있다. 내가 의도적으로 빈값을 두고 싶다면, `null`이 나은 것 같다. 그렇다고 `undefined`가 내가 짠 코드에서 안나오는 것은 아닐 것이다. 말하고 싶은 것은 의도적으로 빈값을 집어 넣을 때 둘중에 `null`을 더 선호한다 정도일 것이다. 그러나 이건 어디까지나 내취향의 문제일 뿐, 적절히 헷갈리지만 않게 쓰면 될 것 같다.


이런 것 또한 매력이라면 매력이 아니다

null과 undefined의 차이, 그리고 역사

## Table of Contents

CSS는 웹 페이지의 성능에 영향을 미치는 중요한 요소중 하나다. 그 이유는

1. 브라우저는 렌더 트리를 만들기 전가지 페이지를 렌더링 할 수 없음
2. 렌더트리는 DOM과 CSSOM을 합쳐서 만드는 것
3. DOM은 HTML과 함께 자바스크립트의 실행을 차단함
4. CSSOM 이란 DOM에 적용해야 하는 모든 CSS 규칙을 의미함
5. 자바스크립트는 `async` 와 `defer`로 차단하지 않도록 만드는 것은 쉽지만
6. CSS를 비동기로 처리하는 것은 매우 어렵
7. 따라서 페이지가 가장 느린 스타일 시트가 렌더링 되는 순간에 페이지가 렌더링 된다는 것을 명심해야 한다.

이러한 점을 염두해두고, DOM과 CSSOM을 최대한 빠르게 구성해야 한다. 일반적으로 DOM은 HTML 응답에 따라서 만들어지므로 비교적 빠르다. 그러나 CSS는 거의 대부분 HTML의 하위리소스이기 때문에 CSSOM을 구성하는 것은 일반적으로 시간이 더 걸린다.

## Critical CSS

렌더링 시작 시간을 줄이는 가장 효과적인 방법은 Critical CSS Pattern을 사용하는 것이다. 이는 렌더링 시작에 필요한 모든 스타일 (일반적으로 스크롤 하지 않아도 맨 처음에 필요한 모든 항목에 필요한 스타일)을 의미한다. 문서의 `<head/>`에 `<style/>` 태그로 인라인처리하고, 나머지 스타일 시트는 비동기적으로 로드 하는 방식이다.

물론 이방식은 효과적이지만 간단하지는 않다. 사이트가 엄청나게 동적일 경우, 스타일을 추출하는 것이 어렵다. 또한 프로세스를 자동화 해야 하며, 안보이는 부분에 대한 정의를 내려야 하고, 예외 처리를 하기가 어렵다. 이는 코드가 커질 수록 어렵다.

## 미디어 쿼리로 나누기

현재 컨텍스트 (medium, 스크린크기, 해상도, 방향 등)에 맞는 css를 가장 최우선 순위로 다운로드 하고, 그 외의 것은 나중에 다운로드 하는 방식이다. 기본적으로 현재 뷰를 렌더링하는데 필요하지 않은 CSS는 브라우저에 의해 지연되어 로딩 된다.

```html
<link rel="stylesheet" href="all.css" />
```

이처럼 되어 있는 것을 미디어 쿼리로 분할 할 수 있다면 네트워크가 분할해서 다르게 취급할 것이다.

```html
<link rel="stylesheet" href="all.css" media="all" />
<link rel="stylesheet" href="small.css" media="(min-width: 20em)" />
<link rel="stylesheet" href="medium.css" media="(min-width: 64em)" />
<link rel="stylesheet" href="large.css" media="(min-width: 90em)" />
<link rel="stylesheet" href="extra-large.css" media="(min-width: 120em)" />
<link rel="stylesheet" href="print.css" media="print" />
```

https://caniuse.com/css-mediaqueries 대부분의 브라우저에서 사용할 수 있다.

물론 여전히 브라우저가 모든 css 파일을 다운로드 하긴 하지만, 현재 컨텍스트를 충족하는데 필요한 파일의 렌더링만 차단한다.

## `@import` 사용하지 않기

`@import`는 아무튼 느리다. 그래서 렌더링 성능에 안좋다. `@import`의 작동 과정을 살펴보자.

1. HTML 다운로드
2. HTML이 CSS를 요청
3. CSS가 또 다른 `@import`에 있는 CSS를 요청
4. 이게 다 끝나면 렌더 트리 생성

```html
<link rel="stylesheet" href="all.css" />
```

안에

```css
@import url(imported.css);
```

와 같은 코드가 있다면, 폭포수 형태로 다운로드를 시작할 것이다.

이는 그냥 단순히

```html
<link rel="stylesheet" href="all.css" />
<link rel="stylesheet" href="imported.css" />
```

로 처리한다면 두개를 동시에 병렬화 하여 다운로드 할 것이다. 그런데 현재 파일에서 `@import` 구문을 지울 수 없는 상황이라 할지라도, 저렇게 별개로 따로 선언해주는 것이 좋다. 그렇다고 해서 브라우저가 중복으로 파일을 다운로드 받지 않을 것이다.

## `<link rel="stylesheet" />`를 비동기 코드 전에 두지 않기

**브라우저는 현재 실행중인 CSS가 있을 경우 `<script/>`를 실행하지 않는다.**

```html
<link rel="stylesheet" href="slow-loading-stylesheet.css" />
<script>
 console.log('I will not run until slow-loading-stylesheet.css is downloaded.')
</script>
```

이는 의도된 다분히 의도적인 동작이다. CSS가 다운로드 중이라면, HTML은 어떤 동기 `<script/>`도 실행하지 않는다. 스크립트 태그 내에서 CSS 가 도착하여 파싱되기 전까지 이에 대한 정보를 찾는 경우, Javascript가 응답하는 내용이 잘못될 수도 있다. 이를 방지하기 위해 브라우저는 CSSOM이 구성될 때 까지 `<script/>`를 실행하지 않는다.

따라서 CSS의 다운로드 시간이 비동기 코드에 영향을 미친다는 것이다. 만약 `<link rel="stylesheet" />` 앞에 비동기 코드를 둔다면, 이는 CSS파일이 다운로드 되어 파싱되기 전까지 실행되지 않을 것이다. 이 말인 즉슨 CSS가 모든 작업을 뒤로 미룬다는 뜻이 된다.

```html
<link rel="stylesheet" href="app.css" />

<script>
 var script = document.createElement('script')
 script.src = 'analytics.js'
 document.getElementsByTagName('head')[0].appendChild(script)
</script>
```

이렇게 순서가 주어지면, CSSOM이 생성되기 전까지 자바스크립트 파일이 다운로드 되지 않는 다는 것을 알 수 있다. 이는 구글 애널리틱스와 같이 제 3자 스크립트를 안전하게 로드 하기 위해 비동기 코드를 제공하는 방식이다. 개발자가 이러한 제3자 코드를 코드 맨 뒷부분에 배치 하고 싶은 것은 일반적이다. 그러나 이는 실수가 될 수 있다.

따라서 `<script/>` 내에 css에 의존하는 코드가 없다면, 이를 상단에 배치하는 것이 좋다.

```html
<script>
 var script = document.createElement('script')
 script.src = 'analytics.js'
 document.getElementsByTagName('head')[0].appendChild(script)
</script>

<link rel="stylesheet" href="app.css" />
```

따라서

- CSSOM에 의존하지 않는 자바스크립트는 CSS이전에
- CSSOM에 의존하는 자바스크립트는 이후에

둔다.

파일이 서로 의존적이지 않은 경우, 차단 스크립트를 차단 스타일 위해 배치 해야 한다. 자바스크립트가 실제로 의존하지 않는 CSS때문에 자바스크립트 실행을 지연시킬 필요는 없다. 만약 자바스크립트 중 일부는 CSS에 의존하고, 일부는 그렇지 않는 경우에는 두개로 분할하는 것이 가장 빠른 방식이다.

```html

<script src="i-need-to-block-dom-but-DONT-need-to-query-cssom.js"></script>

<link rel="stylesheet" href="app.css" />


<script src="i-need-to-block-dom-but-DO-need-to-query-cssom.js"></script>
```

이러한 로딩 순서를 이용하면, 다운로드와 실행이 모두 최적의 순서로 발생된다.

## `<link rel="stylesheet" />`는 `<body/>`에 위치 시키기

기존 HTTP 1.1 에서는 모든 스타일을 하의 기본 번들로 연결하는 것이 일반적이다.

```html
<!DOCTYPE html>
<html>
 <head>
 <link rel="stylesheet" href="app.css" />
 </head>
 <body>
 <header class="site-header">
 <nav class="site-nav">...</nav>
 </header>

 <main class="content">
 <section class="content-primary">
 <h1>...</h1>

 <div class="date-picker">...</div>
 </section>

 <aside class="content-secondary">
 <div class="ads">...</div>
 </aside>
 </main>

 <footer class="site-footer"></footer>
 </body>
</html>
```

그러나 위 코드는 아래와 같은 비효율성이 있다.

1. 실제 페이지에서 필요한 css는 일부분 이지만, 필요한 것보다 더 많은 `app.css`를 다운로드 하고 있다.
2. 캐시전략이 비효율적이다. 예를 들어서 특정 섹션의 배경색만 변경하기 위해서는, `app.css` 전체의 캐시를 버려야 한다.
3. 현재 페이지에서 `app.css`의 어느정도를 필요로 하든지간에, 전체 내용이 도착하기 전까지 렌더링이 블로킹 된다.

이제 http/2 를 사용하면 1, 2번 문제를 해결할 수 있다.

```html
<!DOCTYPE html>
<html>
 <head>
 <link rel="stylesheet" href="core.css" />
 <link rel="stylesheet" href="site-header.css" />
 <link rel="stylesheet" href="site-nav.css" />
 <link rel="stylesheet" href="content.css" />
 <link rel="stylesheet" href="content-primary.css" />
 <link rel="stylesheet" href="date-picker.css" />
 <link rel="stylesheet" href="content-secondary.css" />
 <link rel="stylesheet" href="ads.css" />
 <link rel="stylesheet" href="site-footer.css" />
 </head>
 <body>
 <header class="site-header">
 <nav class="site-nav">...</nav>
 </header>

 <main class="content">
 <section class="content-primary">
 <h1>...</h1>

 <div class="date-picker">...</div>
 </section>

 <aside class="content-secondary">
 <div class="ads">...</div>
 </aside>
 </main>

 <footer class="site-footer"></footer>
 </body>
</html>
```

이제 모든 것을 다 다운로드 하는 대신에, 페이지에 필요한 css만 다운로드 할 수 있다. 그러면 주요 렌더링 과정에서 차단 CSS의 크기가 줄어든다. 또한 캐시 전략을 보다 신중하게 선택할 수 있다. 캐시가 필요한 파일만 날리고, 나머지는 유지한다.

하지만 여전히 해결하지 못한 점은 이 모든 것이 렌더링을 가로막는 다는 것이다. 여전히 우리 사이트는 가장 느린 스타일시트의 속도에 좌우되고 있다. 그러나 이제 크롬 69버전 이후, 파이어폭스, IE/Edge 등에서 아래와 같은 코드가 가능해진다.

```html
<!DOCTYPE html>
<html>
 <head>
 <link rel="stylesheet" href="core.css" />
 </head>
 <body>
 <link rel="stylesheet" href="site-header.css" />
 <header class="site-header">
 <link rel="stylesheet" href="site-nav.css" />
 <nav class="site-nav">...</nav>
 </header>

 <link rel="stylesheet" href="content.css" />
 <main class="content">
 <link rel="stylesheet" href="content-primary.css" />
 <section class="content-primary">
 <h1>...</h1>

 <link rel="stylesheet" href="date-picker.css" />
 <div class="date-picker">...</div>
 </section>

 <link rel="stylesheet" href="content-secondary.css" />
 <aside class="content-secondary">
 <link rel="stylesheet" href="ads.css" />
 <div class="ads">...</div>
 </aside>
 </main>

 <link rel="stylesheet" href="site-footer.css" />
 <footer class="site-footer"></footer>
 </body>
</html>
```

이를 활용하면 페이지를 점진적으로 렌더링할 수 있다. 자세한 내용은 [여기](https://jakearchibald.com/2016/link-in-body/)를 참조.

## 요약

- 렌더링 시작에 필요하지 않은 CSS 를 지연시킨다.
 - Critical CSS로 분리하거나
 - CSS를 미디어 쿼리로 분리한다.
- `@import`의 사용을 줄인다.
- 동기 CSS와 자바스크립트의 순서에 주의한다.
 - CSS 이후에 있는 자바스크립트는 CSSOM이 구성되기 전까지 실행되지 않는다.
- DOM이 필요로 하는 CSS만 불러온다.
 - 이는 점진적 렌더링을 가능하게 하고, 초기 렌더링을 블록하지 않는다.

내 일이 아니라고 생각하면 관심이 안가더라고

CSS와 웹페이지 성능과의 관계

```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를 새로고침하기

<pre class="language-javascript"><code class="language-javascript">import { useRouter } from 'next/router'

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

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

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

export async function getServerSideProps(context) {
 const currentDateTime = new Date().getTime()
 return {
 props: { time: currentDateTime },
 }
}
</code></pre>
<code>getServerSideProps</code> 의 동작을 상상해본다면 아래와 같을 것이다.
<a href="https://yceffort.kr/2020/03/nextjs-02-data-fetching#4-getserversideprops">https://yceffort.kr/2020/03/nextjs-02-data-fetching#4-getserversideprops</a>
<ol>
<li><code>getServerSideProps</code>가 있는 사이트 방문</li>
<li>nextjs가 <code>getServerSideProps</code>를 호출하여 HTML 파일 생성</li>
<li>HTML 파일을 사용자가 내려받고, 리액트가 클라이언트에서 처리 (rehydration)</li>
</ol>
그러나 한가지 nextjs에서 <code>getServerSideProps</code>를 클라이언트 사이드에서 처리하는 경우가 있다. 아래와 같은 시나리오를 상상해보자.
<ol>
<li>유저가 이미 사이트에 있고, next.js의 <code>Link</code>를 클릭하여 서버사이드 렌더링 된 페이지에 방문</li>
<li>nextjs가 <code>getServerSideProps</code>를 서버에 호출하는데, 이전 처럼 HTML파일을 내려주는 대신에 단순히 데이터를 json으로 클라이언트에 전송</li>
<li>리액트가 해당 json을 initial props로 브라우저에서 새 페이지를 렌더링</li>
</ol>
이 와 같은 과정이 위 예제 코드에서 이루어지고 있다.
최초 페이지 진입시에는 이렇게 완성된 html을 내려준다.
<pre class="language-javascript"><code class="language-javascript">&#x3C;div id="__next">
 &#x3C;div>Server Side Props Request Time:
 &#x3C;!-- -->1611794984243&#x3C;/div>&#x3C;button>Refresh Server Side&#x3C;/button>
&#x3C;/div>
</code></pre>
위 코드로 새로고침하면, 아래와 같은 json데이터만 받는다.
<pre class="language-json"><code class="language-json">{ "pageProps": { "time": 1611795117182 }, "__N_SSP": true }
</code></pre>
<blockquote>
<code>__N_SSP</code>는 server side props이라는 뜻이다. <a href="https://github.com/vercel/next.js/blob/e819e00d0c0b2d9cd851c2c7215af1211c561932/packages/next/next-server/lib/constants.ts#L39">https://github.com/vercel/next.js/blob/e819e00d0c0b2d9cd851c2c7215af1211c561932/packages/next/next-server/lib/constants.ts#L39</a>
</blockquote>
nextjs의 좋은 점 중 하나는 <code>getServerSideProps</code>를 일종의 api 호출처럼 사용할 수도 있다는 것이다. 위에서 사용했던 <code>router.asPath</code>는 현재 페이지의 위치를 반환한다. 여기서는 <code>/</code> 일 것이다. 이 페이지로 리다이렉트 시켜달라는 뜻은, 즉 page에 해당 데이터를 json으로 내려달라는 말과 동일하다.그리고 <code>push</code> 대신 <code>replace</code>를 사용하여 히스토리 스택에 쌓이는 것도 방지하였다.
만약 이 경우에 로딩 스피너를 걸어둬야 한다면 어떻게 할까?
<pre class="language-javascript"><code class="language-javascript">const [loading, isLoading] = useState(false)

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

useEffect(() => {
 isLoading(false)
}, [time])
</code></pre>
<code>useEffect</code> 훅에 서버사이드 props를 넣어주었다.
그리고 이렇게 넘겨 받은 서버사이드 props를 고치고 싶다면, 아래와 같이 처리해주면 된다.
<pre class="language-javascript"><code class="language-javascript">export default function IndexPage({ time }) {
 const [currentTime, setCurrentTime] = useState(time)
 //...
}
</code></pre>

## github workflow로 cron 사용

github action이 생긴 이후로 workflow를 활용해서 cron job을 처리하고 있었다.

```yaml
name: cron

on:
  schedule:
    - cron: '0 5 * * 1-5'

jobs:
  cron:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2

      - uses: actions/setup-node@v1
        with:
          node-version: '12'
          check-latest: true

      - name: CI
        run: |
          npm ci
      - name: Run Cron
        run: |
          npm run job
```

그러나 언제선가 부터 작업 시작 시간이 굉장히 안맞기 시작했다. 공짜로 사용하는 것이다 보니, 그러려니 하고 넘어갔었는데 예상 시간 보다 40~50분 넘어가서 작업이 실행되었다. 심지어 09시 (utc 기준 00시)에 실행되는 작업은 2시간 뒤에 실행되곤 했다.

![workflow-cron](./images/workflow-cron.png)

> 00시에 걸어둔 작업이었는데 실제로는 02시 30분에 실행되었다. github도 이런 문제가 있을수 있다는 걸 아는건지(?) 실제 실행시간이 표시되고 있지는 않았다.

그러나 이런 문제는 나만 겪는 것은 아닌듯 했다.

- https://stackoverflow.com/questions/65132563/why-is-github-actions-workflow-scheduled-with-cron-not-triggering-at-the-right-t
- https://github.community/t/github-actions-on-schedule-executed-in-delay/152972

github이 뭔가 조치를 취해주기를 기다렸지만(?) 포스팅 작성 시간 현재 (1월 24일) 까지 문제는 계속되었다. 그리고 별개로 로그를 살펴보니 이러한 증상은 2021년 들어서 더 심해진 것 같았다.

그래서 firebase의 cloud function으로 갈아탔다. 단순히 http요청으로 함수를 실행하게 도와주는 것 뿐만 아니라 cron으로 정해진 작업을 실행할 수도 있었다.

```javascript
exports.cronJob = functions.pubsub
  .schedule('0 14 * * 1-5')
  .timeZone('Asia/Seoul')
  .onRun((_) => {
    job()
  })
```

github과 다르게 시간대도 설정할 수 있어서 좋았다 (github에서는 몇 번 이점을 까먹고 새벽에 스케쥴이 돌아가기도 했다.) 한가지 배운 것은, `firebase init`으로 function을 초기화 할 경우 기본 디렉토리가 `./functions`로 설정되는데, 이를 다음과 같이 설정하면 root로 바꿀 수 있다.

**firebase.json**

```json
{
  "functions": {
    "source": ".",
    "runtime": "nodejs12"
  }
}
```

![functions](./images/functions-cron.png)

당연히 작업도 원하는 시간대에 정확하게 실행되었다.

언제부터인가 AWS를 안쓰고, GCP와 firebase를 위주로 계속 쓰고 있는데 나쁘지 않은 것 같다. 적어도 인터페이스는 GCP와 firebase가 더 나은 것 같다. 내가 구글빠라서 그런걸 수도 있고.

yceffort

no return, await, return, await return 의 차이

null과 undefined의 차이, 그리고 역사

CSS와 웹페이지 성능과의 관계

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

Github action cron이 제시간에 실행되지 않는 문제