## 문제 1.

```javascript
function foo() {
 let a = b = 0;
 a++;
 return a;
}

foo();

typeof a; // ??
typeof b; // ??

```
### 정답

일단 `a`는 함수내에 선언된 `let`변수 이고, 전역 scope에 선언되지 않았기 때문에 당연히 undefined다.

문제는 `b`인데, 이게 전역변수에 선언 되었을까, 아니면 앞에 let이 있었으니까 `b`도 `let` scope를 따라갈까? 정답은 전역 객체를 따라간다는 것이다. 따라서 `b`는 `number`타입이 된다. 위 코드는 아래와 같다.

```javascript
function foo() {
 let a;
 window.b = 0;
 a = window.b;
 a++;
 return a;
}
```

## 문제 2.

```javascript
const clothes = ['jacket', 't-shirt'];
clothes.length = 0;

clothes[0]; // ??
```

### 정답

정답을 알기 위해서는, 배열 객체의 `length`의 동작을 알아야 한다.

http://www.ecma-international.org/ecma-262/6.0/#sec-properties-of-array-instances-length

> The length property of an Array instance is a data property whose value is always numerically greater than the name of every configurable own property whose name is an array index.

> The length property initially has the attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: false }.

> NOTE Reducing the value of the length property has the side-effect of deleting own array elements whose array index is between the old and new length values. However, non-configurable properties can not be deleted. Attempting to set the length property of an Array object to a value that is numerically less than or equal to the largest numeric own property name of an existing non-configurable array indexed property of the array will result in the length being set to a numeric value that is one greater than that non-configurable numeric own property name.

배열의 길이를 원래 값보다 줄이는 행위는 배열의 요소를 줄이는 역할을 한다. (????) 기존 길이에서 새로운 줄어든 길이만큼 뒤에서 배열의 요소들이 사라진다. 반대로 큰 값을 넣으면 `empty`가 그 만큼 들어간다. 따라서 정답은 undefined다.

## 문제 3

```javascript
const length = 4;
const numbers = [];
for (var i = 0; i < length; i++);{ //잘보면 여기에 ; 가 들어가 있다.
 numbers.push(i + 1);
}

numbers; // ??
```

### 정답

`;`은 null statement다. null statement란 empty statment 이며, 이는 곧 아무것도 하지 않는 다는 것을 의미한다. 위 코드는 아래와 같다.

```javascript
const length = 4;
const numbers = [];
var i;
for (i = 0; i < length; i++) {
 // 암것도 안한다.
}
{ 
 // 그냥 스코프를 생성하는 블록일 뿐
 numbers.push(i + 1);
}

numbers; [5]
```

## 문제 4

```javascript
function arrayFromValue(item) {
 return
 [item];
}

arrayFromValue(10); // ???
```

### 정답

단순히 return 뒤애 새줄이 생겼고, 그 뒤에 `[item]`이 존재한다. 이 경우, 자바스크립트는 return 뒤에 자동으로 `;`을 붙여버리게 된다. 따라서 그 뒷줄에 있는 코드는 아무런 역할을 하지 않는다. (물론 lint에 걸리는게 정상이겠지만) 따라서 답은 `undefined`다.

## 문제 5

```javascript
let i;
for (i = 0; i < 3; i++) {
 const log = () => {
 console.log(i);
 }
 setTimeout(log, 100);
}
```

### 정답

자바스크립트 인터뷰 문제를 공부해보다보면 수도없이 나오는 클로저 문제다.

1. for문이 세번돌고, 매번 그때마다 `i`의 값을 확인하는 `log`함수가 생성된다. 그리고 그 `log`를 실행하는 `setTimeOut`이 태스크 큐 대기열에 들어가게 된다.
2. for문이 끝나면, `i`는 3이 되어 있다.
3. for문이 종료 된 뒤에 `setTimeOut`을 실행하려고 `i`를 참조하면, `i`는 3이 되어있다. 

따라서 정답은 3이 세번 나온다 이다.

```javascript
for (let i = 0; i < 3; i++) {
 const log = () => {
 console.log(i);
 }
 setTimeout(log, 1000);
}
```

## 문제 6

```javascript
0.1 + 0.2 === 0.3
```

### 정답

정답은 `false`다 .

```javascript
0.1 + 0.2; // 0.30000000000000004
```

이에 대한 흥미로운 사이트가 있는데, 바로 https://0.30000000000000004.com/ 이다. ㅋㅋㅋㅋㅋㅋㅋㅋ

소수점도 2진법으로 코딩되어 있는데, 0.1은 정확히 0.1과 같은 수가 아니고, 2진법으로 가장 가까운 0.1이 표현되어 있는 것이다. 정확히는, 자바스크립트는 숫자를 모두 64비트 IEEE 754 형식으로 다루는데, 콘솔에 입력해서 0.1이 제대로 보이는 것은, 그것을 앞선 형식에 따라 2진법으로 바꾸고, 다시 그 결과를 10진법으로 보여주는 것이다.

## 문제 7

```javascript
myVar; // ???
myConst; // ???

var myVar = 'value';
const myConst = 3.14;
```

### 정답

https://yceffort.kr/2020/05/var-let-const-hoisting/ 에서도 다뤘듯이, `let`과 `const`는 TDZ에 들어가게 된다. 따라서 첫번째 줄에서는 undefined, 2번째 줄에서는 에러가 날 것이다.

```javascript
var myVar; // TDZ에 들어가지않고, 호이스팅 된다.
const myConst; // error TDZ에 들어갔으며, const의 경우에는 초기화가 되어야 한다. 따라서 
// 따라서 Identifier 'myConst' has already been declared 에러가 날 것이다.
```

5, 6, 7은 솔직히 많이 봐서 별로 재미가 없지만, 앞에 4문제는 좀 재밌었다.

더 변태 같은 문제를 원하면 이전 포스트 https://yceffort.kr/2020/05/10-javascript-quiz/ 를 참고해보자.

뭔가 이상한 자바스크립트 면접 문제는 재밌다. 단 내가 구직 중이 아닐 때만.

재밌는 자바스크립트 면접 문제

조금 부끄러운 이야기지만, 1년이 넘도록 리액트를 쓰면서 아직까지도 `useCallback`에 대한 정확한 개념이 서 있지 않다. 그래, `useCallback`이 함수를 재사용하는 걸 알겠는데, 그래서 어쩌라고? 라는 나를 위해서 다시한번 정리해본다.

조금 다른 미친 이야기로 넘어와서, 만약 모든 콜백 함수를 memoize 한다면, callback 함수를 사용하는 모든 자식 컴포넌트들이 불필요한 리렌더링을 막을 수 있지 않을까? 당연히 이 글을 읽는 훌륭한 개발자 분들은 말도 안되는 것임을 알 것이고, 이는 성능에 악 영향을, 그리고 컴포넌트를 느리게 한다는 것을 알 것이다.

본론으로 들어가기전에, 함수의 동일성 체크에 대해 알아보자.

```javascript
function sum() {
 return (a, b) => a + b
}

const sum1 = sum()
const sum2 = sum()

sum1(1, 2) // 3
sum2(1, 2) // 3

sum1 === sum2 // false
sum2 === sum2 // true
```

`sum1`과 `sum2`는 동일한 코드 소스를 공유하고 있지만, 리턴하는 오브젝트가 다르다. 따라서 두 개를 비고 하면 `false`를 리턴한다. 당연한 이야기이지만, object는 오로지 자기 자신만 동일하다.

이와 비슷하게, 리액트 컴포넌트에서도 동일한 소스코드로 다른 함수 인스턴스가 생성되는 경우가 종종 있다.

```javascript
import React from 'react'

function MyComponent() {
 // handleClick 은 렌더링 될 때 마다 새로 생성된다.
 const handleClick = () => {
 console.log('Clicked!')
 }

 // ...
}
```

`handleClick`은 `MyComponent`가 새롭게 렌더링 될 때마다, 다른 함수 오브젝트가 된다. 다행히도, 인라인 함수를 만드는 비용은 그다지 비싸지 않아서, 매번 새롭게 만드는 것은 큰 비용이 아니다. 다시 말해, 컴포넌트 내부에 있는 몇개의 인라인 함수정도는 괜찮다.

그러나, 이와 반대로 한가지 함수 인스턴스를 유지해야 하는 경우가 있다.

1. `React.memo()` 또는 `shouldComponentUpdate)` 내부에 있는 컴포넌트가 callback prop을 받을 때
2. 함수가 다른 hooks 함수의 dependency로 사용될 때 `useEffect(..., [callback])`

이러한 경우에 `useCallback`이 빛을 발한다. `deps`에 같은 값이 주어질 때마다, hook은 렌더링 시에 완전히 같은 함수 인스턴스를 리턴한다.

```javascript
import React, { useCallback } from 'react'

function MyComponent() {
 // handleClick 은 완전히 같은 오브젝트다.
 const handleClick = useCallback(() => {
 console.log('Clicked!')
 }, [])

 // ...
}
```

`handleClick` 변수는 `MyComponent`가 렌더링 될 때마다 같은 콜백 함수를 가진 오브젝트를 갖게 된다.

컴포넌트가 큰 사이즈의 items을 렌더링 한다고 가정해보자.

```javascript
import React from 'react'
import useSearch from './fetch-items'

function BigList({ term, handleClick }) {
 const items = useSearch(term)

 const element = (item) => <div onClick={handleClick}>{item}</div>

 return <div>{items.map(element)}</div>
}

export default React.memo(BigList)
```

`items`가 정말 많다고 가정하고, 재 렌더링을 방지하지 위하여 `React.memo`를 사용했다. 만약 `BigList`에서 아이템을 클릭할 때 실행할 핸들러 함수가 필요하다고 가정해보자.

```javascript
import React, { useCallback } from 'react'

export default function Parent({ term }) {
 const handleClick = useCallback(
 (item) => {
 console.log('You clicked ', item)
 },
 [term],
 )

 return <BigList term={term} handleClick={handleClick} />
}
```

이렇게 하게 되면, `handleClick`은 `useCallback()`에 memozied 된다. `term`의 값이 같은 이상, `useCallback()`은 항상 같은 함수 인스턴스를 반환할 것이다.

심지어 `Parent`가 리렌더링 되더라도,`BigList`의 memoziation이 깨지지 않은 이상 항상 같은 함수를 리턴할 것이다.

이제 다시 앞선 예제로 와보자.

```javascript
import React, { useCallback } from 'react'

function MyComponent() {
 const handleClick = useCallback(() => {
 // handle the click event
 }, [])

 return <MyChild onClick={handleClick} />
}
```

이 경우는 어떤가? `MyComponent`가 렌더링 될 때 마다 `useCallback()` 훅이 호출 될 것이다. 내부적으로 리액트는 같은 오브젝트 함수를 리턴하기 위해 노력할 것이다. 그렇다고 할지라도, 인라인 함수는 여전히 매번 렌더링 될 때마다 만들어진다. 왜냐하면, `MyComponent`는 특별히 memozied 되지 않았기 때문에, 그 자체 만으로도 이미 매번 렌더링을 하게 된다.

`useCallback()`이 같은 함수 인스턴스를 보장해주지만, 이는 아무런 이득이 없다. 왜냐하면 최적화의 비용이 최적화 하지 않는 비용보다 더 크기 때문이다. 또한 코드의 복잡성도 증가하게 된다. `useCallback()`의 deps에 실제로 memozied할 callback에서 사용하는 것들을 반드시 넣어두어야 한다.

모든 최적화는 복잡성을 증가시킨다. 섣불리 추가된 최적화는 최적화된 코드를 여러번 변경할 수 있기 때문에 위험하다. [성능을 최적화 하기 전에 문제를 프로파일링 해야 한다.](https://wiki.c2.com/?ProfileBeforeOptimizing) `useCallback`의 적절한 예시는 메모화된 자식 컴포넌트에 제공되는 콜백 함수를 memozie하는 것이다.

아직도 useCallback으로 고통 받다니

useCallback 사용 가이드

## Table of Contents

## same-site와 same-origin의 차이

### Origin

https://yceffort.kr:443

- `origin`: 은 `scheme` (`protocol`로도 알려진)와 `host name`, 그리고 `port`의 조합을 의미한다. 예를 들어 https://yceffort.kr:443/2020/07/docker-study-2/ 의 origin은 https://yceffort.kr:443 이다.
- `scheme`: `https://`
- `host name`: `yceffort.kr`
- `port`: 443

https://yceffort.kr:443 를 기준으로 비교했을 때,

| Origin | 비교결과 | 이유 |
| ---------------------------- | -------------- | ------------------------------------------------------ |
| https://fake.kr:443 | `cross-origin` | 도메인이 다르다. |
| https://www.yceffort.kr:443 | `cross-origin` | 서브도메인이 다르다. |
| https://blog.yceffort.kr:443 | `cross-origin` | 서브도메인이 다르다. |
| http://yceffort.kr:443 | `cross-origin` | scheme이 다르다. |
| http://yceffort.kr:80 | `cross-origin` | port가 다르다. |
| https://yceffort.kr:443 | `same-origin` | 완전히 같다. |
| https://yceffort.kr | `same-origin` | 포트가 없지만, https의 기본포트 443이 있다고 간주한다. |

### Site

탑 레벨 도메인 (TLD), 즉 `.com`과 `.org`등은 [Root Zone Database](https://www.iana.org/domains/root/db)에 등록되어 있다. 내 블로그 주소를 기준으로, `site`는 TLD와 domain의 조합이다. 따라서 내 블로그의 `site`는 `yceffort.kr`이다.

그러나, `.co.kr`이나 `.github.io`와 같은 주소도 더러 있는 것을 볼 수 있다. 이들의 TLD는 `.kr` `.io`인데, 단순히 TLD만으로 이들의 도메인을 결정할 수 있는 방법이 없다. 그래서 `eTLD` (effective Top Level Domain) 리스트가 만들어졌다. [eTLD](https://publicsuffix.org/list/)

예를 들어, 내 구 블로그 주소인 https://yceffort.github.io 를 기준으로 살펴보자.

- `TLD`: `.io`
- `eTLD`: `.github.io`
- `eTLD+1`: `yceffort.github.io` (site)

https://yceffort.kr:443 를 기준으로 비교했을 때,

| Origin | 비교결과 | 이유 |
| ---------------------------- | ------------ | ------------------------------- |
| https://fake.kr:443 | `cross-site` | 도메인이 다르다. |
| https://blog.yceffort.kr:443 | `same-site` | 서브도메인이 다르지만 상관없다. |
| http://yceffort.kr:443 | `same-site` | scheme이 다르지만 상관없다. |
| https://yceffort.kr:80 | `same-site` | port가 다르지만 상관없다. |
| https://yceffort.kr:443 | `same-site` | 완전히 같다. |
| https://yceffort.kr | `same-site` | port가 없지만 상관없다. |

위에서 보다시피 `same-site`는 scheme를 무시하고 있지만, http의 취약점을 방어하기 위해 조금 더 엄격한 방식으로 구별하는 방식이 있다. 이를 [schemeful same-site](https://github.com/sbingler/schemeful-same-site/)라고 한다. 이 경우 http://yceffort.kr과 https://yceffort.kr 는 스키마가 다르므로 다른 사이트로 취급한다.

| Origin | 비교결과 | 이유 |
| ---------------------------- | --------------------- | ------------------------------- |
| https://fake.kr:443 | `cross-site` | 도메인이 다르다. |
| https://blog.yceffort.kr:443 | `schemeful-same-site` | 서브도메인이 다르지만 상관없다. |
| http://yceffort.kr:443 | `cross-site` | scheme이 다르다. |
| https://yceffort.kr:80 | `schemeful-same-site` | port가 다르지만 상관없다. |
| https://yceffort.kr:443 | `same-site` | 완전히 같다. |
| https://yceffort.kr | `schemeful-same-site` | port가 없지만 상관없다. |

## Referer와 Referrer-Policy 101

> 맨 처음 포스팅을 할 때 이상하다고 느낀 것은 Referer와 Referrer-policy에서 Referrer의 스펠링이 다른 것이었다. (틀리다고 계속 에러메시지가 떴다.) 알고보니 오타가 고대로 스펙이 되버린 것이었다.

> The misspelling of referrer originated in the original proposal by computer scientist Phillip Hallam-Baker to incorporate the field into the HTTP specification.[4] The misspelling was set in stone by the time of its incorporation into the Request for Comments standards document RFC 1945; document co-author Roy Fielding has remarked that neither "referrer" nor the misspelling "referer" were recognized by the standard Unix spell checker of the period.[5] "Referer" has since become a widely used spelling in the industry when discussing HTTP referrers; usage of the misspelling is not universal, though, as the correct spelling "referrer" is used in some web specifications such as the Document Object Model.

https://en.wikipedia.org/wiki/HTTP_referer

http 요청은 옵셔널 헤더인 [Referer](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referer)를 가지고 있을 수 있다. 이 정보는 이 요청이 만들어진 origin 또는 웹페이지 URL을 가리킨다. [Referrer-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy)헤더는 요청과 함께 얼마나 많은 레퍼럴 정보를 포함해야 하는지 알려준다.

아래 예제를 보자.

![example1](https://webdev.imgix.net/referrer-best-practices/referrer-basics.jpg)

`Referer` 헤더에 해당 정보를 요청한 사이트의 전체 주소가 담겨져 있다.

`Referer` 헤더는 다양한 형태의 요청에 존재할 수 있는데, 예를 들어

- 사용자가 링크를 클릭하는 네비게이션 링크
- 브라우저가 이미지, iframe, script 등 페이지에 필요한 리소스를 요청하는 subresource 요청

가 있다. 네비게이션과 `iframe`의 경우, 자바스크립트의 `document.referrer`를 이용해서도 동일한 정보에 접근할 수 있다.

`Referer`는 꽤나 유용한 정보가 될 수 있다. 옐르 들어, `site-two.example`의 사용자중 50%는 `social-network.example`에서 왔다는 것을 파악할 수 있다.

그러나, query와 path를 포함한 전체 주소를 `Referer`를 통해서 다른 origin에 보내는 것은, 보안 상에서 문제가 될 수 있다. 아래의 예를 살펴보자.

![example2](https://webdev.imgix.net/referrer-best-practices/referrer-urls.jpg)

1번과 5번 예제에서 볼 수 있다시피 이 사이트에 온 사람이 누구인지 식별할 수도 있게 되어 버린다. 6번의 경우에는 극단적이지만 끔찍한 예제이다. 💀

따라서, 사이트의 요청에 사용할 수 있는 `referer` 데이터를 제한하기 위해서 사용하는 것이 `Referrer-Policy`이다.

## 어떠한 것들이 가능하고, 차이는 무엇일까?

가능한 정책은 총 8가지다. 정책에 따라서, `Referer`의 데이터는

- 데이터가 없다. (`Referer` 헤더가 없을 경우)
- `origin`만 존재하는 경우: https://yceffort.kr
- URL 전체: https://yceffort.kr/2020/07/docker-study-2/

일부 정책의 경우 context에 따라서 다르게 작동하도록 동작 되어있다. (cross-origin, same-origin request, security) 이는 사이트 내에서 Referer를 유지하면서, 동시에 다른 origin에서는 정보를 제한하는데 있어서 유용하다.

| | No Data | Origin Only | Full URL |
| --------------------------------- | -------------- | ------------------------------------------ | -------------------------- |
| `no-referrer` | ✔ | | |
| `origin` | | ✔ | |
| `unsafe-url` | | | ✔ |
| `strict-origin` | HTTPS → HTTP | HTTPS → HTTPS, HTTP → HTTP | |
| `no-referrer-when-downgrade` | HTTPS → HTTP | | HTTPS → HTTPS, HTTP → HTTP |
| `origin-when-cross-origin` | | `cross-origin` | `same-origin` |
| `same-origin` | `cross-origin` | | `same-origin` |
| `strict-origin-when-cross-origin` | HTTPS → HTTP | `cross-origin`, HTTPS → HTTPS, HTTP → HTTP | |

실제 예제 까지 보고 싶다면 [여기](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy#Examples)를 참고

- scheme를 보는 모든 정책 (`strict-origin` `no-referrer-when-downgrade` `strict-origin-when-cross-origin`)의 경우에, HTTP가 실제로 더 보안에 취약함에도 불구하고, HTTP origin에서 다른 HTTP origin으로 가는 것을 HTTPS origin에서 다른 HTTPS origin으로 가는 것과 동일하게 취급한다. (= HTTP와 HTTPS에 대해 차이를 두고 있지 않다.) 이러한 정책의 경우 중요한 것은, 보안 다운그레이드가 발생하는지 여부, 즉 암호화된 원본에서 암호화되지 않은 원본으로 데이터를 노출할 수 있는지 여부이다. HTTP에서 HTTP는 암호화가 없어서 다운그레이드 되지 않는다. 다만 HTTPS에서 HTTP는 다운그레이드가 나타난다. (암호화가 된 것에서 암호화가 안된 것으로 가므로)

- 요청이 `same-origin`이라면, 이 뜻은 scheme (HTTS, HTTP)가 같다느 ㄴ뜻이다. 따라서 보안에서 다운그레이드가 이루어지지 않는다.

## 브라우저별 표준

만약 `referrer-policy`가 설정되어 있지 않다면, 브라우저 기본 정책이 적용된다.

| 브라우저 | 기본 정책 |
| -------- | --------------------------------------------------------------------------------------- |
| Chrome | 85 버전부터 `no-referrer-when-downgrade`에서 `strict-origin-when-cross-origin`으로 변경 |
| Firefox | `no-referrer-when-downgrade`, 시크릿 모드에서는 `strict-origin-when-cross-origin` |
| Edge | `no-referrer-when-downgrade` |
| Safari | `strict-origin-when-cross-origin`와 비슷하게 동작 |

## referrer policy 설정하는 올바른 방법

사이트에 referrer policy를 설정하는 방법은 여러가지가 있다.

- http header
- [HTML](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy#Integration_with_HTML)
- [Javascript](https://javascript.info/fetch-api#referrer-referrerpolicy)

페이지마다, 요청마다 다른 정책을 쓸 수 있다는 것을 의미한다. HTTP header와 meta 엘리먼트는 모두 페이지 레벨에서 동작한다. 유효 정책을 정하는 순위는 아래와 같다.

- element 레벨
- page 레벨
- 브라우저 기본값

### 예제

```html
<meta name="referrer" content="strict-origin-when-cross-origin" />
<img src="..." referrerpolicy="no-referrer-when-downgrade" />
```

이 경우 이미지는 `no-referrer-when-downgrade` 정책으로 가게 된다.

### referrer policy를 보는 법

브라우저의 네트워크 탭을 보면 된다.

![Referrer policy example](./images/referrer-policy.png)

## 어떤 정책이 좋을까?

요약: 명시적으로 보안이 강화된 `strict-origin-when-cross-origin`를 사용하는 것이 좋다.

### 왜 명시적으로 써야 할까?

referrer policy가 제공되지 않는다면, 브라우저 기본 정책이 사용된다. 사실, 많은 웹사이트 들이 이러한 정책을 브라우저 기본값에 의존하는데 이는 좋지 않다. 그 이유는

- 브라우저 모드 (시크릿모드 같이)에 따라서 `no-referrer-when-downgrade`이거나 `strict-origin-when-cross-origin`일 수 있는데, 이는 웹사이트에서 일관된 동작을 하지 못하도록 막는다.
- 브라우저의 기본값인 `strict-origin-when-cross-origin`는 cross-origin 요청에 대해서 referrer를 trimming하는 기능으르 가지고 있다. (파이어폭스, 사파리의 경우에만 그렇다. [여기]([Referrer trimming](https://github.com/privacycg/proposals/issues/13))를 참조) 명시적으로 정책을 선언해서 이러한 행위를 막을 수 있다.

### 왜 `strict-origin-when-cross-origin`인가?

- 안전하다: 웹사이트가 https 일 경우, https 가 아닌 요청에 대해서 웹사이트 주소를 노출하고 싶지 않을 것이다. 만약 누구라도 네트워크에서 이런 정보를 본다면, 유저의 정보가 [중간자 공격](https://ko.wikipedia.org/wiki/%EC%A4%91%EA%B0%84%EC%9E%90_%EA%B3%B5%EA%B2%A9) 의 위험에 노출되게 한다. `no-referrer-when-downgrade` `strict-origin-when-cross-origin` `no-referrer` `strict-origin`로 막을 수 있다.
- 개인정보 보안: cross-origin 요청의 경우, `no-referrer-when-downgrade`는 모든 주소를 노출시킨다. `strict-origin-when-cross-origin`와 `strict-origin`은 `origin`만 공유하고, `no-referrer`의 경우에는 아무정보도 안나타나게 된다.
- 용이하다: `no-referrer`와 `strict-origin`은 절대로 전체 URL을 공유하지 않는다. 근데 문제는 `same-orgin`일 때도 공유를 안한다는 것. 이를 피하기 위해서는 `strict-origin-when-cross-origin`를 쓰면 된다.

따라서 모든 경우에 있어서 `strict-origin-when-cross-origin`가 가장 최선의 선택이라고 볼 수 있다.

```html
<meta name="referrer" content="strict-origin-when-cross-origin" />
```

혹은 서버사이드에서

```javascript
const helmet = require('helmet')
app.use(helmet.referrerPolicy({ policy: 'strict-origin-when-cross-origin' }))
```

### 만약 예외가 필요하다면

별도로 element 나 요청별로 예외를 두는 것이 좋다. 그럼에도, `unsafe-url` 같은 건 안쓰는게 좋다.

```html
<meta name="referrer" content="strict-origin-when-cross-origin" />
<img src="…" referrerpolicy="no-referrer-when-downgrade" />
```

```javascript
fetch(url, { referrerPolicy: 'no-referrer-when-downgrade' })
```

> element 별로 정책을 주는 것도 모든 브라우저에서 되는 것은 아니다. [참고](https://caniuse.com/?search=referrerpolicy)

## 외부에서 오는 요청에 referrer를 활용하는 법

### Cross Ste Request Forgery (CSRF) 보호

CSRF 방어를 위해서 referrer를 쓰는 것은 몇가지 허점이 있다.

- `no-referrer`나 request를 도용하는 경우 아무런 데이터를 볼 수 없을 수 있다. 요청의 헤더에 대한 제어를 하고 있지 못한다면, 요청에 안전한 헤더가 온다는 보장이 없다.
- `Referer` (`document.referer`) 에는 원하는 것 (단순히 cross-origin만 알고 싶었는데..) 보다 더 많은 양의 데이터가 들어 있을 수 있다.

CSRF 방어를 위해서는 [CSRF Token](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#token-based-mitigation)을 사용하는 것을 추천한다.

### 로깅

`Referer`에는 개인정보가 담겨 있을 수 있으므로, 다루는데 신중해야 한다. `Referer`를 사용하는 대신에, [Origin](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin)이나 [Sec-Fetch-Site](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Site)를 써보는 것도 좋다.

> `sec-fetch-site`는 지원이 제한적이므로, `origin`을 쓰는게 낫다.

### 결제

결제 사업자는 보안 체크를 위해, 들어오는 요청에 대해서 `Referer`를 확인할 수도 있다. 예를 들어

- 유저가 online-shop.example/cart/checkout 에서 결제 버튼을 누른다.
- online-shop.example 가 결제를 위해 payment-provider.example로 리다이렉트 시킨다.
- payment-provider.example가 `Referer`를 확인하여 허가된 사이트로 부터 온 요청인지 확인한다. 그렇지 않다면, 결제 요청을 거부한다.

#### 결제 플로우에서 보안 체크

결제사업자가 `Referer`를 체크하는 것은 기본적인 방어 체계가 될 수 있다. 그러나 반드시, 또 다른 방어체계를 마련해 두어야 한다.

`Referer`만으로는 모든 것을 막기에 완벽하지 않다. 만약 결제 사이트에서 `no-referrer`를 설정해 두었다면, 해당 정보를 확인할 수 없다. 그러나, 결제 제공 사업자로서, 일단 `Referer`를 본다면 해당 정보가 있는지 없는지 정도 수준의 기본적인 체크는 할수가 있다.

- `Referer`가 언제나 있을 거라고 기대하지마라. 설령 존재한다 하더라도, 이는 아주 기초적인 점검 항목중 하나인 `origin`만 살펴볼 수 있다. `Referer` 허용 값을 작성할때, origin만 있도록 하는 것이 중요하다. 즉, `online-shop.example/cart/checkout`가 아닌 `online-shop.example`여야 한다는 것이다. 이는 결제 사이트에 따라서 정책이 다르게 설계 될 수 있으므로 (=꼭 FULL URL이 온다는 보장은 없으므로) 반드시 origin만 확인해야 한다.
- 만약 `Referer`가 없거나, 기본적인 점검이 통과했을 경우, 아래의 추가적인 항목으로 검사를 시도해야 한다.

#### 더 안전한 방법

한 가지 신뢰할 수 있는 검증 방법은 요청자가 요청한 매개변수를 고유한 키와 함께 해시하여 보내도록 하는 것이다. 결제 제공자로서 이 해시 값을 검사할 수 있고 이 값이 일치하는 요청에 대해서만 받으면 된다.

웹 어플리케이션에서 request를 받기 위한 최적의 Referer와 Referrer 정책

Referer와 Referer-Policy를 위한 가이드

```javascript
const hello = 'hello'
hello.length // 5

const bow = '🙇‍♂️'
bow.length // 5 ???
```

첫 번째 `hello`의 길이는 이해가 되지만, 두번째 `🙇‍♂️` 의 길이는 왜 5일까?

이를 알기 위해서는 [javascript string의 정의](https://tc39.es/ecma262/#sec-ecmascript-language-types-string-type)를 참고할 필요가 있다.

> The String type is the set of all ordered sequences of zero or more 16-bit unsigned integer values (“elements”) up to a maximum length of 253 - 1 elements. The String type is generally used to represent textual data in a running ECMAScript program, in which case each element in the String is treated as a UTF-16 code unit value. Each element is regarded as occupying a position within the sequence. These positions are indexed with nonnegative integers. The first element (if any) is at index 0, the next element (if any) at index 1, and so on. The length of a String is the number of elements (i.e., 16-bit values) within it. The empty String has length zero and therefore contains no elements.

> String type은 최대 길이 $$2^53 - 1$$ 의 원소들로 이루어진 0 이상의 16비트 미부호 정수 값("요소")의 순서로 구성된 모든 시퀀스 집합이다. 문자열 유형은 일반적으로 실행 중인 ECMAScript 프로그램에서 텍스트 데이터를 나타내기 위해 사용되며, 이 경우 문자열의 각 요소는 UTF-16 코드 단위 값으로 처리된다. 각 원소는 순서에서 위치를 차지하는 것으로 간주된다. 이러한 위치는 음이 아닌 정수로 나타난다. 첫 번째 요소(있는 경우)는 index 0에 있고, 다음 요소(있는 경우)는 index 1에 있는 등.. 으로 이루어진다. 문자열의 길이는 문자열 내의 요소 수(즉, 16비트 값)이다. 빈 문자열은 길이가 0이므로 요소를 포함하지 않는다.

자바스크립트는 문자열을 16비트로 표현하고 있고, 문자열의 길이는 이 16비트 요소들의 길이 인 것이다. [UTF-16](https://ko.wikipedia.org/wiki/UTF-16)

실제로, string을 UTF-16으로 변환하는 방법이 [여기](https://developers.google.com/web/updates/2012/06/How-to-convert-ArrayBuffer-to-and-from-String)에 나와 있다.

그리고 이러한 UTF-16 코드 유닛은 `0x0000` 부터 `0xFFFF`까지 존재한다. 예를 들어서, 아까 `hello`는

```javascript
const hello = '\u0048\u0065\u006C\u006C\u006F'

hello === 'Hello' // true
hello.length // 5
```

이 `\u0048\u0065\u006C\u006C\u006F`가 자바스크립트가 string을 보는 방법이다. 그리고 이것이 앞서 언급한 코드 시퀀스의 집합이다.

한가지 알아둬야 할 것은, 이렇게 UTF-16의 한 비트로 표현할 수 있는 문자들은 [Basic Multilangual Plane]()에 한정되어 있다는 것이다. 그 외에 언어들에는

- [Supplementary Multilingual Plane](<https://en.wikipedia.org/wiki/Plane_(Unicode)#Supplementary_Multilingual_Plane>)
- [Supplementary Ideographic Plane](<https://en.wikipedia.org/wiki/Plane_(Unicode)#Supplementary_Ideographic_Plane>)
- [Tertiary Ideographic Plane](<https://en.wikipedia.org/wiki/Plane_(Unicode)#Tertiary_Ideographic_Plane>)

위 언어들은 따로나눌수 없는 UTF-16 의 쌍으로 이루어져 있다. 예를 들어 `😀`는 `0x1F600`인데, 이는 16비트로 표현할 수 있는 범위를 넘어섰으므로, `0xD83D0xDE00`로 표현한다.

어쨌든, `length`의 경우 하나의 16비트 진수를 길이로 표현하므로, 😀의 길이는 2가 된다.

그러나 한가지 다른 예제가 있다.

```javascript
const message = 'hello'
const smile = '😀'

[...message].length // => 5
[...smile].length // => 1
```

`string iterator`의 경우에는, UTF-16의 쌍 `surrogate pair`를 따로 분리하지 않고, 한개의 유닛으로 분리한다. 따라서 이것의 길이는, 사람 눈에 보이는 것처럼 1이 된다.

요약하자면, 자바스크립트의 string을 볼 때, 보여지는 그대로 보는 것이 가장 간단한 방법이다. 이 방법은 영문자, 숫자, 아스키 코드에만 유효하다.

그러나, 엄격하게 보자면 자바스크립트 문자열은 UTF-16 코드의 나열로 이루어져 있다. `string.length`는 이러한 코드의 길이를 보고 판단한다.

자바스크립트 String

<pre class="language-javascript"><code class="language-javascript">const hello = 'hello'
hello.length // 5

const bow = '🙇‍♂️'
bow.length // 5 ???
</code></pre>
첫 번째 <code>hello</code>의 길이는 이해가 되지만, 두번째 <code>🙇‍♂️</code> 의 길이는 왜 5일까?
이를 알기 위해서는 <a href="https://tc39.es/ecma262/#sec-ecmascript-language-types-string-type">javascript string의 정의</a>를 참고할 필요가 있다.
<blockquote>
The String type is the set of all ordered sequences of zero or more 16-bit unsigned integer values (“elements”) up to a maximum length of 253 - 1 elements. The String type is generally used to represent textual data in a running ECMAScript program, in which case each element in the String is treated as a UTF-16 code unit value. Each element is regarded as occupying a position within the sequence. These positions are indexed with nonnegative integers. The first element (if any) is at index 0, the next element (if any) at index 1, and so on. The length of a String is the number of elements (i.e., 16-bit values) within it. The empty String has length zero and therefore contains no elements.
</blockquote>
<blockquote>
String type은 최대 길이 <math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><msup><mn>2</mn><mn>5</mn></msup><mn>3</mn><mo>−</mo><mn>1</mn></mrow><annotation encoding="application/x-tex">2^53 - 1</annotation></semantics></math>253−1 의 원소들로 이루어진 0 이상의 16비트 미부호 정수 값("요소")의 순서로 구성된 모든 시퀀스 집합이다. 문자열 유형은 일반적으로 실행 중인 ECMAScript 프로그램에서 텍스트 데이터를 나타내기 위해 사용되며, 이 경우 문자열의 각 요소는 UTF-16 코드 단위 값으로 처리된다. 각 원소는 순서에서 위치를 차지하는 것으로 간주된다. 이러한 위치는 음이 아닌 정수로 나타난다. 첫 번째 요소(있는 경우)는 index 0에 있고, 다음 요소(있는 경우)는 index 1에 있는 등.. 으로 이루어진다. 문자열의 길이는 문자열 내의 요소 수(즉, 16비트 값)이다. 빈 문자열은 길이가 0이므로 요소를 포함하지 않는다.
</blockquote>
자바스크립트는 문자열을 16비트로 표현하고 있고, 문자열의 길이는 이 16비트 요소들의 길이 인 것이다. <a href="https://ko.wikipedia.org/wiki/UTF-16">UTF-16</a>
실제로, string을 UTF-16으로 변환하는 방법이 <a href="https://developers.google.com/web/updates/2012/06/How-to-convert-ArrayBuffer-to-and-from-String">여기</a>에 나와 있다.
그리고 이러한 UTF-16 코드 유닛은 <code>0x0000</code> 부터 <code>0xFFFF</code>까지 존재한다. 예를 들어서, 아까 <code>hello</code>는
<pre class="language-javascript"><code class="language-javascript">const hello = '\u0048\u0065\u006C\u006C\u006F'

hello === 'Hello' // true
hello.length // 5
</code></pre>
이 <code>\u0048\u0065\u006C\u006C\u006F</code>가 자바스크립트가 string을 보는 방법이다. 그리고 이것이 앞서 언급한 코드 시퀀스의 집합이다.
한가지 알아둬야 할 것은, 이렇게 UTF-16의 한 비트로 표현할 수 있는 문자들은 <a href="">Basic Multilangual Plane</a>에 한정되어 있다는 것이다. 그 외에 언어들에는
<ul>
<li><a href="https://en.wikipedia.org/wiki/Plane_(Unicode)#Supplementary_Multilingual_Plane">Supplementary Multilingual Plane</a></li>
<li><a href="https://en.wikipedia.org/wiki/Plane_(Unicode)#Supplementary_Ideographic_Plane">Supplementary Ideographic Plane</a></li>
<li><a href="https://en.wikipedia.org/wiki/Plane_(Unicode)#Tertiary_Ideographic_Plane">Tertiary Ideographic Plane</a></li>
</ul>
위 언어들은 따로나눌수 없는 UTF-16 의 쌍으로 이루어져 있다. 예를 들어 <code>😀</code>는 <code>0x1F600</code>인데, 이는 16비트로 표현할 수 있는 범위를 넘어섰으므로, <code>0xD83D0xDE00</code>로 표현한다.
어쨌든, <code>length</code>의 경우 하나의 16비트 진수를 길이로 표현하므로, 😀의 길이는 2가 된다.
그러나 한가지 다른 예제가 있다.
<pre class="language-javascript"><code class="language-javascript">const message = 'hello'
const smile = '😀'

[...message].length // => 5
[...smile].length // => 1
</code></pre>
<code>string iterator</code>의 경우에는, UTF-16의 쌍 <code>surrogate pair</code>를 따로 분리하지 않고, 한개의 유닛으로 분리한다. 따라서 이것의 길이는, 사람 눈에 보이는 것처럼 1이 된다.
요약하자면, 자바스크립트의 string을 볼 때, 보여지는 그대로 보는 것이 가장 간단한 방법이다. 이 방법은 영문자, 숫자, 아스키 코드에만 유효하다.
그러나, 엄격하게 보자면 자바스크립트 문자열은 UTF-16 코드의 나열로 이루어져 있다. <code>string.length</code>는 이러한 코드의 길이를 보고 판단한다.

## 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 새로운 기능은 추가되지 않을 예정. 점진적 업그레이드 추가, 이벤트 위임 방식 변경이 주요 변경 내용인 것 같네용.

yceffort

재밌는 자바스크립트 면접 문제

useCallback 사용 가이드

Referer와 Referer-Policy를 위한 가이드

자바스크립트 String

리액트 v17.0 살펴보기