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


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

[원본](https://mobx.js.org/intro/concepts.html)

# 개념과 원칙

## Table of Contents

## 개념

### 1. 상태 (State)

상태란 애플리케이션에서 파생되는 값이다. 일반적으로, 할일 목록 같은 도메인별 상태와 현재 선택된 엘리먼트를 나타내는 뷰 상태가 있다.

### 2. 파생 (Derivations)

더이상의 추가적인 상호작용없이, 상태에서 파생되어지는 값을 모두 파생 (Derivations) 이라고 한다.

> 최종적인 interaction 끝에 만들어진 값을 derivations 이라고 하는 것 같습니다.

여기서 Derivations은 다양한 것이 될 수 있다.

- 유저 인터페이스
- 남은 할일 숫자와 같이 파생되어진 데이터
- 서버에서 전송해온 백엔드 데이터

MobX는 derivations을 두종류로 구분한다.

- Computed values(계산된 값): 순수함수를 활용하여 현재 observable을 하고 있는 값들로 부터 계산되는 값
- Reaction: 상태가 바뀌면 자동으로 일어나야 하는 부수 효과. 이것은 명령형 프로그래밍과 반응형 프로그래밍 사이의 가교로서 필요하다. 이해를 더 쉽게 하기 위해서, I/O를 달성하기 위한 도구로써도 필요하다.

MobX를 처음 사용하는 초심자들은, 리액션을 너무 자주 사용하는 경향이 있다. 중요한 것은 바로 이것이다: **현재 상태를 기반으로 값을 계산하고 싶다면 `computed`를 활용하라.**

스프레드시트와 유사하게, 스프레드시트에서의 수식은 값을 계산해서 파생된 값이다. 그러나 사용자로서, 그러한 파생을 볼 수 있으려면 GUI의 일부를 다시페인팅 하는등의 리액션이 필요하다.

### 3. 액션 (Actions)

액션은 상태를 변화시키는 모든 코드 조각을 의미한다. 사용자 이벤트, 백엔드 데이터, 예약된 이벤트 등 액션은 스프레드시트 셀에 새 값을 입력하는 동작과 같다.

액션은 MobX에 명시적으로 정의되어있어서, 코드를 보다 명확하게 구성할 수 있다. MobX가 엄격모드로 동작될경우, MobX는 어떤 상태도 외부 액션으로 수정할 수 없도록 강제될 것이다.

## 원칙

MobX는 액션이 상태를 변경하는 단방향 데이터 흐름을 지원하고, 이에 영향을 받는 모든 뷰를 업데이트 한다.

![MobX Principles](https://mobx.js.org/assets/action-state-view.png)

- 모든 파생은 상태가 변경될때 자동으로 한번에 업데이트 된다. 따라서 중간에 값을 관찰하는 것은 불가능하다.
- 모든 파생은 기본적으로 동기로 업데이트 된다. 예를 들어, 액션을 통해 상태를 변경한 후, computed value를 직접 검사할 수 있다는 것을 의미한다.
- computed values는 게으르게 업데이트 된다. 현재 사용되지 않은 computed value는 부수효과에 필요할 때 까지 업데이트 되지 않는다. 만약 뷰에서 더이상 사용되지 않으면, 자동으로 가비지 콜렉팅 된다.
- 모든 computed values는 순수해야 한다. 이러한 값들이 상태를 바꾸면 안된다.

## 코드 예제

아래 예제는 위에서 언급한 기본 개념과 원칙을 묘사하고 있다.

```jsx
import { observable, autorun } from 'mobx'

var todoStore = observable({
  /* 관찰의 대상이되는 state */
  todos: [],

  /* 관찰의 대상에서 파생된 값 */
  get completedCount() {
    return this.todos.filter((todo) => todo.completed).length
  },
})

/* 상태값을 관찰하는 함수 */
autorun(function () {
  console.log(
    'Completed %d of %d items',
    todoStore.completedCount,
    todoStore.todos.length,
  )
})

/* 상태값을 수정하는 액션 */
todoStore.todos[0] = {
  title: 'Take a walk',
  completed: false,
}
// -> 동기적으로 콘솔에 로그를 찍는다. 'Completed 0 of 1 items'

todoStore.todos[0].completed = true
// -> 동기적으로 콘솔에 로그를 찍는다. 'Completed 1 of 1 items'
```


MobX 1페이지 요약에 대한 간단한 번역

MobX를 공부하자 (3) - 기본 개념과 원칙

## MobX 실제로 적용해보기

```jsx
import React, { Component } from "react";

import { observable } from "mobx";
import { observer } from "mobx-react";

// @observer 데코레이터가 장착되어 있는 리액트 컴포넌트는 
// @observable로 되어 있는 모든 것들을 rendering 하는 와중에 사용한다.
@observer
class Counter extends Component {
  // @observable 은 @obsever컴포넌트에게 변화를 감시해야 하는 값을 알려준다.
  @observable count = 0;

  handleDec = () => {
    this.count--;
  };

  handleInc = () => {
    this.count++;
  };

  render() {
    return (
      <div>
        Counter: {this.count} <br />
        <button onClick={this.handleDec}>-</button>
        <button onClick={this.handleInc}>+</button>
      </div>
    );
  }
}

export default Counter;
```

https://codesandbox.io/embed/mobx-9z6dh?fontsize=14&hidenavigation=1&theme=dark


위 state를 상위 컴포넌트에서 props로 던지는 방식으로 바꿔보았다.

```jsx
import React, { Component } from "react";
import ReactDOM from "react-dom";

import { observable } from "mobx";
import { observer } from "mobx-react";

const appState = observable({
  count: 0
});

appState.increment = function () {
  this.count++;
};

appState.decrement = function () {
  this.count--;
};

@observer
class Counter extends Component {
  render() {
    return (
      <div>
        Counter: {this.props.store.count} <br />
        <button onClick={this.handleInc}>+</button>
        <button onClick={this.handleDsc}>-</button>
      </div>
    );
  }

  handleInc = () => {
    this.props.store.increment();
  };

  handleDsc = () => {
    this.props.store.decrement();
  };
}

const rootElement = document.getElementById("root");
ReactDOM.render(
  <React.StrictMode>
    <Counter store={appState} />
  </React.StrictMode>,
  rootElement
);
```

![mobx1](./images/mobx1.png)

[mobx devtools](https://github.com/mobxjs/mobx-devtools)을 활용하면, state 값에 대한 디버그도 할 수 있다.

```jsx
import { observable, computed } from "mobx";
import React from "react";
import ReactDOM from "react-dom";
import { observer } from "mobx-react"; 

const t = new class Temperature {
  // 온도 단위와 온도를 추적
  @observable unit = "C";
  @observable temperatureCelsius = 25;

  @computed get temperatureKelvin() {
    console.log("calculating Kelvin");
    return this.temperatureCelsius * (9 / 5) + 32;
  }

  @computed get temperatureFahrenheit() {
    console.log("calculating Fahrenheit");
    return this.temperatureCelsius + 273.15;
  }

  // observable의 값이 바뀔 때마다, 자동으로 변경된 값을 리턴 (엑셀 처럼!)
  @computed get temperature() {
    console.log("calculating temperature");
    switch (this.unit) {
      case "K":
        return this.temperatureKelvin + "K";
      case "F":
        return this.temperatureFahrenheit + "F";
      case "C":
        return this.temperatureCelsius + "C";
      default:
        throw new Error("Unexpected unit.");
    }
  }
};

const App = observer(({ temperature }) => 
  <div>
    {temperature.temperature} <br/>
    <button onClick={() => temperature.unit = 'F'}>F</button>
    <button onClick={() => temperature.unit = 'K'}>K</button>
    <button onClick={() => temperature.unit = 'C'}>C</button>
  </div>
);

ReactDOM.render(<App temperature={t} />, document.getElementById("root"));
```

데코레이터를 사용하지 않고, 마찬가지로  `observable`만 사용해서 똑같이 구현할 수 있다.

```jsx
import { observable } from "mobx";
import React from "react";
import ReactDOM from "react-dom";
import { observer } from "mobx-react";

const t = observable({
  unit: "C",
  temperatureCelsius: 25,
  temperatureKelvin: function () {
    console.log("calculating Kelvin");
    return this.temperatureCelsius * (9 / 5) + 32;
  },
  temperatureFahrenheit: function () {
    console.log("calculating Fahrenheit");
    return this.temperatureCelsius + 273.15;
  },
  temperature: function () {
    console.log("calculating temperature");
    switch (this.unit) {
      case "K":
        return this.temperatureKelvin() + "K";
      case "F":
        return this.temperatureFahrenheit() + "F";
      case "C":
        return this.temperatureCelsius + "C";
      default:
        throw new Error("Unexpected unit.");
    }
  }
});

const App = observer(({ temperature }) => (
  <div>
    {temperature.temperature()} <br />
    <button onClick={() => (temperature.unit = "F")}>F</button>
    <button onClick={() => (temperature.unit = "K")}>K</button>
    <button onClick={() => (temperature.unit = "C")}>C</button>
  </div>
));

ReactDOM.render(<App temperature={t} />, document.getElementById("root"));
```

array도 observable이 가능하다. 다만, 이전 포스트에서 얘기 한 것처럼, 진짜 자바스크립트의 array와는 다른 측면이 있기 때문에 처리에 주의 해야 한다.

```jsx
import { observable, computed, action, asMap } from "mobx";
import React from "react";
import ReactDOM from "react-dom";
import { observer } from "mobx-react";

class Temperature {
  id = Math.random();
  // 온도 단위와 온도를 추적
  @observable unit = "C";
  @observable temperatureCelsius = 25;

  @computed get temperatureKelvin() {
    console.log("calculating Kelvin");
    return this.temperatureCelsius * (9 / 5) + 32;
  }

  @computed get temperatureFahrenheit() {
    console.log("calculating Fahrenheit");
    return this.temperatureCelsius + 273.15;
  }

  // observable의 값이 바뀔 때마다, 자동으로 변경된 값을 리턴 (엑셀 처럼!)
  @computed get temperature() {
    console.log("calculating temperature");
    switch (this.unit) {
      case "K":
        return this.temperatureKelvin + "K";
      case "F":
        return this.temperatureFahrenheit + "F";
      case "C":
        return this.temperatureCelsius + "C";
      default:
        throw new Error("Unexpected unit.");
    }
  }

  // action을 정의할 수 있다.
  @action
  setUnit(newUnit) {
    this.unit = newUnit;
  }

  @action
  setCelsius(degrees) {
    this.temperatureCelsius = degrees;
  }

  @action("update temperature and unit")
  setTemperatureAndUnit(degrees, unit) {
    this.setCelsius(degrees);
    this.setUnit(unit);
  }
}

// 일반적인 array도 가능하다.
// const temps = observable([]);
// temps.push(new Temperature());
// temps.push(new Temperature());
// temps.push(new Temperature());

// array 선언
const temps = observable.map({
  Amsterdam: new Temperature(),
  Rome: new Temperature(),
  Seoul: new Temperature()
});

console.log(temps.entries());

const App = observer(({ temperatures }) => (
  <div>
   {* 진짜 javascript array와는 다르기 때문에 처리에 유의해야 한다. *}
   {* 참고: https://mobx.js.org/refguide/map.html *}
    {[...temperatures.entries()].map(([city, t]) => (
      <div key={t.id}>
        <div>
          ({city}) =&gt; {t.temperature}
        </div>
        <button onClick={() => t.setUnit("F")}>F</button>
        <button onClick={() => t.setUnit("K")}>K</button>
        <button onClick={() => t.setUnit("C")}>C</button>
      </div>
    ))}
  </div>
));

ReactDOM.render(<App temperatures={temps} />, document.getElementById("root"));
```

MobX를 예제 애플리케이션에 실제로 적용해보기

MobX를 공부하자 (2)

# MobX One Page Summary

[MobX One Page Summary](https://mobx.js.org/README.html)를 번역 및 요약 해보았습니다.

> derive는 적절한 단어가 생각이 안나서 '파생'으로 번역했습니다. 여기서 derive는 state(상태)를 변하게 하는 액션을 의미합니다.

## Table of Contents

## MobX

간단하고, 확장 가능한 상태 관리

## 설치

- 설치
  - 일반: `npm install mobx --save`
  - 리액트: `npm install mobx-react --save`
- CDN:
  - https://unpkg.com/mobx/lib/mobx.umd.js
  - https://cdnjs.com/libraries/mobx

## 브라우저 지원

- 버전 5이상 부터는 [ES6 proxy를 지원하는 모든 브라우저](https://kangax.github.io/compat-table/es6/#test-Proxy)에서 실행 가능하다. IE11, nodejs 6 미만 오래된 자바스크립트 코어를 가진 리액트 네이티브 안드로이드 등에서는 오류가 날 것이다.
- 버전 4는 모든 ES5를 지원하는 브라우저에서 동작하며, 계속해서 유지보수 될 것이다. 4와 5의 api 스펙은 동일하지만, 그러나 4에서는 [몇몇 제한](https://mobx.js.org/README.html#mobx-4-vs-mobx-5)이 있다.

> MobX 5 패키지의 진입지점에서는 모든 빌드 도구와의 역호환성을 위하여 ES5 코드가 함께 제공된다. 그러나 위에서 언급했던 것 처럼, 어차피 MobX 5는 모던 브라우저에서만 작동하므로 더빠르고 가벼운 빌드를 위해서 아래와 같은 웹팩 alias를 추가하기를 권한다.

```javascript
resolve: {
  alias: {
    mobx: __dirname + '/node_modules/mobx/lib/mobx.es6.js'
  }
}
```

## 참고해 볼 만한 것들

- https://egghead.io/courses/manage-complex-state-in-react-apps-with-mobx
- https://mobx.js.org/getting-started
- https://github.com/mobxjs/awesome-mobx#boilerplates
- https://github.com/mobxjs/awesome-mobx#related-projects-and-utilities
- https://github.com/mobxjs/awesome-mobx#awesome-mobx

## 소개

MobX는 함수형 반응형 프로그래밍을 적용하여 전역 상태 관리를 단순하고 확장 가능하게 만드는 라이브러리다. MobX의 철학은 간단하다.

> 애플리케이션 상태에서 파생될 수 있는 것은 모두 자동으로 파생되어야 한다.

![MobX-philosophy](https://mobx.js.org/assets/flow.png)

리액트와 MobX를 같이 쓰는 것은 매우 훌륭한 조합이다. 리액트는 렌더링 가능한 컴포넌트 트리를 변환하는 메커니즘을 바탕으로 애플리케이션 상태를 렌더링한다. MobX는 리액트가 사용하는 애플리케이션 상태를 저장하고, 업데이트 하는 메커니즘을 제공한다.

React와 MobX는 모두 애플리케이션 개발에서 발생하는 공통적인 문제에 대한 각각 고유한 최적의 해결책을 제공한다. 리액트는 비용이 많이드는 DOM 조작을 줄이기 위하여, 가장 DOM을 활용하여 UI를 최적으로 렌더링하는 메커니즘을 재공한다. MobX는 엄격하게 필요할 때만 업데이트 되고, 최신을 유지하는 반응형 가상 종속성 상태 그래프를 사용하여 애플리케이션 상태 값을 리액트 컴포넌트와 함께 최적으로 동기화 하는 메커니즘을 제공한다.

## 핵심 개념

MobX에는 몇가지 핵심 개념이 존재한다.

### Observable state (관찰 가능한 상태)

MobX는 객체, 배열, 클래스 인스턴스와 같은 기존 데이트 구조에 예측 가능한 기능을 추가한다. 이것은 단순히 @observable 데코레이터만 추가하면 된다.

```javascript
import { observable } from 'mobx'

class Todo {
  id = Math.random()
  @observable title = ''
  @observable finished = false
}
```

`observable`을 사용하는 것은 객체의 속성을 마치 스프레드시트 셀로 바꾸는 것과 같다. 이는 수정하면 다른 셀이 자동으로 재계산되거나, 그래프가 다시 렌더링 되거나, 다른 흥미로운 Reaction을 트리거할 수 있다. 스프레드시트 셀과 달리 `observable`한 값은 primitive한 값 뿐만 아니라, 참조 객체 및 배열도 될 수 있다.

만약 개발환경에서 데코레이터 문법을 지원하지 않는다면, [이 글](https://mobx.js.org/best/decorators.html)을 참조해봐도 좋다. 그게 아니라면 MobX는 데코레이터 문법을 지원하지 않아도 decorate 유틸리티를 활용해서 똑같이 구현할 수 있다. 대부분의 MobX 유저들은 데코레이터 문법을 선호하는데, 이는 데코레이터 문법이 조금더 간결하기 때문이다.

```javascript
import { decorate, observable } from 'mobx'

class Todo {
  id = Math.random()
  title = ''
  finished = false
}
decorate(Todo, {
  title: observable,
  finished: observable,
})
```

### Compute Values (자동 값 계산)

MobX를 활용하면, 관련 데이터가 수정될 때 자동으로 파생된 값을 정의할 수 있다. 이는 `@computed` 데코레이터나, 위에서 `observable`를 사용했다면, getter/setter 함수를 활용해서 구현할 수도 있다.

```javascript
class TodoList {
  @observable todos = []
  @computed get unfinishedTodoCount() {
    return this.todos.filter((todo) => !todo.finished).length
  }
}
```

MobX는 todo가 추가되너가 `finished` 값이 수정되면 `unfinishedTodoCount`를 자동으로 계산한다. 이는 마치 엑셀과 같은 스프레드시트 프로그램에서 자동으로 연산이 되는 것과 같다. 이들은 오로지 필요할 때만 자동으로 업데이트 된다.

### Reaction

Reaction은 Compute Values와 비슷하지만 값을 계산하는 대신 콘솔, 네트워크 요청, 리액트 컴포넌트 트리 업데이트 등 다른 부수효과를 만들어낸다. 간단히 말해, Reaction은 반응형과 명령형 프로그래밍 사이의 다리 같은 역할을 한다.

#### React Components

만약 리액트를 사용하고 있다면, `mobx-react` 패키지에 있는 [observer](http://mobxjs.github.io/mobx/refguide/observer-component.html) 함수/데코레이터를 추가하여 반응형 컴포넌트를 만들 수 있다.

```javascript
import React, { Component } from 'react'
import ReactDOM from 'react-dom'
import { observer } from 'mobx-react'

@observer
class TodoListView extends Component {
  render() {
    return (
      <div>
        <ul>
          {this.props.todoList.todos.map((todo) => (
            <TodoView todo={todo} key={todo.id} />
          ))}
        </ul>
        Tasks left: {this.props.todoList.unfinishedTodoCount}
      </div>
    )
  }
}

const TodoView = observer(({ todo }) => (
  <li>
    <input
      type="checkbox"
      checked={todo.finished}
      onClick={() => (todo.finished = !todo.finished)}
    />
    {todo.title}
  </li>
))

const store = new TodoList()
ReactDOM.render(
  <TodoListView todoList={store} />,
  document.getElementById('mount'),
)
```

`observer`는 리액트 컴포넌트를 렌더링하는 데이터의 파생 요소로 변환한다. MobX를 사용하면, 모든 컴포넌트들은 스마트하게 렌더링되지만, 멍청한 방식으로 정의된다. MobX는 오직 필요할 때만 컴포넌트를 다시 렌더링하며 그 이상도 그 이하의 작업도 하지 않는다. 따라서 위의 예제에서, `onClick`핸들러는 적절한 `TodoView`를 렌더링 하도록 강제하고, 오직 완료되지 않는 task 숫자가 변경된 경우에 한해서 만 `TodoLIstView`를 렌더링하게 된다. 그러나 `Tasks left` 라인을 삭제하거나 (혹은 다른 컴포넌트로 분리하거나) 하는 경우에는 `TodoListView`는 더이상 재 렌더링 되지 않는다.

#### Custom Reaction

사용자정의 Reaction은 상황에 맞게 [autorun](http://mobxjs.github.io/mobx/refguide/autorun.html) [reaction](http://mobxjs.github.io/mobx/refguide/reaction.html) [when]()를 사용하면 간단하게 만들 수 있다.

예를 들어 `autorun`을 아래와 같이 활용하면, `unfinishedTodoCount`값이 바뀔 때마다 로그를 찍는다.

```javascript
autorun(() => {
  console.log('Tasks left: ' + todos.unfinishedTodoCount)
})
```

### 무엇이 MobX에서 반응하게 하는가?

왜 `unfinishedTodoCount`가 바뀔 때마다 새로운 메시지가 출력될까?

> MobX는 실제로 추적하는 함수의 실행 중에 읽는 모든 관측가능한 속성에 대해서 반응한다.

더 자세한 내용을 알고 싶다면 [이 글](https://mobx.js.org/best/react.html)을 참고하면 된다.

### Actions

다른 flux 프레임워크와는 다르게, MobX에서는 사용자 이베트를 어떻게 처리해야하는지에 대한 의견이 분분하다.

- Flux와 같은 방식으로 처리하기
- RxJS를 활용
- `onClick`핸들러와 같은 가장 간단하고 직관적인 방식으로

결국 이 모든 것들은 한가지로 요약할 수 있다: 어떻게든 상태를 업데이트해야 한다.

상태를 업데이트 한 이후에, MobX는 효율적이고 결함이 없는 방식으로 나머지 동작을 처리한다. 따라서 아래와 같이 간단한 코드는 인터페이스를 자동으로 업데이트 하기에 충분하다.

이벤트를 트리거하거나, dispatcher를 호출하는 등의 기술적인 필요성은 존재하지 않는다. 리액트 컴포넌트는 결국 상태를 멋있게 표현하는 방식에 지나지 않는다. 이는 MobX가 관리하게 된다.

```javascript
store.todos.push(new Todo('Get Coffee'), new Todo('Write simpler code'))
store.todos[0].finished = true
```

그럼에도 불구하고, MobX에는 선택적으로 활용할 수 있는 빌트인 개념인 [action](https://mobx.js.org/refguide/action.html)을 활용할 수 있다. 비동기 액션을 처리하는 방법에 대해 알고 싶다면, 이 글을 읽어보는 것도 좋다. 이는 매우 쉽고, 코드를 더 잘 구성하고 언제 어디서 수정되어야 하는지에 대한 현명한 결정을 내리는데 도움을 준다.

## MobX: 간단하고, 확장가능한

MobX는 글로벌 상태 관리에 사용할 수 있는, 가장 방해요소가 적은 라이브러리다. 이는 MobX 접근 방식을 단순하게 할 뿐만 아니라, 확장성도 매우 뛰어나게 만든다.

### 클래스와 실제 참조 활용

MobX를 사용하면, 데이터를 정규화 할 필요가 없다. 이는 매우 복잡한 도메인 모델에서도 라이브러리를 적절하게 활용할 수 있다.

### 참조 무결성 보장

데이터는 정규화 될 필요가 없고, MobX는 자동으로 상태와 파생 간의 관계를 추적하기 때문에, 참조 무결성을 공짜로 얻을 수 있다. MobX는 상태를 추적해서, 참조자 중 하나가 바뀔 때마다 다시 렌더링하게 된다. 프로그래머는 컴포넌트에 영향을 미친다는 사실을 잊을 수도 있지만, MobX는 그렇지 않다.

### 간단한 액션은 관리를 쉽게 한다

위에서 설명했듯, MobX를 사용하면 상태를 수정하는 것은 매우 간단해진다. 단순히 의도를 코딩하면 된다. 나머지는 MobX가 알아서 한다.

### 효율적인 세밀한 관측

MobX는 애플리케이션의 모든 파생에 대한 그래프를 구축하여, 무결성을 방지하는데 필요한 최소한의 계산 수를 연산한다. "모든 파생" 이라는 것이 비싸게 들릴 수 있지만, 가상 파생 그래프를 구축하여 데이터를 상태와 동기화 시키는데 필요한 재조합수를 최소화 한다.

### 간편한 상호운용성

Mobx는 순수 자바스크립트 구조로 작동한다. 따라서 MobX가 작동하기 위해서 특정 라이브러리를 필요로 하지 않는다. 따라서 지금 사용하고 있는 다양한 라이브러리와도 호환된다. 같은 이류로 서버와 클라이언트, 리액트 네이티브 등에서도 활용가능하다. 이러한 결과 MobX를 사용할 때 다른 상태 관리 솔루션에 비해 새로운 개념을 덜 알아도 된다.

> 실제로 [dependencies에 아무것도 없다.](https://github.com/mobxjs/mobx/blob/6ec6499fb8b55a17fe65f42b14d1188fd7fa1ba1/package.json#L58)

## MobX 4와 5의 차이

위 두 버전의 차이는, 5에서는 속성값 추적을 위해서 `Proxies`를 활용했다는 것이다. 그 결과 MobX 5에서는 Proxy를 지원하는 브라우저에서만 사용할 수 있고, MobX는 ES5가 작동하는 모든 환경에서 사용 가능하다.

MobX4에서 유념해야할 한계점은

- Observable arrays는 진짜 array가 아니어서, `Array.isArray()`를 통과하지 못한다. 따라서 다른 써드 파티라이브러리에서 이를 활용하기 전에 `slice()`등을 활용할 필요가 있다.
- 기존 observable 객채에 속성을 추가하는 것은 자동으로 선택되지 않는다. 따라서 observable 맵을 활용하거나, 빌트인 유틸리티 함수를 활용해야 한다. [참고](https://mobx.js.org/refguide/object-api.html)


MobX를 공부하자 (1)

[이 글](https://redfin.engineering/node-modules-at-war-why-commonjs-and-es-modules-cant-get-along-9617135eeca1)을 번역 요약한 글입니다.

## CommonJS와 ES Modules은 왜 함께 할 수 없는가?

[노드14](https://nodejs.org/en/blog/release/v14.0.0/) 에서는 옛날 스타일의 CommonJS와 (이하 CJS) 새로운 스타일의 ESM Scripts (이하 MJS) 두개가 공존하고 있다. CJS의 경우 `require()`와 `module.exports`를 사용하며, ESM은 `import`와 `export`를 사용한다.

> 정확히는 ECMAScript Modules - Experimental Warning Removal 이다.

ESM과 CJS는 태생부터 완전히 다르다. 일단 겉으로 보기엔, ESM은 CJS와 비슷한 면이 있지만, 이를 구현한 것은 완전히 다르다. ESM에서 CJ를 서로 호출 할 수는 있지만, 꽤나 귀찮은 일이다. 

1. ESM에서는 `require()`를 사용할 수는 없다. 오로지 `import`만 가능하다.
2. CJS도 마찬가지로 `import`를 사용할 수는 없다.
3. ESM에서 CJS를 `import`하여 사용할 수 있다. 그러나 오로지 default import만 가능하다. `import _ from 'lodash'` 그러나 CJS가 named export를 사용하고 있다면 named import `import { shuffle } from 'lodash`와 같은 것은 불가능하다.
4. ESM을 CJS에서 `require()`로 가져올 수는 있다. 그러나 이는 별로 권장되지 않는다. 그 이유는 이를 사용하기 위해서는 더 많은 boilerplate가 필요하고, 최악의 경우 Webpack이나 Rollup 같은 번들러도 필요 하다. 그 이유는, ESM가 `require()`에서 어떻게 동작해야 하는지 모르기 때문이다.
5. CJS는 기본값으로 지정되어 있다. 따라서 ESM 모드를 사용하기 위해서는 opt-in해야 한다. `.js`를 `.mjs`로 바꾸거나, `package.json`에 `"type": "module"` 옵션을 넣는 방법이 있다. (기존에 CJS를 쓰던 것은 `.cjs`로 바꾸면 된다.)

이러한 규칙은 고통스럽다. 이는 다양한 유저들, 특히 노드 뉴비들에게는 이해하기 어려운 과정이다.

이러한 규칙들은 고통스럽지만(?) 그 규칙 나름대로 앞으로 살펴볼 이유가 있어, 미래에도 이러한 규칙을 어기기에는 매우 어려워 질 것이다. 이 아티클에서는 자바스크립트 라이브러리 작성자들을 위한 다음 세가지 유용한 정보를 제공할 것이다.

- 라이브러리를 CJS 버전으로 제공하기
- CJS 라이브러리에 ESM 래퍼를 씌우기
- package.json에 exports map을 추가하기

## CJS와 ESM은 무엇인가?

Nodejs 초창기에는, Node 모듈은 CommonJS 모듈로 작성되었다. 따라서 `require()`로 이들을 사용했다. 다른 개발자들이 이를 사용하게 하기 위해서, `exports`를 정의하거나 named exports라 불리우는 `module.exports.foo = 'bar`를 사용하거나, 기본 값으로 `module.exports = 'baz`를 사용하기도 했다.

다음은 named exports 의 예시다.

```javascript
// @filename: util.cjs
module.exports.sum = (x, y) => x + y;
// @filename: main.cjs
const {sum} = require('./util.cjs');
console.log(sum(2, 4));
```

다음은 default exports의 예시로, 따로 이름을 정해두지 않으면 default로 설정된다.

```javascript
// @filename: util.cjs
module.exports = (x, y) => x + y;
// @filename: main.cjs
const whateverWeWant = require('./util.cjs');
console.log(whateverWeWant(2, 4));
```

ESM 스크립트에서는, `import`와 `export`가 언어의 일부로 추가되었다. CJS와 비슷하게, named exports와 default exports를 지원하는 두가지 문법이 존재한다.

다음은 named exports 의 예시다.

```javascript
// @filename: util.mjs
export const sum = (x, y) => x + y;
// @filename: main.mjs
import {sum} from './util.mjs'
console.log(sum(2, 4));
```

다음은 default export의 예시다. CJS와 마찬가지로, 별도로 이름을 지정해두지 않아도 된다.

```javascript
// @filename: util.mjs
export default (x, y) => x + y;
// @filename: main.mjs
import whateverWeWant from './util.mjs'
console.log(whateverWeWant(2, 4));
```

## ESM과 CJS는 완전히 다르다.

CommonJS에서는 `require()`는 동기로 이루어진다. 따라서 promise나 콜백 호출을 리턴하지 않는다. `require()`는 디스크로 부터 읽어서 (네트워크 일수도 있다) 그 즉시 스크립트를 실행한다. 따라서 스스로 I/O나 부수효과 (side effect)를 실행하고 `module.exports`에 설정되어 있는 값을 리턴한다.

반면에 ESM은 모듈 로더를 비동기 환경에서 실행한다. 먼저 가져온 스크립트를 바로 실행하지 않고, `import`와 `export`구문을 찾아서 스크립트를 파싱한다. 파싱 단계에서, 실제로 ESM 로더는 종속성이 있는 코드를 실행하지 않고도도, named imports에 있는 오타를 깜지하여 에러를 발생시킬 수 있다.

그 다음 ESM 모듈 로더는 가져온 스크립트를 비동기로 다운로드 하여 파싱한다음, import된 스크립트를 가져오고, 더이상 import 할 것이 없어질 때까지 import를 찾은 다음 dependencies의 모듈 그래프를 만들어 낸다. 그리고, 스크립트는 실행될 준비를 마치게 되며, 그 스크립트에 의존하고 있는 스크립트들도 실행할 준비를 마치게 되고, 마침내 실행된다.

ESM 모듈 내의 모든 자식 스크립트들은 병렬로 다운로드 되지만, 실행은 순차적으로 진행된다.

## CJS는 기본 값이다. 왜냐면 ESM은 바뀔게 넘 많아서

ESM은 자바스크립트의 많은 부분에 변경이 필요하다. ESM은 일단 기본 값으로 `use strict`가 설정되어 있어야하고, `this`는 global object를 참조하지 않고, 스코프는 다르게 작동 되는 등등 변화가 많다.

이것이 브라우저에서 조차 `<script>`가 ESM을 기본으로 지정하지 않는 이유다. ESM을 사용하기 위해서는 `type="module"`을 추가해 주어야 한다.

기본 값을 CJS에서 ESM으로 바꾸는 것은 호환성을 해치는 문제가 된다. (node의 대안으로 주목받고 있는 deno는 ESM을 기본값으로 사용하지만, 결과적으로 모든 생태계를 처음부터 다시 설계해야 했다.)

## 톱레벨에 존재하는 await 때문에 CJS는 ESM을 `require()`할 수 없다. 

CJS가 ESM을 `require()` 하지 못하는 가장 단순한 이유는, ESM는 top level에서 `await`을 할 수 있지만, CJS는 그렇지 못하기 때문이다. 여기서 말하는 [top-level await](https://v8.dev/features/top-level-await)은 `async function` 밖에서 `await`을 사용하게 해주는 것이다.

해당 V8 블로그 포스트 글을 인용하자면

> [이 gist](https://gist.github.com/Rich-Harris/0b6f317657f5167663b493c722647221)에서 top-level await에 대한 우려와 함께, 자바스크립트가 미래에 해당 기능을 구현하지 말하야 하는 이유에 대해 논의 한 적이 있다. 여기서 우려하는 사안은
> - top-level await은 코드 실행을 블로킹할 수 있다.
> - top-level await은 리소스를 가져오는 것을 블로킹할 수 있다.
> - commonjs에서 이를 명확히 구현할 수 없다.
> 그리고 이 3가지 문제점에 대해서, stage 3 제안에서 다음과 같이 언급한다.
> - siblings 코드가 실행 가능하므로, 결정적인 블로킹 포인트가 없다.
> - top-level await은 모듈 그래프의 실행 단계에서 이루어 진다. 이 지점에서는, 모든 리소스들이 이미 fetch 되고 링크 되어 있다. 따라서 리소스 fetch를 블로킹할 염려는 없다.
> - top-level await은 오로지 [ESM]에서만 논의 될 문제다. CommonJS 모듈에서는 이를 지원할 계획이 없다.

[ESM을 `require()` 하는 방법에 대한 논의가 이어지고는있지만,](https://github.com/nodejs/modules/issues/454) 빠른 시일 내에 이것이 실현 되기는 어려워 보인다.

## CJS는 ESM에서 `import`할 수는 있지만, 썩 훌륭해보이지는 않는다.

```javascript
(async () => {
    const {foo} = await import('./foo.mjs');
})();
```

## ESM은 cjs의 named exports를 import 할 수 없다.

이것은 가능하지만

```javascript
import _ from './lodash.cjs'
```

이것은 불가능하다.

```javascript
import {shuffle} from './lodash.cjs'
```

CJS는 named exports를 실행단계에서 연산하지만, ESM은 named exports를 파싱 단계에서 연산하기 때문이다.

다행히 이를 우회할 수 있는 방법은 있다.

```javascript
import _ from './lodash.cjs';
const {shuffle} = _;
```

> 하지만 이방법은 tree shaking이 되지 않으므로 번들링 시 사이즈가 커지게 된다.

그러나 이 방법이 순서까지도 보장해주는 것은 아니다.

```javascript
import liquor from 'liquor';
import beer from 'beer';
```

만약 `liquor` `beer`모두 cjs로 되어 있다면 그 순서가 반드시 `liquor`, `beer`가 되는 것은 아니다. `beer`가 `liquor`가 반드시 실행되어야 하는 상황이라면 더욱 문제가 커질 수 있다. 

## CJS와 ESM을 모두 지원하는 방법

### CJS 버전으로 라이브러리를 제공해라

이는 CJS 유저들에게도 친숙하고, 오래된 노드버전도 지원가능하다. 타입스크립트로 작성할 경우, JS > CJS로 트랜스파일하면 된다.

## CJS 라이브러리에 ESM 래퍼를 제공해라

```javascript
import cjsModule from '../index.js';
export const foo = cjsModule.foo;
```

ESM 래퍼를 `esm` 디렉토리에 두고, `package.json` 에  `{"type": "module"}` 을 추가하자. `.mjs`로 이름을 변경하는 것도 방법이지만, 일부 툴에서 제대로 작동하지 않으므로 별도의 디렉토리에 넣는 것을 선호한다.

트랜스파일링이 중복으로 되는 것을 피해야 한다. 만약 typescript에서 트랜스파일링한다면, 이를 CJS와 ESM 두개 모두로 트랜스파일링 할 수 있지만, 이는 사용자가 실수로 `import`하거나 `require`하는 일이 발생하게 된다.

### `package.json`에 `exports` 를 추가하라

```json
"exports": {
    "require": "./index.js",
    "import": "./esm/wrapper.js"
}
```

한가지 명심해야 할 것은, `exports`를 추가하는 것은 시멘틱 버저닝의 브레이킹 체인지 (메이저 버전 업)을 가져온다는 것이다. 그리고 항상 온전한 파일명 `index.js`가 들어가야 한다. `index` 나 `./build`가 들어가서는 안된다.

https://nodejs.org/api/esm.html#esm_package_entry_points



[이 글](https://redfin.engineering/node-modules-at-war-why-commonjs-and-es-modules-cant-get-along-9617135eeca1)을 번역 요약한 글입니다. ## CommonJS와 ES Modules은 왜 함께 할 수 없는가?  [노드14](https://nodejs.org/en/blog/r...

yceffort

javascript

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

MobX를 공부하자 (3) - 기본 개념과 원칙

MobX를 공부하자 (2)

MobX를 공부하자 (1)

CommonJS와 ES Modules은 왜 함께 할 수 없는가?