## Table of Contents

[원문](https://reactjs.org/blog/2020/08/10/react-v17-rc.html)을 대충 요약한 글입니다.

## 새로운 기능은 없다.

리액트 17.0은 새로운 버전이 기능이 추가되는 대신에, 리액트 그 자체의 업그레이드에 초점을 두고 있다.

## 점진적 업그레이드

이전까지 리액트 버전 업그레이드는, 중간이 없었다. 이전 버전을 유지하거나, 새버전을 깔거나 둘중에 하나 였다. 이 전략이 슬슬 한계에 부딪히고 있다. 예를 들어 [legacy context api](https://reactjs.org/docs/legacy-context.html)의 경우에는 이를 자동으로 업그레이드할 방법이 존재 하지 않는다. 대부분의 애플리케이션이 이 api를 쓰고 있지 않지만, react에서는 여전히 이들을 지원해야 한다. 그래서 구 버전 앱들을 뒤로 남겨두고 지원을 하지 않을지, 아니면 계속해서 지원해야할지를 선택해야 하는데, 두 방법 모두 좋지는 않다. 따라서 새로운 방법을 염두해 두고 있다.

### 리액트 17에서는 점진적으로 업그레이드가 가능하다.

이전 버전 업그레이드는, 전체 앱을 한번에 업그레이드 해야 했다. 이는 오래되거나 관리되지 않은 코드에서 사용하기에는 너무나 힘든 문제였다. 그래서 이후 부터는 두가지 옵션을 주려고 한다. 첫번째 옵션은 이전에 그랬던 것 처럼 한번에 전체 애플리케이션을 업데이트 하는 것이다. 그리고 다른 하나는 점진적으로 하나씩 업그레이드 하는 것이다. 예를 들어, 대부분의 앱을 리액트 18로 올릴 수 있지미나, lazy-loading 다이얼러그나 일부 라우트는 리액트 17 상태로 둘 수 있는 것이다.

그렇다고 꼭 점진적 업그레이드를 해야하는 것은 아니다. 여전히, 한번에 앱을 업그레이드 하는 것이 최선의 해결책이다. 그러나 사이즈가 큰 애플리케이션의 경우 이러한 옵션을 선택하기에 무리가 있을 수 있으며, 리액트 17부터 그것을 지원하려고 한다.

이런 점진적 업그레이드를 위해서는 리액트 이벤트 시스템을 몇가지 변경해야 하고, 이러한 변화가 breaking change가 될 수 있어서 메인 버전을 업데이트 하였다. 약 10만개 이상의 컴포넌트 들 중에, 실제로 변화가 있을 것으로 예상되는 것은 20개 정도다.

[데모버전](https://github.com/reactjs/react-gradual-upgrade-demo/) 레포를 참고해보자.

## 이벤트 위임의 변화

먼저 리액트에서 이벤트 핸들러를 붙이는 코드를 살펴보자

```jsx
<button onClick={handleClick}>
```

바닐라 DOM에서는 이렇게 작동할 것이다.

```javascript
myButton.addEventListener('click', handleClick)
```

그러나 대부분의 이벤트의 경우, 리액트는 이벤트가 실제 선언된 DOM에 붙이지 않는다. 대신, 리액트는 하나의 이벤트당 하나의 핸들러를 document node에 붙인다. 이는 이벤트 위임이라고 불린다. 큰 어플리케이션 구조에서 성능의 이점을 볼 수 있는 것 이외에도, [replaying events](https://twitter.com/dan_abramov/status/1200118229697486849)와 같은 기능을 추가할 때도 유용하게 사용할 수 있다.

리액트는 첫 릴리즈 때 부터 이벤트 위임을 자동으로 실행해 왔다. DOM이벤트가 도큐먼트에서 실행되면, 리액트는 어떤 컴포넌트에서 실행되어야 하는지 살펴보고, 리액트는 해당 컴포넌트에서 부터 위로 버블링을 시작한다. 그러나 이 뒤에는, 리액트가 이미 이벤트 핸들러를 붙인 곳에서 네이티브 이벤트가 이미 도큐먼트 레벨까지 버블링되어 있었다.

그러나, 이부분이 점진적 업그레이드 전략에서 문제가 되었다.

만약 페이지 내에서 여러 개의 리액트 버전이 존재한다면, 이벤트 핸들러가 최상단에 붙게 될 것이다. 이는 `e.stopPropagation()`을 어기게 된다. 만약 nested tree에서 이벤트에 대해 전파를 중지하더라도, 바깥 트리에서는 계속해서 이벤트를 받게 된다. 이는 리액트 내부에서 서로다른 버전의 tree를 갖는 것을 어렵게 만든다.

리액트 17부터, 이벤트 핸들러를 더이상 큐먼트의 최상 노드인 `html`에 붙이 지 않는다. 대신, 리액트 트리가 렌더링 되는 DOM Container에 이벤트를 붙이게 된다.

```javascript
const rootNode = document.getElementById('root')
ReactDOM.render(<App />, rootNode)
```

리액트 16 이하에서는, 이벤트 들이 `document.addEventListener()`로 이루어진다. 그러나 17버전 부터는 `rootNode.addEventListener()`로 변경된다.

번역이 거지 같아서 정리

- 특정 노드에 매번 이벤트 리스너를 붙이는 대신, 이벤트 리스너를 부모에게 추가하는 것이 이벤트 위임이다.
- 리액트는 이러한 이벤트 위임을 적극 활용하고 있었으며, 위임의 대상은 `document`였다.
- `document`에서 이벤트가 발생하면, 리액트 이벤트 시스템이 실제로 이벤트가 발생한 컴포넌트를 찾고, 이벤트 버블링으로 상위 컴포넌트에 전달함
- 문제는 여기에서 발생하는데, 네이티브 이벤트는 document 까지 이벤트가 버블링됨 (당연한거 아님?)
- 만약 한 페이지에 여러가지 리액트 버전이 존재한다면, 현재 구조상 모든 이벤트 들이 document에 이벤트를 위임할 것이다.
- 만약 이벤트가 발생한 컴포넌트를 찾아서, 이벤트 전파를 중단하더라도 (`stopPropagation`) 앞서 설명한 것처럼 네이티브 이벤트는 document까지 알아서 버블링이 될 것이기 때문에, 사이드 이펙트가 발생할 수 있다.

[추가 사례 분석](https://github.com/facebook/react/pull/8117)

- atom에서는 여러개 리액트 인스턴스를 생성한뒤, 한개의 앱에서 활용하고 있었다.
- 그러나 두개의 리액트 트리가 nested되어 있는 상태에서는 `e.stopPropagation`이 잘 동작하지 않는 문제가 있었다.
- 그 이유는 두개의 이벤트 리스너가 각각의 트리에 존재했고, 따라서 이들이 각각 전파가 취소되지 않는 문제가 있었다.
  - React version A로 돌아가는 `OuterComponent`와 서로 다른 버전으로 돌아가는 `InnerComponent`가 존재한다고 가정해보자.
  - `InnerComponent`는 이벤트 리스너를 inner tree의 최상단에 이벤트를 부착하려 할 것이고, `OuterComponent`는 해당 컴포넌트의 최상단에 붙이려고 할 것이다.
  - `InnerComponent`에서 클릭이 발생하면, 이 내부버전의 리액트가 트리 더 깊숙히 있기 때문에 이벤트에 대해서 먼저 알아 차릴 것이다.
  - 그리고 이는 `InnerComponent`의 이벤트를 발생시킬 것이고, 따라서 리액트는 `e.stopPropagation()`을 발생시킨다.
  - 이벤트 전파가 중단 되었으므로, 외부버전의 리액트에서는 이를 알아챌 수 없다.
- 이러한 문제를 `html`이 아닌 컴포넌트가 최초에 렌더링되는 `dom`노드에 이벤트를 붙이면서 해결할 수 있음.
- 서로 다른 리액트 버전 (=서로 다른 리액트 인스턴스)을 가지고 있다 하더라도, 이벤트가 부착되는 element가 각각 다르기 때문에 이러한 문제에서 자유로울 수 있음.

요약

- 서로다른 리액트 버전이 페이지 내에서 존재하는 경우 이벤트가 발생했을 시, 리액트에서 일어나는 버블링과 `stopPropagation`때문에 일부 이벤트 실행 여부를 알아채지 못할 수 있음.

![React 17 event delegation](https://reactjs.org/static/bb4b10114882a50090b8ff61b3c4d0fd/1e088/react_17_delegation.png)

이러한 변화로 인해, 한버전에 의해 관리되는 리액트 트리 내부에 서로 다른 리액트 버전을 관리하는 것이 안전해졌다. 이를 위해 두 버전이 모두 최소 리액트 17 버전 이상이어야 한다.

이는 리액트가 다른 기술과 사용하는 것을 더욱 용이하게 한다. 만약 외부에 jQuery가 존재하고, 내부에는 리액트가 존재한다면 이제 예상대로 이벤트 전파를 jQuery단까지 막을 수 있다.

이 변화로 인해, 코드에 몇 가지 변화가 필요할 수 있다. 예를 들어, DOM에 `document.addEventListener`를 활용하여 수동으로 이벤트를 붙여서 리액트의 모든 이벤트를 감지하는 코드가 존재할 수 있다. 리액트 16버전 에서는 이러한 코드가 가능했지만, 리액트 17 부터는 전파가 막히게 되므로 `document`에서도 이벤트가 발생하는지 알 수 없다.

```javascript
document.addEventListener('click', function () {
  // This custom handler will no longer receive clicks
  // from React components that called e.stopPropagation()
})
```

위와 같은 코드는 이제 , `capture: true`를 추가해야 한다.

```javascript
document.addEventListener(
  'click',
  function () {
    // Now this event handler uses the capture phase,
    // so it receives *all* click events below!
  },
  { capture: true },
)
```

결과적으로, 리액트 17의 이벤트 전파가 실제 DOM과 비슷해졌다고 볼 수 있다.

## 기타 Breaking Changes

### 브라우저 최적화

- `onScroll` 관련 이벤트 버블링을 제거하여, 네이티브 `onScroll` 이벤트가 버블링 되지 않는 것과 마찬가지로 동일하게 작동하도록 한다.
- `onFocus` `onBlur`가 네이티브 이벤트인 `focusin` `focusout`을 이용하도록 변경 (이 변경은 실제 버블링에 영향을 미치지 않는다. 리액트에서는 항상 `onFocus`이벤트는 버블링 되고, 리액트 17에서도 마찬가지 일 것이다.)
- Capture phase event (`onClickCapture`)가 실제 브라우저 리스너를 사용하도록 변경

### No Event Pooling

이벤트 풀링이 제거된다. 리액트는 오래된 브라우저의 성능 향상을 위해서 서로 다른 이벤트 사이에서 이벤트 객체를 재사용하고, 모든 이벤트 필드를 null로 설정해두었다. 리액트 16 및 이전 버전에서는 `e.persist()`를 호출하여 이벤트를 적절히 사용하거나, 필요한 속성을 미리 읽어와야 했다.

```jsx
function handleChange(e) {
  setData((data) => ({
    ...data,
    // 리애트 16버전에서는 에러가 났다.
    text: e.target.value,
  }))
}
```

이제 리액트 17에서 부터는 예상처럼 동작한다. 이벤트 풀링 최적화가 완전히 삭제 되었기 때문에, event 필드를 언제든지 원할때 마다 읽어올 수 있다.

사실 breaking changes라고는 했지만, 페이스북에서는 어떠한 문제점도 찾지 못했다. 리액트에 `e.persist()`가 존재하긴 하지만, 실제로는 아무런 동작을 하지 않는다는 것을 알아두길 바란다.

### Effect Cleanup Timing

`useEffect` 라이프 사이클 메서드의 Cleanup 타이밍을 일관되게 동작하도록 만들고 있다.

```javascript
useEffect(() => {
  // effect
  return () => {
    // cleanup
  }
}
```

대부분의 경우 스크린 업데이트를 지연시킬 필요가 없으므로, `useEffect` cleanup은 변경사항이 스크린에 반영된 직후 비동기적으로 작동하도록 변경되었다. (스크린 엽데이트를 지연시켜야 하는 경우 `useLayoutEffect`)

기존에 `useEffect` cleanup은 16버전에서는 동기적으로 실행하기 위해 사용되었다. `componentWillUnMount`와 유사하게, 탭 변경과 같은 큰 사이즈의 페이지 전환에서 성능 저하를 유발한다.

이 변경사항 이후, 컴포넌트가 언마운트 되면 화면이 업데이트 된후 `cleanup`이 실행된다.

또한, 돔 트리에 위치한 순서와 같은 순서로 실행되도록 보장한다.

그러나 위의 변화로 인해 아래와 같은 코드에서 에러가 나는 경우가 있다.

```javascript
useEffect(() => {
  someRef.current.someSetupMethod()
  return () => {
    someRef.current.someCleanupMethod()
  }
})
```

`someRef.current` 는 mutable 하기 때문에, cleanup 함수가 실행되는 순간에 null 이 될 가능성이 있다. 따라서 아래와 같이 고쳐줘야 한다.

```javascript
useEffect(() => {
  const instance = someRef.current
  instance.someSetupMethod()
  return () => {
    instance.someCleanupMethod()
  }
})
```

### undefined를 return 할 경우 일관되게 에러 발생

16버전 이하에서는, 모든 컴포넌트에서 undefined를 리턴할 경우 항상 에러를 발생했다. 하지만 코딩 실수로 인해, `forwardRef` `memo`컴포넌트 에서는 이러한 에러 처리가 누락되어 있었는데, 이제 부터 에러처리가 추가되었다.

```javascript
let Button = forwardRef(() => {
  // We forgot to write return, so this component returns undefined.
  // React 17 surfaces this as an error instead of ignoring it.
  ;<button />
})

let Button = memo(() => {
  // We forgot to write return, so this component returns undefined.
  // React 17 surfaces this as an error instead of ignoring it.
  ;<button />
})
```

렌더링을 아무것도 하지 않기 위해서는, null을 리턴하면 된다.

### Native Component Stacks

브라우저에서 에러 발생시, 자바스크립트 함수이름과 해당하는 위치를 추적하여 에러 메시지에서 보여줬지만, javascript stack이 리액트 트리 구조를 파악하고 진단하기에 충분하지 않았다. 특히 리액트는 소스코드에서 함수가 어디 선언되있는지 모르기 때문에, 콘솔에서 에러를 클릭해서 살펴볼 수 없었다. 또한, 프로덕션 모드에서 더욱 쓸모가 없었다. 일반적인 자바스크립트 스택이 소스맵과 함께 함수명을 복구할 수 있었던 반면, 리액트 스택은 번들 사이즈(에러를 안볼 것인지) 와 프로덕션 스택 (에러를 볼 것인지) 사이에서 선택을 해야 했다.

이를 해결하기 위해, 새로운 메커니즘을 사용하여 component stacks를 생성한다. 이를 통해 프로덕션 환경에서도 리액트 컴포넌트 스택을 추적할 수 있다.

### Private Exports 삭제

- React Native for Web에서 사용하던 private exports를 삭제하였다.
- `ReactTestUtils.SimulateNative` 헬퍼 메소드를 삭제하였다.


리액트 17.0 새로운 기능은 추가되지 않을 예정. 점진적 업그레이드 추가, 이벤트 위임 방식 변경이 주요 변경 내용인 것 같네용.

리액트 v17.0 살펴보기

## Table of Contents

출처는 [여기](https://devblogs.microsoft.com/typescript/announcing-typescript-4-0/)

## 가변 튜플

튜플은 원소의 수와, 각 원소의 타입이 정확히 지정된 배열의 타입을 지정하고 싶을 때 사용하는 방법이다.

```typescript
const hello: [string, number] = ['yc', 33]
```

먼저 tuple 타입 신택스에 있는 spread 연산자 `...`가 제네릭하게 될 수 있다. (외부에서 타입을 지정할 수 있다.) 블로그에서 나온 예시로는, `tail`함수를 예로 들고 있다.

```typescript
// 이 ... 이 3.x 버전 이하에서는 에러가 났지만, 4.0 부터는 쓸 수 있게 되었다.
function tail<T extends any[]>(arr: readonly [any, ...T]) {
  const [_ignored, ...rest] = arr
  return rest
}

const myTuple = [1, 2, 3, 4] as const
const myArray = ['hello', 'world']

// type [2, 3, 4]
const r1 = tail(myTuple)

// type [2, 3, 4, ...string[]]
const r2 = tail([...myTuple, ...myArray] as const)
```

[예제코드](https://www.typescriptlang.org/play?ts=4.0.2#code/GYVwdgxgLglg9mABFAhjANgHgCqIKYAeUeYAJgM6IpgCeA2gLoB8AFCgE7sBci7eKpBOhqI61GgBpEAOlnYGASkQBvAFCINiCAnJRRAfRgBzMHD6kps6X10NEAXiqcA3Os18oIdkhtRXAX1VVbTBdRABbGmwQAAd0PAdRAEYpACYpAGYpABY7FEoQ3VdCvUiAQU4UEUc6ACIACzx0dDhaqVqAdzN0UlqGV1UAekHkGhiEunTELMRc4J09diTE1AwWSOi4vAUB4dHx0SmZ7MtZXXYYMCNGBnnQxdSVtHQWOisN2PjT6XLKmjyCgsdkA)

또한 tuple 내부에서 전개 연산자를 어디서든 쓸 수 있다.

```typescript
type Strings = [string, string]
type Numbers = [number, number]

// [string, string, number, number, boolean]
type StrStrNumNumBool = [...Strings, ...Numbers, boolean]
```

아마도 함수 합성을 하는데 있어서 중요한 역할을 할 것으로 보인다. 블로그에 예제에서 보여준 것처럼, 자바스크립트의 `bind`함수에 타입체크를 할 때도 많이 이용될 것으로 보인다.

[다양한 예제들](https://github.com/microsoft/TypeScript/pull/39094)

```typescript
// Variadic tuple elements

type Foo<T extends unknown[]> = [string, ...T, number]

type T1 = Foo<[boolean]> // [string, boolean, number]
type T2 = Foo<[number, number]> // [string, number, number, number]
type T3 = Foo<[]> // [string, number]

// Strongly typed tuple concatenation
function concat<T extends unknown[], U extends unknown[]>(
  t: [...T],
  u: [...U],
): [...T, ...U] {
  return [...t, ...u]
}

const ns = [0, 1, 2, 3] // number[]

const t1 = concat([1, 2], ['hello']) // [number, number, string]
const t2 = concat([true], t1) // [boolean, number, number, string]
const t3 = concat([true], ns) // [boolean, ...number[]]

// Inferring parts of tuple types
declare function foo<T extends string[]>(...args: [...T, () => void]): T

foo(() => {}) // []
foo('hello', 'world', () => {}) // ["hello", "world"]
foo('hello', 42, () => {}) // Error, number not assignable to string

// Inferring to a composite tuple type
function curry<T extends unknown[], U extends unknown[], R>(
  f: (...args: [...T, ...U]) => R,
  ...a: T
) {
  return (...b: U) => f(...a, ...b)
}

const fn1 = (a: number, b: string, c: boolean, d: string[]) => 0

const c0 = curry(fn1) // (a: number, b: string, c: boolean, d: string[]) => number
const c1 = curry(fn1, 1) // (b: string, c: boolean, d: string[]) => number
const c2 = curry(fn1, 1, 'abc') // (c: boolean, d: string[]) => number
const c3 = curry(fn1, 1, 'abc', true) // (d: string[]) => number
const c4 = curry(fn1, 1, 'abc', true, ['x', 'y']) // () => number
```

## 튜플 요소에 이름 지정하기

튜플에 이름을 지정할 수 있다.

```typescript
type Range = [start: number, end: number]
type Foo = [first: number, second?: string, ...rest: any[]]
```

대신 하나라도 이름을 지정하면, 그 뒤에도 주르륵 이름을 지정해야 한다.

```typescript
type Bar = [first: string, number]
// error! Tuple members must all have names or all not have names.
```

## 생성자에서 클래스 프로퍼티 추론

`noImplicitAny` 속성이 켜져 있다면, 아래와 같은 추론이 가능해진다.

```typescript
class Square {
  // Previously: implicit any!
  // Now: inferred to `number`!
  area
  sideLength

  constructor(sideLength: number) {
    this.sideLength = sideLength
    this.area = sideLength ** 2
  }
}
```

그리고 위의 정보만으로는 추론할 수 없는 경우에는 `undefined`에러가 난다.

```typescript
class Square {
  sideLength

  constructor(sideLength: number) {
    if (Math.random()) {
      this.sideLength = sideLength
    }
  }

  get area() {
    return this.sideLength ** 2
    //
    // error! Object is possibly 'undefined'.
  }
}
```

사실 저렇게 하는 것보다, 명확하게 타입을 선언하고 초기화 해주는 것이 낫다.

## 간략 할당 연산자

자바스크립트에는 아래와 같이 간략하게 할당하는 연산자가 존재한다.

```javascript
// Addition
// a = a + b
a += b

// Subtraction
// a = a - b
a -= b

// Multiplication
// a = a * b
a *= b

// Division
// a = a / b
a /= b

// Exponentiation
// a = a ** b
a **= b

// Left Bit Shift
// a = a << b
a <<= b
```

새로운 ECMAScript의 표준에 맞춰, 타입스크립트에도 `&&=` `||=` `??=` 도 지원하게 된다.

```typescript
a = a && b
a = a || b
a = a ?? b
```

```typescript
const obj = {
  get prop() {
    console.log('getter has run')

    // Replace me!
    return Math.random() < 0.5
  },
  set prop(_val: boolean) {
    console.log('setter has run')
  },
}

function foo() {
  console.log('right side evaluated')
  return true
}

console.log('This one always runs the setter')
obj.prop = obj.prop || foo()

console.log('This one *sometimes* runs the setter')
obj.prop ||= foo()
```

## catch binding에 unknown사용

이전 까지는 에러 객체 타입이 `any`여서 아무렇게나 사용할 수 있었다. 그러나 이제 `unknown`으로 간주되면서, 보다 안전하게 사용될 수 있다.

```typescript
try {
  // ...
} catch (e) {
  // error!
  // Property 'toUpperCase' does not exist on type 'unknown'.
  console.log(e.toUpperCase())

  if (typeof e === 'string') {
    // works!
    // We've narrowed 'e' down to the type 'string'.
    console.log(e.toUpperCase())
  }
}
```

그러나 이 기능은 개발자들에게 익숙해기 전까지 `--strict`모드를 켜놔야만 적용된다. 조만간 이를 위한 lint룰도 추가될 예정이다.

## Custom JSX Factory

JSX에서 [fragment](https://reactjs.org/docs/fragments.html)란 자식 엘리먼트 여러개를 반환하는 JSX 엘리먼트 타입을 의미한다. 과거 타입스크립트에 프래그먼트를 추가할 때는 별로 이에 대한 고민이 이뤄지지 않았지만, 현재는 많은 라이브러리들이 JSX를 사용하며 이에 관련된 API의 지원도 늘려가고 있다.

타입스크립트 4.0부터 `jsxFragmentFactory` 옵션을 사용해서 프래그먼트 팩토리를 커스터마이징 할 수 있다.

이렇게 하면 대신 React의 `Fragment`대신 `Fragment`를, `createElement`대신 `h`를 사용해야 한다.

`tsconfig.json`

```json
{
  "compilerOptions": {
    "target": "esnext",
    "module": "commonjs",
    "jsx": "react",
    "jsxFactory": "h",
    "jsxFragmentFactory": "Fragment"
  }
}
```

파일마다 JSX 팩토리를 다르게 사용하려면 `/** @jsxFrag */` 주석을 함께 사용해야 한다. 아래 예를 보자.

```typescript
// Note: these pragma comments need to be written
// with a JSDoc-style multiline syntax to take effect.
/** @jsx h */
/** @jsxFrag Fragment */

import { h, Fragment } from 'preact'

let stuff = (
  <>
    <div>Hello</div>
  </>
)
```

위 코드는 아래 처럼 빌드 된다.

```javascript
// Note: these pragma comments need to be written
// with a JSDoc-style multiline syntax to take effect.
/** @jsx h */
/** @jsxFrag Fragment */
import { h, Fragment } from 'preact'
let stuff = h(Fragment, null, h('div', null, 'Hello'))
```

## `--noEmitOnError` 빌드 시에 속도 향상

이전 버전 까지는 `----incremental`를 `--noEmitOnError`와 함께 사용하면 빌드가 매우 느렸다. 이는 `--noEmitOnError` 플래그를 사용하면, 이전 컴파일 결과에 대한 정보가 `.tsbuildinfo`파일에 캐싱되지 않았기 때문이다. 그리고 이를 해결해서 속도를 향상 시켰다.

## `--incremental`과 `--noEmit`

위와 동일

## VSCode 에디터 지원 개선

VSCode에서 원하는 타입스크립트 버전을 선택할 수 있도록 한다.

## 옵셔널 체이닝 지원

- 옵셔널 체이닝 지원
- null 병합연산자 지원

## `/** @deprecated */` 지원

JSDoc 에서 `/** @deprecated */`를 사용할 수 있도록 지원한다.

## 에디터 시작시 파셜 시맨틱 모드 지원

에디터 실행시간이 길다는 유저들의 불만이 많았다. 이를 해결 하기 위해 언어 지원 서비스 전체가 로딩되기 전에 바로 현재 파일에서 활용할 수 있는 부분 시맨틱 모드를 추가했다. 이는 에디터를 실행했을 때 현재 파일 만이라도 언어지원 서비스를 지원하는 것이다.

좌측 (구버전)과 우버전 (신버전) 을 비교하면 확연한 속도 차이를 느낄 수 있다.

https://devblogs.microsoft.com/typescript/wp-content/uploads/sites/11/2020/08/partialModeFast.mp4

## 더 똑똑해진 자동 임포트

타입스크립트로 작성된 라이브러리라 할지라도, 프로젝트에 한번도 로드 되지 않은 임포트 문이 자동으로 불러와지지 않는 문제가 있었다. 이는 자동 로드 기능이 해당 프로젝트에 한번이라도 로드된 패키지들을 대상으로만 동작하기 때문이다.

를 보완하기 위해, `package.json`의 `dependencies`와 `peerDependencies`를 처리하는 로직을 따로 추가했으며, 이 정보는 auto import 를 위해서만 사용된다.

## Breaking Changes

### `lib.d.ts` 수정

`lib.d.ts`가 수정되었다. 특히, DOM 타입 관련된 부분의 수정이 있었다. 그중 가장 유의깊게 봐야할 것은 [document.origin](https://developer.mozilla.org/en-US/docs/Web/API/Document/origin)대신에 [self.origin][https://developer.mozilla.org/en-us/docs/web/api/windoworworkerglobalscope/origin]를 사용하는 것이다.

### 프로퍼티, 게터, 세터 오버라이딩 금지

이전 버전까지는 `useDefineForClassFields`가 있어야만 오류로 처리했지만, 이제부터는 이 옵션이 없어도 에러가 발생한다. 이는 상속관계에서만 발생한다.

```typescript
class Base {
  get foo() {
    return 100
  }
  set foo() {
    // ...
  }
}

class Derived extends Base {
  foo = 10
  //  ~~~
  // error!
  // 'foo' is defined as an accessor in class 'Base',
  // but is overridden here in 'Derived' as an instance property.
}
```

```typescript
class Base {
  prop = 10
}

class Derived extends Base {
  get prop() {
    //  ~~~~
    // error!
    // 'prop' is defined as a property in class 'Base', but is overridden here in 'Derived' as an accessor.
    return 100
  }
}
```

### 옵셔널 항목만 delete 가능

`strictNullChecks`가 켜져 있는 상태에서 delete를 사용하면, 그 대상이 반드시 `any` `unknown` `never`이거나 옵셔널 항목이어야 한다. 그렇지 않으면 에러가 발생한다.

```typescript
interface Thing {
  prop: string
}

function f(x: Thing) {
  delete x.prop
  //     ~~~~~~
  // error! The operand of a 'delete' operator must be optional.
}
```

### Node Factory 가 deprecated 되었다

AST(추상 구문 트리) 노드 생성을 위해, 팩토리 함수를 제공했지만, 이제는 새로운 API 형태로 노드 팩토리를 제공한다. 자세한 내용은 [여기](https://github.com/microsoft/TypeScript/pull/35282)를 참고


한 발 늦었지만 타입스크립트 4.0에서 추가된 기능을 알아보자

Typescript 4.0 릴리즈 노트 

몇 년 전 만 하더라도, C9이 지금의 프로게임단이 아닌 (...) 온라인 코드 에디터로 유명하던 때가 있었다.

![C9-IDE](https://miro.medium.com/max/700/1*q6Rn63AwFqlRx8N81PDIRw.png)

리눅스나 맥북을 기반으로 개발을 할 환경이 되지 않았던 시절, ASUS의 오래된 윈도우 노트북을 들고 다니면서 개발을 공부했을 때 주로 사용하던 것이 C9 이었다. 그 때는 기억으로는 무료에 특별하게 제한이 없어서 굉장히 유용하게 썼던 기억이 난다. (없었던 건 아니고 조심해서 썼던 거 같기도)

시간이 흘러 여전히 집에는 윈도우 컴밖에 없었고, 맥북은 무거워 오랫만에 C9을 찾았다. C9는 온대간대 없이 AWS에 인수되어 있었고, 이용료도 받고 있었다. (당연히 AWS Free Tier는 진작에 다썼고) 그래서 C9 대신 선택한 것이 VS Codespace (처음에는 VS Code Online인가 그랬다)였다. Azure에 내 개인정보를 팔아넘긴 덕분에 고맙게도 맥북에어에서 개발을 할 수 있게 많은 도움이 되었다. (흑흑)

그러던 어느날 VS Codespace가 github codespace로 이전될 예정이라 베타 신청을 받는다는 팝업이 떴다! 신청하고 한달만에! 드디어! 베타에 당첨이 되어! 쓰게 되었다!

![welcome to codespaces](./images/codespaces-beta.png)

지겨운! 도큐먼트는! 보지 않으련다! 대충 몇 가지로 요약해보자

- 이번 베타 기간에는 최대 두 개의 codespace를 개설할 수 있다. 따라서 쓰고 난뒤엔 지워야 한다.
- 당연하게도 VSCode와 연동해서 쓸 수 있다! [참고](https://docs.github.com/en/github/developing-online-with-codespaces/connecting-to-your-codespace-from-visual-studio-code)
- 프로젝트의 Codespace에 기본 설정을 적용해 둘 수 있다. [참고](https://docs.github.com/en/github/developing-online-with-codespaces/configuring-codespaces-for-your-project)
- 가격은 기존 VS Codespace의 미국 동부기준 가격과 동일하다. 성능별로 차이가 있으며, 아래를 참고하세용. (베타 기간엔 베이직만 존재하는 듯?)

가격은 나름 괜찮은 거 같다. 프리미엄이면 맥북 프로 최신형에 가까운 성능을 누릴 수 있다. 3시간 개발하면 1달러. 하루에 8시간, 20일 개발하면... 55달러다.

![price](./images/codespaces-price.png)

이제 Github에서 clone하는 영역에 이렇게 codespaces를 볼 수 있다.

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

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

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

포트 포워딩도 제공해서, dev환경을 실행하면 실제로 들어가서 볼 수도 있다.

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

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

이제 맥북에어를 혹사시킬 필요도, 회사 맥북을 무겁게 들고 다니지 않아도 되는 시대가 왔다. 이제 코딩도 나 대신 로봇이 하는 시대만 오면 종말이 완성될 것 같다.

![doomsayer](https://img1.wikia.nocookie.net/__cb20131211232726/hearthstone/images/4/4c/Doomsayer.gif?width=200)

감사합니다 github 열심히 개발할게용


이게 당첨이 되네 (사실 아무나 되는 건 아니었겠지)

Github Code Spaces 베타 당첨 및 후기

## 지극히 주관적인 책 리뷰

https://read.amazon.com/kp/card?asin=B081Y3R657&preview=inline&linkCode=kpe&ref_=cm_sw_r_kb_dp_X.RyFb5WBPP20

넷플릭스의 조직 문화하면 가장 먼저 떠오르는 것은, 아마도 gizmodo에서 쓴 기사일 것이다. [Working at Netflix Sounds Like Hell
](https://gizmodo.com/working-at-netflix-sounds-like-hell-1830020977)

> The profile’s sources described the “Netflix way” as a structure founded on brutal honesty, ritual humiliation, insider lingo, and constant fear. It’s a mix of elements that a lot of people in corporate culture might recognize but according to many employees, it’s been a chaotic process that is difficult to scale as the company carries out its plans of world domination.

이른바 `Keeper Test`를 통과하지 못한 직원들은 가차 없이 해고 한다는 것이고, 이러한 테스트로 인해 많은 직원들이 스트레스를 받는 다는 것이었다. 뭐, 미국이야 우리나라에 비해 쉬운 해고를 할 수 있으니 이런일이야 가능하겠지만서도, 넷플릭스가 성과에 대해 굉장히 깐깐한 문화를 가졌구나 라고 만 생각했다. 그런 회사의 CEO가 쓴 책이 바로 이 책이다. 이 책은 넷플릭스의 기업, 조직, 인사 문화를 담고 있다.

대충 요약하자면 다음과 같다.

> 업계 최고의 인재를 어떻게든 데려와서, 그들에게 최소한의 통제(휴가, 업무시간, 보고 등)와 최대의 자유를 주어라. 그리고 직원들에게 서로 솔직한 피드백을 (그러나 재수없지 않은) 주고받게 하며, 피드백에 적절히 대처하지 못하거나 솔직하지 못한 직원은 두둑한 보상금을 주고 쫓아내라
>
> 어떤 식이든 통제는 창의성을 저해하며, 최대한의 자유를 보장해야 한다. 그 자유 내에서 직원들은 무엇이 회사를 위해 최선인지 고민하게 될 것이다. 어떤식으로 결정했든지, 그 결정에 대한 맥락을 설명할 수 있으면 무슨 결정을 하든 상관 없다.

특히, 개발자의 경우에는 그저그런 개발자 10명 보다 슈퍼 탤런트를 가진 한명의 개발자를 훨씬 더 생산성이 뛰어나다고 이야기 하고 있다. 따라서 어떻게든, 업계 최고의 인재를 데려오는 것은 중요하며, 그러한 인재를 모셔오는 데 있어서 지원을 아끼지 말아야 한다고 강조한다.

그리고 이런 기업문화에 대해 동양권에서는 특히 힘들어 한다는 이야기도 포함되어 있었다. (도쿄의 예시) 우리나라 넷플릭스 직원들이 얼마나 있는지 모르겠지만, 아마 우리나라도 마찬가지 일 것이다. (해고까지 이런식으로 할 수 있을런지는 모르겠지만)

넷플릭스 CEO가 썼다는 것을 충분히 감안하더라도, 이들의 주장에는 어느정도 설득력이 있는 것 같다. 또한 실제 해고율도 다른 회사 대비 그렇게 높지 않다고 나와있었다.

마지막으로, 해고에 대한 걱정을 하고 있는 직원들에게 이런 말을 남겼다.

> 구멍난 배 쪽을 계속해서 보지마라. 노를 젓는 일에 방해가 될 뿐이다. 계속해서 나야가야 할 방향을 보고 노력해라. 그리고 내 위치에 대해, 자주 매니저에게 피드백을 요청하고 이를 수용하라.

그렇다면 과연 나에게 최대한의 자유가 주어졌을때, 최고의 성과를 낼 준비가 되어 있을까? 나는 그러한 일련의 과정마저 즐길 수 있을까?


규칙 없음: 넷플릭스, 지구상 가장 빠르고 유연한 기업의 비밀

[Book] No Rules Rules

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

## Table of Contents

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

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

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

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

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

### 용어

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

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

정리해서 예를 들어보자.

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

## federated application 만들어보기

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

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

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

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

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

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

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

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

export default Page1
```

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

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

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

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

export default Routes
```

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

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

루트 앱은 이런 모양이다.

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

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

export default App
```

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

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

export default MainPage
```

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

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

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

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

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

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

## Server Side Rendering

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

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

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

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

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


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

Page 21

리액트 v17.0 살펴보기

Typescript 4.0 릴리즈 노트

Github Code Spaces 베타 당첨 및 후기

[Book] No Rules Rules

Webpack Module Federation에 대해 알아보자