조금 부끄러운 이야기지만, 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 사용 가이드

## Table of Contents

## same-site와 same-origin의 차이

### Origin

https://yceffort.kr:443

- `origin`: 은 `scheme` (`protocol`로도 알려진)와 `host name`, 그리고 `port`의 조합을 의미한다. 예를 들어 https://yceffort.kr:443/2020/07/docker-study-2/ 의 origin은 https://yceffort.kr:443 이다.
- `scheme`: `https://`
- `host name`: `yceffort.kr`
- `port`: 443

https://yceffort.kr:443 를 기준으로 비교했을 때,

| Origin                       | 비교결과       | 이유                                                   |
| ---------------------------- | -------------- | ------------------------------------------------------ |
| https://fake.kr:443          | `cross-origin` | 도메인이 다르다.                                       |
| https://www.yceffort.kr:443  | `cross-origin` | 서브도메인이 다르다.                                   |
| https://blog.yceffort.kr:443 | `cross-origin` | 서브도메인이 다르다.                                   |
| http://yceffort.kr:443       | `cross-origin` | scheme이 다르다.                                       |
| http://yceffort.kr:80        | `cross-origin` | port가 다르다.                                         |
| https://yceffort.kr:443      | `same-origin`  | 완전히 같다.                                           |
| https://yceffort.kr          | `same-origin`  | 포트가 없지만, https의 기본포트 443이 있다고 간주한다. |

### Site

탑 레벨 도메인 (TLD), 즉 `.com`과 `.org`등은 [Root Zone Database](https://www.iana.org/domains/root/db)에 등록되어 있다. 내 블로그 주소를 기준으로, `site`는 TLD와 domain의 조합이다. 따라서 내 블로그의 `site`는 `yceffort.kr`이다.

그러나, `.co.kr`이나 `.github.io`와 같은 주소도 더러 있는 것을 볼 수 있다. 이들의 TLD는 `.kr` `.io`인데, 단순히 TLD만으로 이들의 도메인을 결정할 수 있는 방법이 없다. 그래서 `eTLD` (effective Top Level Domain) 리스트가 만들어졌다. [eTLD](https://publicsuffix.org/list/)

예를 들어, 내 구 블로그 주소인 https://yceffort.github.io 를 기준으로 살펴보자.

- `TLD`: `.io`
- `eTLD`: `.github.io`
- `eTLD+1`: `yceffort.github.io` (site)

https://yceffort.kr:443 를 기준으로 비교했을 때,

| Origin                       | 비교결과     | 이유                            |
| ---------------------------- | ------------ | ------------------------------- |
| https://fake.kr:443          | `cross-site` | 도메인이 다르다.                |
| https://blog.yceffort.kr:443 | `same-site`  | 서브도메인이 다르지만 상관없다. |
| http://yceffort.kr:443       | `same-site`  | scheme이 다르지만 상관없다.     |
| https://yceffort.kr:80       | `same-site`  | port가 다르지만 상관없다.       |
| https://yceffort.kr:443      | `same-site`  | 완전히 같다.                    |
| https://yceffort.kr          | `same-site`  | port가 없지만 상관없다.         |

위에서 보다시피 `same-site`는 scheme를 무시하고 있지만, http의 취약점을 방어하기 위해 조금 더 엄격한 방식으로 구별하는 방식이 있다. 이를 [schemeful same-site](https://github.com/sbingler/schemeful-same-site/)라고 한다. 이 경우 http://yceffort.kr과 https://yceffort.kr 는 스키마가 다르므로 다른 사이트로 취급한다.

| Origin                       | 비교결과              | 이유                            |
| ---------------------------- | --------------------- | ------------------------------- |
| https://fake.kr:443          | `cross-site`          | 도메인이 다르다.                |
| https://blog.yceffort.kr:443 | `schemeful-same-site` | 서브도메인이 다르지만 상관없다. |
| http://yceffort.kr:443       | `cross-site`          | scheme이 다르다.                |
| https://yceffort.kr:80       | `schemeful-same-site` | port가 다르지만 상관없다.       |
| https://yceffort.kr:443      | `same-site`           | 완전히 같다.                    |
| https://yceffort.kr          | `schemeful-same-site` | port가 없지만 상관없다.         |

## Referer와 Referrer-Policy 101

> 맨 처음 포스팅을 할 때 이상하다고 느낀 것은 Referer와 Referrer-policy에서 Referrer의 스펠링이 다른 것이었다. (틀리다고 계속 에러메시지가 떴다.) 알고보니 오타가 고대로 스펙이 되버린 것이었다.

> The misspelling of referrer originated in the original proposal by computer scientist Phillip Hallam-Baker to incorporate the field into the HTTP specification.[4] The misspelling was set in stone by the time of its incorporation into the Request for Comments standards document RFC 1945; document co-author Roy Fielding has remarked that neither "referrer" nor the misspelling "referer" were recognized by the standard Unix spell checker of the period.[5] "Referer" has since become a widely used spelling in the industry when discussing HTTP referrers; usage of the misspelling is not universal, though, as the correct spelling "referrer" is used in some web specifications such as the Document Object Model.

https://en.wikipedia.org/wiki/HTTP_referer

http 요청은 옵셔널 헤더인 [Referer](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referer)를 가지고 있을 수 있다. 이 정보는 이 요청이 만들어진 origin 또는 웹페이지 URL을 가리킨다. [Referrer-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy)헤더는 요청과 함께 얼마나 많은 레퍼럴 정보를 포함해야 하는지 알려준다.

아래 예제를 보자.

![example1](https://web-dev.imgix.net/image/admin/cXgqJfmD5OPdzqXl9RNt.jpg)

`Referer` 헤더에 해당 정보를 요청한 사이트의 전체 주소가 담겨져 있다.

`Referer` 헤더는 다양한 형태의 요청에 존재할 수 있는데, 예를 들어

- 사용자가 링크를 클릭하는 네비게이션 링크
- 브라우저가 이미지, iframe, script 등 페이지에 필요한 리소스를 요청하는 subresource 요청

가 있다. 네비게이션과 `iframe`의 경우, 자바스크립트의 `document.referrer`를 이용해서도 동일한 정보에 접근할 수 있다.

`Referer`는 꽤나 유용한 정보가 될 수 있다. 옐르 들어, `site-two.example`의 사용자중 50%는 `social-network.example`에서 왔다는 것을 파악할 수 있다.

그러나, query와 path를 포함한 전체 주소를 `Referer`를 통해서 다른 origin에 보내는 것은, 보안 상에서 문제가 될 수 있다. 아래의 예를 살펴보자.

![example2](https://web-dev.imgix.net/image/admin/oTUtfrwaGYYjlOJ6KRs6.jpg?auto=format&w=1600)

1번과 5번 예제에서 볼 수 있다시피 이 사이트에 온 사람이 누구인지 식별할 수도 있게 되어 버린다. 6번의 경우에는 극단적이지만 끔찍한 예제이다. 💀

따라서, 사이트의 요청에 사용할 수 있는 `referer` 데이터를 제한하기 위해서 사용하는 것이 `Referrer-Policy`이다.

## 어떠한 것들이 가능하고, 차이는 무엇일까?

가능한 정책은 총 8가지다. 정책에 따라서, `Referer`의 데이터는

- 데이터가 없다. (`Referer` 헤더가 없을 경우)
- `origin`만 존재하는 경우: https://yceffort.kr
- URL 전체: https://yceffort.kr/2020/07/docker-study-2/

일부 정책의 경우 context에 따라서 다르게 작동하도록 동작 되어있다. (cross-origin, same-origin request, security) 이는 사이트 내에서 Referer를 유지하면서, 동시에 다른 origin에서는 정보를 제한하는데 있어서 유용하다.

|                                   | No Data        | Origin Only                                | Full URL                   |
| --------------------------------- | -------------- | ------------------------------------------ | -------------------------- |
| `no-referrer`                     | ✔              |                                            |                            |
| `origin`                          |                | ✔                                          |                            |
| `unsafe-url`                      |                |                                            | ✔                          |
| `strict-origin`                   | HTTPS → HTTP   | HTTPS → HTTPS, HTTP → HTTP                 |                            |
| `no-referrer-when-downgrade`      | HTTPS → HTTP   |                                            | HTTPS → HTTPS, HTTP → HTTP |
| `origin-when-cross-origin`        |                | `cross-origin`                             | `same-origin`              |
| `same-origin`                     | `cross-origin` |                                            | `same-origin`              |
| `strict-origin-when-cross-origin` | HTTPS → HTTP   | `cross-origin`, HTTPS → HTTPS, HTTP → HTTP |                            |

실제 예제 까지 보고 싶다면 [여기](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy#Examples)를 참고

- scheme를 보는 모든 정책 (`strict-origin` `no-referrer-when-downgrade` `strict-origin-when-cross-origin`)의 경우에, HTTP가 실제로 더 보안에 취약함에도 불구하고, HTTP origin에서 다른 HTTP origin으로 가는 것을 HTTPS origin에서 다른 HTTPS origin으로 가는 것과 동일하게 취급한다. (= HTTP와 HTTPS에 대해 차이를 두고 있지 않다.) 이러한 정책의 경우 중요한 것은, 보안 다운그레이드가 발생하는지 여부, 즉 암호화된 원본에서 암호화되지 않은 원본으로 데이터를 노출할 수 있는지 여부이다. HTTP에서 HTTP는 암호화가 없어서 다운그레이드 되지 않는다. 다만 HTTPS에서 HTTP는 다운그레이드가 나타난다. (암호화가 된 것에서 암호화가 안된 것으로 가므로)

- 요청이 `same-origin`이라면, 이 뜻은 scheme (HTTS, HTTP)가 같다는 뜻이다. 따라서 보안에서 다운그레이드가 이루어지지 않는다.

## 브라우저별 표준

만약 `referrer-policy`가 설정되어 있지 않다면, 브라우저 기본 정책이 적용된다.

| 브라우저 | 기본 정책                                                                               |
| -------- | --------------------------------------------------------------------------------------- |
| Chrome   | 85 버전부터 `no-referrer-when-downgrade`에서 `strict-origin-when-cross-origin`으로 변경 |
| Firefox  | `no-referrer-when-downgrade`, 시크릿 모드에서는 `strict-origin-when-cross-origin`       |
| Edge     | `no-referrer-when-downgrade`                                                            |
| Safari   | `strict-origin-when-cross-origin`와 비슷하게 동작                                       |

## referrer policy 설정하는 올바른 방법

사이트에 referrer policy를 설정하는 방법은 여러가지가 있다.

- http header
- [HTML](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy#Integration_with_HTML)
- [Javascript](https://javascript.info/fetch-api#referrer-referrerpolicy)

페이지마다, 요청마다 다른 정책을 쓸 수 있다는 것을 의미한다. HTTP header와 meta 엘리먼트는 모두 페이지 레벨에서 동작한다. 유효 정책을 정하는 순위는 아래와 같다.

- element 레벨
- page 레벨
- 브라우저 기본값

### 예제

```html
<meta name="referrer" content="strict-origin-when-cross-origin" />
<img src="..." referrerpolicy="no-referrer-when-downgrade" />
```

이 경우 이미지는 `no-referrer-when-downgrade` 정책으로 가게 된다.

### referrer policy를 보는 법

브라우저의 네트워크 탭을 보면 된다.

![Referrer policy example](./images/referrer-policy.png)

## 어떤 정책이 좋을까?

요약: 명시적으로 보안이 강화된 `strict-origin-when-cross-origin`를 사용하는 것이 좋다.

### 왜 명시적으로 써야 할까?

referrer policy가 제공되지 않는다면, 브라우저 기본 정책이 사용된다. 사실, 많은 웹사이트 들이 이러한 정책을 브라우저 기본값에 의존하는데 이는 좋지 않다. 그 이유는

- 브라우저 모드 (시크릿모드 같이)에 따라서 `no-referrer-when-downgrade`이거나 `strict-origin-when-cross-origin`일 수 있는데, 이는 웹사이트에서 일관된 동작을 하지 못하도록 막는다.
- 브라우저의 기본값인 `strict-origin-when-cross-origin`는 cross-origin 요청에 대해서 referrer를 trimming하는 기능으르 가지고 있다. (파이어폭스, 사파리의 경우에만 그렇다. [여기]([Referrer trimming](https://github.com/privacycg/proposals/issues/13))를 참조) 명시적으로 정책을 선언해서 이러한 행위를 막을 수 있다.

### 왜 `strict-origin-when-cross-origin`인가?

- 안전하다: 웹사이트가 https 일 경우, https 가 아닌 요청에 대해서 웹사이트 주소를 노출하고 싶지 않을 것이다. 만약 누구라도 네트워크에서 이런 정보를 본다면, 유저의 정보가 [중간자 공격](https://ko.wikipedia.org/wiki/%EC%A4%91%EA%B0%84%EC%9E%90_%EA%B3%B5%EA%B2%A9) 의 위험에 노출되게 한다. `no-referrer-when-downgrade` `strict-origin-when-cross-origin` `no-referrer` `strict-origin`로 막을 수 있다.
- 개인정보 보안: cross-origin 요청의 경우, `no-referrer-when-downgrade`는 모든 주소를 노출시킨다. `strict-origin-when-cross-origin`와 `strict-origin`은 `origin`만 공유하고, `no-referrer`의 경우에는 아무정보도 안나타나게 된다.
- 용이하다: `no-referrer`와 `strict-origin`은 절대로 전체 URL을 공유하지 않는다. 근데 문제는 `same-orgin`일 때도 공유를 안한다는 것. 이를 피하기 위해서는 `strict-origin-when-cross-origin`를 쓰면 된다.

따라서 모든 경우에 있어서 `strict-origin-when-cross-origin`가 가장 최선의 선택이라고 볼 수 있다.

```html
<meta name="referrer" content="strict-origin-when-cross-origin" />
```

혹은 서버사이드에서

```javascript
const helmet = require('helmet')
app.use(helmet.referrerPolicy({ policy: 'strict-origin-when-cross-origin' }))
```

### 만약 예외가 필요하다면

별도로 element 나 요청별로 예외를 두는 것이 좋다. 그럼에도, `unsafe-url` 같은 건 안쓰는게 좋다.

```html
<meta name="referrer" content="strict-origin-when-cross-origin" />
<img src="…" referrerpolicy="no-referrer-when-downgrade" />
```

```javascript
fetch(url, { referrerPolicy: 'no-referrer-when-downgrade' })
```

> element 별로 정책을 주는 것도 모든 브라우저에서 되는 것은 아니다. [참고](https://caniuse.com/?search=referrerpolicy)

## 외부에서 오는 요청에 referrer를 활용하는 법

### Cross Ste Request Forgery (CSRF) 보호

CSRF 방어를 위해서 referrer를 쓰는 것은 몇가지 허점이 있다.

- `no-referrer`나 request를 도용하는 경우 아무런 데이터를 볼 수 없을 수 있다. 요청의 헤더에 대한 제어를 하고 있지 못한다면, 요청에 안전한 헤더가 온다는 보장이 없다.
- `Referer` (`document.referer`) 에는 원하는 것 (단순히 cross-origin만 알고 싶었는데..) 보다 더 많은 양의 데이터가 들어 있을 수 있다.

CSRF 방어를 위해서는 [CSRF Token](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#token-based-mitigation)을 사용하는 것을 추천한다.

### 로깅

`Referer`에는 개인정보가 담겨 있을 수 있으므로, 다루는데 신중해야 한다. `Referer`를 사용하는 대신에, [Origin](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin)이나 [Sec-Fetch-Site](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Site)를 써보는 것도 좋다.

> `sec-fetch-site`는 지원이 제한적이므로, `origin`을 쓰는게 낫다.

### 결제

결제 사업자는 보안 체크를 위해, 들어오는 요청에 대해서 `Referer`를 확인할 수도 있다. 예를 들어

- 유저가 online-shop.example/cart/checkout 에서 결제 버튼을 누른다.
- online-shop.example 가 결제를 위해 payment-provider.example로 리다이렉트 시킨다.
- payment-provider.example가 `Referer`를 확인하여 허가된 사이트로 부터 온 요청인지 확인한다. 그렇지 않다면, 결제 요청을 거부한다.

#### 결제 플로우에서 보안 체크

결제사업자가 `Referer`를 체크하는 것은 기본적인 방어 체계가 될 수 있다. 그러나 반드시, 또 다른 방어체계를 마련해 두어야 한다.

`Referer`만으로는 모든 것을 막기에 완벽하지 않다. 만약 결제 사이트에서 `no-referrer`를 설정해 두었다면, 해당 정보를 확인할 수 없다. 그러나, 결제 제공 사업자로서, 일단 `Referer`를 본다면 해당 정보가 있는지 없는지 정도 수준의 기본적인 체크는 할수가 있다.

- `Referer`가 언제나 있을 거라고 기대하지마라. 설령 존재한다 하더라도, 이는 아주 기초적인 점검 항목중 하나인 `origin`만 살펴볼 수 있다. `Referer` 허용 값을 작성할때, origin만 있도록 하는 것이 중요하다. 즉, `online-shop.example/cart/checkout`가 아닌 `online-shop.example`여야 한다는 것이다. 이는 결제 사이트에 따라서 정책이 다르게 설계 될 수 있으므로 (=꼭 FULL URL이 온다는 보장은 없으므로) 반드시 origin만 확인해야 한다.
- 만약 `Referer`가 없거나, 기본적인 점검이 통과했을 경우, 아래의 추가적인 항목으로 검사를 시도해야 한다.

#### 더 안전한 방법

한 가지 신뢰할 수 있는 검증 방법은 요청자가 요청한 매개변수를 고유한 키와 함께 해시하여 보내도록 하는 것이다. 결제 제공자로서 이 해시 값을 검사할 수 있고 이 값이 일치하는 요청에 대해서만 받으면 된다.


웹 어플리케이션에서 request를 받기 위한 최적의 Referer와 Referrer 정책

Referer와 Referer-Policy를 위한 가이드

[이 글](https://indepth.dev/webpack-5-module-federation-a-game-changer-in-javascript-architecture/)을 위주로 번역한 글이며, 추가적으로 micro frontend에 대한 개념도 넣어두었습니다.

## Table of Contents

> Module Federation은 서버, 클라이언트 모두에서 자바스크립트 애플리케이션을 다른 번들/빌드로 부터 코드를 다이나믹하게 실행해준다.

이는 자바스크립트 번들러를 아폴로가 GraphQL에서 하는 것과 동일한 기능을 할 수 있게 해준다. (근데 내가 안써봐서 모름)

서로 독립된 애플리케이션 간에 코드를 공유할 수 있는 확장 가능한 솔루션은 여지껏 편리하지 않았으며, 확장은 불가능에 가까웠다. 코드를 공유하는 것도 번거롭고, 실제로 애플리케이션은 독립적이지도 않았으며, 종속성 또한 제한되어 있었다. 또한 실제 코드 형상이나 컴포넌트를 별도로 묶은 애플리케이션 간 공유는 불가능에 가까웠고, 비생산적이었으며, 수익성이 없었다.

Module Federation은 자바스크립트 애플리케이션이 다른 애플리케이션에서 동적으로 코드를 불러오고, 그 과정에서 종속성을 가질 수 있도록 허용한다. 만약 모듈을 사용하는 애플리케이션이 Module Federation에서 필요로 하는 종속성을 가지고 있지 않다면, 웹팩은 Module Entry Point에서 누락된 종속성을 다운로드 할 것이다.

코드는 가능하면 공유되지만, fallback은 각각의 케이스에 별도로 존재한다. Federated된 코드는 항상 종속성을 불러올수 있지만, 더 많은 페이로드를 다운로드 하기전에 사용하는 측의 종속성을 사용하려고 시도한다. 이말은, 획일적인 웹팩의 빌드 처럼 코드 중복과 의존성 공유가 적다는 것을 의미한다.

### 용어

- Module Federation: Apollo GraphQL federation 과 같은 개념을, 자바스크립트 모듈에 녹였다고 보면 된다. 브라우저와 node에서 사용가능하다.
- Host: 첫 페이지 로딩을 담당하는 웹팩 빌드 (`onLoadEvent`를 트리거하는)
- Remote: host에 의해 사용되는 다른 웹팩 빌드, host의 일부다.
- Bi-directional hosts: 번들 또는 웹팩 빌드가 호스트 또는 리모트로 작동할 수 있는 때. 런타임시에 각각 서로를 실행할 수 있다.

애플리케이션은 bi-directional host가 될 수 있다. 즉, 어떤 애플리케이션이든 최초에 로딩된다면, host가 될 수 있다. 예를 들어, 애플리케이션에서 라우팅이 바뀌거나 다른 페이지로 이동할 경우, federated된 모듈을 불러오게 되는데, 이는 dynamic import와 마찬가지로 동작하게 된다. 만약에 이동한 페이지에서 새로고침한다면, 그 지점이 host가 된다.

정리해서 예를 들어보자.

웹 애플리케이션에서 home 페이지에 들어갔다면, 이는 host가 된다. 만약 about 페이지로 간다면, host는 별도로 독립된 애플리케이션(about)을 동적으로 임포트 하게 된다. 이는 메인 entry point나 전체 애플리케이션을 로딩하는 것이 아니다. 단지 몇 kb 코드만 불러올 뿐이다. 만약 현재 상태에서 새로고침을 하면 about 페이지는 host가 되고, 뒤로가기를 시도할 경우 앞서 host였던 home을 remote로 불러오게 된다. 모든 애플리케이션은 리모트나 호스트가 될 수 있으며, 다른 federated된 모듈에 의해 실행 될 수 있다.

## federated application 만들어보기

`./src/App`을 `app_one_remote`라고 선언하였다. 이는 다른 애플리케이션에서 실행될 수 있다.

```javascript
const HtmlWebpackPlugin = require('html-webpack-plugin')
const ModuleFederationPlugin = require('webpack/lib/container/ModuleFederationPlugin')

module.exports = {
  // other webpack configs...
  plugins: [
    new ModuleFederationPlugin({
      name: 'app_one_remote',
      remotes: {
        app_two: 'app_two_remote',
        app_three: 'app_three_remote',
      },
      exposes: {
        AppContainer: './src/App',
      },
      shared: ['react', 'react-dom', 'react-router-dom'],
    }),
    new HtmlWebpackPlugin({
      template: './public/index.html',
      chunks: ['main'],
    }),
  ],
}
```

애플리케이션 헤드에, `app_one_remote.js`를 불러오도록 했다. 이렇게 하면 다른 웹팩 런타임에 연결되고, 런타임에 오케이스트레이션 계층을 프로비저닝 할 수 있다. 이는 특별히 설계된 웹팩 런타임과 진입점이다. 이는 일반적인 애플리케이션 진입점과 다르게, 몇 kb에 불과하다.

```html
<head>
  <script src="http://localhost:3002/app_one_remote.js"></script>
  <script src="http://localhost:3003/app_two_remote.js"></script>
</head>
<body>
  <div id="root"></div>
</body>
```

`App One`에서 `App Two`에 있는 코드를 사용하고 싶다면,

```javascript
const Dialog = React.lazy(() => import('app_two_remote/Dialog'))

const Page1 = () => {
  return (
    <div>
      <h1>Page 1</h1>
      <React.Suspense fallback="Loading Material UI Dialog...">
        <Dialog />
      </React.Suspense>
    </div>
  )
}

export default Page1
```

라우터는 일반적인 표준과 비슷하다.

```javascript
import { Route, Switch } from 'react-router-dom'

import Page1 from './pages/page1'
import Page2 from './pages/page2'
import React from 'react'

const Routes = () => (
  <Switch>
    <Route path="/page1">
      <Page1 />
    </Route>
    <Route path="/page2">
      <Page2 />
    </Route>
  </Switch>
)

export default Routes
```

App Two에서는 Dialog를 내보낼 것이며, 이는 위에서 봤던 것 처럼 App One에서 사용한다.

```javascript
const HtmlWebpackPlugin = require('html-webpack-plugin')
const ModuleFederationPlugin = require('webpack/lib/container/ModuleFederationPlugin')
module.exports = {
  plugins: [
    new ModuleFederationPlugin({
      name: 'app_two_remote',
      filename: 'remoteEntry.js',
      exposes: {
        Dialog: './src/Dialog',
      },
      remotes: {
        app_one: 'app_one_remote',
      },
      shared: ['react', 'react-dom', 'react-router-dom'],
    }),
    new HtmlWebpackPlugin({
      template: './public/index.html',
      chunks: ['main'],
    }),
  ],
}
```

루트 앱은 이런 모양이다.

```javascript
import React from 'react'
import Routes from './Routes'
const AppContainer = React.lazy(() => import('app_one_remote/AppContainer'))

const App = () => {
  return (
    <div>
      <React.Suspense fallback="Loading App Container from Host">
        <AppContainer routes={Routes} />
      </React.Suspense>
    </div>
  )
}

export default App
```

```javascript
import React from 'react'
import { ThemeProvider } from '@material-ui/core'
import { theme } from './theme'
import Dialog from './Dialog'

function MainPage() {
  return (
    <ThemeProvider theme={theme}>
      <div>
        <h1>Material UI App</h1>
        <Dialog />
      </div>
    </ThemeProvider>
  )
}

export default MainPage
```

`App Three`의 경우, `<App>`에서 실행되는 것이 없이 독립되어 있으므로, 아래와 같이 처리하면 된다.

```javascript
new ModuleFederationPlugin({
  name: "app_three_remote",
  library: { type: "var", name: "app_three_remote" },
  filename: "remoteEntry.js",
  exposes: {
    Button: "./src/Button"
  },
  shared: ["react", "react-dom"]
}),
```

트위터에 제작자가 공유해준 실제 코드를 살펴보자.

네트워크 탭을 살펴보면, 세 코드가 모두 다른 번들에 존재하고 있음을 알 수 있다.

의존성 중복이 존재하지 않는다. `shared` 옵션에 나와있듯, `remote`는 `host`의 의존성에 의존하게 된다. 만약 호스트에 해당 의존성이 존재하지 않는다면, 리모트는 알아서 다운로드 할 것이다.

`vendor`나 다른 모듈을 `shared`에 추가하는 것은 확장성에 그다지 좋지 못하다. `AutomaticModuleFederationPlugin`를 제공하여, 웹팩 코어 외부에 있는 코드들을 관리할 수 있도록 할 것이다.

## Server Side Rendering

Module Federation은 브라우저 node 모든 환경에서 동작한다. 단지 서버 빌드가 commonjs 라이브러리 타겟을 사용하기만 하면 된다.

```javascript
module.exports = {
  plugins: [
    new ModuleFederationPlugin({
      name: 'container',
      library: { type: 'commonjs-module' },
      filename: 'container.js',
      remotes: {
        containerB: '../1-container-full/container.js',
      },
      shared: ['react'],
    }),
  ],
}
```

Module Federation에 대한 다양한 예제를 아래에서 살펴볼 수 있다.

- https://github.com/module-federation/module-federation-examples
- https://github.com/module-federation/next-webpack-5
- https://github.com/ScriptedAlchemy/mfe-webpack-demo
- https://github.com/ScriptedAlchemy/webpack-external-import

> 결과적으로 하나의 큰 애플리케이션을 여러개의 독립된 애플리케이션으로 만든 다음, 다이나믹 로딩을 하듯이 필요한 순간에 필요한 컴포넌트 (소스)를 불러오게 한다는 개념인 것 같다. webpack5 에 포함될 예정이라고 하니, 정식 출시 될 때 실제 동작하는 예제를 만들어보고 고민해봐야겠다.


자바스크립트 아키텍쳐의 게임체인저라고 하는데, 과연 그렇게 될 수 있을까?

Webpack Module Federation에 대해 알아보자

전 회사에서 자체적으로 만든 `eslint-config-***`를 쓰고 있었는데, private 레파지토리에 있어서 내 public 레파지토리에 적용해서 쓰는데에 어려움이 있었다. 1년간 쓰면서 자체적으로 정한 규칙도 맘에 들었고, 만들어 주신 분께서 꽤나 많은 공을 쏟아 주셔서 정말 잘 쓸 수 있었다. 그래서 이와 거의 흡사한 룰을 가진 나만의 `eslint-config-yceffort` 를 만들어서 써보기로 했다. 룰은 물론 거의 비슷하지만, 갖다 배낄 수는 없는 노릇이고 - 이미 퇴사해서 코드는 없으므로 기억나는 룰을 최대한 비슷하게 맞춰보았다.

## 1. eslint-config-\*\*\* 만드는 법

만드는 방법은 https://tech.kakao.com/2019/12/05/make-better-use-of-eslint/ 여기에 잘나와 있어서 따로 자세히 포스팅 하지 않으려고 한다. 분명히 예전에 다닐 때는 저런게 없었던 것 같은데 🤔 어느 틈엔가 만들어 쓰고 있었나보다.

## 2. github npm registry를 쓰고 싶었지만...

github의 리치한 대부분의 기능, 단순 소스 관리 부터 workflows 에 이르기 까지 모든 기능들을 쓰는데 심취하면서, 이 package registry 까지 github에서 사용해보고 싶었다. https://github.com/features/packages

결론부터 말하자면 그러지 못했다.

https://github.com/yceffort/eslint-config-yceffort/packages

패키지를 올리는 것은 꽤나 단순하지만, 사용하는 입장에서 `.npmrc`에 `registry`를 아래 처럼 별도로 등록해줘야 하는 허들이 있었다. https://docs.github.com/en/packages/using-github-packages-with-your-projects-ecosystem/configuring-npm-for-use-with-github-packages

```
registry=https://npm.pkg.github.comOWNER
@OWNER:registry=npm.pkg.github.com
@OWNER:registry=npm.pkg.github.com
```

어차피 나 밖에 쓸일이 없으므로 별다른 허들이 되지 않겠지만서도 (...) 매번 만드는 나의 레파지토리에 한단계라도 허들을 낮추고자 그냥 npm registry를 쓰기로 했다.

https://www.npmjs.com/package/eslint-config-yceffort

## 3. 버전 관리의 중요성

최초의 버전은 0.01 이었는데, 몇가지를 `README.md`에 잘못써서 그것만 따로 커밋 푸쉬했더니, github의 README와 npm의 READEME가 다른 사태가 발생했다.

- https://github.com/yceffort/eslint-config-yceffort
- https://www.npmjs.com/package/eslint-config-yceffort

허허~~

## 4. prettier의 일부 기능을 끄고 싶은데..

`mathjax`를 사용하기 위해서 `$$..$$` 문법을 쓰고 있는게 있었다. 근데 이걸 뭔가 계속 escape 처리를 해서.. 뭔가 수정할 방법이 있는 것 같은데 귀찮아서 다음으로 미뤘다.

## 5. 결론

https://www.npmjs.com/package/eslint-config-yceffort

많은 이용 부탁드립니다.


나만의 일관된 javascript code를 위하여 만들어보았습니다.

eslint-config-yceffort, 나만의 eslint-config 만들기

[이 글](https://mobx.js.org/getting-started.html)을 번역한 글입니다.

# MobX와 React를 위한 10분 소개글

## Table of Contents

## 핵심 아이디어

State는 각 애플리케이션의 핵심이며, 주변에 남아 있는 지역 변수와 일치하지 않는 상태 또는 상태를 생성하는 것만큼 관리 불가능한 버그를 만들 수 있는 더 빠른 방법은 없다. 따라서 많은 국가 관리 솔루션은 예를 들어 상태를 불변하게 함으로써 상태를 수정할 수 있는 방법을 제한하려고 한다. 그러나 이것은 새로운 문제를 야기시킨다; 데이터는 정규화되어야 하고, 참조 무결성은 더 이상 보장될 수 없으며, 프로토타입과 같은 강력한 개념을 사용하는 것은 거의 불가능해진다.

state(상태)는 애플리케이션의 핵심이자 동시에, 지역 변수와 일치하지 않는 상태를 만들거나, 상태 값이 관리 불가능해지는 등 각종 버그를 야기하는 문제점 이기도 하다. 따라서 많은 전역 상태 관리 솔루션은 상태 값을 불면하게 만들어서 상태를 수정할 수 있는 방법을 제한하려고 한다. (Immutable.js) 그러나 이는 또다른 문제를 만드는 원인이 되기도 한다. 데이터를 정규화 해야하고, 참조 무결성은 더잇아 보장되지 않으며, 프로토타입과 같은 강력한 기능을 사용하는 것은 더 이상 불가능해 진다.

MobX는 상태관리를 근본적인 문제를 다룸으로써 이러한 상태 관리 문제를 간단하게 한다. MobX에서는 즉 일관되지 않은 상태를 만드는 것을 막는다. 이를 달성하기 위한 전략은 간단하다. 자동적으로 애플리케이션 상태에서 파생될 수 있는 모든 것들이 파생되게 하는 것이다.

MobX는 애플리케이션을 마치 스프레드시트 (엑셀) 처럼 다룬다.

![MobX Overview](https://mobx.js.org/assets/getting-started-assets/overview.png)

1. 먼저, 애플리케이션에는 상태가 있다. 이러한 상태에는 오브젝트, 배열, 원시값, 참고 값등 애플리케이션 모델을 구성하는 것들이 존재한다. 그리고 이 값들은 애플리케이션의 '데이터 셀' 처럼 작동한다.
2. 두번째로, 파생이 있다. 기본적으로, 어떤 값들이든 애플리케이션의 상태에 따라서 자동으로 계산되어 진다. 이러한 파생 (또는 계산된 값) 들은 끝내지 못한 할일 수와 같은 단순한 숫자일 수도 있으며, 혹은 할일 목록을 나타내는 HTML 값이 될 수도 있다. 스프레드시트 용어를 빌리자면, 이들은 수식이자 애플리케이션의 차트가 될 수 있다.
3. 리액션은 파생과 매우 비슷하다. 이 둘의 핵심 차이점은 값을 따로 만들어내지 않는 다는 것이다. 그 대신, 무언가 다른 작업을 자동으로 수행한다. 보통 I/O와 관련된 작업을 수행한다. 이들은 DOM이 업데이트 되도록 하거나 또는 적절한 타이밍에 네트워크 요청을 하는 등의 작업을 한다.
4. 마지막으로 액션이 있다. 액션은 상태값을 바꾸는 것들을 말한다. Mobx는 액션으로 인한 애플리케이션 상태의 모든 변경사항이 자동으로 파생과 리액션에 의해 처리되도록 한다. 이는 동기식으로 이루어지며, 버그로부터 자유로울 수 있다.

## 간단한 할일 목록 예제

아래는 간단한 할일 목록을 보여주는 예제다. 보시다시피, 따로 MobX는 포함되어 있지 않다. `TodoStore`가 할일 목록을 가지고 있다.

```javascript
class TodoStore {
  todos = []

  get completedTodosCount() {
    return this.todos.filter((todo) => todo.completed === true).length
  }

  report() {
    if (this.todos.length === 0) return '<none>'
    const nextTodo = this.todos.find((todo) => todo.completed === false)
    return (
      `Next todo: "${nextTodo ? nextTodo.task : '<none>'}". ` +
      `Progress: ${this.completedTodosCount}/${this.todos.length}`
    )
  }

  addTodo(task) {
    this.todos.push({
      task: task,
      completed: false,
      assignee: null,
    })
  }
}

const todoStore = new TodoStore()
```

`todos` 목록과 함께 `todoStore`를 만들었다. 이번에는 todoStore에 할일 목록을 넣어보자. 주목해야 할 것은, `report`는 항상 최초의 할일을 프린트 하도록 되어 있다는 것이다. 이것은 약간 인위적인 기능이지만, MobX의 기능을 이해하는데 있어서 유효한 예제다.

```javascript
todoStore.addTodo('read MobX tutorial')
console.log(todoStore.report())

todoStore.addTodo('try MobX')
console.log(todoStore.report())

todoStore.todos[0].completed = true
console.log(todoStore.report())

todoStore.todos[1].task = 'try MobX in own project'
console.log(todoStore.report())

todoStore.todos[0].task = 'grok MobX tutorial'
console.log(todoStore.report())
```

## 반응형으로 만들기.

아직까지, 코드에 특별한 것은 없다. 하지만 만약에 명시적으로 `report()`를 호출하는 대신에, 단지 상태값이 바뀔대 마다 자동으로 호출되게 할 수 있을까? 이는 `report()`에 영향을 미치는 코드를 호출하는 책임에 대해서 자유로워질 수 있다.

이러한 지점이 바로 MobX가 도움이 될 수 있는 부분이다. 상태에만 의존하는 코드를 자동으로 실행하게 해주자. 이는 스프레드시트의 차트처럼 `report`가 자동으로 업데이트 되도록 하는 것이다. 이를 위해, MobX가 TodoStore를 관찰 가능하도록 만들어야 한다.

또한 `completedTodosCount` 의 값은 할일 목록에서 자동으로 파생될 수 있다. `@observable`과 `@computed` 데코레이터를 사용하면 가능하다.

```javascript
class ObservableTodoStore {
  @observable todos = []
  @observable pendingRequests = 0

  constructor() {
    mobx.autorun(() => console.log(this.report))
  }

  @computed get completedTodosCount() {
    return this.todos.filter((todo) => todo.completed === true).length
  }

  @computed get report() {
    if (this.todos.length === 0) return '<none>'
    const nextTodo = this.todos.find((todo) => todo.completed === false)
    return (
      `Next todo: "${nextTodo ? nextTodo.task : '<none>'}". ` +
      `Progress: ${this.completedTodosCount}/${this.todos.length}`
    )
  }

  addTodo(task) {
    this.todos.push({
      task: task,
      completed: false,
      assignee: null,
    })
  }
}

const observableTodoStore = new ObservableTodoStore()
```

이것이 전부다. 일부 속성을 `@observable`하게 만들어서, MobX가 해당 값이 변화할 때마다 추적하도록 한다. `@computed`는 이러한 변화한 상태에 따라서 자동으로 값이 계산되도록 한다.

`pendingRequests`와 `assignee`는 아직 사용되고 있지 않지만, 이후 튜토리얼에서 사용 될 것이다. 간결하게 코딩하기 위하여 이 예제에서는 ES6, JSX, 그리고 데코레이터를 사용한다. 그리고 모든 데코레이터들은 이 대신 사용할 ES5 스펙의 기술들이 대응되어 있다.

`constructor`에서 `autorun`으로 감싼 `report`함수를 볼 수 있다. `Autorun`은 한번 실행되는 reaction을 만들어내며, 이는 함수 내부에서 사용된 관찰 가능한 데이터가 변경될 때마다 자동으로 실행된다. `report`는 관찰할 수 있는 `todos`를 사용하고 있기 때문에, 적절한 때에 자동으로 실행될 것이다.

```javascript
observableTodoStore.addTodo('read MobX tutorial')
observableTodoStore.addTodo('try MobX')
observableTodoStore.todos[0].completed = true
observableTodoStore.todos[1].task = 'try MobX in own project'
observableTodoStore.todos[0].task = 'grok MobX tutorial'
```

`report` 함수가 자동으로, 동기적으로, 그리고 중간에 값을 유출하지 않는 형태로 프린트 하는 것을 볼 수 있다. 앞선 예제와는 다르게, 마지막 5번째 로그가 출력되지 않는 것을 볼 수 있다. 왜냐하면 실제로 단순히 이름을 변경한 경우이기 때문이다. 반면, 1번째 이름을 변경하게 되면, 해당 이름이 사용되고 있기 때문에 업데이트 되어 로그가 찍히는 것을 볼 수 있다. 이는 `Autorun`에서 `todos`배열 뿐만 아니라, 항목 내부의 개별 속성도 관찰하고 있음을 알 수 있다.

## 더욱 더 반응형으로 만들어보기

여기까지는 단순히 `report`를 단순하게 반응형으로 만들어 보았다. 이제는 동일한 스토어에 있는 사용자 인터페이스를 더욱더 반응형으로 만들어 볼 차례다. 반응형 컴포넌트는 (그 이름에도 불구하고) 즉시 반응하지 않는다. `mobx-react` 패키지의 `@observable` 데코레이터는 React 컴포넌트 렌더링 함수를 `autorun`으로 감써서, 컴포넌트를 자동으로 상태와 동기화되게 하여 이를 수정한다. 이는 개념적으로 우리가 이전에 했던 `report`와 다르지 않다.

아래 예제 코드는 리액트 컴포넌트를 정의한 예제이다. 여기에서 MobX는 오직 `@observable` 데코레이터만 사용되었다. 단순히 이것 만으로도 상태 값이 변할때마다 각 컴포넌트가 각각 다시 렌더링 하도록 하는데 충분하다. 더 이상 `setState`를 호출할 필요가 없으며, 또한 어떤 상태값 혹은 어떤 higher order component가 렌더링하는데 필요한지 알아낼 필요가 없다. 기본적으로, 모든 컴포넌트가 스마트 해진 것이다. 그리고 이들은 여전히 멍청한 기존방식대로 작성되어 있다.

```javascript
@observer
class TodoList extends React.Component {
  render() {
    const store = this.props.store
    return (
      <div>
        {store.report}
        <ul>
          {store.todos.map((todo, idx) => (
            <TodoView todo={todo} key={idx} />
          ))}
        </ul>
        {store.pendingRequests > 0 ? <marquee>Loading...</marquee> : null}
        <button onClick={this.onNewTodo}>New Todo</button>
        <small> (double-click a todo to edit)</small>
        <RenderCounter />
      </div>
    )
  }

  onNewTodo = () => {
    this.props.store.addTodo(prompt('Enter a new todo:', 'coffee plz'))
  }
}

@observer
class TodoView extends React.Component {
  render() {
    const todo = this.props.todo
    return (
      <li onDoubleClick={this.onRename}>
        <input
          type="checkbox"
          checked={todo.completed}
          onChange={this.onToggleCompleted}
        />
        {todo.task}
        {todo.assignee ? <small>{todo.assignee.name}</small> : null}
        <RenderCounter />
      </li>
    )
  }

  onToggleCompleted = () => {
    const todo = this.props.todo
    todo.completed = !todo.completed
  }

  onRename = () => {
    const todo = this.props.todo
    todo.task = prompt('Task name', todo.task) || todo.task
  }
}

ReactDOM.render(
  <TodoList store={observableTodoStore} />,
  document.getElementById('reactjs-app'),
)
```

```javascript
const store = observableTodoStore
store.todos[0].completed = !store.todos[0].completed
store.todos[1].task = 'Random todo ' + Math.random()
store.todos.push({ task: 'Find a fine cheese', completed: true })
// etc etc.. add your own statements here...
```

## 참조된 값과의 작동

지금까지는 단순히 원시값과 배열과 함께 작동되는 모습을 보았다. 하지만 참조값과 작동은 어떻게 될까? 아래의 예제를 살펴보자.

```javascript
const store = observableTodoStore
store.todos[0].completed = !store.todos[0].completed
store.todos[1].task = 'Random todo ' + Math.random()
store.todos.push({ task: 'Find a fine cheese', completed: true })
// etc etc.. add your own statements here...
```

이제 두개의 독립된 store를 갖게 되었다. 하나는 `people`이고 다른 하나는 `todos`다. `assignee`에 `people` store에 있는 값을 할당하기 위해, 단순히 참조값을 할당하였다. 이러한 변화는 자동으로 `TodoView`에 반영된다. MobX에서는, 컴포넌트를 업데이트하기 위하여 더 이상 자료형을 정규화할 필요가 없다. 사실, 데이터가 어디에 있든지 상관없다. 객체가 `observable`한 이상, MobX는 이를 실시간으로 추적하게 된다.

```html
<input onkeyup="peopleStore[1].name = event.target.value" />
```

## 비동기 액션

todo 애플리케이션은 모든 것이 상태에서 파생되기 때문에, 상태가 언제 어떻게 바뀌는지는 정말 문제가 되지 않는다. 이는 비동기 작업을 매우 쉽게 만든다.

코드는 매우 직관적이다. `pendingRequests`값을 업데이트 하게 되면, 이는 바로 UI의 상태 값에 반영된다. 그리고 로딩이 끝나게 되면, 해당 값을 다시 줄이게 된다.

```javascript
observableTodoStore.pendingRequests++
setTimeout(function () {
  observableTodoStore.addTodo('Random Todo ' + Math.random())
  observableTodoStore.pendingRequests--
}, 2000)
```

## 결론

이것이 전부다. 특별한 보일러플레이트는 필요치 않다. 우리는 UI를 완성시키기 위해 단순히 간단한 선언적인 컴포넌트를 만들었다. 이들은 상태값으로 부터 자동적으로 파생되고, 반응하게 된다. 지금까지 배운것을 요약하면 다음과 같다.

1.  `@observable` 데코레이터 또는 `observable`을 사용하여 MobX가 해당 객체를 추적가능하게 한다.
2.  `@computed` 데코레이터를 사용하여 자동으로 상태값으로 부터 값이 계산되는 함수를 만든다.
3.  `autorun`은 의존하고 있는 `observable`한 값이 변경 될때 마다 자동으로 실행되는 함수다. 이는 로깅, 네트워크 요청 등을 처리할 때 유용하다.
4.  `mobx-react`의 `@observer`를 사용하여 리액트 컴포넌트를 반응형으로 반들 수 있다. 이는 자동적으로 그리고 효율적으로 컴포넌트를 업데이트 한다. 이는 매우 크고 복잡한 데이터를 다루는 애플리케이션에서도 유용하다.

## MobX는 상태 컨테이너가 아니다.

사람들은 종종 MobX를 Redux의 대체재로 생각하고는 한다. MobX는 그러나 단순히 기술적인 문제를 풀기 위한 라이브러리이며, 상태 컨테이너 그 자체 또는 새로운 아키텍쳐가 절대 아니다. 그런 의미에서 위의 예제들이 고안되었으며, 로직의 컵슐화, 스토어 또는 컨트롤러 등의 정리등은 적절한 엔지니어링 관행을 사용하는 것이 좋다.


Javascript 27

useCallback 사용 가이드

Referer와 Referer-Policy를 위한 가이드

Webpack Module Federation에 대해 알아보자

eslint-config-yceffort, 나만의 eslint-config 만들기

MobX를 공부하자 (4) - React와 Mobx의 10분 요약 글