타입스크립트의 type과 interface의 차이점을 찾아보던 중, 몇 가지 잘못된 사실들을 보면서 진짜로 둘의 차이점이 무엇인지 정리하기 위해서 포스팅한다. (물론 이것도 시간이 지나면 (2021년 3월 기준) 잘못된 사실이 될 수도 있다... 🤪)

## 예제

```typescript
interface PeopleInterface {
  name: string
  age: number
}

const me1: PeopleInterface = {
  name: 'yc',
  age: 34,
}

type PeopleType = {
  name: string
  age: number
}

const me2: PeopleType = {
  name: 'yc',
  age: 31,
}
```

위에서 볼 수 있는 것 처럼, `interface`는 타입과 마찬가지로 객체의 타입의 이름을 지정하는 또 다른 방법이다.

## 차이점

### 확장하는 방법

```typescript
interface PeopleInterface {
  name: string
  age: number
}

interface StudentInterface extends PeopleInterface {
  school: string
}
```

```typescript
type PeopleType = {
  name: string
  age: number
}

type StudentType = PeopleType & {
  school: string
}
```

### 선언적 확장

`interface`에서 할 수 있는 대부분의 기능들은 `type`에서 가능하지만, 한 가지 중요한 차이점은 `type`은 새로운 속성을 추가하기 위해서 다시 같은 이름으로 선언할 수 없지만, `interface`는 항상 선언적 확장이 가능하다는 것이다. 그 차이에 대한 예제가 바로 밑에 있는 것이다.

```typescript
interface Window {
  title: string
}

interface Window {
  ts: TypeScriptAPI
}

// 같은 interface 명으로 Window를 다시 만든다면, 자동으로 확장이 된다.

const src = 'const a = "Hello World"'
window.ts.transpileModule(src, {})
```

```typescript
type Window = {
  title: string
}

type Window = {
  ts: TypeScriptAPI
}

// Error: Duplicate identifier 'Window'.
// 타입은 안된다.
```

### ~~type은 이름이 없다?~~

https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#interfaces 에 다음과 같은 내용이 나와있다.

> Type alias names may appear in error messages, sometimes in place of the equivalent anonymous type (which may or may not be desirable). Interfaces will always be named in error messages.

`type`은 무명의 타입으로 선언되어서 에러메시지에서 뜨지 않을 때가 있고, `interface`는 에러에 항상 이름이 나와 있다고 하지만 이는 더 이상 사실이 아니다. (하단 참조)

### interface는 객체에만 사용이 가능하다.

당연한거 아님? 🤔

```typescript
interface FooInterface {
  value: string
}

type FooType = {
  value: string
}

type FooOnlyString = string
type FooTypeNumber = number

// 불가능
interface X extends string {}
```

### computed value의 사용

`type`은 가능하지만 `interface`는 불가능

```typescript
type names = 'firstName' | 'lastName'

type NameTypes = {
  [key in names]: string
}

const yc: NameTypes = { firstName: 'hi', lastName: 'yc' }

interface NameInterface {
  // error
  [key in names]: string
}
```

### 성능을 위해서는 interface를 사용하는 것이 좋다.

라는 취지의 문서를 본적이 있는데, 이것에 대해서 조금 이야기 해볼까 한다.

https://github.com/microsoft/TypeScript/wiki/Performance#preferring-interfaces-over-intersections

> Interfaces create a single flat object type that detects property conflicts, which are usually important to resolve! Intersections on the other hand just recursively merge properties, and in some cases produce never.

여러 `type` 혹은 `interface`를 `&`하거나 `extends`할 때를 생각해보자. `interface`는 속성간 충돌을 해결하기 위해 단순한 객체 타입을 만든다. 왜냐하면 interface는 객체의 타입을 만들기 위한 것이고, 어차피 객체 만 오기 때문에 단순히 합치기만 하면 되기 때문이다. 그러나 타입의 경우, 재귀적으로 순회하면서 속성을 머지하는데, 이 경우에 일부 `never`가 나오면서 제대로 머지가 안될 수 있다. `interface`와는 다르게, `type`은 원시 타입이 올수도 있으므로, 충돌이 나서 제대로 머지가 안되는 경우에는 `never`가 떨어진다. 아래 예제를 살펴보자.

```typescript
type type2 = { a: 1 } & { b: 2 } // 잘 머지됨
type type3 = { a: 1; b: 2 } & { b: 3 } // resolved to `never`

const t2: type2 = { a: 1, b: 2 } // good
const t3: type3 = { a: 1, b: 3 } // Type 'number' is not assignable to type 'never'.(2322)
const t3: type3 = { a: 1, b: 2 } // Type 'number' is not assignable to type 'never'.(2322)
```

따라서 타입 간 속성을 머지 할 때는 주의를 필요로 한다. 어차피 객체에서만 쓰는 용도라면, `interface`를 쓰는 것이 훨씬 낫다.

> Interfaces also display consistently better, whereas type aliases to intersections can't be displayed in part of other intersections.

그러나 위의 명제는 이제 더 이상 사실이 아니다. 이제 type의 경우에도 어디에서 에러가 났는지 잘 알려준다. (어째 문서 업데이트가 못따라가는 느낌이다)

```typescript
type t1 = {
  a: number
}

type t2 = t1 & {
  b: string
}

const typeSample: t2 = { a: 1, b: 2 } // error
// before(3.x): Type 'number' is not assignable to type 'string'.
// after(4.x): Type 'number' is not assignable to type 'string'.(2322) input.tsx(14, 5): The expected type comes from property 'b' which is declared here on type 't2'
```

> Type relationships between interfaces are also cached, as opposed to intersection types as a whole.

`interface` 들을 합성할 경우 이는 캐시가 되지만, 타입의 경우에는 그렇지 못하다.

> A final noteworthy difference is that when checking against a target intersection type, every constituent is checked before checking against the "effective"/"flattened" type.

타입 합성의 경우, 합성에 자체에 대한 유효성을 판단하기 전에, 모든 구성요소에 대한 타입을 체크하므로 컴파일 시에 상대적으로 성능이 좋지 않다.

## 결론?

무엇이 되었건 간에, 프로젝트 전반에서 `type`을 쓸지 `interface`를 쓸지 통일은 필요해보인다. 그러나 객체, 그리고 타입간의 합성등을 고려해 보았을 때 `interface`를 쓰는 것이 더 나을지 않을까 싶다.


타입스크립트 type과 interface의 공통점과 차이점

자바스크립트 정규식으로 숫자를 찾는 방법은 보통 아래와 같다.

```javascript
const str = 'hello world, 123'
const digitRegex = /\d+/g

digitRegex.test(str) //true
```

그런데 코딩을 하던 중 한가지 이상한 일이 발생했는데, 대략 아래와 같은 모습이었다.

```javascript
const digitRegex = /\d+/g

const result1 = digitRegex.test('hello 123')
const result2 = digitRegex.test('123')
const result3 = digitRegex.test('123')

console.log(result1) // true
console.log(result2) // false ???????????
console.log(result3) // true
```

> 정규 표현식에 전역 플래그를 설정한 경우, test() 메서드는 정규 표현식의 lastIndex (en-US)를 업데이트합니다. (RegExp.prototype.exec()도 lastIndex 속성을 업데이트합니다.)
>
> test(str)을 또 호출하면 str 검색을 lastIndex부터 계속 진행합니다. lastIndex 속성은 매 번 test()가 true를 반환할 때마다 증가하게 됩니다.
>
> 참고: test()가 true를 반환하기만 하면 lastIndex는 초기화되지 않습니다. 심지어 이전과 다른 문자열을 매개변수로 제공해도 그렇습니다!

https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Global_Objects/RegExp/test

조금더 자세히 살펴보자면, 대략 다음과 같다는 뜻이다.

```javascript
const digitRegex = /\d+/g

console.log(digitRegex.lastIndex) // 0
const result1 = digitRegex.test('hello 123')

// test로 digitRegex의 index (9) 를 찾았으므로 업데이트 함
console.log(digitRegex.lastIndex) // 9
// 9 부터 다시 찾음. 그런데 못찾았으므로 초기화가 진행됨.
const result2 = digitRegex.test('123')

console.log(digitRegex.lastIndex) // 0
// 0 부터 다시 찾아서 숫자를 찾음.
const result3 = digitRegex.test('123')
```

정확히 왜 이렇게 구현했는지에 대해서는 찾을 수 없었다. 추측건데 정규식에 전역플래그가 있다는 것은 검색하려는 대상 str도 전역으로 쓰이는 용도일 것이고, 그 때문에 검색하는 str이 아예 다른 것이 온다는 가정을 하지 않았기 때문이 아닐까? (뭐래는거야?)

어쨌든 간에, 이를 올바르게 동작하게 만들기 위해서는 `search`를 쓰면 된다. 주의할 점은 `.search`는 string에 있는 메소드라는 것.

```javascript
const digitRegex = /\d+/g

const result1 = 'hello 123'.search(digitRegex) > -1
const result2 = '123'.search(digitRegex) > -1
const result3 = '123'.search(digitRegex) > -1
const result4 = '바보'.search(digitRegex) > -1

console.log(result1) // true
console.log(result2) // true
console.log(result3) // true
console.log(result4) // false
```


정규식을 자유자재로 써야 간지인데

알쏭 달쏭한 자바스크립트 정규식

next + react 로 서버사이드 렌더링 환경을 구축하면서 개발을 하고 있었는데 두 가지 문제에 부딪혔었다.

## 1. `window is not defined`, SSR 환경에서의 컴포넌트

먼저 원래 코드를 보자.

```javascript
import Calendar from '@toast-ui/react-calendar'

export default function Index() {
  return (
    <Calendar
      view="month"
      month={{
        narrowWeekend: true,
      }}
      onBeforeCreateSchedule={(e) => {
        setOpenCreatePopup(true)
        setSelectedDate(e.start.toDate())
      }}
      onClickSchedule={(e) => {
        console.log(e)
      }}
      scheduleView
      calendars={calendars}
      schedules={schedules}
    />
  )
}
```

```bash
Server Error
ReferenceError: window is not defined

This error happened while generating the page. Any console logs will be displayed in the terminal window.
Call Stack
Object.<anonymous>
file:///.../node_modules/tui-calendar/dist/tui-calendar.js (16:4)
```

```javascript
(function webpackUniversalModuleDefinition(root, factory) {
	if(typeof exports === 'object' && typeof module === 'object')
		module.exports = factory(require("tui-code-snippet"), require("tui-date-picker"));
	else if(typeof define === 'function' && define.amd)
		define(["tui-code-snippet", "tui-date-picker"], factory);
	else if(typeof exports === 'object')
		exports["Calendar"] = factory(require("tui-code-snippet"), require("tui-date-picker"));
	else
		root["tui"] = root["tui"] || {}, root["tui"]["Calendar"] = factory((root["tui"] && root["tui"]["util"]), (root["tui"] && root["tui"]["DatePicker"]));
})(window, function(__WEBPACK_EXTERNAL_MODULE_tui_code_snippet__, __WEBPACK_EXTERNAL_MODULE_tui_date_picker__) // 여기에서 에러가 난다.
```

해당 컴포넌트는 최초 시작시에 `window` 가 필요한데, 서버사이드 렌더링 시에는 `window`가 없는 환경이기 때문에 에러가 난다.

아래 코드를 넣고, 최초 페이지 접근시에 새로고침을 하면 이 모듈이 실행되는 환경이 node 임을 알 수 있다.

```javascript
console.log('node  >> ', globalThis === global) // true
```

결론적으로 이 컴포넌트는 서버사이드 렌더링을 지원하지 않고 있으며, 이를 해결하기 위해서는 `window`가 있는 브라우저 환경에서만 import 해서 사용해야 한다. 이를 nextjs에서 처리하기 위해서는 아래와 같이 하면 된다.

```javascript
// dynamic 만으로는 부족하다. 꼭 ssr을 꺼야 한다.
import dynamic from 'next/dynamic'
const Calendar = dynamic(() => import('@toast-ui/react-calendar'), {
  ssr: false,
})
```

## 2. Next SSR 환경에서의 ref

```javascript
export default function Index() {
  const cal = useRef()

  useEffect(() => {
    console.log(cal.current)
  }, [cal])

  return <Calendar ref={cal} />
}
```

위의 log 는 아래와 같이 찍힌다.

```bash
{retry: ƒ}
retry: ƒ ()arguments: (...)caller: (...)length: 0name: "bound retry"__proto__: ƒ ()[[TargetFunction]]: ƒ retry()[[BoundThis]]: LoadableSubscription[[BoundArgs]]: Array(0)__proto__: Object
```

> `useEffect`는 SSR에서 절대로 실행되지 않는다. 이를 해결하기 위해 [useServerEffect](https://www.npmjs.com/package/use-server-effect)라고 불리우는(?) 해괴한 effect가 있지만 , 굳이 그럴필요 없이 next의 `getServerSideProps`를 사용하면 된다.

왜 `useRef`는 정상적으로 동작하지 않는 것일까?

> `useRef` returns a mutable ref object whose `.current` property is initialized to the passed argument (initialValue). The returned object will persist for the full lifetime of the component.
>
> ...
>
> This works because useRef() creates a plain JavaScript object. The only difference between useRef() and creating a {current: ...} object yourself is that useRef will give you the same ref object on every render.

https://reactjs.org/docs/hooks-reference.html#useref

`useRef`는 순수한 자바스크립트 객체이며, 컴포넌트가 아무리 렌더링이 된다고 해도 같은 `ref`객체를 반환한다. 그런데 현재 `ref.current`에는 `retry`만 존재한다. 이것은 무엇일까?

https://github.com/vercel/next.js/blob/f06c58911515d980e25c33874c5f18ade5ac99df/packages/next/next-server/lib/loadable.js#L219-L260

https://github.com/vercel/next.js/blob/f06c58911515d980e25c33874c5f18ade5ac99df/packages/next/next-server/lib/loadable.js#L161-L173

위 두 코드에 정답이 나와있다. `useImperativeHandle`를 통해서 `ref`를 노출하고 있기 때문에, current에는 현재 세팅되어 있는 `retry`만 보이고 있었던 것이다. `useImperativeHandle`는 [`forwardRef`](https://ko.reactjs.org/docs/react-api.html#reactforwardref)와 사용해야 한다.

> `useImperativeHandle` customizes the instance value that is exposed to parent components when using `ref`. As always, imperative code using refs should be avoided in most cases. useImperativeHandle should be used with `forwardRef`:

https://.reactjs.org/docs/react-api.html#reactforwardref

`forwardRef`는 전달 받은 `ref`속성을 하부트리의 다른 컴포넌트로 전달 할 수 있는 리액트 컴포넌트를 생성한다.

```javascript
// #components/TuiCalendarWrapper
import React from 'react'
import Calendar from '@toast-ui/react-calendar'

export default (props) => (
  // 3. 넘겨받은 `forwardedRef`를 진짜 컴포넌트에 넘긴다.
  <Calendar {...props} ref={props.forwardedRef} />
)
```

```javascript
const TuiCalendar = dynamic(() => import('#components/TuiCalendarWrapper'), {
  ssr: false,
})
// 2. forwardRef를 통해서 전달받은 ref를 하위 컴포넌트에 보낸다.
const CalendarWithForwardedRef = React.forwardRef((props, ref) => (
  <TuiCalendar {...props} forwardedRef={ref} />
))

export default function Index() {
  const ref = useRef()
  // 1. ref를 넘겨준다.
  return <CalendarWithForwardedRef ref={ref} />
}
```

Ref를 포워딩 하는 방법은 여기에 더 자세히 나와있다.

https://reactjs.org/docs/forwarding-refs.html


리액트 서버사이드 렌더링과 컴포넌트

어디 공부할 만 한 좋은 포스팅이 없나 찾던 중, 애플의 단축어 명령으로 내 폰에 있는 건강정보를 업로드 할 수 있다는 포스팅을 보았다. https://blog.maximeheckel.com/posts/build-personal-health-api-shortcuts-serverless 그래서 이걸 나도 해보면 어떨까 싶어서, 최근에 빠져있는 걷기+달리기에 관련되니 정보를 업로드 해보는 작업을 해보았다.

## 1. 단축어 설정

일단 아이폰에 있는 단축어 앱을 사용해서 내 건강정보를 업로드 할 수 있는 환경을 만들어야 한다.

![shortcut1](./images/shortcut1.jpeg)
![shortcut2](./images/shortcut2.jpeg)
![shortcut3](./images/shortcut3.jpeg)
![shortcut4](./images/shortcut4.jpeg)

> 추가: 자동화와 연결해서 자기전에 자동으로 업로드 하도록 했다. 그러나 아이폰이 잠겨있을 경우에는 업로드가 되지 않으므로, 아이폰 잠금을 해제해 둬야 한다. 🤪

당연히, 헤더 정보에 secret 키 등으로 접근을 하지 못하게 막아둬야 한다. (누가 여기에 업로드 할 일이 있을지는 모르겠지만,,)

## 2. Google Cloud Function 작업

```javascript
exports.health = functions.https.onRequest(async (req, res) => {
  // {'health': {'run': '28.88118937860876', 'timestamps': '2021-03-17T08:45:00+09:00', 'unit': 'km'}}
  const {
    health: { run, timestamps },
  } = req.body

  const { secret } = req.headers

  if (secret !== APPLE_HEALTH_SECRET) {
    return res.send('permission denied! 🤬')
  }

  const healthRef = db.collection('apple_health')

  const date = new Date(timestamps)
  const timeZoneFromDB = +9.0
  const tzDifference = timeZoneFromDB * 60 + date.getTimezoneOffset()
  const offsetDate = new Date(date.getTime() + tzDifference * 60 * 1000)

  const key = `${offsetDate.getFullYear()}${(offsetDate.getMonth() + 1)
    .toString()
    .padStart(2, 0)}${offsetDate.getDate()}`

  const data = (await healthRef.doc('daily').get()).data()

  healthRef.doc('daily').set({
    ...data,
    [key]: run,
  })

  // 응답을 단순 text로 쏘면 아이폰에서 알림을 내보낼 수 있다.
  res.send('성공')
})
```

## 3. 결과

![result](./images/shortcut-result.gif)

![result](./images/shortcut-result.png)

지금은 단축어 앱을 클릭해야만 업로드 되는 구조지만, 이 작업을 그대로 단축어 > 자동화에 옮기면 자동으로 처리할 수 있다. 애플 워치에서 운동이 끝난 뒤라든가, 수면 준비 시작 시간이 되면 업로드 한다든가,,

처음에 단축어 앱이 생겼을 때, 그냥 단순히 QR 체크인 꺼내는 용도로만 썼었는데 이렇게 강력한 기능이 있는지 몰랐다. 이렇게 반성하면서 🤪 이걸로 해볼만한 더 재밌는일이 있을지 고민해봐야겠다. 심박수나 달리기 정보를 strava처럼 그래프로 보여주는 것들을 하면 재밌을 것 같다.


간만에 했본 간단하고 재밌는 일

애플 단축어와 GCP로 내 건강정보 업로드하기

ES6에서 새롭게 나온 Proxy는 요즘 많은 프레임워크에서 (요즘이라기엔 많이 지났지만,) 주목하고 있는 기능인 것 같다.

[mobx에서도 proxy를 쓰고 있고](https://mobx.js.org/configuration.html) [2010 JSconf 에서도 관련 영상이 존재하고](https://www.youtube.com/watch?v=sClk6aB_CPk&ab_channel=JSConf) (무려 11년전,,) [vue.js](https://v3.vuejs.org/guide/reactivity.html#what-is-reactivity)에서도 reactivity 지원을 위해 Proxy를 사용하고 있다.

## Proxy

[Proxy 객체는 기본적인 동작(속성 접근, 할당, 순회, 열거, 함수 호출 등)의 새로운 행동을 정의할 때 사용합니다.](https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Global_Objects/Proxy) 라고 되어 있다. 즉, 특정 객체의 읽기 쓰기 등 객체에 가해지는 작업을 중간에 가로채서 새로운 작업을 할 수 있는 것을 말한다. 프록시를 이해 하기 위해서는 아래의 용어에 대해 이해하고 있어야 한다.

- `target`: 기본 동작을 가로챌, 즉 감싸게 될 객체로 함수를 포함해서 모든 객체가 가능하다.
- `handler`: 동작을 가로채는 메서드인 `trap`을 가지고 있는 객체로, 여기에서 프록시를 설정한다.

먼저 트랩이 존재하지 않는 (= 동작을 가로채는 메서드가 없는) 예제를 살펴보자.

```javascript
const target = {}
const proxy = new Proxy(target, {}) // 핸들러가 없다

proxy.test = 5 // 프록시에 값을 썼는데

console.log(target.test) // 5 타겟에도 프로퍼티가 추가됐다.
console.log(proxy.test) // 5 프록시를 통해서도 읽을 수 있다.

console.log(proxy) // Proxy {test: 5}
console.log(target) // {test: 5}
```

마치 프록시가 타겟을 감싸는 래퍼처럼 작동한다.

이제 본격적으로 트랩을 추가하기 전에, 프록시가 가로챌 수 있는 작업에는 무엇이 있는지 알아보자.

- `get`
- `set`
- `has`
- `deleteProperty`
- `apply`
- `constructor`
- `getPrototypeOf`
- `setPrototypeOf`
- `isExtensible`
- `preventExtensions`
- `getOwnPropertyDescriptor`
- `ownKeys`

이 중에서, 가장 기본적인 예제인 `get` 트랩을 만들어보자.

```javascript
const arr = new Proxy([0, 1, 2, 3], {
  get(target, prop) {
    if (prop in target) {
      return target[prop]
    } else {
      console.log(`${prop}은 존재하지 않습니다`)
      return 0
    }
  },
})

console.log(arr[0]) // 1
console.log(arr[1]) // 2
console.log(arr[100]) // 0
// 100은 존재하지 않습니다 proxyConsoleLog.js:12
```

프록시에서 정의한 trap이 get을 가로채서 작동하고 있음을 알 수 있다.

이번엔 `set`트랩을 만들어보자. 다른언어의 그것 처럼, 숫자만 추가할 수 있는 배열을 만들어보자.

```javascript
const arr = new Proxy([], {
  set(target, prop, value) {
    if (typeof value === 'number') {
      target[prop] = value
      return true
    } else {
      return false
    }
  },
})

arr.push(1)
arr.push(2)
arr.push(3)
arr.push('졸려') // VM503:1 Uncaught TypeError: 'set' on proxy: trap returned falsish for property '3'

console.log([...arr]) // 1, 2, 3
```

성공적으로 push를 막은 것을 볼 수 있다.

## Reflect

[`Reflect`는 중간에서 가로챌 수 있는 작업에 대한 메소드를 제공한다.](https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Global_Objects/Reflect) `Reflect`는 생성자 함수가 아니므로, 인스턴스를 만들거나 `new`로 호출할 없다.

요약해서 말하자면, `Proxy` 생성을 단순화 한 빌트인 객체라고 보면 된다.

```javascript
const user = new Proxy(
  { name: 'John' },
  {
    get(target, prop, receiver) {
      return target[prop]
    },
    set(target, prop, val, receiver) {
      target[prop] = value
      return true
    },
  },
)
```

```javascript
const user = new Proxy(
  { name: 'John' },
  {
    get(target, prop, receiver) {
      return Reflect.get(target, prop, receiver) // target[prop] 를 대체 해주었다.
    },
    set(target, prop, val, receiver) {
      return Reflect.set(target, prop, val, receiver) // target[prop] = value 를 대체해주고, true/false도 리턴해준다.
    },
  },
)

console.log(user.name) // John
user.name = 'Pete' // pete
```

## `Observable` 만들기

mobx의 그것인 observable을 만들어보자.

```javascript
// 모든 객체에 공통적으로 observe를 달아둘 심볼
// 심볼로 선언하여 모든 객체에서 동일한 방법으로 접근할 수 있도록 한다.
const handlers = Symbol.for('handlers')

// 객체를 넘겨 받아서 observable 하게 만든다.
function observable(target) {
  // observe가 들어가는 곳
  target[handlers] = []

  // observe에 함수가 들어오면, handlers에 넣어 둔다.
  target.observe = function (handler) {
    this[handlers].push(handler)
  }

  // 프록시를 리턴한다.
  return new Proxy(target, {
    set(target, property, value, receiver) {
      // Reflect.set으로 값을 설정한다.
      const result = Reflect.set(...arguments)
      if (result) {
        // 각 handler에 현재 set arguments를 넘겨준다.
        target[handlers].forEach((handler) =>
          handler({ target, property, value, receiver }),
        )
      }
      return result
    },
  })
}

const user = observable({})

user.observe(({ property, value }) => {
  console.log(`'${property}' => '${value}'`)
})

user.name = '삼전주가떡상기원' // 'name' => '삼전주가떡상기원'
```

## Polyfill

바벨의 문서에는 다음과 같이 적혀있다.

https://babeljs.io/docs/en/learn/#ecmascript-2015-features-proxies

> Unsupported feature
>
> Due to the limitations of ES5, Proxies cannot be transpiled or polyfilled. See support in various JavaScript engines.

[따라서 babel repl에서 시도해보아도, 별 소용이 없다..](https://babeljs.io/repl#?browsers=defaults%2C%20ie%2011%2C%20not%20ie_mob%2011&build=&builtIns=false&spec=false&loose=false&code_lz=MYewdgzgLgBAhgJwTAvDMBTA7jACgkADwE8AKAbQF0AaGAbwCgYYIMpSpEBzN2gBwJ9aANzgAbAK4YAlPWbMm8gJYAzGB2J8MINaMkZUKNAHIwEgLYAjDAmOzG8-ZwQ8o5ASD6VUMPVMWOCGwSCGAwUAj-jgC-MBhirPQB8kFQIWEq4qzJ0Yq50dIMQA&debug=false&forceAllTransforms=false&shippedProposals=false&circleciRepo=&evaluate=false&fileSize=false&timeTravel=false&sourceType=module&lineWrap=true&presets=env&prettier=false&targets=&version=7.13.10&externalPlugins=)

- https://kangax.github.io/compat-table/es6/#test-Proxy
- https://github.com/GoogleChrome/proxy-polyfill
- https://caniuse.com/proxy

아쉽게도, 완벽하게 polyfill이 지원이 되지 않는다. 구글 크롬팀에서 만든 폴리필도 몇가지 밖에 동작하지 않는다.

> Currently, the following traps are supported-
>
> - get
> - set
> - apply
> - construct

따라서, ie 브라우저에서는 사용할 수 없다.


Page 6

타입스크립트 type과 interface의 공통점과 차이점

알쏭 달쏭한 자바스크립트 정규식

리액트 서버사이드 렌더링과 컴포넌트

애플 단축어와 GCP로 내 건강정보 업로드하기

자바스크립트의 프록시