전 회사에서 자체적으로 만든 `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 만들기

```bash
GIT_COMMITTER_DATE="Tue Sep 15 2020 10:57:29 +0900" git commit --date="Tue Sep 15 2020 10:57:29 +0900"
```

주의: `git rebase`시 강제로 일시를 변경하기 때문에 꼬일 수 있음.

출처: https://stackoverflow.com/questions/454734/how-can-one-change-the-timestamp-of-an-old-commit-in-git


Git commit의 일시를 변경하기

블로그를 업데이트 했다. 업데이트를 하게 되면서 배운 점과 개선해 나가야할 점들에 대해서 간단히 요약해 본다.

## Table of Contents

## 시작

원래는 https://developer-diary.netlify.app/ 이 블로그를 커스터마이징해서 쓰고 있었다. 고를 때만 해도 꽤 괜찮아서 잘 쓰고 있었는데, 걔속 사용하다 보니 몇가지가 걸렸다. 제목과 부제목 사이의 간격이라던가, Tech Topics 아이콘 수집, 그리고 사이드 바의 간격 등... 몇가지를 계속해서 커스터마이징 하다보니 땜질식의 처방이 되고 있었고, 더 이상 무엇을 더 이쁘게 만들어야 할지 모르겠다는 생각에 까지 이르게 되자, 결국에는 모든 것을 갈아 엎고 새로 만들자는 생각에 이르게 되었다.

## 시작

### 1. 테마 선택

1. 최대한 깔끔해서 더 이상 손댈 것이 없을 것
2. 페이징을 지원할 것
3. SEO를 어느정도 지원할 것

그래서 선택한 블로그는 https://lumen-v2.netlify.app/ 다.

### 2. Github repository 이사

사실상 markdown 블로그 내용을 제외하고는 모든 것이 바뀌기 때문에, 기존 Repository를 archived 시키고, 새로운 Repository로 이동했다.

- 기존: https://github.com/yceffort/yceffort-blog
- 신규: https://github.com/yceffort/yceffort-blog-v2

### 3. FrontMatter 일괄 업데이트

frontmatter는 특정 페이지에만 쓰이는 변수를 최상단에 선언해 둔 것을 의미한다.

https://github.com/yceffort/yceffort-blog-v2/blob/master/content/posts/articles/2020/08/mobx-study-4.md

```yaml
---
title: MobX를 공부하자 (4) - React와 Mobx의 10분 요약 글
tags:
  - javascript
  - MobX
published: true
date: 2020-08-30 19:27:22
description: 'React와 MobX에 대한 10분 설명'
category: MobX
template: post
---

```

위의 내용이 frontmatter를 의미한다. 기존에는 frontmatter가 몇개 쓰이는 것 없이 깔끔했는데, 이 테마에는 제법 쓰이는 것이 많았다. 아래는 frontmatter에 대한 변경사항이다.

- tags, category등은 기존의 tags를 기준으로 사용하게 두었다.
- published: true 는 draft: false 와 동일하게 동작하도록 수정했다.
- slug는 기존 주소와 호환성을 위해 `/:year/:month/:file-name` 을 유지하도록 했다. slug가 없을 경우 디렉토리 구조에 따라서 파일명을 이전과 같이 설정한다.

frontmatter 에디팅을 위해서 nodejs로 .md 파일을 모두 읽어서 사용했으며, `fs`외에는 별도의 라이브러리를 사용하지 않았습니다. 파일을 line by line 으로 읽어서 `---` 내부의 내용을 읽어 왔다.

### 4. 이미지 경로 업데이트

과거 이미지들의 경우 이상하게 path설정을 해두거나, `static` 폴더에 두는 등 일관적이지 못한 문제가 있었는데, 이러한 문제를 수정했다. `![](.jpg|.png.jpeg)` 로 되어 있는 모든 파일을 읽어와서, 적절한 경로로 이미지로 이동하고, path를 수정했다.

### 5. 기타 블로그 커스터 마이징

블로그의 내용 일부를 커스터마이징했다. (리트윗 기능 제거, 일부 string 변경 등)

### 6. github action으로 CI 단계 추가

CI단계를 추가해서 배포전에 기본적인 코드 검사를 할 수 있도록 했다. https://github.com/yceffort/yceffort-blog-v2/blob/master/.github/workflows/ci.yaml 기본적인 빌드 뿐만 아니라, 다음 포스팅에서 언급할 `eslint-config-yceffort`를 활용해서 `lint`와 `prettier`도 동시에 체크한다.

### 7. heroku에서 vercel로

과거 블로그 서빙을 위해서 heroku를 사용했다. 사이트가 점차 비대해지면서 무료 버전으로 감당이 안되기 시작했고, 이에 `production` 버전으로 업그레이드 해서 매달 25달러 씩 주고 유지했다. https://www.heroku.com/pricing

최근 vercel을 눈여겨보면서 (nextjs 덕분!) vercel로 갈아타기로 결심 했고, 이 기회에 [vercel](https://vercel.com/)로 이주했다.

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

#### 장점

- netlify처럼 CD 기능 지원이 뛰어나다. 매 PR 마다 배포를 자동으로 해줘서 ([이런 느낌](https://yceffort-blog-v2-4llxkkbh3.vercel.app/)) https://github.com/yceffort/yceffort-blog-v2/pull/27 실제 머지 전에 상태를 확인할 수 있다.
- 개인 유저는 무조건 공짜다. 팀 단위 프로젝트 관리를 위해서는 돈을 지불해야 하는데, 어차피 개인 블로그 이므로 해당이 없다.
- 인터페이스가 깔끔하다.
- 기능에 군더더기가 없다. (장점일 수도 단점일 수도. heroku는 DB 등 다양한 addons을 붙일 수 있다.)

무엇보다도 다크모드를 지원한다는 점(...?)과 인터페이스가 깔끔하다는 것이 마음에 들었다. 도메인 설정도 아래 그림처럼 깔끔하게 할 수 있었다.

![vercel-domains](./images/vercel-domains.png)

## 결과

미니멀한 블로그를 만든 결과, 굉장히 만족 스러웠고, 당연하게도 google page speed insights 에서도 좋은 점수를 받을 수 있었다.

https://developers.google.com/speed/pagespeed/insights/?hl=ko&url=yceffort.kr

![desktop](./images/yceffort-blog-speed-insight-desktop.png)

![mobile](./images/yceffort-blog-speed-insight-mobile.png)

그리고 모바일에서 사용성이 굉장히 좋아졌다. 검색 등 이것저것 기능이 붙어있어서 좀 어지러운 감이 있었는데, 이전보다 훨씬 깔끔해졌다.

## 아쉬웠던 점

### 굉장히 느린 빌드 타임

빌드가 굉장히 느려졌다.

![vercel-build](./images/vercel-build.png)

기본적으로 블로그 글이 많은 것도 있지만, 빌드 하면서 gatsby에서 이것저것 수행하는 것이 많아졌다. `mathjax`지원을 위한 처리, 이미지 preview 생성 등 기본적으로 마크다운을 html로 바꾸는 과정에서 처리하는 작업 외에도 거치는 작업이 너무 많아졌다. 또한 추가/수정한 글만 생성하는 것이 아니라, 모든 글을 새로 다시 만들기 때문에 굉장히 느려질 수 밖에 없다. 빌드가 느려졌다는 것은 곧 dev로 개발하는 것도 엄청나게 느려졌다는 것을 의미하며, 내 맥북 에어에서 dev로 개발하기 위해서는 10분 넘게 빌드를 돌려야 한다. (ㅠㅠ) 이는 visual studio codespace를 사용하는 계기가 되기도 했다.

이를 해결할 수 있는 방법이 몇가지 떠오르긴 하지만, 다시 이직하게 되다면 그 때 처리하도록 하겠다. (....)

### Prettier 미적용

markdown에 pretter를 적용하고 싶었는데, mathjax 를 위해 사용한 문법 `$$...$$` , 즉 `$`를 모두 `\$`로 바꾸는, 이스케이프 처리해버리는 문제가 발생했다. 당연히 mathjax가 죄다 박살나 버렸고, 얼른 revert했다.

### mathjax error 에러

```
14:11:12.944  	error CHTML - Unknown character: U+BE14 in MathJax_Main,MathJax_Size1,MathJax_AMS
14:11:12.945  	error CHTML - Unknown character: U+B85D in MathJax_Main,MathJax_Size1,MathJax_AMS
14:11:12.946  	error CHTML - Unknown character: U+B2F9 in MathJax_Main,MathJax_Size1,MathJax_AMS
14:11:12.947  	error CHTML - Unknown character: U+C791 in MathJax_Main,MathJax_Size1,MathJax_AMS
14:11:12.948  	error CHTML - Unknown character: U+C5C5 in MathJax_Main,MathJax_Size1,MathJax_AMS
14:11:12.948  	error CHTML - Unknown character: U+C99D in MathJax_Main,MathJax_Size1,MathJax_AMS
```

`$$...$$`로 대변되는 mathjax syntax안에 내가 한글을 넣어놨나보다. 이 한글을 찾아내서 모두 없애야 빌드 타임에 비명을 지르지 않을텐데, 귀찮아서 아직 수정하지 못하고 있다. (ㅠㅠ)

### 리다이렉트 누락

내 글을 블로그에서 검색하면, https://www.yceffort.kr 로 대부분이 검색이 되는데, https://yceffort.kr만 설정해두고, https://www.yceffort.kr를 https://yceffort.kr로 리다이렉트 해주는 처리를 누락해서 2주간 구글 검색 실적이 박살났다. (...) 다행히 2주뒤에 복구 해두었지만, 박살난 실적이 되돌아 오려면 꽤 오랜 시간이 걸릴 것 같다.

### yceffort.github.io

몇몇 블로그나 위키에 yceffort.github.io 로 걸린 포스팅이 보이는데, 이 주소는 현재 동작하고 있지 않다 ㅠㅠ 따라서 yceffort.github.io 블로그를 다시 살려서 현재 동작하는 웹페이지로 리다이렉트 시키는 작업을 검토 중이다.

## 결론

일주일에 걸쳐 블로그 이사작업을 마쳤고, 심각한 버그 없이 대부분의 작업을 완료 했다. 아직 몇몇 작업들이 남아있고 이들을 [이슈업](https://github.com/yceffort/yceffort-blog-v2/issues)해서 차근차근 관리하도록 하겠다. 그리고 앞으로 이런식의 대형 작업은 더 이상 없었으면 좋겠다................


백수가 될 때마다 블로그를 갈아엎는 습관

블로그 업데이트에 대한 회고

[이 글](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>
 (double-click a todo to edit)
 <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 ? {todo.assignee.name} : 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) - 기본 개념과 원칙

<a href="https://mobx.js.org/intro/concepts.html">원본</a>
<h1 id="개념과-원칙">개념과 원칙</h1>
<h2 id="table-of-contents">Table of Contents</h2>
<ul>
<li>
<a href="#%EA%B0%9C%EB%85%90">개념</a>
<ul>
<li><a href="#1-%EC%83%81%ED%83%9C-state">1. 상태 (State)</a></li>
<li><a href="#2-%ED%8C%8C%EC%83%9D-derivations">2. 파생 (Derivations)</a></li>
<li><a href="#3-%EC%95%A1%EC%85%98-actions">3. 액션 (Actions)</a></li>
</ul>
</li>
<li>
<a href="#%EC%9B%90%EC%B9%99">원칙</a>
</li>
<li>
<a href="#%EC%BD%94%EB%93%9C-%EC%98%88%EC%A0%9C">코드 예제</a>
</li>
</ul>
<h2 id="개념">개념</h2>
<h3 id="1-상태-state">1. 상태 (State)</h3>
상태란 애플리케이션에서 파생되는 값이다. 일반적으로, 할일 목록 같은 도메인별 상태와 현재 선택된 엘리먼트를 나타내는 뷰 상태가 있다.
<h3 id="2-파생-derivations">2. 파생 (Derivations)</h3>
더이상의 추가적인 상호작용없이, 상태에서 파생되어지는 값을 모두 파생 (Derivations) 이라고 한다.
<blockquote>
최종적인 interaction 끝에 만들어진 값을 derivations 이라고 하는 것 같습니다.
</blockquote>
여기서 Derivations은 다양한 것이 될 수 있다.
<ul>
<li>유저 인터페이스</li>
<li>남은 할일 숫자와 같이 파생되어진 데이터</li>
<li>서버에서 전송해온 백엔드 데이터</li>
</ul>
MobX는 derivations을 두종류로 구분한다.
<ul>
<li>Computed values(계산된 값): 순수함수를 활용하여 현재 observable을 하고 있는 값들로 부터 계산되는 값</li>
<li>Reaction: 상태가 바뀌면 자동으로 일어나야 하는 부수 효과. 이것은 명령형 프로그래밍과 반응형 프로그래밍 사이의 가교로서 필요하다. 이해를 더 쉽게 하기 위해서, I/O를 달성하기 위한 도구로써도 필요하다.</li>
</ul>
MobX를 처음 사용하는 초심자들은, 리액션을 너무 자주 사용하는 경향이 있다. 중요한 것은 바로 이것이다: 현재 상태를 기반으로 값을 계산하고 싶다면 <code>computed</code>를 활용하라.
스프레드시트와 유사하게, 스프레드시트에서의 수식은 값을 계산해서 파생된 값이다. 그러나 사용자로서, 그러한 파생을 볼 수 있으려면 GUI의 일부를 다시페인팅 하는등의 리액션이 필요하다.
<h3 id="3-액션-actions">3. 액션 (Actions)</h3>
액션은 상태를 변화시키는 모든 코드 조각을 의미한다. 사용자 이벤트, 백엔드 데이터, 예약된 이벤트 등 액션은 스프레드시트 셀에 새 값을 입력하는 동작과 같다.
액션은 MobX에 명시적으로 정의되어있어서, 코드를 보다 명확하게 구성할 수 있다. MobX가 엄격모드로 동작될경우, MobX는 어떤 상태도 외부 액션으로 수정할 수 없도록 강제될 것이다.
<h2 id="원칙">원칙</h2>
MobX는 액션이 상태를 변경하는 단방향 데이터 흐름을 지원하고, 이에 영향을 받는 모든 뷰를 업데이트 한다.
<img src="https://mobx.js.org/assets/action-state-view.png" alt="MobX Principles">
<ul>
<li>모든 파생은 상태가 변경될때 자동으로 한번에 업데이트 된다. 따라서 중간에 값을 관찰하는 것은 불가능하다.</li>
<li>모든 파생은 기본적으로 동기로 업데이트 된다. 예를 들어, 액션을 통해 상태를 변경한 후, computed value를 직접 검사할 수 있다는 것을 의미한다.</li>
<li>computed values는 게으르게 업데이트 된다. 현재 사용되지 않은 computed value는 부수효과에 필요할 때 까지 업데이트 되지 않는다. 만약 뷰에서 더이상 사용되지 않으면, 자동으로 가비지 콜렉팅 된다.</li>
<li>모든 computed values는 순수해야 한다. 이러한 값들이 상태를 바꾸면 안된다.</li>
</ul>
<h2 id="코드-예제">코드 예제</h2>
아래 예제는 위에서 언급한 기본 개념과 원칙을 묘사하고 있다.
<pre class="language-jsx"><code class="language-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'
</code></pre>