## 메모이제이션

https://ko.wikipedia.org/wiki/%EB%A9%94%EB%AA%A8%EC%9D%B4%EC%A0%9C%EC%9D%B4%EC%85%98

> 메모이제이션(memoization)은 컴퓨터 프로그램이 동일한 계산을 반복해야 할 때, 이전에 계산한 값을 메모리에 저장함으로써 동일한 계산의 반복 수행을 제거하여 프로그램 실행 속도를 빠르게 하는 기술이다. 동적 계획법의 핵심이 되는 기술이다.

함수형 프로그래밍의 기본원칙을 잘 지켰다면, (어떠한 외부 부수 효과에 영향을 받지 않는다면) 어떤 input이 들어가도 그 input에 대한 output은 동일 할 것이고, 따라서 동일한 input이 들어온다면 미리 전에 계산해두었던 output을 그대로 돌려줘도 될 것이다.

```javascript
const cache = {}
function addTwo(input) {
  if (!cache[input]) {
    console.log('계산 중..')
    cache[input] = input + 2
  } else {
    console.log('계산된 값을 그대로 돌려드립니다.')
  }
  return cache[input]
}
```

```javascript
addTwo(2) // 계산 중..
4
addTwo(3) // 계산 중..
5
addTwo(2) // 계산된 값을 그대로 돌려드립니다.
4
```

예제의 연산 자체는 간단했지만, 연산이 복잡하다면 메모이제이션으로 분명히 이득을 볼 수가 있다.

또 한가지 메모이제이션의 이점은, 정말로 동일한 결과가 리턴된다는 것이다. 결과값이 원시값이 아닌경우, 주소를 비교하기 때문에 `===`이 성립하지 않는데, 메모이제이션을 한다면 정말로 똑같은 값을 리턴할 것이다. (기존에 가지고 있던 값을 그대로 돌려줄 것이므로)

## 리액트의 메모이제이션

리액트는 메모이제이션을 위한 세개의 api를 제공한다.

- [memo](https://ko.reactjs.org/docs/react-api.html#reactmemo)
- [useMemo](https://ko.reactjs.org/docs/hooks-reference.html#usememo)
- [useCallback](https://ko.reactjs.org/docs/hooks-reference.html#usecallback)

리액트 메모이제이션에서는 주목해야 할 부분이 있다. https://ko.reactjs.org/docs/hooks-faq.html#how-to-memoize-calculations

> The useMemo Hook lets you cache calculations between multiple renders by “remembering” the previous computation:

바로 이전의 값만 메모이제이션 한다는 것이다.

```javascript
const Memoized = React.memo(Component)
```

```html

<Memoized num="{1}" />

<Memoized num="{1}" />

<Memoized num="{2}" />

<Memoized num="{1}" />
```

`useMemo` `useCallback`도 마찬가지로, 직전의 값만 메모이제이션한다. 코드로 풀면 이런 느낌의 메모이제이션일 것이다.,

```javascript
let prevInput;
let prevResult;

function someFunction(input) {
  if (input !== prevInput) {
    prevResult = doSomethingHeavyJob....
  }

  prevInput = input
  return prevResult
}
```

## 메모이제이션의 이유

메모이제이션은 아래 두가지 이유때문에 한다고 볼 수 있다.

1. 비싼 연산을 반복하는 것을 피하여 성능을 향상시킨다
2. 안정된 값 제공

1번에 대해서는 모든 리액트 개발자들이 공감하고 있을 것이기 때문에 생략하고, 2번에 대해서 이야기 해보자.

```javascript
function App() {
  const [body, setBody] = useState()
  const fetchOptions = {
    method: 'POST',
    body,
    headers: { 'content-type': 'application/json' },
  }

  const callApi = () => (body ? fetch('/url', fetchOptions) : null)

  useEffect(() => {
    const result = callApi()
    if (!result) return
  }, [callApi])

  return <>...</>
}
```

리액트에서 흔히 볼 수 있는 코드다. `useEffect`는 `deps`에 변경이 있을 때마다 실행된다. 여기에서는 `callApi`가 있으므로, `callApi`는 컴포넌트 내에서 매번 새롭게 렌더링 될 때마다 계속해서 만들어질 것이다.

따라서 이 값을 안정시키기 위해서 memoization을, 정확히는 `useCallback`을 사용해야 한다.

```javascript
const callApi = useCallback(() => (body ? fetch('/url', fetchOptions) : null), [
  body,
  fetchOptions,
])
```

그러나 `fetchOptions`역시 컴포넌트가 렌더링 될 때마다 새롭게 생성될 것이므로, `fetchOptions`도 memoization을 거쳐야 한다.

```javascript
const fetchOptions = useMemo(() => {
  return {
    method: 'POST',
    body,
    headers: { 'content-type': 'application/json' },
  }
}, [body])
```

`fetchOptions`와 `callApi`를 오로지 `body`의 값이 변경될 때만 다시 연산하게 함으로써 값을 안정시킬 수 있다.

원하는 값을 memoization하기 위해서 중요한 것은 memoization에 필요한 값들을 안정화 시키는 것이다. `fetchOptions`의 `useMemo`를 사용하여 `callApi`에서 하고자하는 memoization을 안정적으로 달성할 수 있게 되었다.

물론, 위의 예제를 제대로 작성하기 위해선 아래와 같이 해야할 것이다.

```javascript
useEffect(() => {
  if (!body) return

  const fetchOptions = {
    method: 'POST',
    body,
    headers: { 'content-type': 'application/json' },
  }

  fetch('/url', fetchOptions)
}, [body])
```

굳이 memoization을 하지 않더라도, `useEffect`가 `body`의 값의 변화에만 트리거하도록 바꾸면 (이것도 리액트의 직전 값만 비교하는 memoization전략과 일치한다고 볼 수 있다.) 쉽게 원하는 바를 달성할 수 있다.

블로그에서 계속 같은 글을 쓰는 것 같은데🤪

리액트와 메모이제이션

`eslint-config-***` 시리즈를 만들면서 몇 가지 배운 것, 그리고 잊지 않기 위해 기억해야 할 것을 요약해 둔다.

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

## eslint 와 prettier의 충돌

`eslint`와 `prettier`를 적요한 사람들이 가장 많이 겪는 문제 중 하나는, vs code 등 에디터에서 `eslint`를 적용했는데, 룰이 서로 충돌을 한다는 문제였다.

대표적인 예가 `indent`룰 인데, 놀랍게도 `eslint`와 `prettier`모두 indent 룰이 존재한다.

- `eslint`: https://eslint.org/docs/rules/indent
- `prettier`: https://prettier.io/docs/en/options.html#tab-width

예를 들어, 나는 2칸을 규칙으로 지정해서 하고 싶어서, 아래와 같이 두개 다 적용했다고 가정해보자.

```javascript
rules: {
  indent: ['error', 2],
  'prettier/prettier': ['error', { tabWidth: 2 }],
},
```

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

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

뭔가 둘이 똑같은 일을 하는 `indent`와 `tabWidth`의 동작이 미묘하게 다른 것을 알 수 있다.

https://github.com/eslint/eslint/issues/10930

> @jlchereau ESLint's indent rule and Prettier's indentation styles do not match - they're completely separate implementations and are two different approaches to solving the same problem ("how do we enforce consistent indentation in a project").

> When using Prettier, you shouldn't be using ESLint's indent rule at all. In your current configuration, the prettier config disables indent and then you're turning it back on using "indent": ["error", 4, { "SwitchCase": 1 }], in the rules property of your config. I don't use eslint-plugin-prettier, but I believe you should be letting that rule handle any warnings about indentation.

이러한 `indent`룰 이외에도 충돌하는 룰이 몇가지 있다.

이런 경우에는 `prettier`가 할 수 있는 일은 `prettier`에게 모두 맡기고, 관련 `eslint`룰은 모두 끄는 것이 좋다.

https://github.com/prettier/eslint-config-prettier

> Turns off all rules that are unnecessary or might conflict with Prettier. ;
> This lets you use your favorite shareable config without letting its stylistic choices get in the way when using Prettier.

## 특정 라이브러리 import 방지

`lodash`는 다양한 기능을 제공하는 좋은 라이브러리이지만, 여기저기서 언급한 것처럼 - 오래된 설계 방식으로 인해 잘못 import 를 하면 트리쉐이킹이 되지 않는다.

```javascript
// 설정이 잘 되어있어도 lodash 모든 것들을 가져온다.
import { sortBy } from 'lodash'

// sortBy 경로에서 가져온다.
import sortBy from 'lodash-es/sortBy'
```

https://yceffort.kr/2020/07/how-commonjs-is-making-your-bundles-larger

https://yceffort.kr/2020/07/how-commonjs-is-making-your-bundles-larger

이것을 [no-restricted-imports](https://eslint.org/docs/rules/no-restricted-imports)로 막을 수 있다.

```javascript
"no-restricted-imports": [
    "error",
    {
    "name": "lodash",
    "message": "lodash has been prohibited due to bundle size. use lodash-es instead."
    }
]
```

![no-restricted-imports](./images/no-restricted-imports.png)

만약 기존에 이미 `no-restricted-imports` 룰이 있다면, 별개의 `eslintrc`룰을 만들어서 `eslint`를 한번 더 돌리면 된다. 뭔가 이 룰을 고도화 하자는 issue도 있었는데, `eslint`팀에서 복잡성을 이유로 거절했었다.

## husky, lint-staged

`prettier`와 `lint`에 대한 점검은 보통 CI 단계에서 하는 경우가 많은데, 코드를 커밋하기 전에도 할 수 있다.

- `husky`: https://github.com/typicode/husky
- `lint-staged`: https://github.com/okonet/lint-staged

두 라이브러리를 devDependencies에 설치해두고, `package.json`에 아래와 같이 추가해주면 된다.

```json
{
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged -q"
    }
  },
  "lint-staged": {
    "**/*.{js}": ["eslint", "git add"]
  }
}
```

코드의 양이 많아질수록, git add 하는 과정이 버벅일 수 있으므로, 이는 적당히 고려해보기만 하면 될 것 같다.

## 취향을 타는 룰은 변경보다는 현상 유지가 낫다.

나는 대표적인 80width 2indent 파인데, 이는 굉장히 개인적인 취향의 영역이다. ([물론 prettier는 합리적인 선택이라고 주장하지만 서도](https://prettier.io/docs/en/options.html#print-width)) 이렇게 취향을 타는, 그리고 전체적인 코드 베이스를 수정해야 하는 룰은 그대로 두는게 낫다.

고치는게 어렵다거나, 수정이 많아진다거나 하는 이유가 아니고, 전반적인 코드의 history를 오염시킬 수 있기 때문이다. 온갖 코드에 히스토리가 바로 보이지 않고, 직전 히스토리에 `변경된 eslint 룰 적용`이라는 커밋 메시지만 잔뜩 남아있으면 git blame 하기가 여간 쉽지 않을 것이다.

## prettier 1.0과 2.0 사이에 default 값의 변화가 있다.

이건 내가 ~~멍청해서~~ 잘 못 찾고 삽질하던 영역인데, 1.0에서 2.0으로 업그레이드 하면서 기본값에서 몇가지 변화가 있었다. (내가 헤매던건 `trailing commas`)

https://prettier.io/docs/en/options.html

1.0에서 버전업 할 때 이를 잘 살펴볼 필요가 있다.

## react/exhaustive-deps는 죄가 없다.

리액트 코드들을 많이 살펴보면 이 `react/exhaustive-deps`룰을 warning처리 해놓거나, 혹은 eslint-disable을 도배해놓은 걸 볼 때가 많다.

경험적으로 봤을 때, 그리고 많은 아티클을 참고 했을 때 이룰은 `error` 로 두고, 필요할 때만 `eslint-disable-line` 을 해두는 것이 좋다.

이 논쟁에 대한 많은 글들이 있기 때문에,, 더이상 설명하는 것은 생략..

- https://reactjs.org/docs/hooks-faq.html#is-it-safe-to-omit-functions-from-the-list-of-dependencies
- https://github.com/facebook/react/issues/14920
- https://yceffort.kr/2020/10/think-about-useEffect

## camelcase

나는 camelCase와 PascalCase를 사용하는 것을 좋아한다. 그리고 대부분의 자바스크립트 라이브러리들이 둘 중 하나으로 작성되어 있다. 그러나 가끔 라이브러리들을 보면 snake_case로 작성되어 있는 경우가 있는데, 이 camelcase룰이 잘 되어 있어서 쓰는데 많은 도움이 되었다. destructuring시에 무시하거나, 혹은 특정 string에 대해서는 예외로 설정해 둘 수 있다.

https://eslint.org/docs/rules/camelcase

## .editorconfig도 쓰자.

[.editorconfig](https://editorconfig-specification.readthedocs.io/en/latest/)는 다양한 편집기와 IDE에서 작엏바는 여러 개발자들을 일관된 코딩스타일로 묶어주는데 도움을 준다. 따라서 이것도 프로젝트 코딩 컨벤션과 맞춰서 작성해서 제공하는게 좋다.

`.editorconfig`는 편집기 그 자체를 코딩 컨벤션에 맞춰서 자동으로 구성되게 해주기 때문에, `editorconfig` `prettier` `eslint`이 모든 것을 사용하는 것이 모두에게 일관된 코딩 스타일을 제공하는데 효과적이다.

아래는 내 전용 `.editorconfig`다.

https://github.com/yceffort/eslint-config-yceffort/blob/master/.editorconfig

```yaml
# http://editorconfig.org
root = true

[*.{js,ts,tsx}]
charset = utf-8
end_of_line = lf
indent_style = space
indent_size = 2
insert_final_newline = true
max_line_length = 80
trim_trailing_whitespace = true

[*.{json,yml,yaml}]
charset = utf-8
end_of_line = lf
indent_style = space
indent_size = 2
insert_final_newline = true
trim_trailing_whitespace = true
```

https://stackoverflow.com/questions/48363647/editorconfig-vs-eslint-vs-prettier-is-it-worthwhile-to-use-them-all

## 오타도 주의 하자.

eslint와는 조금 다른 얘기지만, 오타도 점검내지는 고쳐줬으면 좋겠다.

우리는 영어권 민족이 아니기 때문에, 영문 오타를 낼 가능성이 많다. 물론 영어권 사람들도 그렇겠지만. 그래서 대규모 프로젝트를 진행하다보면, 많은 사람들이 실수로 저질러 놓은 영어 오타들을 많이 보게 된다.

이를 점검할 수 있는 방법엔 여러가지가 있다.

- https://github.com/aotaduy/eslint-plugin-spellcheck
- https://github.com/TypoCI/spellcheck-action
- https://github.com/marketplace/actions/check-spelling

다양한 방법이 있지만, 개인적으로는 [vscode의 code spell checker](https://marketplace.visualstudio.com/items?itemName=streetsidesoftware.code-spell-checker)를 사용해서 내 코드 - 내지는 내 담당 PR만이라도 보고 있다.

왜냐하면, 아무래도 오타를 죄다 `error` 내지는 `warning`으로 띄운다면 `naver`나 `daum`같은 것도 죄다 오타로 걸리고, 그래서 이 예외적인 표현을 예외 목록에 추가하고, 그러다보면 예외목록에 갖가지 단어가 추가되는 등의 번거로움이 있을 것 같아서 적극적인 적용에는 망설이고 있다.

변수나 함수명의 귀여운 오타들이 코드의 성능이나 생산성에 영향을 미치는 것은 아니라서 모두 고칩시다! 라고 주장하기엔 무리가 있지만, 아무래도 거슬리는 건 어쩔 수가 없다. 나라도 조심하자.

## `warn`은 결국 `off`나 `error`로 가야 한다.

`warn`으로 설정하는 이유의 대부분은

> 문제가 있는건 알지만 일단 나중에 한꺼번에 고치자
> 문제인건 알지만 나중에 다시 논의 해보자
> 문제인건 알지만 에러까지는 아니고, 알아서 조심하자

정도로 나눠 볼 수 있을 것 같다. 그러나 이 `warn`을 장기간 방치해두면 그 경고가 쌓이게 되어, 정작 코드 컨벤션을 맞추기 위한 `eslint`의 의미를 퇴색시키고, 다른 경고들도 볼 수 없게 된다.

개인적인 생각으로는, `warn`으로 할 바엔 `off`로 하든, 혹은 `error`로 두고 예외적인 부분만 disable 처리하고 코멘트를 달아두는게 나은 것 같다. `warn`은 어디까지나 임시일뿐, 결국엔 `eslint`의 이점을 누릴 수 없게 만든다.

## AST 에 대한 이해

`eslint`를 만들면서 병적으로 사소한 룰을 추가하고 빼보고 카나리 배포해보고 적용해보고 fix해보고 commit 해보고 충돌나고 다시 고치고를 반복하면서 배운 것 이외에, 한가지 배운 것이 있다면 AST(Abstract Syntax Tree) 에 대한 이해였다.

eslint 는 아래와 같은 순서로 동작한다.

1. javascript 코드를 읽는다
2. parser로 AST를 만든다.

- 여기서 parser는 `Espree` `babel-eslint`등이 존재한다.
- AST는 소스코드의 구조를 트리 형태로 표현한 것이다.

3. linter와 rule을 활용하여 AST를 검사한다.
4. 검사결과에 따라서 에러를 뱉거나 고친다.

```javascript
var hello = 'hello'
console.log(hello)
```

이 parser를 거치면 아래와 같은 AST 형태로 바뀌게 된다.

```json
{
  "type": "Program",
  "start": 0,
  "end": 38,
  "body": [
    {
      "type": "VariableDeclaration",
      "start": 0,
      "end": 19,
      "declarations": [
        {
          "type": "VariableDeclarator",
          "start": 4,
          "end": 19,
          "id": {
            "type": "Identifier",
            "start": 4,
            "end": 9,
            "name": "hello"
          },
          "init": {
            "type": "Literal",
            "start": 12,
            "end": 19,
            "value": "hello",
            "raw": "'hello'"
          }
        }
      ],
      "kind": "var"
    },
    {
      "type": "ExpressionStatement",
      "start": 20,
      "end": 38,
      "expression": {
        "type": "CallExpression",
        "start": 20,
        "end": 38,
        "callee": {
          "type": "MemberExpression",
          "start": 20,
          "end": 31,
          "object": {
            "type": "Identifier",
            "start": 20,
            "end": 27,
            "name": "console"
          },
          "property": {
            "type": "Identifier",
            "start": 28,
            "end": 31,
            "name": "log"
          },
          "computed": false
        },
        "arguments": [
          {
            "type": "Identifier",
            "start": 32,
            "end": 37,
            "name": "hello"
          }
        ]
      }
    }
  ],
  "sourceType": "module"
}
```

이러한 구조를 이해해야 `eslint`가 어떻게 동작하는지 알수 있으며, 나아가 단순히 룰을 조합하는 `eslint-config`뿐만 아니라 내가 직접 custom rule을 만들 수도 있다.


eslint, prettier, editorconfig 로 코드 컨벤션을 맞춘 후기

`export default` 구문은 보통 파일 내에서 한개만 `export`하거나, 대표로 `export`할 것이 있을 때 많이 쓴다.

```typescript
function Foo {
  // ...
}

export default Foo
```

```typescript
export default function Foo {
  // ...
}
```

그리고 쓰는 쪽에서는 이렇게 `import`할 것이다.

```typescript
import Foo from './foo'
```

그런데 왜 이것을 않았으면 좋겠는지 몇 가지 이유를 들어서 설득해보자.

## Table of Contents

## 예제

`foo.ts`

```typescript
export default function Foo() {
  console.log('foo')
}
```

`bar.ts`

```typescript
export function hello() {
  console.log('hello')
}

export function hi() {
  console.log('hi')
}
```

## 검색이 어렵다.

```typescript
import { h } from './bar'
```

default export를 하게 되면 내보내기가 있는지 여부가 불투명하다.

```typescript
import { Foo } from 'something'
```

그러나 기본값이 없으면 코드 intellisense로 내부에 어떤 것을 import 할 수 있는지 쉽게 알 수 있다.

![export](./images/export1.png)

## commonjs

`default`는 `commonjs`를 쓰는 사람들에게는 혼동을 준다. 위의 default export를 `commonjs`로 바꾸면

```javascript
export default function Foo() {
  console.log('foo')
}

module.exports = {
  Foo,
  default: Foo,
}
```

방식으로 해야하는 어려움이 있다.

## re-export

```typescript
export { default as Foo } from './foo'
```

```typescript
export * from './bar'
```

named export 쪽이 다시 export 하는데 있어서 훨씬 편하다.

## 다이나믹 import

```typescript
const foo = await import('./foo')
foo.default()
```

```typescript
const { hello } = await import('./bar')
hello()
```

`default` 한단계를 더 거쳐야 한다.

## 클래스나 함수가 아니면 한줄이 더 필요함.

```typescript
// 이건 안된다
export default const hello = 'hello'

// 이건 가능
export const hi = "hi";
```

```typescript
// 이렇게 해야한다.
const hello = 'hello'

export default hello
```

## 리팩토링의 어려움

`default export`는 가져다 쓰는 곳에서 네이밍을 제멋대로 할 수 있으므로, 리팩토링 하기가 어렵다.

```typescript
import Foo from './foo'
import Wow from './foo'
import Bye from './foo'
```

위 세개는 모두 동일하게 동작하기 때문에, 오타를 수정하는 등의 작업이 어려워 진다.

## 트리 쉐이킹

만약 여러개의 object를 하나의 `default export`로 내보내는 코드가 있다고 가정해보자.

`foo.ts`

```javascript
export default {
  foo1: 'foo1',
  bar1: 'bar1',
}
```

`bar.ts`

```javascript
export const bar2 = 'bar2'
export const foo2 = 'foo2'
```

`index.ts`

```javascript
import Foo from './foo'
import { foo2 } from './bar'

console.log(Foo.foo1)
console.log(foo2)
```

[이를 트리쉐이킹을 거치게 되면 아래와 같은 결과가 나온다.](https://rollupjs.org/repl/?version=2.33.1&shareable=JTdCJTIybW9kdWxlcyUyMiUzQSU1QiU3QiUyMm5hbWUlMjIlM0ElMjJtYWluLmpzJTIyJTJDJTIyY29kZSUyMiUzQSUyMmltcG9ydCUyMEZvbyUyMGZyb20lMjAnLiUyRmZvbyclNUNuaW1wb3J0JTIwJTdCJTIwZm9vMiUyMCU3RCUyMGZyb20lMjAnLiUyRmJhciclNUNuJTVDbmNvbnNvbGUubG9nKEZvby5mb28xKSU1Q25jb25zb2xlLmxvZyhmb28yKSUyMiUyQyUyMmlzRW50cnklMjIlM0F0cnVlJTdEJTJDJTdCJTIybmFtZSUyMiUzQSUyMmJhci5qcyUyMiUyQyUyMmNvZGUlMjIlM0ElMjJleHBvcnQlMjBjb25zdCUyMGJhcjIlMjAlM0QlMjAnYmFyMiclNUNuZXhwb3J0JTIwY29uc3QlMjBmb28yJTIwJTNEJTIwJ2ZvbzInJTIyJTdEJTJDJTdCJTIybmFtZSUyMiUzQSUyMmZvby5qcyUyMiUyQyUyMmNvZGUlMjIlM0ElMjJleHBvcnQlMjBkZWZhdWx0JTIwJTdCJTVDbiUyMCUyMGZvbzElM0ElMjAnZm9vMSclMkMlNUNuJTIwJTIwYmFyMSUzQSUyMCdiYXIxJyUyQyU1Q24lN0QlMjIlN0QlNUQlMkMlMjJvcHRpb25zJTIyJTNBJTdCJTIyZm9ybWF0JTIyJTNBJTIyZXMlMjIlMkMlMjJuYW1lJTIyJTNBJTIybXlCdW5kbGUlMjIlMkMlMjJhbWQlMjIlM0ElN0IlMjJpZCUyMiUzQSUyMiUyMiU3RCUyQyUyMmdsb2JhbHMlMjIlM0ElN0IlN0QlN0QlMkMlMjJleGFtcGxlJTIyJTNBbnVsbCU3RA==)

```javascript
var Foo = {
  foo1: 'foo1',
  bar1: 'bar1',
}

const foo2 = 'foo2'

console.log(Foo.foo1)
console.log(foo2)
```

`named exports`를 하는게 번들 사이즈를 더 줄이는데 도움을 준다.

## 결론

그럼에도 불구하고 default export를 쓰는 것을 그만두지는 않을 것 같다. `eslint-config-airbnb` 만 보더라도 [내보낼 것이 한개인 경우에는 default를 쓰는 것을 권장하고 있고](https://github.com/airbnb/javascript#modules--prefer-default-export) `nextjs` 등의 라이브러리에서도 `default export`를 하지 않고서는 할 수 없는 기능들이 더러 있다.

[물론 여전히 두 export 방식에 대해서는 논란이 많지만](https://github.com/airbnb/javascript/issues/1365) 아무래도 `default` 가 깔끔한 건 기분 탓일까, 습관 탓일까 🤔

그래도 **가급적이면** named exports를 하는 방향으로 코드를 써보자. 그럼에도 `default`는 죄가 없는 것 같다.


근데 쓰는게 뭔가 더 안정적인 기분이야

export default를 쓰지 말아야 할 이유

한 사이트가 여러 탭에서 떠 있을 때, 탭 사이에서 통신이 필요한 경우가 있을까?

- 한 탭에서 사이트의 테마를 변경해서 다른 탭에 있는 사이트에까지 변경이 필요한 경우
- 애플리케이션의 상태를 탭 사이에 맞춰야 하는 경우
- 가장 최근에 가져온 인증 정보를 브라우저 탭 간에 공유가 필요한 경우

이를 달성할 수 있는 방법이 무엇이 있을까?

## Local Storage

놀랍게도 [로컬 스토리지에도 event를 지원한다.](https://developer.mozilla.org/en-US/docs/Web/API/Window/storage_event) 이 event를 활용해서 localStorage의 변화를 감지하는 방법이다.

```javascript
React.useEffect(() => {
  function listener(event: StorageEvent) {
    if (event.storageArea !== localStorage) return
    if (event.key === LOGGINED) {
      setLoginTime(parseInt(event.newValue || '0', 10))
    }
  }
  window.addEventListener('storage', listener)

  return () => {
    window.removeEventListener('storage', listener)
  }
}, [])
```

https://codesandbox.io/s/tab-communications-1-localstorage-5ldjw

![example1](./images/tab-communication-1.gif)

잘 작동하는 것 같지만 몇가지 문제가 존재한다.

- 정확히는 탭 별로 이벤트가 발생하는게 아니고 storage의 event를 가져다 쓰는 꼼수라는 점
- localStorage는 동기로 작동하기 때문에 메인 UI 쓰레드를 블로킹할 수도 있음.

## Broadcast Channel API

[BroadCast Channel API](https://developer.mozilla.org/en-US/docs/Web/API/Broadcast_Channel_API)는 탭, 윈도우, 프레임, iframe 그리고 Web worker 간에 통신을 할 수 있게 해주는 API다.

이 방법을 쓰면, [브라우저 콘텍스트](https://developer.mozilla.org/en-US/docs/Glossary/browsing_context) 간에 통신이 가능해진다.

```javascript
const LOGGINED = "loggedIn";

const channel = new BroadcastChannel(LOGGINED);

export default function App() {
  const [loginTime, setLoginTime] = React.useState<number>(() =>
    parseInt(window.localStorage.getItem(LOGGINED) || "0", 10)
  );

  React.useEffect(() => {
    function listener(event: MessageEvent) {
      setLoginTime(event.data);
    }

    channel.addEventListener("message", listener);

    return () => {
      channel.removeEventListener("message", listener);
    };
  }, []);

  return (
    // jsx
  );
}
```

https://codesandbox.io/s/tab-communications-2-braodcast-channel-m50d6

~~코드가 어딘가 이상하다면 그냥 무시해주셈~~

![example2](./images/tab-communication-2.gif)

다만 문제점은 [Broadcast Channel Api는 너무 힙한 나머지 사파리와 IE에서 쓸 수 없다는 점](https://caniuse.com/broadcastchannel)ㅣ다.

## Service Worker

[서비스 워커](https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerRegistration)를 이용하는 방법도 있다.

```javascript
window.navigator.serviceWorker.controller?.postMessage({
  [LOGGINED]: currentDateTime,
})
```

그리고 이 정보를 서비스워커에서 받으면 된다. 그러나 서비스 워커를 세팅하는 것은 쉽지 않고, 추가적으로 `serviceWorker.js`등을 만드는 등의 노력이 필요하다. 그리고 [서비스 워커도 마찬가지로 IE에서 지원하지 않는다.](https://caniuse.com/serviceworkers)

## postMessage

가장 전통적이고도 널리 쓰이는 방식은 [window.postmessasge](https://developer.mozilla.org/ko/docs/Web/API/Window/postMessage)다. 아마 대다수의 서비스들이 이 방식을 쓰고 있을 것이다.

```javascript
targetWindow.postMessage(message, targetOrigin)
```

```javascript
window.addEventListener(
  'message',
  (event) => {
    if (event.origin !== 'http://localhost:8080') return
    // Do something
  },
  false,
)
```

이 방법의 장점은 cross-origin을 지원한다는 것이다. 그러나 단점은 위 코드에서 알 수 있듯이 브라우저 탭의 레퍼런스를 가지고 있어야 한다. (`targetWindow`를 가지고 있는 것 같이) 그래서 이 방식은 `window.open()`이나 `document.open()`을 통해서 탭을 열었을 때만 사용 가능하다.

https://caniuse.com/mdn-api_window_postmessage


블로그 다크모드 지원시에 고려해보겠습니다 🤔

브라우저 탭 사이에서 통신 하는 방법

https://yceffort.kr/2020/09/webpack-module-federation 에서 이어진다.

webpack 5가 발표 되면서 동시에 module federation도 직접해볼 수 있게 되었다. 한번 직접 적용해보면서 정말로 게임 체인저가 될 수 있는지 살펴보자.

해당 예제 프로젝트 저장소는 [여기](https://github.com/yceffort/webpack-module-federation-exmaple)다.

react v17과 webpack 5를 바탕으로, 아주 기초적인 세팅만 해서 빠르게 개발을 진행해보았다.

## main 설정

일단 메인 프로젝트가 있고, 여기저기에 있는 컴포넌트를 가져다 쓰는 모습을 상상해보면서 프로젝트를 만들어보자. main은 module federation으로 서빙되는 다른 프로젝트를 가져다가 쓰는 federation의 중심이라고 보면 될 것 같다.

`webpack.config.js`

```javascript
const path = require('path')

const HtmlWebpackPlugin = require('html-webpack-plugin')
const { ModuleFederationPlugin } = require('webpack').container

module.exports = {
  entry: './src/index',
  mode: 'development',
  devServer: {
    contentBase: path.join(__dirname, 'dist'),
    port: 3001,
  },
  output: {
    publicPath: 'http://localhost:3001/',
  },
  module: {
    rules: [
      {
        test: /\.jsx?$/,
        loader: 'babel-loader',
        exclude: /node_modules/,
        options: {
          presets: ['@babel/preset-react'],
        },
      },
    ],
  },
  plugins: [
    new ModuleFederationPlugin({
      name: 'main',      
      remotes: {
        app1: 'app1',
      },
      shared: ['react', 'react-dom'],
    }),
    new HtmlWebpackPlugin({
      template: './public/index.html',
    }),
  ],
}
```

[ModuleFederationPlugin](https://webpack.js.org/concepts/module-federation/)을 사용한 것을 볼 수 있다. 이 플러그인은 `ContainerPlugin`과 `ContainerReferencePlugin` 를 합친 개념이라고 보면 될 것 같다.

여기는 단순히 expose 한 다른 federation을 가져다 쓰는 역할만 하기 때문에, `exposes`를 하기 않고 있다. 

## app1 설정

`main`에서 가져다 쓸 실제 컴포넌트를 expose하는 곳이다.

`webpack.config.js`

```javascript
const path = require('path')

const HtmlWebpackPlugin = require('html-webpack-plugin')
const { ModuleFederationPlugin } = require('webpack').container

module.exports = {
  entry: './src/index',
  mode: 'development',
  devServer: {
    contentBase: path.join(__dirname, 'dist'),
    port: 3002,
  },
  output: {
    publicPath: 'http://localhost:3002/',
  },
  module: {
    rules: [
      {
        test: /\.jsx?$/,
        loader: 'babel-loader',
        exclude: /node_modules/,
        options: {
          presets: ['@babel/preset-react'],
        },
      },
    ],
  },
  plugins: [
    new ModuleFederationPlugin({
      name: 'app1',
      library: { type: 'var', name: 'app1' },
      filename: 'remoteEntry.js',
      exposes: {
        './Counter': './src/components/counter/index.jsx',
      },
      shared: ['react', 'react-dom'],
    }),
    new HtmlWebpackPlugin({
      template: './public/index.html',
    }),
  ],
}
```

`main`과 차이점은 `exposes`가 있다는 것이다. 여기에서는 간단한 `Counter`를 내보내도록 하고 있다. 그리고 이렇게 내보낸 `Counter`를 `https://localhost:3000/remoteEntry.js`에서 서비스 하도록 설정해주었다.

## main

`index.html`

```html
<!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Main App</title>
</head>

<body>
    <div id="root"></div>
    <script src="http://localhost:3002/remoteEntry.js"></script>
</body>

</html>
```

아까 서빙하기로 작성해둔 `remoteEntry.js`를 땡겨오는 모습이다. 물론 더 빠르게 만들기 위해서는 async 등을 사용할 수 도 있다.

`bootstrap.js` 

이름이 `bootstrap`인 이유는 공식 문서에서 그렇게 하고 있길래 그렇게 했다. 👀 뜻과도 연관이 있을듯.

```javascript
import React, { Suspense } from 'react'
import ReactDOM from 'react-dom'

const Counter = React.lazy(() => import('app1/Counter'))

function App() {
  return (
    <>
      <h1>Hello from React component</h1>
      <Suspense fallback="Loading Counter...">
        <Counter title={'hello, counter'} />
      </Suspense>
    </>
  )
}

ReactDOM.render(<App />, document.getElementById('root'))
```

`React`의 `lazy`와 `suspense`를 활용하여 `app1`에서 expose한 `Counter`를 가져다 쓰고 있다.


## 결과

카운터가 잘 나오고 있고

![result1](./images/module-federation-result1.png)

정상적으로 `remoteEntry`에서 가져다 쓰는 것을 볼 수 있다.

![result2](./images/module-federation-result2.png)

그리고 두 컴포넌트 모두 `share`로 `['react', 'react-dom']`을 쓰고 있었는데, 이것 역시 중복되지 않고 `main`에서 묶어서 쓰고 있는 것을 알 수 있었다.

## 좋은 점 내지는 기대하는 미래

요즘 유행이라고 하는 [Micro Frontend](https://micro-frontends.org/)를 달성할 수 있는 좋은 방법 중 하나 인 것 같다. 하나의 앱이 덩치가 너무 커서, 싱글 폴트의 위험 내지는 개발환경에서 쓸 데 없이 다 불러와야 하는 문제 등등이 존재하는데, module federation이 그것을 훌륭하게 해결해 줄 수 있을 것 같다. (물론 `main`이 고장나버리면 답이 없겠지만) 

![vertical](https://micro-frontends.org/ressources/diagrams/organisational/verticals-headline.png)

## 아쉬운 점

문서가 잘 나와있으면 좋을 것 같은데 아직 webpack의 문서가 좀 부실한 것 같다.

그래서

- https://github.com/webpack/webpack/blob/master/lib/container/ContainerPlugin.js
- https://github.com/webpack/webpack/blob/master/lib/container/ContainerReferencePlugin.js
- https://github.com/webpack/webpack/blob/master/lib/container/ModuleFederationPlugin.js
- https://github.com/module-federation/module-federation-examples

를 그냥 참고 하면서 했다. 다른 여타 기능들 처럼 webpack document에서 옵션으로 들어갈 수 있는 object의 특징이나 값을 명시해주었으면 좋겠다. 

https://webpack.js.org/concepts/module-federation/#containerplugin-low-level

아직은 문서가 그냥 아주 간단한 예제와 컨셉정도만 보여주고 있어서 아쉽다.

이러한 Documentation의 아쉬움 말고는 아직 이렇다할 단점을 느끼지 못했다. (물론 대규모 서비스에 직접 써보지는 않았지만) 향 후에 `create-react-app`이라든지, 다른 프론트엔드 생태계에서 적극적으로 사용되어서 더욱 발전해나갔으면 좋겠다.

## 다양한 예제들

더욱 다양한 예제들은 [여기](https://github.com/module-federation/module-federation-examples)에서 볼 수 있다.


yceffort

리액트와 메모이제이션

eslint, prettier, editorconfig 로 코드 컨벤션을 맞춘 후기

export default를 쓰지 말아야 할 이유

브라우저 탭 사이에서 통신 하는 방법

Webpack Module Federation 직접해보기