버튼 중복 클릭을 방지하는 것은 중요하다. 물론 기본적인 중복 방지에 대한 처리는 서버에 되어 있어야 하지만, 그렇다고 마냥 프론트엔드에서 손놓고 있을 수는 없는 일이다.

주니어 풀스택 개발자일때, 중복 클릭에 대해서 프론트엔드에서 부단히도 막아보려고 노력했지만, 사용자들은 갖가지 방법으로 여러번 클릭을 했고, 그 때마다 사용자들은 더욱 더 빠른 속도로 (혹은 창의적인 방법으로) 중복클릭을 해서 괴롭히곤 했다. 결국 어느정도 감내하고 (?) 서버에서 막는 방향으로 가긴했지만 - 그 때 마다 더 좋은 방법이 없을까 고민하곤 했다. 그 때 나왔던 다양한 중복 클릭 방지 방법을 이야기 해보고, 문제점은 무엇이었으며, 이를 해결할 수 있는 최선의 코드를, 함수형으로 써보면 어떻게 되는지 알아보장

## 방법 1) 글로벌 플래그 사용하기

```javascript
let clicked = false

function payment() {
  if (!clicked) {
    clicked = true
    window.alert('결제가 진행 중입니다.')
    // 결제 프로세스..
  }
}
```

이 방법도 물론 작동은 하겠지만 몇가지 문제가 있다.

- 전역 변수를 선언하는 것은 위험하다. 전역변수는 누구든 접근 가능하기 때문에, 자신이 알지도 못하는 새에 값이 변경될 수 있다.
- 사용자가 다시 버튼을 누를 수 있는 상황에 대비하여 해당 변수를 다시 초기화 하는 코드를 어딘가에도 넣어야 한다.
- 외부 변수에 의존하기 때문에 테스트 하기가 곤란하다.

## 방법 2) 핸들러를 날려 버리기 (혹은 변경하기)

```javascript
function payment() {
  document.getElementById('payment').onclick = null
  window.alert('결제가 진행 중입니다.')
  // 결제 프로세스..
}
```

이 방법도 일단은 작동하겠지만 문제가 존재한다.

- DOM의 버튼과 매우 강하게 연결 되어 있는 코드 이기 때문에, 재사용이 불가능하다.
- 위 예제와 마찬가지로 다시 버튼 클릭할 수 있는 상황에 대비하여 초기화하는 코드가 필요하다.
- DOM 요소가 있어야만 테스트가 가능하다.

## 방법 3) 버튼을 disable 처리하기

```javascript
function payment() {
  document.getElementById('payment').setAttribute('disabled', 'true')
  window.alert('결제가 진행 중입니다.')
  // 결제 프로세스..
}
```

역시 위와 마찬가지 이슈가 있다.

## 방법 4) 지역 변수 사용하기

```javascript
var payment = ((clicked) => {
  return () => {
    if (!clicked) {
      clicked = true
      window.alert('결제가 진행 중입니다.')
      // 결제 프로세스..
    }
  }
})(false)
```

이번에는 즉시실행함수를 사용하였다. 이는 함수형 접근법이기도 하고, `clicked`를 외부에서 접근할 수 없기도 하다. 1번의 예제에서 전역변수로 되어 있던 것을 지역변수로 바꾸고, 스코프를 잠궈서 접근하지 못하게 했다고 생각하면 된다. 이 코드의 단점은 한번만 클릭이 필요한 모든 함수에 대해서 이와 같이 똑같이 작업을 해야한다는 것이다.

## (아마도) 최선의 방법

- 단 한번만 호출해야 하는 원래 함수는 원래 작업 (결제) 이외의 작업을 해서는 안된다.
- 원본 함수를 수정해서는 안된다.
- 원본 함수를 한번만 호출하는 새로운 함수가 필요하다.
- 기존 기능에 적용할 수 있는 일반적인 솔루션이 필요하다.

여기에 필요한 것이 바로 고차함수 (higher-order function) 이다.

```javascript
const doOnce = (fn) => {
  let done = false
  return (...args) => {
    if (!done) {
      done = true
      fn(...args)
    }
  }
}
```

```typescript
const doOnceTypescript = (fn: Function) => {
  let done = false
  return (...args: any) => {
    if (!done) {
      done = true
      fn(...args)
    }
  }
}
```

이를 적용하면 아래와 같은 모습일 것이다.

```html
<button id="payment" onclick="doOnce(payment)()">결제하기</button>
```


어렸을 때 내가 어떻게 했더라?

(함수형으로) 자바스크립트로 HTML 버튼 중복 클릭 방지하기

가령 아래와 같은

```javascript
const button = document.querySelector("button");
button.addEventListener("click", (event) => /* do something with the event */)
```

이 코드에서, 버튼 클릭에 대해서 리스너를 달았다. 이 뜻은 이벤트가 발생하는 것 (emitted를 발생하다라고 의역했다.) 에 대해서 구독을 했다는 것이고, 그러한 이벤트가 발생할 경우 콜백을 실행하겠다는 것을 의미한다. 버튼을 클릭할 때 마다, 이벤트가 발생하게 되고 해당 이벤트와 함께 콜백이 실행된다.

기존 코드베이스에서 작업 할 때, 커스텀 이벤트를 발생시키고 싶을 때가 있다. 버튼 클릭과 같은 DOM 이벤트 말고, 다른 트리거를 기반으로 이벤트를 내보내고 응답하도록 한다고 가정해보자. 이를 위해서는 커스텀 EventEmitter가 필요하다.

EventEmitter란 정의된 이벤트를 수신하고, 콜백을 실행한다음, 값과 함께 해당 이벤트를 내보내는 패턴이다. 이를 `pub, sub` 모델, 혹은 리스너라고 부르기도 한다.

```javascript
let n = 0
const event = new EventEmitter()
event.subscribe('THUNDER_ON_THE_MOUNTAIN', (value) => (n = value))
event.emit('THUNDER_ON_THE_MOUNTAIN', 18)
// n: 18
event.emit('THUNDER_ON_THE_MOUNTAIN', 5)
// n: 5
```

위 예제에서는 `THUNDER_ON_THE_MOUNTAIN`라고불리는 이벤트를 구독하였고, 이 이벤트가 발생할 때 마다 콜백 `(value) => (n = value)`를 실행하였다.이 이벤트를 실행하기 위하여, `.emit()`을 사용하였다.

이는 비동기 코드로 작업 할 때 유용하다. 그리고 현재 모듈과 다른 위치에서 값을 업데이트 해야 한다. (값을 업데이트 할 수 있는 스코프가 되어야 한다.)

이에 대한 적절한 예가 Redux다. Redux는 내부 저장소가 업데이트 된 것을 외부에 공유해 줄 수 있는 방법이 필요하다. 그래야 리액트가 해당 값이 변경되었다는 것을 인지하고 `setState()`를 호출하여 다시 렌더링을 할 수 있다. 이러한 일련의 과정이 `EventEmitter`를 통해 이루어진다. Redux에는 subscribe 함수가 존재하며, 이는 새로운 값을 받을 때 마다 실행되는 콜백을 함수로 받는다. 이를 Redux `<Provider />` 컴포넌트라고 하며, 새로운 값을 받을 때 마다 `setState()`를 호출한다.

## Implementation

위 EventEmitter는 Nodejs에만 존재한다. 한번 실재로 이를 구현해보도록 하자.

```typescript
class EventEmitter {
  public events: Events
  constructor(events?: Events) {
    this.events = events || {}
  }
}
```

### Events

Events 인터페이스를 정의해보자.

```typescript
interface Events {
  [key: string]: Function[]
}

/**
{
  "event": [fn],
  "event_two": [fn]
}
*/
```

### Subscribe

먼저 정의된 이벤트를 구독할 방법이 필요하다.

```typescript
event.subscribe('named event', (value) => value)
```

두개의 파라미터 (이벤트 명, 콜백)을 받을 수 있도록 구현해보자.

```typescript
class EventEmitter {
  public events: Events
  constructor(events?: Events) {
    this.events = events || {}
  }

  public subscribe(name: string, cb: Function) {
    ;(this.events[name] || (this.events[name] = [])).push(cb)
  }
}
```

### Emit

다음으로, `emit`을 활용해서 이벤트를 발생시키는 코드를 구현해야 한다. 파라미터는 몇개가 있을지 모르므로, 유연하게 대처해야 한다.

```typescript
class EventEmitter {
  public events: Events
  constructor(events?: Events) {
    this.events = events || {}
  }

  public subscribe(name: string, cb: Function) {
    ;(this.events[name] || (this.events[name] = [])).push(cb)
  }

  public emit(name: string, ...args: any[]): void {
    ;(this.events[name] || []).forEach((fn) => fn(...args))
  }
}
```

### Unsubscribing

이제는 이벤트 구독을 해제 해보자.

```javascript
subscribe(name: string, cb: Function) {
  (this.events[name] || (this.events[name] = [])).push(cb);

  return {
    unsubscribe: () =>
      this.events[name] && this.events[name].splice(this.events[name].indexOf(cb) >>> 0, 1)
  };
}
```

이제 `subscribe`에서 `unsubscribe`를 리턴한다. 화살표 함수를 활용하여 부모 스코프와 같은 스코프를 사용할 수 있도록 했다. 이 함수에서, 부모에게 전달한 콜백의 인덱스를 찾고자 bitwise operator (`>>>`) 를 사용했다.

이제 아래와 같이 이벤트 구독을 해제 할 수 있다.

```javascript
const subscription = event.subscribe('event', (value) => value)

subscription.unsubscribe()
```

## 결론

```typescript
interface Events {
  [key: string]: Function[]
}

export class EventEmitter {
  public events: Events
  constructor(events?: Events) {
    this.events = events || {}
  }

  public subscribe(name: string, cb: Function) {
    ;(this.events[name] || (this.events[name] = [])).push(cb)

    return {
      unsubscribe: () =>
        this.events[name] &&
        this.events[name].splice(this.events[name].indexOf(cb) >>> 0, 1),
    }
  }

  public emit(name: string, ...args: any[]): void {
    ;(this.events[name] || []).forEach((fn) => fn(...args))
  }
}
```

출처: https://css-tricks.com/understanding-event-emitters/


면접 때 잘 대답 못했던 질문 22222

EventEmitter 구현해보기

웹사이트의 렌더링 성능을 최적화하면서, 가장 중점적으로 살펴봐야 할 것은 렌더링을 막는 자바스크립트 실행이다. 그런데 종종, 블로킹 자바스크립트의 원인이 `async` 태그라는 것을 발견하게 되다. 많은 사람들이 async가 렌더링을 막지 않는다고 생각한다. 그러나 슬프게도, 그렇지 않다. async 태그는 렌더링을 블로킹할 뿐만아니라, 스크립트를 동기로 실행하는 것을 막을 수도 있다. 추정컨데, 동기식으로 만든 스크립트는 페이지에 중요한 컨텐츠 이므로, 이를 지연시키는 것은 사용자 경험에 안좋은 영향을 미친다.

이번 글에서는 `defer`가 `async` 보다 더 기본적으로 선택해야할 것인지를 알아본다.

## 병렬화는 성능에 중요하다.

아마도 실제 웹 성능 향상에 가장 중요하게 영향을 미친 것 중 하나는, 스크립트 다운로드를 병렬로 다운로드 받는 것이다. 2006년 이전에는, 브라우저는 모든 외부 스크립트를 순서대로 받았다.

```html
<script src="aphid.js"></script>
<script src="bmovie.js"></script>
<script src="seaserpent.js"></script>
<img src="deejay.gif" />
<img src="elope.gif" />
```

이런 페이지가 있다고 하면, 아래와 같은 순서로 실행된다.

```bash
aphid.js        ====xxx
bmovie.js              =====xx
seaserpent.js                 =====xx
deejay.gif                           =====
elope.gif                            =====
DOM Interactive                      *
image render                              *
```

여기서 `==`는 다운로드하는 작업을 의미하고, `xx`는 스크립트 파싱과 실행을 의미한다. DOM interactive는 브라우저가 HTML 구문 분석을 완효한 후에 실행된다.

이러한 접근 방식에는 많은 비효율이 존재한다. 스크립트는 뭐 순차적으로 실행될 순 있지만, 다운로드는 병렬로 진행할 수 있다. 또한 스크립트가 이미지와 같은 비 스크립트 리소스를 차단할 필요도 없다.

IE8을 필두로 많은 브라우저가 스크립트를 병렬로 다운로드 할 수 있는 `preloader`개념을 도입하기 시작했다. 이로 인해 페이지 속도가 엄청나게 빨라졌다.

```bash
aphid.js        ====xxx
bmovie.js       =====  xx
seaserpent.js   =====    xx
deejay.gif      =====
elope.gif       =====
DOM Interactive            *
image render               *
```

`preloader`를 활용하여 모든 리소스가 병렬로 다운로드 되는 것을 볼 수 있다. 여전히 DOM interactive는 세 리소스를 기다려야 하지만, 이전에 비해서 훨씬더 빠르게 동작하는 것을 볼 수 있다.

## 동기 스크립트는 HTML 구문 분석을 차단한다.

preloader는 동기식 스크립트가 다른 리소스의 다운로드를 차단하지 않도록 변경하여 웹 성능을 향상시켰다. 그러나 동기 스크립트는 여전히 HTML 구문 분석을 차단한다. HTML 구문 분석이 `<script/>` 태그에 도달하면 해당 스크립트가 다운로드되고, 구문 분석이 실행 될 때까지 중지된다. HTML 파서가 차단되면 사용가자 페이지의 컨텐츠를 보기 위해 기다려야 한다. 이러한 이유로 인해 앞선 예제에서, 이미지가 다 다운로드 되었음에도 나중에 뵤여지게 된다.

동기스크립트가 HTML 분석을 차단하는 것을 막기 위해, 개발자들은 스크립트를 비동기적으로 로드하는 방법을 찾기 시작했다. 모든 스크립트가 비동기로 동작할 필요는 없다. 페이지 렌더링에 있어서 중요한 스크립트는 동기적으로 로딩되어야 한다. 그러나 중요한 렌더링 이외의 요소는 비동기적으로도 할 수 있다. 2009년 이전에는 이런 것을 처리하기 위한 [꼼수](https://www.stevesouders.com/blog/2009/04/27/loading-scripts-without-blocking/)가 존재했다. 그리고, HTML에 async와 defer가 추가되었다.

## async와 defer

async와 defer는 HTML 파서를 차단하지 않고 스크립트를 로드할 수 있다는 점에서 유사하다. 즉, 둘다 사용자는 페이지를 더 빨리 볼 수 있다. 그러나 여기에 차이점이 존재한다.

- `async`로 로드된 스크립트는 다운로드가 완료되면 즉시 구문 분석을 하고 실행된다. 그에 반해 `defer`는 HTML 문서가 파싱되기 전까지 실행되지 않는다.
- `async`는 순서없이 로드가 가능하지만 `defer`는 마크업 순서대로 로딩된다.

### async

```html
<script async src="aphid.js"></script>
<script src="bmovie.js"></script>
<script src="seaserpent.js"></script>
<img src="deejay.gif" />
<img src="elope.gif" />
```

```bash
aphid.js        ====xxx
bmovie.js       =====  xx
seaserpent.js   =====    xx
deejay.gif      =====
elope.gif       =====
DOM Interactive            *
image render               *
```

`aphid`가 async였지만, 다운로드가 먼저 되었기 때문에 다른 스크립트 실행을 차단하고 먼저 실행되었다. 다시말해, `async`는 다운로드 된 뒤에 모든 동기 스크립트 실행을 차단해 버린다.

### defer

```html
<script defer src="aphid.js"></script>
<script src="bmovie.js"></script>
<script src="seaserpent.js"></script>
<img src="deejay.gif" />
<img src="elope.gif" />
```

```
aphid.js        ====     xxx
bmovie.js       =====xx
seaserpent.js   =====  xx
deejay.gif      =====
elope.gif       =====
DOM Interactive          *
image render             *
```

defer는 DOM이 상호작용이 가능해지는 시점에 실행된다. defer는 다운로드가 먼저 되었음에도 다른 동기 스크립트가 실행된 이후에 실행된 것을 볼 수 있다.

## defer를 더 선호해야하는 이유

`defer`는 항상 `async`와 동시에, 또는 그 이후에 스크립트 실행을 발생시킨다. 아마도 스크립트 중에서도 덜 중요한 것들을 `defer`나 `async`로 만들 것이다. 따라서 기본 렌더링 시간 외에 실행 될 수 있도록 `defer`로 하는 것이 좋다. `defer`는 동기 스크립트를 차단할 수 없지만, `async`는 스크립트 다운로드에 따라 차단할 수도 있다. 동기 스크립트는 일반적으로 페이지에서 중요한 내용을 담고 있으므로, 다른 작업이 방해하지 않도록 `defer`를 쓰는 것이 좋다.

이러한 잘못된 최적화의 예는 종종 찾아볼 수 있다. [예전 인스타그램 웹페이지 테스트 결과](https://www.webpagetest.org/result/161204_ZY_9a82d23e52565194cb985a10cf8d5465/2/details/)를 한번 살펴보자. 4번째 스크립트가 `async`로 로딩되는 것을 볼 수 있다. 그리고 [Timeline](https://www.webpagetest.org/chrome/timeline.php?test=161204_ZY_9a82d23e52565194cb985a10cf8d5465&run=2)을 살펴보면, 이 스크립트가 다른 스크립트 보다 0.6초정도 먼저 (c0456c81549b.js) 실행되서 다른 스크립트를 블록했다.

반대로 yelp의 [웹 페이지 테스트결과](https://www.webpagetest.org/result/161206_RP_DBM/3/details/)를 보자. 두번째 스크립트가 defer로 로딩되어있는데, 다운로드가 된 이후에 실행은 `DOM Content Loaded` 이후에 이루어졌다. 따라서 다른 동기스크립트가 먼저 로딩 되었고, 렌더링이 더 빨리 이루어졌다.

## 결론

결론은 DOM Interactive 까지 defer 스크립트 실행을 지연하는 것과는 다르게, async는 다운로드가 빨리 되서 실행이 먼저되버리고, 다른 스크립트 분석을 멈춰버리게 하는 위험성을 가지고 있다는 것이다. 따라서, DOM Interative 시간을 아는 것이 굉장히 중요하다. [Alexa Top 100](https://www.alexa.com/topsites)에 따르면 2016년 11월 기준 DOM interactive의 중앙값은 2.1초이지만, 하위 95%의 경우에는 11.2초이다. 이정도 값이면, async 스크립트가 DOM Interative 이전에 다운로드를 마치고, 페이지 렌더링을 방해하고 있는지 합리적으로 의심해 볼법하다.

스크립트에서 async를 사용하면, defer로 바꿔서 렌더링이 더 빨리 되는지 확인해보자.

출처: https://calendar.perfplanet.com/2016/prefer-defer-over-async/


스크립트 실행 최적화를 위해 잘 고민해봐야 한다.

왜 Async 보다는 Defer를 써야할까

브라우저가 어떻게 스크립트를 스케쥴링 하고 실행하느냐에 따라서 웹페이지 성능에 큰 영향을 미친다. `<script defer />` `<link rel=preload>` 등등 스크립트 로딩에 영향을 미치는 다양한 기술들이 있으며 이러한 기술을 브라우저에서 어떤 순서로 처리하는지 이해하는 것도 중요하다.

### Table of Contents

### `<head />` 안에 있는 `<script />`

#### 로딩 우선 순위

중간, 높음

#### 실행 우선 순위

매우높음, 파서 실행을 멈춤

### 사용처

- First Meaningful Paint, First Contentful Paint 컨텐츠
- 다른 스크립트 이전에 실행해야 되는 스크립트

#### 예

- 프레임워크 런타임 (정적 렌더링이 아닌 경우)
- 폴리필
- 전체 페이지 DOM 구조에 영향을 미치는 A/B 테스트

### `<link rel=preload` + `<script async>` 또는 `<script type=module async />`

#### 로딩 우선 순위

중간, 높음

#### 실행 우선 순위

높음, 파서 실행을 방해함

#### 사용처

- 중요한 컨텐츠를 만드는 스크립트 (First Meaningful Paint)
- 그러나 페이지 상단 (above-the-fold)에는 영향을 미치지 않는 요소
- 동적으로 컨텐츠를 넣기 위해 네트워크 fetch를 실행하는 스크립트
- imports한 요소들이 모두 fetch된 이후 즉시 실행되어야 하는 스크립트는, `<script async type=module />`

#### 예

- `<canvas />` 에 그려야 하는 것

### `<script async />`

#### 로딩 우선 순위

제일 낮음, 낮음

#### 실행 우선 순위

높음, 파서를 방해함

#### 사용처

사용할 때 주의 해야 한다. (https://calendar.perfplanet.com/2016/prefer-defer-over-async/) 요즘 들어 중요하지 않은 스크립트를 로딩 할 때 많이 사용하고 있지만, 로딩 우선순위만 낮을 뿐 실행 우선순위는 높다는 것을 기억해야 한다.

### `<script defer />`

#### 로딩 우선 순위

제일 낮음, 낮음

#### 실행 우선 순위

매우 낮음, `<body />` 최하단에 있는 `<script />`가 실행된 이후에 실행

#### 사용처

- 중요하지 않은 컨텐츠를 만드는 스크립트
- 페이지 방문자의 50% 이상정도가 사용하는 중요한 상호작용 기능

#### 예

- 광고
- 프레임 워크 런타임 (클라이언트 또는 서버사이드 렌더링)

### `<body />` 최하단에 있는 `<script />`

#### 로딩 우선 순위

중간, 높음

#### 실행 우선 순위

낮음, 파서의 작업이 끝나기를 기다림

#### 사용처

이 방법은 생각만큼 낮은 우선순위로 실행되지 않는다.

### `<body />` 최하단에 있는 `<script defer />`

#### 로딩 우선 순위

가장 낮음, 낮음, 큐의 모든 작업이 끝난 후에 실행됨.

#### 실행 우선 순위

매우 낮음. `<body />` 최하단에 있는 `<script />` 보다도 낮음.

#### 사용처

- 사용자들이 가끔 사용하는 상호작용 기능

#### 예

- '연관된 기사들' 같은 컨텐츠 (중요도가 낮은)
- '피드백을 주세요' 같은 기능들 (역시 중요도가 낮은)

### `<link rel=prefetch />` + `<script/>`

#### 로딩 우선 순위

작업이 없을 때, 가장낮음

#### 실행 우선 순위

스크립트가 어떻게 작동하느냐에 따라 다름.

#### 사용처

다음 페이지 탐색을 위한 중요한 기능을 제공하는 스크립트

#### 예

- 다음 라우팅을 위한 자바스크립트 번들

### 마치며

- 브라우저 별로 동작이 통일되어 있지 않으므로 사용할 때 주의를 필요로 한다.
- 크롬에서 스크립트 우선순위를 알아내기 위해서는 네트워크 탭에서 Priority를 보면된다.

![priorities](https://addyosmani.com/assets/images/tweet-priorities@3x.png)

출처: https://addyosmani.com/blog/script-priorities/


크롬에서 자바스크립트를 로딩하는 순서

크롬에서 자바스크립트 로딩 순서

리액트로 웹페이지를 만들때, 최대한 작은 단위로 쪼개서 이를 개별 컴포넌트로 만들고 조립하는 방식을 택한다. 그런 방식을 택하다 보면, 십중 팔구 아래와 같은 구조로 구성하게 된다.

```javascript
function App() {
  return (
    <div>
      <MainNav />
      <Homepage />
    </div>
  )
}
function MainNav() {
  return (
    <div>
      <GitHubLogo />
      <SiteSearch />
      <NavLinks />
      <NotificationBell />
      <CreateDropdown />
      <ProfileDropdown />
    </div>
  )
}
function Homepage() {
  return (
    <div>
      <LeftNav />
      <CenterContent />
      <RightContent />
    </div>
  )
}
function LeftNav() {
  return (
    <div>
      <DashboardDropdown />
      <Repositories />
      <Teams />
    </div>
  )
}
function CenterContent() {
  return (
    <div>
      <RecentActivity />
      <AllActivity />
    </div>
  )
}
function RightContent() {
  return (
    <div>
      <Notices />
      <ExploreRepos />
    </div>
  )
}
```

위 구조는 실제 깃헙 홈페이지를 React로 구성한다고 했을 때의 모습이다. 매우 일반적인 구조고, 작동하는데 문제는 없지만, 아래와 같은 구조를 사용해본다면 어떨까?

```javascript
function App() {
  return (
    <div>
      <MainNav>
        <GitHubLogo />
        <SiteSearch />
        <NavLinks />
        <NotificationBell />
        <CreateDropdown />
        <ProfileDropdown />
      </MainNav>
      <Homepage
        leftNav={
          <LeftNav>
            <DashboardDropdown />
            <Repositories />
            <Teams />
          </LeftNav>
        }
        centerContent={
          <CenterContent>
            <RecentActivity />
            <AllActivity />
          </CenterContent>
        }
        rightContent={
          <RightContent>
            <Notices />
            <ExploreRepos />
          </RightContent>
        }
      />
    </div>
  )
}
function MainNav({ children }) {
  return <div>{children}</div>
}
function Homepage({ leftNav, centerContent, rightContent }) {
  return (
    <div>
      {leftNav}
      {centerContent}
      {rightContent}
    </div>
  )
}
function LeftNav({ children }) {
  return <div>{children}</div>
}
function CenterContent({ children }) {
  return <div>{children}</div>
}
function RightContent({ children }) {
  return <div>{children}</div>
}
```

이렇게 코드를 바꾼 구조적인 아이디어는, 대부분의 구성요소가 단순히 레이아웃만 담당한다는 것이다. 이들은 상태를 스스로 관리하기 위해 무언가 일을 하는 코드는 적고 (물론 자체적인 상태관리가 필요할 수도 있지만) 단순히 상태를 받아서 이를 나타나야 하는 페이지에 표시하는 역할만 한다.

만약 첫번째 예제와 같은 구조를 가지고 있다면, `prop-drilling`이 발생하게 된다. `<App/>` 에서 `<HomePage />`로 다시, `<CenterContent />`에서 `<AllActivity />`로 가는 등, prop을 넘기고 넘기는 과정이 반복된다. 이런 구조를 보게 되면 사람들은 아마도 React API인 `context` 를 사용하여 해결하려 할 것이다. 하지만 그러기 전에, 좀더 간단하게 생각해볼 필요가 있다. 자체적인 상태관리가 필요없고, 단순히 레이아웃인 컴포넌트라면 `prop`을 직접적으로 넘기면 된다. `<App />` 에서 `<AllActivity/>`로.

너무 많은 사람들이 `prop-drilling`에서 `context`로 섣불리 넘어가버리려고 한다. 더 많은 컴포넌트를 염두에 두고, 구성요소를 구조화 한다면 더 유지 보수가 쉬워지고, 성능및 관리 문제가 줄어들 것이다.

출처: https://epicreact.dev/one-react-mistake-thats-slowing-you-down


처음부터 구조를 잘 생각해 둔다면 성능상 에 이점을 가져갈 수 있다.

Javascript 24

(함수형으로) 자바스크립트로 HTML 버튼 중복 클릭 방지하기

EventEmitter 구현해보기

왜 Async 보다는 Defer를 써야할까

크롬에서 자바스크립트 로딩 순서

Prop drilling 해결을 위해 context를 사용하기 전에 구조를 생각해보자.