[원문](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는 무엇일까

## useEffect는 라이프 사이클 메소드가 아니다

과거 리액트 클래스 컴포넌트에는 `constructor` `componentDidMount` `componentDidUpdate` `componentWillUnmount` 와 같이 리액트 라이프 사이클에 대응할 수 있는 각각의 메소드가 존재했다. 함수형 컴포넌트의 훅으로 넘어오면서, 이러한 라이프 사이클 메소드를 훅으로 각각 대체하려고 하지만 이는 큰 실수다.

결론부터 말하자면, `useEffect`는 라이프 사이클 훅이 아니다. `useEffect`는 app 의 state값을 활용하여 동기적으로 부수효과를 만들 수 있는 메커니즘이다.

> The question is not "when does this effect run" the question is "with which state does this effect synchronize with"

https://twitter.com/ryanflorence/status/1125041041063665666

```javascript
useEffect(fn) // all state
useEffect(fn, []) // no state
useEffect(fn, [these, states])
```

## `eslint-plugin-react-hooks/exhaustive-deps`로 deps를 무시하지마라

물론 기술적으로는 가능하다. 그리고 때로는 사용하는게 좋은 이유가 될 수 있다. 그러나 대부분의 경우에 이를 사용하는 것은 나쁜 생각이며, 잠재적인 버그를 만들 수 있다. 이런 이야기를 했을 때, 많은 사람들이 '컴포넌트를 mount 했을 때만 실행 하고 싶을 때가 있다' 라고 말할 수 있다. 그러나 이는 라이프사이클의 접근법이며, 옳지 못하다. `useEffect`에 deps가 있을 경우, effect 백은 deps에 변화가 있을 때 항상 실행된다. 그 외에는, app의 state 변화로 부터 부수효과와 분리되어 sync가 맞지 않게 된다. (app의 state값과 부수효과가 별개로 돌아가게 된다.)

요약하자면, 이는 버그로 이어질 수 있으므로 해당 룰을 off해서는 안된다.

> app의 state와 상관없이 mount시에 실행되어야만 하는 코드가 얼마나 많겠느냐? 하는 의미로 받아드리면 될 것 같다.

## 하나의 큰 `useEffect`를 만들지 마라.

각각의 `useEffect`는 관심사를 따로 분리해 두어야 한다. 하나의 큰 `useEffect`보다는, 각각의 로직을 분리해두는 것이 훨씬 좋다.

## 불필요한 외부 함수를 만들지 마라.

아래와 같은 코드는, `useEffect`에 두가지 deps를 추가해야 된다.

```javascript
// before. Don't do this!
function DogInfo({ dogId }) {
  const [dog, setDog] = React.useState(null)
  const controllerRef = React.useRef(null)
  const fetchDog = React.useCallback((dogId) => {
    controllerRef.current?.abort()
    controllerRef.current = new AbortController()
    return getDog(dogId, { signal: controller.signal }).then(
      (d) => setDog(d),
      (error) => {
        // handle the error
      },
    )
  }, [])
  React.useEffect(() => {
    fetchDog(dogId)
    return () => controller.current?.abort()
  }, [dogId, fetchDog])
  return <div>{/* render dog's info */}</div>
}
```

위의 코드를 다음과 같이 바꿨다.

```javascript
function DogInfo({ dogId }) {
  const [dog, setDog] = React.useState(null)
  React.useEffect(() => {
    const controller = new AbortController()
    getDog(dogId, { signal: controller.signal }).then(
      (d) => setDog(d),
      (error) => {
        // handle the error
      },
    )
    return () => controller.abort()
  }, [dogId])
  return <div>{/* render dog's info */}</div>
}
```

`useEffect` 밖에서 정의되어 있던 `fetchDog` 함수를 `useEffect` 내부로 가지고 왔다. 이전에는 이것이 외부에 정의되어 있었기 때문에, deps 배열에 추가해야 했다. 또한 이 때문에 무한 루프에 빠지는 것을 방지하기 위하여 memoize를 해야 했다. 또한, controller를 위해 `ref`도 사용했다.

반드시 effect내에서 사용할 함수는 외부가 아닌 내부에서 정의 해야 한다.


useEffect는 라이프 사이클 메소드가 아니다.

조금 부끄러운 이야기지만, 1년이 넘도록 리액트를 쓰면서 아직까지도 `useCallback`에 대한 정확한 개념이 서 있지 않다. 그래, `useCallback`이 함수를 재사용하는 걸 알겠는데, 그래서 어쩌라고? 라는 나를 위해서 다시한번 정리해본다.

조금 다른 미친 이야기로 넘어와서, 만약 모든 콜백 함수를 memoize 한다면, callback 함수를 사용하는 모든 자식 컴포넌트들이 불필요한 리렌더링을 막을 수 있지 않을까? 당연히 이 글을 읽는 훌륭한 개발자 분들은 말도 안되는 것임을 알 것이고, 이는 성능에 악 영향을, 그리고 컴포넌트를 느리게 한다는 것을 알 것이다.

본론으로 들어가기전에, 함수의 동일성 체크에 대해 알아보자.

```javascript
function sum() {
  return (a, b) => a + b
}

const sum1 = sum()
const sum2 = sum()

sum1(1, 2) // 3
sum2(1, 2) // 3

sum1 === sum2 // false
sum2 === sum2 // true
```

`sum1`과 `sum2`는 동일한 코드 소스를 공유하고 있지만, 리턴하는 오브젝트가 다르다. 따라서 두 개를 비고 하면 `false`를 리턴한다. 당연한 이야기이지만, object는 오로지 자기 자신만 동일하다.

이와 비슷하게, 리액트 컴포넌트에서도 동일한 소스코드로 다른 함수 인스턴스가 생성되는 경우가 종종 있다.

```javascript
import React from 'react'

function MyComponent() {
  // handleClick 은 렌더링 될 때 마다 새로 생성된다.
  const handleClick = () => {
    console.log('Clicked!')
  }

  // ...
}
```

`handleClick`은 `MyComponent`가 새롭게 렌더링 될 때마다, 다른 함수 오브젝트가 된다. 다행히도, 인라인 함수를 만드는 비용은 그다지 비싸지 않아서, 매번 새롭게 만드는 것은 큰 비용이 아니다. 다시 말해, 컴포넌트 내부에 있는 몇개의 인라인 함수정도는 괜찮다.

그러나, 이와 반대로 한가지 함수 인스턴스를 유지해야 하는 경우가 있다.

1. `React.memo()` 또는 `shouldComponentUpdate)` 내부에 있는 컴포넌트가 callback prop을 받을 때
2. 함수가 다른 hooks 함수의 dependency로 사용될 때 `useEffect(..., [callback])`

이러한 경우에 `useCallback`이 빛을 발한다. `deps`에 같은 값이 주어질 때마다, hook은 렌더링 시에 완전히 같은 함수 인스턴스를 리턴한다.

```javascript
import React, { useCallback } from 'react'

function MyComponent() {
  // handleClick 은 완전히 같은 오브젝트다.
  const handleClick = useCallback(() => {
    console.log('Clicked!')
  }, [])

  // ...
}
```

`handleClick` 변수는 `MyComponent`가 렌더링 될 때마다 같은 콜백 함수를 가진 오브젝트를 갖게 된다.

컴포넌트가 큰 사이즈의 items을 렌더링 한다고 가정해보자.

```javascript
import React from 'react'
import useSearch from './fetch-items'

function BigList({ term, handleClick }) {
  const items = useSearch(term)

  const element = (item) => <div onClick={handleClick}>{item}</div>

  return <div>{items.map(element)}</div>
}

export default React.memo(BigList)
```

`items`가 정말 많다고 가정하고, 재 렌더링을 방지하지 위하여 `React.memo`를 사용했다. 만약 `BigList`에서 아이템을 클릭할 때 실행할 핸들러 함수가 필요하다고 가정해보자.

```javascript
import React, { useCallback } from 'react'

export default function Parent({ term }) {
  const handleClick = useCallback(
    (item) => {
      console.log('You clicked ', item)
    },
    [term],
  )

  return <BigList term={term} handleClick={handleClick} />
}
```

이렇게 하게 되면, `handleClick`은 `useCallback()`에 memozied 된다. `term`의 값이 같은 이상, `useCallback()`은 항상 같은 함수 인스턴스를 반환할 것이다.

심지어 `Parent`가 리렌더링 되더라도,`BigList`의 memoziation이 깨지지 않은 이상 항상 같은 함수를 리턴할 것이다.

이제 다시 앞선 예제로 와보자.

```javascript
import React, { useCallback } from 'react'

function MyComponent() {
  const handleClick = useCallback(() => {
    // handle the click event
  }, [])

  return <MyChild onClick={handleClick} />
}
```

이 경우는 어떤가? `MyComponent`가 렌더링 될 때 마다 `useCallback()` 훅이 호출 될 것이다. 내부적으로 리액트는 같은 오브젝트 함수를 리턴하기 위해 노력할 것이다. 그렇다고 할지라도, 인라인 함수는 여전히 매번 렌더링 될 때마다 만들어진다. 왜냐하면, `MyComponent`는 특별히 memozied 되지 않았기 때문에, 그 자체 만으로도 이미 매번 렌더링을 하게 된다.

`useCallback()`이 같은 함수 인스턴스를 보장해주지만, 이는 아무런 이득이 없다. 왜냐하면 최적화의 비용이 최적화 하지 않는 비용보다 더 크기 때문이다. 또한 코드의 복잡성도 증가하게 된다. `useCallback()`의 deps에 실제로 memozied할 callback에서 사용하는 것들을 반드시 넣어두어야 한다.

모든 최적화는 복잡성을 증가시킨다. 섣불리 추가된 최적화는 최적화된 코드를 여러번 변경할 수 있기 때문에 위험하다. [성능을 최적화 하기 전에 문제를 프로파일링 해야 한다.](https://wiki.c2.com/?ProfileBeforeOptimizing) `useCallback`의 적절한 예시는 메모화된 자식 컴포넌트에 제공되는 콜백 함수를 memozie하는 것이다.


아직도 useCallback으로 고통 받다니

useCallback 사용 가이드

[What every front-end developer should know about change detection in Angular and React](https://indepth.dev/what-every-front-end-developer-should-know-about-change-detection-in-angular-and-react/)를 번역/요약한 것입니다.

## Table of Contents

요즘 거의 대부분의 웹 애플리케이션에서 Change Detection을 찾을 수 있다. 이는 인기있는 웹 프레임워크의 필수적인 부분이다. Data Grids나 stateful jquery 플러그인 등도 충분히 발전된 Change Detection를 가지고 있다. 그리고 아마도 대부분의 애플리케이션 코드 베이스에는 Change Detection가 존재할 가능성이 크다.

소프트웨어 설계에 관심있는 사람은 이 메커니즘을 잘 이해 해야 한다. DOM 업데이트와 같이 눈에 띄는 부분을 담당하기 때문에, Change Detection이 아키텍쳐의 가장 중요한 부분이라고 생각한다. 응용프로그램의 성능에 영향을 미치는 영역이기도 하다.

전반적인 Change Detection을 알아보는 것을 시작으로, 메커니즘을 구현해볼 것이다. 그리고 이것이 리액트와 앵귤러에서 어떻게 구현되는지 심층적으로 살펴볼 것이다.

## Change Detection 은 무엇인가?

> Change Detection은 애플리케이션 상태(state) 변경을 추적하고 이러한 업데이트된 상태를 화면에 렌더링 하도록 설계한 메커니즘이다. 이는 사용자 인터페이스가 항상 내부 상태와 동기화 되도록 한다.

이 정의에서 알 수 있듯, Change Detection이 `변경 추적` 과 `렌더링` 이라는 중요한 두부분을 가지고 있다는 것을 알 수 있다.

먼저 렌더링을 알아보자. 어떤 애플리케이션이든, 렌더링 프로세스는 프로그램 내부 상태를 파악하고, 화면에서 이를 볼 수 있도록 한다. 웹 개발에서 객체나 배열 같은 데이터 구조를 가지고 있고, 이를 이미지, 버튼, 등 기타 시각적인요소의 형태로 해당 데이터의 DOM을 표현하게 된다. 렌더링 로직구현이 사소한 것은 아니지만 - 꽤 간단한 형태를 취한다.

시간이 지남에 따라 변하는 데이터를 표시하기 시작하면 상황은 훨씬 더 정교함을 요구하게 된다. 오늘날의 웹 애플리케이션은 상호작용한다. 즉 애플리케이션의 상태는 사용자의 상호작용의 결과로 언제든지 변경 될 수 있다. 또는 서버에서 데이터를 가져와서 변경될 수도 있다.

상태 변화는, 이것을 감지해야 하며 이러한 변화를 반영해야 한다.

![](https://admin.indepth.dev/content/images/2019/11/image-10.png)

예제를 살펴보자.

## Rating Widget

별점 위젯을 만든다고 가정해보자. 대략 아래와 같은 모습을 취할 것이다.

![rating-widget](https://admin.indepth.dev/content/images/2020/01/1_4OWcFci2w7bTNpEDaZHoEQ.gif)

별점을 추적하기 위해, 현재의 값을 어딘가에 저장해두어야 한다. 아래와 같은 private `_rating` 프로퍼티로 현재 상태를 정의해 두자.

```javascript
export class RatingsComponent {
  constructor() {
    this._rating = 1
  }
}
```

위젯의 상태가 변화하게되면, 이를 화면에 반영해야 된다.

```html
<ul class="ratings">
  <li class="star solid"></li>
  <li class="star solid"></li>
  <li class="star solid"></li>
  <li class="star outline"></li>
  <li class="star outline"></li>
</ul>
```

### 초기화

먼저, 구현하는데 필요한 돔 노드를 만들어야 한다.

```javascript
export class RatingsComponent {
  // ...
  init(container) {
    this.list = document.createElement('ul')
    this.list.classList.add('ratings')
    this.list.addEventListener('click', (event) => {
      this.rating = event.target.dataset.value
    })

    this.elements = [1, 2, 3, 4, 5].map((value) => {
      const li = document.createElement('li')
      li.classList.add('star', 'outline')
      li.dataset.value = value
      this.list.appendChild(li)
      return li
    })

    container.appendChild(this.list)
  }
}
```

### Change Detection

별점에 변화가 있을 때 마다 이를 알아채야 한다. Change Detection의 기본적인 구현에서는, 자바스크립트에서 제공하는 [setter](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/set)를 활용할 것이다. 따라서 별점을 위한 setter를 정의하고, 그 값이 변경될 때 마다 업데이트를 트리거 한다. DOM 업데이트는 목록 항목의 클래스를 변경하면서 수행한다.

```javascript
export class RatingsComponent {
  // ...
  set rating(v) {
    this._rating = v

    // triggers DOM update
    this.updateRatings()
  }

  get rating() {
    return this._rating
  }

  updateRatings() {
    this.elements.forEach((element, index) => {
      element.classList.toggle('solid', this.rating > index)
      element.classList.toggle('outline', this.rating <= index)
    })
  }
}
```

예제는 [여기](https://stackblitz.com/edit/js-aufmae)에서 찾아볼 수 다.

이렇게 매운 간단한 위젯을 구현하기 위해 작성해야 하는 코드의 양을 보자. 일부 시각적 요소를 표시하거나, 숨길 수 있는 목록, 조건부 로직 등 훨씬더 정교한 기능을 상상한다면, 코드의 양과 복잡성은 계속해서 증가할 것이다. 이상적인 상황이라면, 일반적인 개발에서 우리는 애플리케이션의 논리에 초점을 맞춰야 한다. 다른 누군가가 상태를 추적하고, 화면을 업데이트 하는 것을 맡기를 원한다. 그리고 이것이 프레임워크가 필요한 지점이다.

## 프레임워크

프레임워크에서 애플리케이션 내부 상태와 사용자 인터페이스 사이의 동기화를 관리한다. 이들은 우리의 부담을 줄여줬을 뿐 만 아니라, 상태 주적과 DOM 업데이트를 매우 효율적으로 처리한다.

다음은 리액트와 앵귤러에서 동일한 위젯을 구현하는 방법이다. UI와 관련한 사용자 관점에서, 템플릿은 컴포넌트 구성요소에서 매우 중요하다. 이러한 프레임워크에서 비슷한 방식으로 처리한 것은 매우 흥미롭다.

### Angular

```html
<ul class="rating" (click)="handleClick($event)">
  <li [className]="'star ' + (rating > 0 ? 'solid' : 'outline')"></li>
  <li [className]="'star ' + (rating > 1 ? 'solid' : 'outline')"></li>
  <li [className]="'star ' + (rating > 2 ? 'solid' : 'outline')"></li>
  <li [className]="'star ' + (rating > 3 ? 'solid' : 'outline')"></li>
  <li [className]="'star ' + (rating > 4 ? 'solid' : 'outline')"></li>
</ul>
```

### React

```html
<ul className="rating" onClick={handleClick}>
    <li className={'star ' + (rating > 0 ? 'solid' : 'outline')}></li>
    <li className={'star ' + (rating > 1 ? 'solid' : 'outline')}></li>
    <li className={'star ' + (rating > 2 ? 'solid' : 'outline')}></li>
    <li className={'star ' + (rating > 3 ? 'solid' : 'outline')}></li>
    <li className={'star ' + (rating > 4 ? 'solid' : 'outline')}></li>
</ul>
```

구문은 약간 다르다. DOM의 속성에 값을 사용한다는 아이디어는 동일하다. 위 템플릿에서, DOM 속성인 `className`이 컴포넌트의 속성값인 rating에 의존하고 있다고 볼 수 있다. 따라서 rating이 변할때 마다, 해당 expression등은 다시 계산된다. 만약 변화가 감지되면, className 속성 값이 바뀌는 것이다.

> click 이벤트 리스너는 앵귤러와 리액트에서 change detection의 일부가 아니다. 이들은 chagne detection을 트리거 할 지언정, 이러한 과정에서 포함되어 있지는 않다.

## Change Detection구현

DOM 요소의 속성에 값을 준다는 것은 기본적으로 두 프레임워크 모두 동일하지만, 기본적인 메커니즘에서 차이가 있다.

### Angular

컴파일러가 템플릿을 분석하면, DOM 요소와 관련된 property를 식별한다. 여기서 연결된 구성마다, 컴파일러는 일종의 명령의 형태로 바인딩을 만든다. 바인딩은 앵귤러에서 변화를 감지하는 핵심요소다. 컴포넌트의 속성과 DOM 요소 속성 사이에 연관관계를 정의한다.

이렇게 바인딩이 만들어지면, 앵귤러는 더이상 템플릿과 함께 동작하지 않는다. 변경 감지 메커니즘은 바인딩을 처리하는 명령을 실행한다. 이러한 작업은 속성이 있는 표현식의 값이 변경되었는지 확인하고, 필요한 경우 DOM 업데이트를 수행한다.

본 예제에서는, `rating` 속성이 템플릿의 `className`에 바인딩된다.

`[className]="'star ' + ((ctx.rating > 0) ? 'solid' : 'outline')"`

템플릿의 이부분에 대해 컴파일러는 바인딩을 설정하고, 더티 체크를 수행하며 필요한 경우 DOM을 업데이트 한다.

```javascript
if (initialization) {
    elementStart(0, 'ul');
        ...
        elementStart(1, 'li', ...);

        // sets up the binding to the className property
        elementStyling();
        elementEnd();
        ...
    elementEnd();
}

if (changeDetection) {

    // checks if the value of the expression has changed
    // if so, marks the binding as dirty and update the value
    elementStylingMap(1, ('star ' + ((ctx.rating > 0) ? 'solid' : 'outline')));
    elementStylingApply(1);
    ...
}
```

> 위 코드는 `Ivy`라고 알려진 새로운 컴파일러의 결과물이다. 이전 버전의 앵귤러는 바인딩과 더티체크에 대해 같은 아이디어를 사용하긴 했지만, 구현이 약간 다르다.

예를 들어 앵귤러가 `className`을 위한 바인딩을 만들었고, 현재 그 값은 대충 이럴 것이다.

`{ dirty: false, value: 'outline' }`

별점이 변화하게 되면, 앵귤러는 변화감지를 실행하게 될 것이다. 먼저 계싼된 값의 결과를 받아서 바인딩에 의해 가지고 있는 이전 값과 비교한다. 여기에서 `dirty check`라는 말이 유래되었다. 값이 변경되었다면, 현재 값을 업데이트 하고 이 바인딩을 dirty로 표시한다.

`{ dirty: true, value: 'solid' }`

그 다음엔 바인딩 된 값이 dirty인지 확인된다음에, 만약 dirty라면 (true라면) 새로운 값으로 DOM을 업데이트 한다. 우리의 예제에서는 `className` 프로퍼티가 업데이트 될 것이다.

더티체크를 수행하고, DOM의 관련된 부분을 업데이트 하는 바인딩을 처리하는 것이 앵귤러의 Change Detection의 핵심 작업이다.

### React

앞서 얘기했던 것 처럼, 리액트는 전혀 다른 접근 법을 사용한다. 리액트는 바인딩을 사용하지 않는다. 리액트에서 가장 중요한 변경 감지 매커니짐은 가상 DOM 비교다.

모든 리액트의 컴포넌트들은 JSX 템플릿을 반환하는 렌더링을 구현한다.

```javascript
export class RatingComponent extends ReactComponent {
    ...
    render() {
        return (
            <ul className="rating" onClick={handleClick}>
                <li className={'star ' + (rating > 0 ? 'solid' : 'outline')}></li>
                ...
            </ul>
        )
    }
}
```

리액트에서, 템플릿은 `React.createElement` 함수를 호출해서 컴파일 된다.

```javascript
const el = React.createElement;

export class RatingComponent extends ReactComponent {
    ...
    render() {
        return el('ul', { className: 'ratings', onclick: handleClick}, [
                 el('li', { className: 'star ' + (rating > 0 ? 'solid' : 'outline') }),
                    ...
        ]);
    }
}
```

`React.createElement` 함수가 호출될 때마다, 가상 DOM 노드라고 하는 데이터 구조를 생성하게 된다. 전혀 새로울 것이 없는, HTML 요소를 표현하는 일반적인 자바스크립트 오브젝트다. 이게 여러번 호출되면, 가상 돔 트리를 만들게 된다. 결과적으로, render 메소드는 가상 돔트리를 만들어 낸다.

```javascript
export class RatingComponent extends ReactComponent {
   ...
   render() {
       return {
           tagName: 'UL',
           properties: {className: 'ratings'},
           children: [
               {tagName: 'LI', properties: {className: 'outline'}},
               ...
           ]
       }
   }
}
```

render 함수가 호출될 때마다, 컴포넌트에 있는 프로퍼티를 보게 된다. 가상 돔 노드 속성은 이러한 계산된 값을 포함하게 된다. 우리 예제에서 별점이 0이라고 가정해보자. 이는 아래와 같은 표현식을 갖게 된다.

`{ className: rating > 0 ? 'solid' : 'outline' }`

![](https://admin.indepth.dev/content/images/2019/11/image-12.png)

이 값은 가상 돔의 `className`에 사용되는 값이다. 이 가상 돔 트리에 기반하여, 리액트는 class 값을 포함하는 리스트 아이템을 생성하게 된다.

만약 값이 0에서 1로 바뀌었다면

`{ className: rating > 0 ? 'solid' : 'outline' }`

이 값은 이제 solid가 될 것이다. 리액트가 변화감지를 수행하면, render 함수를 호출하여 새로운 버전의 가상 돔 트리를 만들어 낸다. `className` 의 속성은 이제 `solid`값으로 변경되었다. **각 change detection이 호출될 때 마다 render function이 호출된다는 것은 굉장히 중요한 사실이다.** 이 말은, 함수가 호출될때마다, 완전히 다른 가상 돔트리를 리턴한다는 것이다.

![](https://admin.indepth.dev/content/images/2019/11/image-13.png)

이렇게 만들어진 두 가상 DOM에서 비교 알고리즘을 실행하여, 두 가상 DOM 사이의 변경사항 집합을 얻는다. 우리의 경우에는 `className`의 차이 일 것이다. 차이점이 발견되면, 알고리즘은 해당 DOM 노드를 수정하는 패치를 생성한다. 이경우 패치는 `className`속성을 새 가상 돔에서 solid라는 값으로 변경할 것이다. 그리고 업데이트 된 버전에서 가상 돔은 다음 변경 감지 주기 동안 비교 대상으로 사용될 것이다.

컴포넌트에서 새로운 가상 DOM 트리를 가져와 이전 버전의 트리와 비교하고, DOM의 관련된 부분을 업데이트 하기 위한 패치를 생성하고 업데이트를 수행하는 것이 리액트 Change Detection의 핵심 요소다.

## 언제 Change Detection이 실행되는가?

Change Detection에 대한 이해를 하기 위해서는, React의 렌더 함수 또는 Angular의 측정이 언제 호출되는지 알아야 한다.

생각해보면, 변화를 감지하는 방법엔 두가지가 있다. 먼저 프레임워크에 변화가 있거나 혹은 변화가 있을 수 있는 것들을 알려서, Change Detection을 실행해야 한다는 것을 알리는 것이다.

### React

리액트에서는 change detection을 수동으로 해야 한다. 그것은 바로 `setState`다.

```javascript
export class RatingComponent extends React.Component {
    ...
    handleClick(event) {
        this.setState({rating: Number(event.target.dataset.value)})
    };
}
```

리액트에서는 이를 자동으로 하는 방법이 없다. 모든 변경감지 사이클은 `setState`로 부터 시작된다.

### Angular

앵귤러에서는 두가지 옵션이 다 있다. changeDetector 서비스를 활용해서 수동으로 트리거할 수도 있다.

```javascript
class RatingWidget {
  constructor(changeDetector) {
    this.cd = changeDetector
  }

  handleClick(event) {
    this.rating = Number(event.target.dataset.value)
    this.cd.detectChanges()
  }
}
```

그러나, 프레임워크에서 자동으로 Chnage Detection을 하게 할 수 있다. 여기에서는, 단순히 property를 업데이트 해야 한다.

```javascript
class RatingWidget {
  handleClick(event) {
    this.rating = Number(event.target.dataset.value)
  }
}
```

하지만 앵귤러에서는 어떻게 change detection을 실행해야 한다는 것을 알까?

앵귤러가 제공하는 메커니즘을 활용하여, 템플릿의 UI 이벤트에 바인딩 하기 때문에 모든 UI 이벤트 리스너에 대해 알수 있다.이 이벤트 리스너를 가로챈다는 것은, 애플리케이션 코드 실행이 끝난후 변경 탐지 실행을 스케줄링할 수 있다는 것을 의미한다. 이것은 기발한 아이디어지만, 이 메커니즘으로 모든 비동기 이벤트를 가로챌수는 없다.

`setTimout`이나 `XHR` 과 같은 이벤트에 앵귤러 매커니즘을 바인딩 할 수 없으므로, Change Detection이 자동으로 이루어질 수 없다. 이러한 문제를 해결하기 위해 zone.js라는 라이브러리를 사용한다. 브라우저의 모든 비동기 이벤트를 패치한다음, 특정 이벤트가 발생할때 앵귤러에 알릴 수 있다. UI 이벤트와 마찬가지로, 앵귤러는 애플리케이션 의 실행이 완료될 때 까지 기다렸다가 자동으로 변경을 탐지할 수 있다.


[What every front-end developer should know about change detection in Angular and React](https://indepth.dev/what-every-front-end-developer-should-know-about-change-detection-in-angular-and-react/)를 번...

프론트엔드 개발자가 알아야 하는 Angular와 React의 Change Detection

[이 글](https://ko.reactjs.org/docs/higher-order-components.html)이 한글로 번역이 안되있어서 대충 번역해봅니다.

# Higher-Order Components

고차 컴포넌트 (이하 HOC)는 리액트에서 컴포넌트 로직을 재사용하기 위한 고오급 기술이다. HOC는 리액트 API의 일부분은 아니다. 이는 리액트의 컴포넌트 환경에서 자주 나타나는 일종의 패턴이다.

구체적으로, **HOC는 컴포넌트를 받아 새로운 컴포넌트를 반환하는 함수다**

```javascript
const EnhancedComponent = higherOrderComponent(WrappedComponent);
```

컴포넌트의 props가 ui를 바꾼다면, HOC는 컴포넌트를 다른 컴포넌트로 바꿔버린다.

이러한 HOC는 리액트 써드 파티 라이브러리에서 자주사용되는 패턴으로, Redux의 `connect`와 `Relay`의 `createFragmentContainer`에서 볼 수 있다. 

이 문서에서는 왜 HOC패턴이 유용한지, 그리고 어떻게 작성하는지 살펴본다.

## 공통적인 문제를 해결하기 위해 사용하는 HOC

컴포넌트는 리액트 내에서 코드를 재사용할 수 있는 가장 기본적인 유닛이다. 그러나, 일부 패턴은 이러한 전톡적인 컴포넌트로 해결할 수 없다는 것을 알게 된다.

예를 들어, 외부에서 데이터를 받아서 목록을 보여주는 `CommentList`라는 컴포넌트가 아래처럼 있다고 가정해보자.

```javascript
class CommentList extends React.Component {
  constructor(props) {
    super(props);
    this.handleChange = this.handleChange.bind(this);
    this.state = {
      // "DataSource" is some global data source
      comments: DataSource.getComments()
    };
  }

  componentDidMount() {
    // Subscribe to changes
    DataSource.addChangeListener(this.handleChange);
  }

  componentWillUnmount() {
    // Clean up listener
    DataSource.removeChangeListener(this.handleChange);
  }

  handleChange() {
    // Update component state whenever the data source changes
    this.setState({
      comments: DataSource.getComments()
    });
  }

  render() {
    return (
      <div>
        {this.state.comments.map((comment) => (
          <Comment comment={comment} key={comment.id} />
        ))}
      </div>
    );
  }
}
```

그리고 비슷한 패턴으로 블로그 포스트 하나를 보여주는 컴포넌트가 있다고 가정하자.

```javascript
class BlogPost extends React.Component {
  constructor(props) {
    super(props);
    this.handleChange = this.handleChange.bind(this);
    this.state = {
      blogPost: DataSource.getBlogPost(props.id)
    };
  }

  componentDidMount() {
    DataSource.addChangeListener(this.handleChange);
  }

  componentWillUnmount() {
    DataSource.removeChangeListener(this.handleChange);
  }

  handleChange() {
    this.setState({
      blogPost: DataSource.getBlogPost(this.props.id)
    });
  }

  render() {
    return <TextBlock text={this.state.blogPost} />;
  }
}
```

`CommentList`와 `BlogPost`는 동일하지 않다. 이 두 컴포넌트는 서로 다른 메소드에서 `DataSource`를 참조하고 있으며, 서로 다른 결과물을 렌더링한다. 하지만 이들은 공통적으로 구현할 수 있는게 있다.

- mount 시점에, DataSource에 `changeListener`를 단다
- 리스너 내부에서 변경된 데이터에 따라 `setState`를 호출한다.
- unmount 시점에 해당 listener를 해제한다.

만약 이 앱의 크기가 커진다면, 이와 비슷한 패턴이 반복해서 나타날 것이다. 우리는 여기서 이러한 로직을 추상화하여 한 요소에 두고, 서로다른 컴포넌트에서 사용하게 할 수 있다. 이것이 바로 HOC 컴포넌트의 기본 개념이다.

우리는 `CommentList`나 `BlogPost`등의 컴포넌트를 만드는 함수를 만들어, 여기에 공통적으로 `DataSource`를 달아 줄 수 있다. 이 함수는 자식 함수 하나를 argument로 넘겨 받아서, 넘겨받은 데이터를 prop으로 넘길 수 있다. 이러한 함수를 `withSubscription`이라고 해보자.

```javascript
const CommentListWithSubscription = withSubscription(
  CommentList,
  (DataSource) => DataSource.getComments()
);

const BlogPostWithSubscription = withSubscription(
  BlogPost,
  (DataSource, props) => DataSource.getBlogPost(props.id)
);
```

첫번째 파라미터는 컴포넌트고, 두번째 파라미터는 데이터를 받아올 `DataSource`다.

`CommentListWithSubscription`와 `BlogPostWithSubscription`가 렌더링되면, `CommentList`와 `BlogPost`는 `DataSource`로 부터 받은 데이터를 prop으로 넘기게 된다.

```javascript
// This function takes a component...
function withSubscription(WrappedComponent, selectData) {
  // ...and returns another component...
  return class extends React.Component {
    constructor(props) {
      super(props);
      this.handleChange = this.handleChange.bind(this);
      this.state = {
        data: selectData(DataSource, props)
      };
    }

    componentDidMount() {
      // ... that takes care of the subscription...
      DataSource.addChangeListener(this.handleChange);
    }

    componentWillUnmount() {
      DataSource.removeChangeListener(this.handleChange);
    }

    handleChange() {
      this.setState({
        data: selectData(DataSource, this.props)
      });
    }

    render() {
      // ... and renders the wrapped component with the fresh data!
      // Notice that we pass through any additional props
      return <WrappedComponent data={this.state.data} {...this.props} />;
    }
  };
}
```

HOC는 파라미터로 넘어온 컴포넌트를 수정하지도, 복제하지도 않는 다는 것을 염두해 두어야 한다. 그 대신, HOC는 단순히 넘겨 받은 컴포넌트를 감싸는 역할을 하는 것이다. HOC는 순수 함수이며, 어떠한 부수효과도 만들지 않는다.

이게 끝이다. 감싸진 컴포넌트는 모든 props를 넘겨 받을 것이며, 새롭게 받은 prop, `data`를 바탕으로 결과물을 그릴 것이다. HOC는 이 데이터가 어떻게 왜 쓰이는지는 관여하지 않으며, 감싼 컴포넌트도 마찬가지로 이러한 데이터가 어디서 오는지 신경쓰지 않는다.

`withSubscription`은 단지 일반적인 함수이므로, 여기에 많은 arguments를 추가할 수 있다. 예를 들어, `data` prop를 설정가능하게 만들고 싶다면, 또다른 HOC를 만들어서 감쌀 수 있다. 또는 새로운 argument를 받아서 `shouldComponentUpdate`에서 수정할 수도 있다. 이는 모두 HOC가 컴포넌트가 어떻게 제어되는지 전체적으로 관리할 수 있기 때문에 가능하다.

컴포넌트와 마찬가지로, `withSubscription`와 감싸진 컴포넌트는 완전히 `prop`을 기반으로 움직인다. 이는 동일한 `prop`을 사용하는 다른 HOC로 교체하기 용이하게 만든다. 이는 데이터를 fetch하는 라이브러리 등을 바꿀때 유용하게 사용할 수 있다.

## 원본 컴포넌트를 바꾸지마라, 대신 Composition을 사용하라.

HOC 내부에서는 컴포넌트를 수정해서는 안된다.

```javascript
function logProps(InputComponent) {
  InputComponent.prototype.componentDidUpdate = function(prevProps) {
    console.log('Current props: ', this.props);
    console.log('Previous props: ', prevProps);
  };
  // The fact that we're returning the original input is a hint that it has
  // been mutated.
  return InputComponent;
}

// EnhancedComponent will log whenever props are received
const EnhancedComponent = logProps(InputComponent);
```

위 코드에는 여러가지 문제가 있다. 그 중 하나는 `EnhancedComponent`로 부터 분리되어 `inputComponent`를 재사용할 수 없다는 것이다. 더 끔찍한 것은, 기존 컴포넌트의 `ComponentDidUpdate`도 엎어버린다는 것이다. 또한 이는 라이프 사이클 메소드가 없는 함수형 컴포넌트에서는 사용할 수가 ㅇ벗다.

컴포넌트를 변경하는 HOC는 추상화를 누출 시키는 것이다. 다른 HOC와의 충돌을 막기 위해서는, 어떻게 구현되는지 알아야 한다.

직접적으로 변경하는 대신에, HOC는 `InputComponent`를 감싸는 컨테이너 컴포넌트를 정의하여 합성을 해야 한다.

```javascript
function logProps(WrappedComponent) {
  return class extends React.Component {
    componentDidUpdate(prevProps) {
      console.log('Current props: ', this.props);
      console.log('Previous props: ', prevProps);
    }
    render() {
      // Wraps the input component in a container, without mutating it. Good!
      return <WrappedComponent {...this.props} />;
    }
  }
}
```

이런식으로 작성한다면, 기능적으로도 완전히 동일하게 작동하며 잠재적인 충돌 이슈도 피할 수 있다.

이전에 살짝 언급했지만, HOC는 컨테이너 컴포넌트 패턴으로도 불리운다. 컨테이너 컴포넌트란 고차원과 저차원의 관심사를 분리하여 역할을 맡기는 일종의 전략이다. 컨테이너는 state와 데이터 변화를 감지하는 역할을 하고, UI를 렌더링하는 컴포넌트에 이러한 데이터를 넘기는 역할을 한다. HOC는  컨테이너를 일종의 implmentation으로 사용한다. HOC를 일종의 파라미터화 된 컴포넌트 정의로 생각할 수도 있다.

## 규칙: HOC와 관련이 없는 prop을 Wrapped Component에 넘겨라

HOC는 컴포넌트에 일종의 규칙을 더해준다. 따라서 극적인 변화를 가하지는 않는다. HOC에서 반환된 컴포넌트는 기존의 컴포넌트와 비슷한 인터페이스를 가지고 있으리라 예상한다.

HOC는 HOC에서 관여하지 않는 props 에 대해서는 바로 넘겨줘야 한다. 아래의 예제를 살펴보자.

```javascript
render() {
  // 그냥 컴포넌트에 넘길 prop을 분리한다.
  const { extraProp, ...passThroughProps } = this.props;

  // WrappedComponent에 넣을 props을 정의한다.
  const injectedProp = someStateOrInstanceMethod;

  // 이렇게 넘긴다.
  return (
    <WrappedComponent
      injectedProp={injectedProp}
      {...passThroughProps}
    />
  );
```

이러한 컨벤션은 HOC를 더욱 유연하고 재사용할 수 있게 해준다.

## 규칙: 결합성을 극대화 하라.

모든 HOC가 다 똒같은 생김새를 가지고 있는 것은 아니다. argument가 컴포넌트 단 하나인 경우도 있다.

```javascript
const NavbarWithRouter = withRouter(Navbar);
```

보통 HOC는 추가적인 arugment를 받는다. Relay를 예로 들면, 컴포넌트의 데이터 디펜던시를 명세한 config 오브젝트를 추가적으로 받는다.

```javascript
const CommentWithRelay = Relay.createContainer(Comment, config);
```

그러나 일반적인 HOC는 이렇게 생겼다.

```javascript
// React Redux's `connect`
const ConnectedComment = connect(commentSelector, commentActions)(CommentList);
```

생김새가 달라서 당황스럽지만, 나누면 이렇게 구성되어 있다.

```javascript
// connect is a function that returns another function
const enhance = connect(commentListSelector, commentListActions);
// The returned function is a HOC, which returns a component that is connected
// to the Redux store
const ConnectedComment = enhance(CommentList);
```

다시말해, `connect`는 HOC를 리턴하는 HOC인 것이다.

이러한 형태는 혼란스럽고 불필요해보일 수 있지만, 꽤 유용한 면도 가지고 있다. 단일 argument를 받는 connect 함수는 컴포넌트에서 컴포넌트를 반환하는 모양새를 띄고 있다. 출력과 입력이 동일한 함수는 합성하기 매우 편리하다.

```javascript
// 이렇게 하는 대신에..
const EnhancedComponent = withRouter(connect(commentSelector)(WrappedComponent))

// ... 함수를 합성하는 유틸리티를 사용할 수 있다.
// compose(f, g, h) is the same as (...args) => f(g(h(...args)))
const enhance = compose(
  // 여기는 모두 인자를 하나로 받는 HOC들이다.
  withRouter,
  connect(commentSelector)
)
const EnhancedComponent = enhance(WrappedComponent)
```

이러한 유틸리티 함수 `componse` 는 lodash, redux, ramda와 같은 다양한 써드파티 라이브러리에서 지원한다.

## 규칙: 감싼 컴포넌트에 이름을 부여하여 디버깅을 쉽게 하자.

HOC에 의해 생성된 컨테이너 컴포넌트는 React Developer Tool에서 다른 컴포넌트 처럼 보인다. 디버깅을 쉽게 하기 위해서는, 이러한 HOC 에 이름을 부여할 필요가 있다.

```javascript
function withSubscription(WrappedComponent) {
  class WithSubscription extends React.Component {/* ... */}
  WithSubscription.displayName = `WithSubscription(${getDisplayName(WrappedComponent)})`;
  return WithSubscription;
}

function getDisplayName(WrappedComponent) {
  return WrappedComponent.displayName || WrappedComponent.name || 'Component';
}
```


## 주의사항

HOC에는 리액트를 처음 접하는 사람의 경우 헷갈릴 수 있는 몇가지 주의사항이 있다.

### HOC를 렌더링 메소드 내부에서 사용하지 마라

리액트의 비교 알고리즘 ([재조정](https://ko.reactjs.org/docs/reconciliation.html)) 은 현재 존재하는 서브트리에서 컴포넌트 업데이트가 필요한지 혹은 새롭게 마운트 해야하는지 결정한다. 만약 render에서 반환된 요소가 이전 렌더의 요소와 완전히 동일하다면, 리액트는 새로운 렌더와 이전의 서브트리를 재귀적으로 비교하면서 업데이트를 한다. 만약 동일하지 않다면, 이전의 서브트리는 완전히 unmount 된다.

일반적으로는 이러한 것들을 고민할 필요가 없다. 그러나 HOC에서는 문제가 될 수 있는데, 이는 HOC 컴포넌트내에서는 render 메소드를 사용할 수 없기 때문이다.

```javascript
render() {
  // 렌더링이 될때마다 새로운 버전의 EnchanceComponent가 생성된다.
  const EnhancedComponent = enhance(MyComponent);
  // 이는 서브트리가 반복적으로 mount 되는 원인이 된다.
  return <EnhancedComponent />;
}
```

단순히 성능만이 문제가 아니다. 컴포넌트를 새롭게 mount 한다는 것은 하위 컴포넌트들의 상태값이 모두 사라진 다는 것을 의미한다.

이렇게 하지말고, HOC의 결과물을 컴포넌트 밖에서 적용하여 딱 한번만 만들도록 해야 한다.  그러면 렌더링 사이에서 일관성이 유지되는 것이고, 이는 개발자가 원하는 것이다.

HOC를 동적으로 사용해야 하는 매우 드문 경우에는, 컴포넌트의 라이프사이클 혹은 constructor 내부에서 수행해야 한다.

### static 메소드는 반드시 복사 해야 한다.

때때로 리액트 컴포넌트에 정적 메소드를 정의하는 것이 유용할 때가 있다. 예를 들어 Relay컨테이넌 `getFragment`라는 정적 메소드를 활용하여 GraphQL 과의 합성을 용이하게 한다.

그러나 HOC 컴포넌트에 이를 적용할 경우, 원 컴포넌트는 컨테이너 컴포넌트로 감싸지게 된다. 이 말은 원본 컴포넌트가 가지고 있던 static 메소드가 모두 사라진다는 것을 의미한다.

```javascript
// Define a static method
WrappedComponent.staticMethod = function() {/*...*/}
// Now apply a HOC
const EnhancedComponent = enhance(WrappedComponent);

// The enhanced component has no static method
typeof EnhancedComponent.staticMethod === 'undefined' // true
```

이를 해결하기 위해서는, 메소드를 이전에 복사해두었다가 붙이는 방법을 써야 한다.

```javascript
function enhance(WrappedComponent) {
  class Enhance extends React.Component {/*...*/}
  // Must know exactly which method(s) to copy :(
  Enhance.staticMethod = WrappedComponent.staticMethod;
  return Enhance;
}
```

그러나 이런 기법을 사용하기 위해서는, 어떤 메소드가 정의되어있는지 정확히 알아야 한다. 이 때는 [hoist-non-react-statics](https://github.com/mridgway/hoist-non-react-statics)라이브러리를 사용하여 자동으로 복사하게 할 수 있다.

```javascript
import hoistNonReactStatic from 'hoist-non-react-statics';
function enhance(WrappedComponent) {
  class Enhance extends React.Component {/*...*/}
  hoistNonReactStatic(Enhance, WrappedComponent);
  return Enhance;
}
```

다른 방법으로는 static 메서드를 컴포넌트와 분리하여 따로 export 하는 방법이 있다.

```javascript
// Instead of...
MyComponent.someFunction = someFunction;
export default MyComponent;

// ...export the method separately...
export { someFunction };

// ...and in the consuming module, import both
import MyComponent, { someFunction } from './MyComponent.js';
```


### Ref 는 넘어가지 않는다.

HOC가 모든 props을 넘기지만, ref에는 똑같이 적용할 수 없다. 그 이유는 `ref`가 사실 `prop`이라기 보다는 `key`에 가깝기 때문이다. 만약 HOC의 결과로 나온 컴포넌트에 ref를 달게 된다면, ref는 감싼 컴포넌트가 아닌 컨테이너 컴포넌트를 가르키게 된다.

이것을 해결할 수 있는 방법은 `React.forwardRef` API를 사용하는 것이다. [여기](https://ko.reactjs.org/docs/forwarding-refs.html)에서 자세한 내용을 살펴보자.


[이 글](https://ko.reactjs.org/docs/higher-order-components.html)이 한글로 번역이 안되있어서 대충 번역해봅니다. # Higher-Order Components  고차 컴포넌트 (이하 HOC)는 리액트에서 컴포넌트 로직을 재사용하기 위한 고오급 기술이다. HOC는 리액트 API의 일부분은 아니다. 이는 리액트...

yceffort

react

Create React App의 serviceWorker는 무엇일까

useEffect는 라이프 사이클 메소드가 아니다.

useCallback 사용 가이드

프론트엔드 개발자가 알아야 하는 Angular와 React의 Change Detection

리액트 고차 컴포넌트 (React Higher Order Component)