흔히 쓰고 있는 `useState`를 다시 살펴보자.

```javascript
const [count, setCount] = useState(
  Number.parseInt(window.localStorage.getItem(cacheKey)),
)
```

```javascript
const [count, setCount] = useState(() =>
  Number.parseInt(window.localStorage.getItem(cacheKey)),
)
```

두 코드의 차이는, useState에 직접 변수를 넣는가와 즉시실행 화살표 함수를 넣느냐의 차이다.

`useState`에 직접적인 값 대신에 함수를 넘기는 것을 [게으른 초기화(lazy)](https://reactjs.org/docs/hooks-reference.html#lazy-initial-state)라고 한다. react 공식 문서에서는, 이러한 게으른 초기화를 초기 값이 복잡한 연산을 포함할 때 사용하라고 되어 있다. 게으른 초기화 함수는 **오직 state가 처음 만들어 질 때만 실행된다.** 이 후에 다시 리렌더링이 된다면, 이 함수의 실행은 무시된다.

다시 말해, `useState`는 그 함수가 처음 렌더링 될 때 작동하며, 이는 `count` state의 초기값을 만든다. `setCount`가 실행되면, 전체 함수가 다시 실행되며, `count`의 값을 업데이트 한다. 이는 `count`의 값이 변경될 때 마다 리 렌더링을 발생시킨다. 다시말해, 이 초기 값은 다시 쓰일 일이 없게 된다.

따라서, 리 렌더링이 발생할 때 마다 `localStorage`의 값을 읽지만, 오직 우리는 딱 최초 렌더링 시에만 해당 값이 필요하므로, 이는 필요없는 계산을 계속해서 하게 되는 것이다. 두 번째 예제에서는 게으른 초기화를 하기 때문에 불필요한 계산을 막게된다.

말이 조금 어렵다면, 아래 예제를 살펴보자.

예제1

```javascript
const Counter = () => {
  const initialValue = Number.parseInt(window.localStorage.getItem(cacheKey))
  const [count, setCount] = useState(initialValue)
  // ...
```

이제 매번 리렌더링 하여 `Counter`함수가 호출 될 때 마다, `localStorage`의 값을 계속해서 가져오는 것을 볼 수 있다.

예제2

```javascript
// Example 2
const Counter = () => {
  const [count, setCount] = useState(function() {
    return Number.parseInt(window.localStorage.getItem(cacheKey)),
  })

  // ...
}
```

이 더분째 예제에서는 이전 예제와는 다르게 딱 한번 초기화 할 때 한 번만 우리가 원하는 대로 호출하는 것을 볼 수 있다.

그렇다면 모든 값들을 게으른 초기화로 처리하면 어떨까?

```javascript
// 원시 값 리턴
const Counter = () => {
  const [count, setCount] = useState(() => 0)

  // ...
}
```

```javascript
// prop 또는 이미 존재하는 변수의 값을 리턴
const Counter = ({ initialCount }) => {
  const [count, setCount] = useState(() => initialCount)

  // ...
}
```

각각 초기 값이 간단한 값이거나 이미 계산된 값인 경우이다. 비록 함수가 게으른 초기화로 인해 한번만 호출되지만, 여전히 함수를 만드는 비용이 존재한다. 그리고 함수를 만드는 비용이 보통 변수를 생성하거나 단순히 값을 넘기는 비용보다는 크다. 이는 과한 최적화의 예다.

그렇다면 언제 게으른 최적화를 써야할까? 이는 상황에 따라 다르다. 문서에서는 '비싼 비용의 계산' 이 필요할 때 쓰라고 되어있다. 앞선 예와 같이 `localStorage` 의 접근, ` map`, `filter`,`find` 등의 배열을 조작하는 것들이 그 예가 될 수 있다. 일반적으로, 함수를 통해서 값을 구해야한다면, 이는 비싼 비용이 드는 계산이며, 게으른 초기화를 하는게 좋을 수도 있다. `new Date()`도 마찬가지로.


리액트 최적화의 길은 멀고도 험하다

리액트의 useState와 lazy initialization

흔히 쓰고 있는 <code>useState</code>를 다시 살펴보자.
<pre class="language-javascript"><code class="language-javascript">const [count, setCount] = useState(
 Number.parseInt(window.localStorage.getItem(cacheKey)),
)
</code></pre>
<pre class="language-javascript"><code class="language-javascript">const [count, setCount] = useState(() =>
 Number.parseInt(window.localStorage.getItem(cacheKey)),
)
</code></pre>
두 코드의 차이는, useState에 직접 변수를 넣는가와 즉시실행 화살표 함수를 넣느냐의 차이다.
<code>useState</code>에 직접적인 값 대신에 함수를 넘기는 것을 <a href="https://reactjs.org/docs/hooks-reference.html#lazy-initial-state">게으른 초기화(lazy)</a>라고 한다. react 공식 문서에서는, 이러한 게으른 초기화를 초기 값이 복잡한 연산을 포함할 때 사용하라고 되어 있다. 게으른 초기화 함수는 오직 state가 처음 만들어 질 때만 실행된다. 이 후에 다시 리렌더링이 된다면, 이 함수의 실행은 무시된다.
다시 말해, <code>useState</code>는 그 함수가 처음 렌더링 될 때 작동하며, 이는 <code>count</code> state의 초기값을 만든다. <code>setCount</code>가 실행되면, 전체 함수가 다시 실행되며, <code>count</code>의 값을 업데이트 한다. 이는 <code>count</code>의 값이 변경될 때 마다 리 렌더링을 발생시킨다. 다시말해, 이 초기 값은 다시 쓰일 일이 없게 된다.
따라서, 리 렌더링이 발생할 때 마다 <code>localStorage</code>의 값을 읽지만, 오직 우리는 딱 최초 렌더링 시에만 해당 값이 필요하므로, 이는 필요없는 계산을 계속해서 하게 되는 것이다. 두 번째 예제에서는 게으른 초기화를 하기 때문에 불필요한 계산을 막게된다.
말이 조금 어렵다면, 아래 예제를 살펴보자.
예제1
<pre class="language-javascript"><code class="language-javascript">const Counter = () => {
 const initialValue = Number.parseInt(window.localStorage.getItem(cacheKey))
 const [count, setCount] = useState(initialValue)
 // ...
</code></pre>
이제 매번 리렌더링 하여 <code>Counter</code>함수가 호출 될 때 마다, <code>localStorage</code>의 값을 계속해서 가져오는 것을 볼 수 있다.
예제2
<pre class="language-javascript"><code class="language-javascript">// Example 2
const Counter = () => {
 const [count, setCount] = useState(function() {
 return Number.parseInt(window.localStorage.getItem(cacheKey)),
 })

 // ...
}
</code></pre>
이 더분째 예제에서는 이전 예제와는 다르게 딱 한번 초기화 할 때 한 번만 우리가 원하는 대로 호출하는 것을 볼 수 있다.
그렇다면 모든 값들을 게으른 초기화로 처리하면 어떨까?
<pre class="language-javascript"><code class="language-javascript">// 원시 값 리턴
const Counter = () => {
 const [count, setCount] = useState(() => 0)

 // ...
}
</code></pre>
<pre class="language-javascript"><code class="language-javascript">// prop 또는 이미 존재하는 변수의 값을 리턴
const Counter = ({ initialCount }) => {
 const [count, setCount] = useState(() => initialCount)

 // ...
}
</code></pre>
각각 초기 값이 간단한 값이거나 이미 계산된 값인 경우이다. 비록 함수가 게으른 초기화로 인해 한번만 호출되지만, 여전히 함수를 만드는 비용이 존재한다. 그리고 함수를 만드는 비용이 보통 변수를 생성하거나 단순히 값을 넘기는 비용보다는 크다. 이는 과한 최적화의 예다.
그렇다면 언제 게으른 최적화를 써야할까? 이는 상황에 따라 다르다. 문서에서는 '비싼 비용의 계산' 이 필요할 때 쓰라고 되어있다. 앞선 예와 같이 <code>localStorage</code> 의 접근, <code> map</code>, <code>filter</code>,<code>find</code> 등의 배열을 조작하는 것들이 그 예가 될 수 있다. 일반적으로, 함수를 통해서 값을 구해야한다면, 이는 비싼 비용이 드는 계산이며, 게으른 초기화를 하는게 좋을 수도 있다. <code>new Date()</code>도 마찬가지로.

## 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


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

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

[원문](https://blog.bitsrc.io/using-service-workers-with-react-27a4c5e2d1a9)

## 개요

```typescript
// This optional code is used to register a service worker.
// register() is not called by default.

// This lets the app load faster on subsequent visits in production, and gives
// it offline capabilities. However, it also means that developers (and users)
// will only see deployed updates on subsequent visits to a page, after all the
// existing tabs open on the page have been closed, since previously cached
// resources are updated in the background.

// To learn more about the benefits of this model and instructions on how to
// opt-in, read https://bit.ly/CRA-PWA

const isLocalhost = Boolean(
  window.location.hostname === 'localhost' ||
    // [::1] is the IPv6 localhost address.
    window.location.hostname === '[::1]' ||
    // 127.0.0.0/8 are considered localhost for IPv4.
    window.location.hostname.match(
      /^127(?:\.(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)){3}$/,
    ),
)

type Config = {
  onSuccess?: (registration: ServiceWorkerRegistration) => void
  onUpdate?: (registration: ServiceWorkerRegistration) => void
}

export function register(config?: Config) {
  if (process.env.NODE_ENV === 'production' && 'serviceWorker' in navigator) {
    // The URL constructor is available in all browsers that support SW.
    const publicUrl = new URL(process.env.PUBLIC_URL, window.location.href)
    if (publicUrl.origin !== window.location.origin) {
      // Our service worker won't work if PUBLIC_URL is on a different origin
      // from what our page is served on. This might happen if a CDN is used to
      // serve assets; see https://github.com/facebook/create-react-app/issues/2374
      return
    }

    window.addEventListener('load', () => {
      const swUrl = `${process.env.PUBLIC_URL}/service-worker.js`

      if (isLocalhost) {
        // This is running on localhost. Let's check if a service worker still exists or not.
        checkValidServiceWorker(swUrl, config)

        // Add some additional logging to localhost, pointing developers to the
        // service worker/PWA documentation.
        navigator.serviceWorker.ready.then(() => {
          console.log(
            'This web app is being served cache-first by a service ' +
              'worker. To learn more, visit https://bit.ly/CRA-PWA',
          )
        })
      } else {
        // Is not localhost. Just register service worker
        registerValidSW(swUrl, config)
      }
    })
  }
}

function registerValidSW(swUrl: string, config?: Config) {
  navigator.serviceWorker
    .register(swUrl)
    .then((registration) => {
      registration.onupdatefound = () => {
        const installingWorker = registration.installing
        if (installingWorker == null) {
          return
        }
        installingWorker.onstatechange = () => {
          if (installingWorker.state === 'installed') {
            if (navigator.serviceWorker.controller) {
              // At this point, the updated precached content has been fetched,
              // but the previous service worker will still serve the older
              // content until all client tabs are closed.
              console.log(
                'New content is available and will be used when all ' +
                  'tabs for this page are closed. See https://bit.ly/CRA-PWA.',
              )

              // Execute callback
              if (config && config.onUpdate) {
                config.onUpdate(registration)
              }
            } else {
              // At this point, everything has been precached.
              // It's the perfect time to display a
              // "Content is cached for offline use." message.
              console.log('Content is cached for offline use.')

              // Execute callback
              if (config && config.onSuccess) {
                config.onSuccess(registration)
              }
            }
          }
        }
      }
    })
    .catch((error) => {
      console.error('Error during service worker registration:', error)
    })
}

function checkValidServiceWorker(swUrl: string, config?: Config) {
  // Check if the service worker can be found. If it can't reload the page.
  fetch(swUrl, {
    headers: { 'Service-Worker': 'script' },
  })
    .then((response) => {
      // Ensure service worker exists, and that we really are getting a JS file.
      const contentType = response.headers.get('content-type')
      if (
        response.status === 404 ||
        (contentType != null && contentType.indexOf('javascript') === -1)
      ) {
        // No service worker found. Probably a different app. Reload the page.
        navigator.serviceWorker.ready.then((registration) => {
          registration.unregister().then(() => {
            window.location.reload()
          })
        })
      } else {
        // Service worker found. Proceed as normal.
        registerValidSW(swUrl, config)
      }
    })
    .catch(() => {
      console.log(
        'No internet connection found. App is running in offline mode.',
      )
    })
}

export function unregister() {
  if ('serviceWorker' in navigator) {
    navigator.serviceWorker.ready
      .then((registration) => {
        registration.unregister()
      })
      .catch((error) => {
        console.error(error.message)
      })
  }
}
```

서비스 워커란 브라우저에서 실행되는 스크립트 파일이다. 이 파일에서 직접적으로 DOM을 다뤄서는 안된다. 여기에는 별도 구성 없이 사용하라 수 있는 네트워크 관련 기능들이 존재한다. 서비스 워커는 오프라인 경험을 제공하기 위해서 존재한다. 여기에는 푸쉬 알림, 백그라운드 동기화 등이 있다.

리액트에서 서비스 워커를 적절하게 구성할 수 있다면, 네트워크 요청을 가로채서 관리함으로써 다양한 작업등을 할 수 있다. `create-react-app`을 사용하면 서비스 워커는 `SWPrecacheWebpackPlugin`를 통해 자동으로 설치된다. 서비스 워커는 네트워크가 새로운 요청을 처리하기 위한 병목현상이 되지않도록 한다.

## 서비스워커: 유즈케이스

이는 개발자가 심리스한 연결성을 보여주기 위해서는, 가장 먼저 해결해야 할 문제가 바로 네트워크 연결 중단이다. 최근에는 좋은 사용자 경험을 제공하는 오프라인 어플리케이션의 개념이 인기를 끓고 있다. 서비스워커는 웹 개발자에게 다음과 같은 이점을 제공한다.

- 웹사이트의 성능향상. 웹사이트의 로딩 속도를 빠르게 하기 위해 사이트 일부를 캐싱할 수 있다.
- 오프라인 화면을 제공하여, 연결이 끊기더라도 정상적으로 애플리케이션을 계속 사용하도록 할 수 있다.
- 기존 웹 기술로는 불가능한 알림과 푸쉬 API를 활용할 수 있다.
- 백그라운드 동기화를 수행할 수 있게 해준다. 사용자에게 원활한 환경을 제공하기 위해, 네트워크 연결이 다시 복원될 때 까지 특정 작업을 연기할 수 있다.

## 서비스워커의 라이브사이클

서비스워커의 라이프 사이클은 웹 애플리케이션과 관련이 없다. 자바스크립트를 활용하여 서비스 워커를 등록하면 설치가 된다. 이는 브라우저가 백그라운드에서 설치를 시작하도록 지시한다. 또한 필요한 에셋을 이 기간 동안 캐시할 수도 있다. 설치가 끝나면 활성화 프로세스가 시작된다. 활성화되면, 서비스 워커는 해당 범위의 모든 페이지와 연결되며, 이벤트에 의해 호출되지 않는 한 프로세스가 종료된다.

서비스워커의 라이프 사이클은 일반적으로 개발자가 코딩해야 한다. 리액트의 서비스 워커의 경우, 리액트 자체로 라이프 사이클을 관리하여 개발자가 조금더 서비스 워커를 다루기 쉽게 했다.

![lifecycle of service worker](https://miro.medium.com/max/1400/1*HUnu3nbBSq2lDoOSllBkiA.png)

## 리액트 서비스 워커의 고려사항

- 서비스 워커는 브라우저에 의해 자체 글로벌 스크립트 컨텍스트에서 실행된다. 이는 즉, 페이지의 DOM 요소에 접근해서는 안된다는 것을 의미한다. 따라서, 페이지와의 통신이 필요하다면 간접적인 방식으로 처리해야 한다. 보통 [postMessage](https://developer.mozilla.org/en-US/docs/Web/API/Client/postMessage)를 사용한다.
- 서비스 워커는 HTTPS 프로토콜에서만 실행된다. `localhost`는 제외.
- 서비스 워커는 특정 페이지에 종속되어 있지 않으므로, 재사용이 가능하다.
- 서비스워커는 이벤트 중심으로 이루어져 있다 (event driven). 이는 서비스 워커가 종료되면 어떠한 정보도 얻을 수 없다는 것을 의미한다. 이전 상태의 정보에 접근하기 위해서는, [IndexedDB API](https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API)를 사용해야 한다.

## 리액트 서비스워커 활성화

`create-react-app`으로 리액트 어플리케이션을 만들면, 아래와 같은 구조를 띄고 있을 것이다.

````
├── README.md
├── node_modules
├── package.json
├── .gitignore
├── build
├── public
│   ├── favicon.ico
│   ├── index.html
│   └── manifest.json
└── src
    ├── App.css
    ├── App.js
    ├── App.test.js
    ├── index.css
    ├── index.js
    ├── logo.svg
    └── serviceWorker.js
    ```
````

`serviceWorker.js`가 `src` 밑에 존재한다. 이 파일은 디폴트로 생성된다. 이 단계에서는 서비스워커는 등록되지 않았으므로, 서비스 워커를 사용하기 위해서는 이를 등록해야 한다.

`src/index.js`의

```javascript
serviceWorker.unregister()
```

를

```javascript
serviceWorker.register()
```

로 바꾼다. 이렇게 딱 한줄만 바꾸면, 리액트 애플리케이션의 서비스 워커를 사용할 준비가 된다.

일반적인 웹 애플리케이션에서는, 서비스워커의 전체 라이프 사이클을 코딩해야 한다. 그러나 리액트는 기본값으로 이러한 개발을 할 준비를 해두었다. `src/serviceWorker.js` 파일을 확인해보면, 서비스워커와 관련된 코드가 준비되어 있는 것을 볼 수 있다.

## 개발환경에서 리액트 서비스 워커 작업하기

`serviceWorker.js`의 `register()` 함수를 보면, `process.env.NODE_ENV === 'production'` 때문에 프로덕션 모드에서만 실행된다는 것을 알 수 있다. 이를 수정할 방법이 몇가지 있다.

- 이조건을 삭제하여 development에서도 실행하는 방법. 그러나 잠재적인 이슈가 있을 수 있다.
- 리액트 애플리케이션을 프로덕션 버전으로 만들어서, 서빙하는 방법. 아래와 같은 방법으로 사용하면 된다.

```
$ yarn global add serve
$ yarn build
$ serve -s build
```

## 서비스 워커를 커스터마이징 하는법

CRA에서 `service-worker.js`는 기본적으로 모든 기본 에셋을 캐싱한다. 서비스 워커에 기능을 추가하기 위해서는, `custom-service-worker.js`를 만들고, `register()`를 수정해서 커스터마이징 하는 방법이 있다.

34번째 라인에 가서, 아래와 같이 수정하면 된다.

```javascript
window.addEventListener('load', () => {
  const swUrl = `${process.env.PUBLIC_URL}/custom-service-worker.js`;
  //
}
```

`package.json`을 아래와 같이 수정한다.

```json
"scripts": {
   "start": "react-app-rewired start",
   "build": "react-app-rewired build",
   "test": "react-app-rewired test",
   "eject": "react-app-rewired eject"
},
```

그리고, Google의 workbox plugin을 추가한다. [Google's Workbox plugin](https://developers.google.com/web/tools/workbox/guides/codelabs/webpack)

```
npm install --save-dev workbox-build
```

다음에, CRA에 커스텀 서비스 워커를 삽입하도록 지시하는 설정파일을 생성한다.

```javascript
const WorkboxWebpackPlugin = require('workbox-webpack-plugin')
module.exports = function override(config, env) {
  config.plugins = config.plugins.map((plugin) => {
    if (plugin.constructor.name === 'GenerateSW') {
      return new WorkboxWebpackPlugin.InjectManifest({
        swSrc: './src/custom-service-worker.js',
        swDest: 'service-worker.js',
      })
    }
    ㄴ
    return plugin
  })
  return config
}
```

다음 아래와 같이 특정 디렉토리를 캐시하는 커스텀 서비스 워커를 만들 수 있다.

```javascript
workbox.routing.registerRoute(
  new RegExp('/path/to/cache/directory/'),
  workbox.strategies.NetworkFirst(),
)
workbox.precaching.precacheAndRoute(self.__precacheManifest || [])
```

변경사항을 적용하기 위해서는 애플리케이션을 다시 빌드하면 된다.

## 더 공부해보기

https://developers.google.com/web/fundamentals/primers/service-workers/

> 서비스 워커는 브라우저가 백그라운드에서 실행하는 스크립트로, 웹페이지와는 별개로 작동하며, 웹페이지 또는 사용자 상호작용이 필요하지 않은 기능에 대해 문호를 개방합니다. 현재 푸시 알림 및 백그라운드 동기화와 같은 기능은 이미 제공되고 있습니다. 향후 서비스 워커는 주기적 동기화 또는 지오펜싱과 같은 다른 기능을 지원할 수 있습니다. 이 가이드에서는 프로그래밍 방식의 응답 캐시 관리를 비롯하여 네트워크 요청을 가로채고 처리하는 핵심 기능에 대해 설명합니다.

https://github.com/facebook/create-react-app/pull/1728

https://developers.google.com/web/tools/workbox/modules/workbox-webpack-plugin#generatesw_plugin


가끔 봤지만 전혀 궁금해 하지 않았던 그 것

Create React App의 serviceWorker는 무엇일까

먼저 [styled components](https://styled-components.com/)를 쓰는 방법을 간단하게 살펴보자.

## Table of Contents

## Create

```javascript
import styled from 'styled-components'

const Button = styled.button`
 display: inline-block;
 padding: 6px 12px;
 font-size: 16px;
 font-family: Arial, sans-serif;
 line-height: 1.5;
 color: white;
 background-color: #6c757d;
 border: none;
 border-radius: 4px;
 :not(:disabled) {
 cursor: pointer;
 }
 :hover {
 background-color: #5a6268;
 }
`
```

`styled` 컴포넌트를 임포트하고, `button`과 함께 사용하여 백틱 두개 사이에서 스타일을 적용하였다. `button` 대신에 `h1` `p` 등의 HTML elements를 사용할 수 있으며, 스타일에는 유효한 모든 CSS 문법이 가능하다.

## Usage

이렇게 만든 styled component는 리액트 컴포넌트와 마찬가지로 JSX 문법을 이용하여 사용할 수 있다.

```javascript
const App = () => {
 return (
 <Button onClick={() => alert('clicked!')} type="button">
 Button
 </Button>
 )
}
```

## Internal

이렇게 해서 만들어진 `button`을 한번 살펴보자.

<iframe src="https://codesandbox.io/embed/sweet-forest-1eix4?fontsize=14&hidenavigation=1&theme=dark"
 style="width:100%; height:500px; border:0; border-radius: 4px; overflow:hidden;"
 title="sweet-forest-1eix4"
 allow="accelerometer; ambient-light-sensor; camera; encrypted-media; geolocation; gyroscope; hid; microphone; midi; payment; usb; vr; xr-spatial-tracking"
 sandbox="allow-forms allow-modals allow-popups allow-presentation allow-same-origin allow-scripts"
 ></iframe>

```html
<style data-styled="active" data-styled-version="5.2.0">
 .eWMwHd {
 display: inline-block;
 padding: 6px 12px;
 font-size: 16px;
 font-family: Arial, sans-serif;
 line-height: 1.5;
 color: white;
 background-color: #6c757d;
 border: none;
 border-radius: 4px;
 }
 .eWMwHd:not(:disabled) {
 cursor: pointer;
 }
 .eWMwHd:hover {
 background-color: #5a6268;
 }
</style>
<button type="button" class="sc-dlnjPT eWMwHd">Button</button>
```

그렇다면 내부에서는 어떻게 작할까?

1. styled components는 정의된 스타일을 기반으로 유니크한 클래스명을 만든다.
2. HTML `<head>` 영역에 `<style>` 태그를 넣고, 여기에 1번에서 만든 유니크 클래스명과 연결되는 스타일을 넣어둔다.
3. 1번과 2번을 바탕으로 렌더링한다.

## Extend

기존에 존재하는 styled component를 바탕으로 디자인을 확장할 수 있다. 대신 `.button`이 아닌 `.(확장할 컴포넌트명)`을 사용한다.

```javascript
const PrimaryButton = styled(Button)`
 background-color: #007bff;
 :hover {
 background-color: #0069d9;
 }
`
const App = () => {
 return (
 <PrimaryButton onClick={() => alert('clicked!')} type="button">
 Primary
 </Button>
 )
}
```

이와 유사하게, 리액트 컴포넌트를 확장할 수 도 있다.

```javascript
const ButtonComponent = ({ className }) => {
 return (
 <Button
 className={className}
 onClick={() => alert('clicked!')}
 type="button"
 >
 Primary
 </Button>
 )
}
const PrimaryButton = styled(ButtonComponent)`
 background-color: #007bff;
 :hover {
 background-color: #0069d9;
 }
`
```

한가지 다른 점은 `className` prop이 추가되었다는 것이다. 이 `className`은 앞서 언급했던 class와 동일하게 동작하며, 반드시 prop으로 넘겨주어야 한다. 그렇지 않으면 작동하지 않는다.

## Compose

기존에 존재하는 스타일과 합성도 가능하다.

```javascript
import styled, { css } from 'styled-components'
const blackFont = css`
 color: black;
`

const WarningButton = styled(Button)`
 background-color: #ffc107;
 :hover {
 background-color: #e0a800;
 }
 ${blackFont}
`

const App = () => {
 return (
 <WarningButton onClick={() => alert('clicked!')} type="button">
 Warning
 </WarningButton>
 )
}
```

## Prop Style

prop을 받아서 스타일을 선택적으로 적용할 수도 있다.

```javascript
import styled, { css } from 'styled-components'
const SuccessButton = styled(Button)`
 ${(props) =>
 props.$success
 ? css`
 background-color: #28a745;
 :hover {
 background-color: #218838;
 }
 `
 : ''}
`
const App = () => {
 return (
 <SuccessButton $success onClick={() => alert('clicked!')} type="button">
 Success
 </SuccessButton>
 )
}
```

여기에 필수는 아니지만 `$` prefix를 붙였는데, 이는 다른 DOM, React 컴포넌트에서 사용하는 props와 명확히 구별하기 위함이다.

styled-components로 스타일 적용하는법

## I/O는 느리다

IO (Input / Output)은 컴퓨터의 기본 작업 중에 제일 느리다. RAM에 비해서 당연히 느리고, 디스크의 처리속도, CPU 등등과 비교해서도 제일 느린 것이 IO다. 과거 플로피 디스크를 생각해보면, 디스크에서 긁히는 (읽는) 소리가 나서야 프로그램이 동작했다. 따라서 I/O는 웹 서비스의 성능에 가장 많은 영향을 미치는, 모니터링 해야 하는 요소 중에 하나다.

## 블로킹 I/O

전통적인 블로킹 IO 프로그래밍 에서는, IO 요청에 해당하는 함수의 작업이 완료 될 때까지 쓰레드의 실행이 차단된다.

```javascript
// 데이터가 사용가능해질 때까지 블로킹됨
data = socket.read()
// 데이터가 사용가능해져야 비로소 print가 된다.
print(data)
```

따라서 블로킹 IO를 사용하여 구현된 웹서버에서는, 한개의 쓰레드에서 여러개의 연결을 처리할 수 없다. 소켓의 IO 동작이 다른 연결의 처리를 차단해 버리기 때문이다. 이 문제를 해결하기 위한 전통적인 접근 방식은, 각각의 연결을 동시에 처리하기 위해 별도의 스레드 (프로세스)를 사용하는 것이다.

데이터 베이스 또는 파일 시스템과 상호작용하기 위하여 IO를 차단해야 한다면, IO 작업 결과를 대기 하기 위해 얼마나 많은 스레드가 차단되어야 하는지는 쉽게 상상할 수 있다. 당연히도, 스레드는 시스템 리소스 측면에서 저렴하지 않으므로, 각 연결에 대해 장기간 실행되는 스레드를 가지고 대부분의 시간 동안 사용하지 않는 것은 소중한 메모리와 CPU 사이클을 낭비하게 되는 결과를 초래한다.

## 논블로킹 I/O

대부분의 최신 OS는 블로킹 IO 외에도 논블로킹 IO라고 하는 또다른 메커니즘을 지원한다. 이 모드에서는, 데이터가 읽히거나 쓰일 때 까지 기다리지 않고 즉시 시스템 호출을 반환한다. 이 시점에 결과를 리턴할 준비가 안되어 있을 경우, 미리 정해진 상수를 반환하여 그 순간에 아직 반환할 수 있는 데이터가 없음을 나타낸다.

이러한 논블로킹 IO 처리를 위한 기본적인 패턴은, 실제 데이터가 반환될 때까지 루프 내에서 리소스를 계속해서 폴링하는 것이다. 이를 `busy-waiting`이라고 한다.

```javascript
resources = [socketA, socketB, fileA]
while (!resources.isEmpty()) {
  for (resource of resources) {
    // 읽기 시도
    data = resource.read()
    if (data === NO_DATA_AVAILABLE) {
      // 아직 데이터가 없다
      continue
    }
    if (data === RESOURCE_CLOSED) {
      // 리소스가 종료되었다. 리스트에서 삭제
      resources.remove(i)
    } else {
      // 데이터를 받았다.
      consumeData(data)
    }
  }
}
```

보시다시피 이는 간단하게 동일 스레드에서 서로 다른 자원을 처리할 수 있지만, 여전히 효율적이 지 않다. 위 예제의 루프는 대부분의 시간을 사용할 수 없는 리소스를 반복하기 위해 귀중한 CPU 자원만 소비한다. 폴링 알고리즘은, CPU 를 엄청나게 낭비한다.

## 이벤트 디멀티플렉싱

멀티플렉싱이란, 하나의 통신 채널을 통해서 둘 이상의 데이터를 전송하는데 사용하는 기술로, 여러개의 신호를 하나로 결합해 용량이 제한된 매체를 통해 전송하는 방식이다.

디멀티플렉싱은, 신호가 원래 구성요소로 다시 분할되는, 멀티플렉싱과 반대되는 동작이다. 여러 리소스를 감시하고, 이중 하나의 실행된 읽기 또는 쓰기 작업이 완료되면 새로운 이벤트를 반환한다. 여기서 장점은 동기식으로 작동하기 때문에 새로운 이벤트가 있을 때까지 차단한다는 것이다. 즉 이 매커니즘은, 일련의 리소스들로부터 오는 IO 이벤트를 모아서 큐에 넣고 처리할 수 있는 새 이벤트가 있을 때까지 차단한다.

```javascript
// 리소스가 하나씩 추가된다
watchedList.add(socketA, FOR_READ)
watchedList.add(fileB, FOR_READ)
// demultiplexer.watch는 동기식으로 작동되며
// 감시 대상 중 하나라도 데이터를 리턴하기 전까지 차단된다.
// 자원이 읽어드릴 준비가 되면, 호출로 부터 복귀해서 새로운 이벤트를 처리할 수 있게 된다. (비동기)
while ((events = demultiplexer.watch(watchedList))) {
  // 디멀티플렉서가 감시할 자원의 그룹을 설정해둔다.
  // 이벤트 루프
  for (event of events) {
    // (3)
    // 디멀티플렉서가 반환한 이벤트가 처리된다.
    // 이곳에 도달했다는 것은, 읽기 작업이 완료되었다는 것이므로 차단되지 않고 데이터를 반환한다.
    data = event.resource.read()
    if (data === RESOURCE_CLOSED) {
      // 리소스가 닫히면, 더이상 감시하지 않는다.
      demultiplexer.unwatch(event.resource)
    } else {
      // 데이터를 받으면, 그냥 처리한다.
      consumeData(data)
    }
  }
}
```

정리하자면, 바로 값을 가져올 수 없는 형태의 함수를 만날 경우, 일단 약속된 상수값을 리턴하고, 해당 함수를 디멀티플렉서에 추가한다. 추가된 내용에는 완료 후 호출된 콜백과 이벤트가 들어 있다. 이벤트가 완료되면 디멀티플렉서가 이벤트를 반환한다. 반환된 이벤트는 이벤트 큐에 푸시되고, 이벤트 루프는 이 큐를 순환하며 각각 이벤트에 대한 핸들러를 실행한다.

이를 활용하면, 하나의 스레드로 여러 IO 작업을 동시에 실행할 수 있다. 이 외에도 하나의 쓰레드에서 처리한다는 것은, 프로그래머들이 동시성에 접근하는 방식에도 이점을 얻을 수 있다.

## 반응자 패턴 (Reactor Pattern)

반응자 패턴의 핵심 개념은 각 IO 동작과 관련된 핸들러를 갖는 것이다. Nodejs에서 핸들러는 콜백 함수로 표현된다. 핸들러는 이벤트 루프에 의해 이벤트가 생성되고, 처리되는 즉시 호출된다.

![Reactor pattern](https://miro.medium.com/max/1200/1*X0m82lpBhRONFvRGCRu84w.jpeg)

1. 애플리케이션이 요청을 이벤트 디멀티플렉서에 제출하여, 새로운 IO 작업을 생성한다. 애플리케이션은 또한 작업이 완료되면 호출할 핸들러(콜백)를 지정한다. 새로운 요청을 이벤트 디멀티플렉서에 제출하는 것은 논블로킹 요청으로, 즉시 애플리케이션에 통제권을 반환한다.
2. IO 작업 세트가 완료되면, 이벤트 디멀티플렉서가 해당 이벤트 세트를 이벤트 큐로 푸시 한다.
3. 이 때, 이벤트 루프는 이벤트 큐 항목에서 반복된다.
4. 각 이벤트에 연결된 핸들러가 호출된다.
5. 애플리케이션 코드의 일부인 핸들러(콜백) 실행이 완료되면, 이벤트 루프를 다시 제어한다. 콜백이 실행되는 동안, 새로운 비동기 작업을 요청할 수 있으며, 이는 이벤트 디멀티플렉서에 새로운 항목 추가를 야기한다.
6. 이벤트 큐의 모든항목이 처리되면, 이벤트 루프는 이벤트 디멀티플렉서를 다시 차단하며, 이 경우 새로운 이벤트가 가능해질 때 다시 트리거한다.

비동기 동작이 이제 보다 분명해졌다. 애플리케이션은 특정 시점에 (블로킹 없이) 자원에 접근하는 것에 대한 의사를 표시하고 이에 따른 핸들러를 제공하며, 다음 연산이 완료되면 다른 시점에 호출된다.

우리는 Node.js의 핵심 패턴을 다음과 같이 정의할 수 있다.

> 반응자 패턴: 관찰 대상 리소스가 반응하면 (콜백) 해당 이벤트 핸들러를 추적해 실행하는 디자인 패턴.

## Libuv, Node.js의 IO 엔진

각 운영체제는 이벤트 디멀티플렉서에 대한 자체 인터페이스가 있다. (리눅스의 epoll, macos의 kqueue, 윈도우의 IOCP API) 이러한 불일치로 인해 node.js 팀은 모든 주요 운영 체제와 호환되고 서로 다른 유형의 논블로킹 동작을 정상적으로 처리하기 위한 목적으로 `libuv`라고 하는 네이티브 라이브러리를 만들었다. `libuv`는 기본적인 시스템 호출을 추상화 하는 것 외에도, 반응자 패턴을 구현하여 이벤트 루프 생성, 이벤트 큐 곤리, 비동기 IO 작업 실행 및, 기타 유형의 작업 큐를 위한 API를 제공한다.

## Node.js

반응자패턴과 `libuv`는 Node.js를 구성하는 핵심이며, 여기에 추가적으로 3개의 구성요소를 더하면 node.js가 완성된다.

- Binding: `libuv` 과 기타 저수준 기능을 자바스크립트에 래핑하고 사용가능하게 만들어 준다.
- V8: 구글에서 만든 크롬용 자바스크립트 엔진. Node.js를 빠르고 효율적으로 만들어 준다. 혁신적인 디자인과 속도, 효율적인 메모리 관리로 호평받고 있다.
- Javascript Core API: Node.js API를 구현하는 코어

![receipt node.js](https://t1.daumcdn.net/cfile/tistory/992DF44A5AD96F4E0B)


yceffort

리액트의 useState와 lazy initialization

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

Create React App의 serviceWorker는 무엇일까

styled-components로 스타일 적용하는법

Node.js는 어떻게 동작하는가