작년 10월 쯤에 nextjs 10을 적용해보고 릴리즈 노트를 살펴보았는데, 어느덧 nextjs 11까지 나오게 되었다. 8개월 만에 메이저 버전을 업데이트 했는데, 정말 놀랍다. 반년 남짓한 사이에 또 발전을 만들어 냈는데 대단하다는 생각이 드는 한편으로 많이 자극도 되었다. 11 버전에서는 어떤 것들이 달라졌는지 살펴보자.

https://nextjs.org/blog/next-11

## Table of Contents

## CHANGELOG

### [Conformance](http://web.dev/conformance)

Conformance (한글로는 일치,부합,적합성이라고 하는데 딱히 뭐라고 번역해야 할지 모르겠다. 그냥 Conformance라 부르겠다.) 는 최적의 로딩 및 Core web vital을 지원하기 위해 만들어진 시스템으로, 보안 및 접근성과 같은 여러 품질 측면의 다양한 리소스를 지원하기 위한 기능이 제공된다. 이를 활용하면, 최적의 성능을 내기 위한 다양한 규칙들을 개발자들이 외우고 다닐 필요가 없이, 적합한 옵션을 선택할 수 있다.

또한 이번에 [eslint-config-next](https://github.com/vercel/next.js/tree/canary/packages/eslint-config-next)도 제공하면서, 개발 중에 생기는 프레임워크 관련 문제를 더 쉽게 파악할 수 있고, 개발 시에도 베스트 프랙티스를 보장할 수 있는 여러가지 가이드라인을 제공하게 되었다.

```bash
» npx next lint
info  - Loaded env from /Users/yceffort/private/yceffort-blog-v2/.env
info  - Using webpack 5. Reason: Enabled by default https://nextjs.org/docs/messages/webpack5
✔ No ESLint warnings or errors
```

뭐 근데, 사실 살펴보니까 대단한 룰들이 있지는 않았다.

https://github.com/vercel/next.js/blob/afa86cc5bbd488d123e2c5888205a40a5a0afe42/packages/eslint-config-next/index.js#L16-L27

```json
{
  "rules": {
    "import/no-anonymous-default-export": "warn",
    "react/react-in-jsx-scope": "off",
    "react/prop-types": "off",
    "jsx-a11y/alt-text": [
      "warn",
      {
        "elements": ["img"],
        "img": ["Image"]
      }
    ]
  }
}
```

하지만 주목할 만한 것은 `eslint-config-next`보다 `eslint-plugin-next` 였다.

https://github.com/vercel/next.js/tree/canary/packages/eslint-plugin-next/lib/rules

여기에 있는 룰들을 간단히 요약해보았다.

- `google-font-display`: 구글 폰트에 `font-display` 속성이 적절히 되어 있는지 여부
- `google-font-preconnect`: 구글 폰트에 `preconnect`가 사용되고 있는지 여부 (rel 속성)
- `link-passhref`: [next/link](https://nextjs.org/docs/tag/v9.5.2/api-reference/next/link#if-the-child-is-a-custom-component-that-wraps-an-a-tag)의 하위 컴포넌트가 커스텀으로 있다면 `passhref`를 넘겨주었는지 여부
- `no-css-tags`: html link 엘리먼트가 외부 스타일 시트를 불러오는 경우 (웹 페이지의 css 성능에 악영향)
- `no-document-import-in-page`: `next/document`가 `pages/_document.*sx`외부에서 사용되는 경우
- `no-head-import-in-document`: `pages/_document.*sx` 내부에 `next/head`를 쓰는 경우
- `no-html-link-for-pages`: `pages` 디렉토리가 없는 경우
- `no-img-element`: `<img/>` 대신 `<next/image>`를 쓰세여. `next/image`가 더 좋다. https://nextjs.org/docs/api-reference/next/image
- `no-page-custom-font`: custom font는 `pages/_document.*sx`에서 불러오세여
- `no-sync-script`: 외부 스크립트를 sync로 불러오지 말것
- `no-title-in-document-head`: `next/document`에 `<Head>`에 `<title>`에 있으면 안된다.
- `no-unwanted-polyfills`: next에서 이미 기본으로 제공하는 폴리필을 중복으로 불러오지 말것

대부분이 next와 관련된 룰이었지만, 이번에 구글과 함께 Conformance를 적용하면서 Core web vital을 많이 신경을 쓰기 시작한 것 같다. vercel에도 이와 관련한 기능이 있기도 하고.

![partner drive process](https://web-dev.imgix.net/image/0SXGYLkliuPQY3aSy3zWvdv7RqG2/QFTQX7npdBsFheXIqbuc.png?auto=format&w=845)

이전까지는 구글이 개발자들에게 제발좀 Core web vital을 지키세여!!! 라고 외치는 전략이었다면, 이번에는 영리하게도 프레임워크를 만들고 있는 파트너 (리액트, 뷰, 타입스크립트, 바벨 등)을 공략하여 이러한 프레임워크를 쓰고 있는 개발자라면 자연스럽게 Core Web Vital을 챙길 수 있게 끔 하는 전략으로 바꾼 것으로 보인다.

사실 잘 돌아가고 있는 앱에 (사실 그렇게 보이는 앱을..) 성능이 중요하다, core web vital이 중요하다, 라고 백날 이야기 해봐야 이를 챙기는 프론트엔드 개발자가 몇이나 있을까? 그래서 제발 좀 이를 지켜주세요!! 라고 하는 것보다는, 프레임워크 레벨에서 아예 이를 세트로 묶어서 공략한다면 번거롭게 추가로 무언가를 한다는 거부감을 줄일 수 있을 것 같다.

그리고 전체적인 프론트엔드 애플리케이션의 품질이 좋아지면, 구글의 웹페이지 정보 수집에도 많은 발전이 있을 것으로 보인다. 구글의 이러한 전략에 대한 내용은 https://web.dev/introducing-aurora/ 에 있는데, 나중에 나도 한번 다뤄봐야겠다.

### 성능 향상

개발자들의 개발 경험을 향상 시키기 위해, 10.1, 10.2 에서는 시작시간을 최대 24% 단축했고, React fast refresh를 활용해 개발시 업데이트 반영시간을 40%까지 단축했다. 그리고 이번 11에서는 시간을 더 줄이기 위해 babel에 추가적인 최적화가 포함되었다. 개발자들에게 느껴지는 직접적인 코드의 변화는 없지만, 개발 환경에서 더 빠른 환경을 제공할 수 있게 되었다.

### 스크립트 최적화

[next/script](https://nextjs.org/docs/basic-features/script)가 탄생했다. 써드파티 스크립트를 로딩할 때 시간과 성능을 개선할 수 있도록 도와준다.

```jsx
function Home() {
  return (
    <>
      <Script src="https://www.google-analytics.com/analytics.js" />
    </>
  )
}
```

이 `<Script>`는 `strategy` 속성있고, 다음 갑승ㄹ 가질 수 있다.

- `beforeInteractive`: 페이지가 활성화되기전에 (번들된 자바스크립트가 실행되기전에) 스크립트를 가져오고 실행한다. 스크립트가 SSR된 html내부에 주입된다.
- `afterInteractive`: 페이지가 활성화 된 이후 (번들된 자바스브립트가 모두 실행되고) 스크립트를 가져오고 실행한다. 스크립트를 hydration과정에서 주입하고, 이 후 즉시 실행된다.
- `lazyOnload`: `onload` 시점에 스크립트를 실행한다. `requestIdleCallback`을 활용하여 idle 상태가 되면 바로 실행한다.

```jsx
<Script
  src="https://polyfill.io/v3/polyfill.min.js?features=Array.prototype.map"
  strategy="beforeInteractive" // lazyOnload, afterInteractive
/>
```

`onLoad` 속성도 생겼다.

```jsx
<Script
  src={url} // consent mangagement
  strategy="beforeInteractive"
  onLoad={() => {
    // 로딩이 끝나면 그 이후에 실행됨. 그 이후에 스크립트를 로딩하거나 할 수 있음.
  }}
/>
```

또한 기본 script 로딩을 `async`에서 `defer`로 변경했다. `defer`가 더 좋은 이유, 이러한 변경을 하게된 계기는 아래 링크를 참조하자.

- https://yceffort.kr/2020/10/defer-than-async
- https://github.com/vercel/next.js/discussions/24938
- https://docs.google.com/document/u/0/d/1ZEi-XXhpajrnq8oqs5SiW-CXR3jMc20jWIzN5QRy1QA/mobilebasic#

### 이미지 최적화

[Cumulative Layout Shift](https://vercel.com/blog/core-web-vitals#cumulative-layout-shift)란 이미지 로딩으로 인해 사이트의 레이아웃이 갑자기 밀리거나 변하는 현상을 의미한다. `next/image`가 이 현상을 개선했다고 한다.

- 로컬이미지에 대한 사이즈 감지: `src`에 들어가 있는 로컬 이미지에 대해 너비와 높이를 자동으로 정의 한다고 한다.

```jsx
import Image from 'next/image'
import author from '../public/me.png'

export default function Home() {
  return (
    // 로컬 이미지를 불러오면, 알아서 width height를 계산한다.
    <Image src={author} alt="Picture of the author" />
  )
}
```

- 이미지 placeholder: 이미지가 완전히 로딩 되기전에 자동으로 블러된 이미지를 보여주는 placeholder를 지원한다.

지금 내 블로그의 헤더이미지, 프로필이미지, about 이미지 등에 적용되어 있다. (본문 이미지는 mdx로 되어있어서 적용되어있지 않다.)

```javascript
<Image src={author} alt="Picture of the author" placeholder="blur" />
```

또는 `blurDataURL`을 직접 넣어서 구현가능하다.

```jsx
<Image
  src="https://nextjs.org/static/images/learn.png"
  blurDataURL="data:image/jpeg;base64,/9j/2wBDAAYEBQYFBAYGBQYHBwYIChAKCgkJChQODwwQFxQYGBcUFhYaHSUfGhsjHBYWICwgIyYnKSopGR8tMC0oMCUoKSj/2wBDAQcHBwoIChMKChMoGhYaKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCj/wAARCAAIAAoDASIAAhEBAxEB/8QAFQABAQAAAAAAAAAAAAAAAAAAAAb/xAAhEAACAQMDBQAAAAAAAAAAAAABAgMABAUGIWEREiMxUf/EABUBAQEAAAAAAAAAAAAAAAAAAAMF/8QAGhEAAgIDAAAAAAAAAAAAAAAAAAECEgMRkf/aAAwDAQACEQMRAD8AltJagyeH0AthI5xdrLcNM91BF5pX2HaH9bcfaSXWGaRmknyJckliyjqTzSlT54b6bk+h0R//2Q=="
  alt="Picture of the author"
  placeholder="blur"
/>
```

### Webpack 5

nextjs에 webpack5가 이제 기본으로 지원된다. 이로 인한 이점은 [여기](https://nextjs.org/blog/next-10-2#webpack-5)에 나와 있다. 만약 webpack 5 미만 버전으로 custom 옵션을 사용하고 있다면, [여기](https://nextjs.org/docs/messages/webpack5)에서 마이그레이션을 할 수 있다.

### create-react-app migration

[@next/codemod](https://nextjs.org/docs/advanced-features/codemods)는, nextjs에서 deprecated된 기능을 자동으로 변환해주는 도구다. 여기에는 `/pages` 디렉토리를 생성하고, css를 적절한 위치로 import 하는 등의 옵션이 포함되어 있다. 여기에 cra로 생성된 앱을 점진적으로 nextjs로 바꿔주는 기능이 추가되었다.

```bash
npx @next/codemod cra-to-next
```

아직은 실험단계라고 한다.

### Next.js Live

https://nextjs.org/live 는, next를 활용한 전체 개발 프로세스를 웹 브라우저에서 할 수 있도록 도와주는 애플리케이션이다. 빌드단계를 생략하고 URL로 즉시 개발이 가능해지고, 공동작업도 가능하다고 한다. 아직 early access 단계라서 직접 사용해보지는 못했지만,

![nextjs.live](https://nextjs.org/_next/image?url=%2F_next%2Fstatic%2Fimage%2Fpublic%2Fstatic%2Flive%2Fbrowser.f5aa736f88c19b45aa423f7b1c0ca58f.png&w=3840&q=75)

모습을 보아하니, nextjs 애플리케이션을 stackblitz 처럼 웹에서 실시간으로 개발할 수 있게 해주고, 거기에 다른 디자이너나 기획자들이 협업할 수 있도록 도와주는 도구 인 것 같다.

이를 위해 서비스워커, 웹어셈플리, ESModule, [sucrase](https://github.com/alangpierce/sucrase), Tailwind JIT 등의 최신 기술을 집약했다고 한다.

### React 버전

최소 리액트 버전이 17.0.2로 업데이트 되었다고 한다.

### Upgrade guide

https://github.com/vercel/next.js/blob/canary/docs/upgrading.md

## 블로그 적용 후기

일단 새롭게 추가된 `<next/script>`, `<next/image>`의 blur를 위주로 적용했다. 개발 속도에서의 개선은 체감상 크게 못느꼈지만 (상대적으로 무겁지 않은 애플리케이션이라 더더욱), `Script` `blur` 등의 기능은 유용하게 쓸 수 있었다. 그리고 Conformance를 읽으면서 블로그의 라이트 하우스에 소홀했었다는 점을 떠올리며 점수를 끌어올렸다.

### before

![before](./images/before-blog.png)

### after

![after](./images/after-blog.png)

> 이정도면 꽤 만족스럽게 끌어올렸다. 당분간은 라이트 하우스를 쳐다보지 않아도 될 것 같다.

nextjs가 이렇게 훌륭한 프레임워크를 제공해주어서 좋을 따름이지만, 그 뒤에 숨겨져 있는, 프론트엔드 개발에 필요한 많은 요소들을 놓치거나 혹은 이것들을 상대적으로 덜 중요한 것으로 생각하는 경우도 종종 보게 된다. 어떻게든 좋은 애플리케이션을 만들면 되는 것은 회사와 블로그에서는 중요한 것일 수도 있지만, 그 뒤에 `babel`, `webpack`, `eslint` 가 어떻게 동작하고 있는지, `blur`처리는 어떻게 자동으로 되고 있는지, `Script`의 각 값별로 어떤식으로 동작하는 지 등을 이해하는 것은 개발자로서 성장하는데 있어 정말 중요한 일이다. 무지성 버전업, 이후 documentation 감상 후 적용 또한 좋은 일이지만, 이 뒤에서 무엇이 일어나고 있는지, 오픈소스 컨트리뷰터 들이 어떠한 고민을 하고 있는지도 뒤늦게나마 함께 공부해본다면 분명 유의미한 일이 될 것이다.


Nextjs 11 릴리즈 노트 살펴보고 블로그에 적용하기

[K8s 공부 (3)](/2021/06/study-k8s-3)에서 이어집니다.

## Namespace

- 리소스를 네임스페이스 안에 모아 둘 수 있다. 따라서 클러스트 하나에서 여러 개의 네임스페이스를 둘 수 있다. - 클러스트 내부의 가상의 클러스터로 볼 수 있다.
- 클러스터를 생성하면 기본적으로 네임스페이스가 4개 생성되어 있다.

```bash
» kubectl get namespace
NAME              STATUS   AGE
default           Active   8d
kube-node-lease   Active   8d
kube-public       Active   8d
kube-system       Active   8d
```

- `kube-system`: 이 namespace는 우리가 건들 필요가 없음. 시스템 프로세스, master, kubectl 을 관리
- `kube-public`: config map 과 같이 public하게 (인증이 없어도) 접근할 수 있는 데이터를 관리

```bash
» kubectl cluster-info
Kubernetes control plane is running at https://192.168.64.3:8443
KubeDNS is running at https://192.168.64.3:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
```

- `kube-node-lease`: nodes의 하트비트. 각 노드의 현재 가용성을 관리.
- `default`: 여기서 우리가 만드는 리소스가 생성됨.

```bash
» kubectl create namespace my-namespace
namespace/my-namespace created
» kubectl get namespace
NAME              STATUS   AGE
default           Active   8d
kube-node-lease   Active   8d
kube-public       Active   8d
kube-system       Active   8d
my-namespace      Active   11s
```

이렇게 명령어로 생성하는 것 외에, namespace 설정 파일로도 만들 수 있음. (이게 더 낫다)

### 왜 네임스페이스를 만들어야 하나?

공식 문서에 따르면, 10명이하의 사용자가 있는 작은 프로젝트에서는 네임스페이스를 사용하지 말라고 한다. 뭐 그럼에도 네임스페이스별로 관리해서 개발하는 것이 여러가지 이점이 있다.

만약 클러스터에 하나의 네임스페이스만 있다고 가정해보자. 온갖 리소스들이 디폴트 네임스페이스에 생성되고, 복잡한 deployments의 경우 여러가지 리소스들이 섞이게 될 것이다. 그렇게 되면 여러개의 컴포넌트가 섞이게 되면서 현재의 overview를 볼 수 없을 것이다.

따라서 리소스를 네임스페이스를 통해서 그룹화 할 수 있다. `Database` `Monitoring` `Elastic Stack` `nginx-ingress` 등으로 관리 할 수 있다.

또 두개의 팀이 있고, 하나의 디폴트 네임스페이스만 쓴다고 가정해보자. 두 팀이 같은 deployment 이름으로 다른 설정으로 배포한다면, 하나의 deployment를 덮어버리는 사태가 발생한다. 이러한 충돌을 방지하기 위해서는, 팀별로 네임스페이스를 별도로 관리하는 것이 좋다. 그리고 팀별로 분리하게 되면, 서로의 리소스를 침해하는 등의 문제도 발생하지 않을 것이다.

마지막으로, staging, deployment 등 배포 레벨을 여러개로 관리하는 경우를 생각해보자. nginx-ingress controller, elastic 등은 배포 환경에 상관없이 재활용할 수 있으므로 네임스페이스를 활용하는 것이 좋다.

- 컴포넌트를 구조화 할 수 있음
- 팀 사이의 충돌을 방지할 수 있음
- 다른 환경에서도 서비스를 재사용할 수 있음
- 네임스페이스 별로 접근과 리소스를 제한할 수 있음

### 네임스페이스의 특징

- 다른 네임스페이스에 있는 대부분의 리소스에 접근할 수 없다. (다른 네임스페이스에 있는 configmap, secret을 참조하는 등을 할 수 없다.) 그러나, 서비스의 경우에는 가능하다.
- 일부 컴포넌트는 네임스페이스 내부에서 생성할 수 없다. (글로벌로 생성해야하는 것들) 이러한 것들에는 volume, node 가 있다.

`네임스페이스 내부에 생성할 수 없는 것들`

```bash
» kubectl api-resources --namespaced=false
NAME                              SHORTNAMES   APIVERSION                             NAMESPACED   KIND
componentstatuses                 cs           v1                                     false        ComponentStatus
namespaces                        ns           v1                                     false        Namespace
nodes                             no           v1                                     false        Node
persistentvolumes                 pv           v1                                     false        PersistentVolume
mutatingwebhookconfigurations                  admissionregistration.k8s.io/v1        false        MutatingWebhookConfiguration
validatingwebhookconfigurations                admissionregistration.k8s.io/v1        false        ValidatingWebhookConfiguration
customresourcedefinitions         crd,crds     apiextensions.k8s.io/v1                false        CustomResourceDefinition
apiservices                                    apiregistration.k8s.io/v1              false        APIService
tokenreviews                                   authentication.k8s.io/v1               false        TokenReview
selfsubjectaccessreviews                       authorization.k8s.io/v1                false        SelfSubjectAccessReview
selfsubjectrulesreviews                        authorization.k8s.io/v1                false        SelfSubjectRulesReview
subjectaccessreviews                           authorization.k8s.io/v1                false        SubjectAccessReview
certificatesigningrequests        csr          certificates.k8s.io/v1                 false        CertificateSigningRequest
flowschemas                                    flowcontrol.apiserver.k8s.io/v1beta1   false        FlowSchema
prioritylevelconfigurations                    flowcontrol.apiserver.k8s.io/v1beta1   false        PriorityLevelConfiguration
ingressclasses                                 networking.k8s.io/v1                   false        IngressClass
runtimeclasses                                 node.k8s.io/v1                         false        RuntimeClass
podsecuritypolicies               psp          policy/v1beta1                         false        PodSecurityPolicy
clusterrolebindings                            rbac.authorization.k8s.io/v1           false        ClusterRoleBinding
clusterroles                                   rbac.authorization.k8s.io/v1           false        ClusterRole
priorityclasses                   pc           scheduling.k8s.io/v1                   false        PriorityClass
csidrivers                                     storage.k8s.io/v1                      false        CSIDriver
csinodes                                       storage.k8s.io/v1                      false        CSINode
storageclasses                    sc           storage.k8s.io/v1                      false        StorageClass
volumeattachments                              storage.k8s.io/v1                      false        VolumeAttachment
```

`네임스페이스 내부에 생성할 수 있는 것들`

```bash
» kubectl api-resources --namespaced=true
NAME                        SHORTNAMES   APIVERSION                     NAMESPACED   KIND
bindings                                 v1                             true         Binding
configmaps                  cm           v1                             true         ConfigMap
endpoints                   ep           v1                             true         Endpoints
events                      ev           v1                             true         Event
limitranges                 limits       v1                             true         LimitRange
persistentvolumeclaims      pvc          v1                             true         PersistentVolumeClaim
pods                        po           v1                             true         Pod
podtemplates                             v1                             true         PodTemplate
replicationcontrollers      rc           v1                             true         ReplicationController
resourcequotas              quota        v1                             true         ResourceQuota
secrets                                  v1                             true         Secret
serviceaccounts             sa           v1                             true         ServiceAccount
services                    svc          v1                             true         Service
controllerrevisions                      apps/v1                        true         ControllerRevision
daemonsets                  ds           apps/v1                        true         DaemonSet
deployments                 deploy       apps/v1                        true         Deployment
replicasets                 rs           apps/v1                        true         ReplicaSet
statefulsets                sts          apps/v1                        true         StatefulSet
localsubjectaccessreviews                authorization.k8s.io/v1        true         LocalSubjectAccessReview
horizontalpodautoscalers    hpa          autoscaling/v1                 true         HorizontalPodAutoscaler
cronjobs                    cj           batch/v1beta1                  true         CronJob
jobs                                     batch/v1                       true         Job
leases                                   coordination.k8s.io/v1         true         Lease
endpointslices                           discovery.k8s.io/v1beta1       true         EndpointSlice
events                      ev           events.k8s.io/v1               true         Event
ingresses                   ing          extensions/v1beta1             true         Ingress
ingresses                   ing          networking.k8s.io/v1           true         Ingress
networkpolicies             netpol       networking.k8s.io/v1           true         NetworkPolicy
poddisruptionbudgets        pdb          policy/v1beta1                 true         PodDisruptionBudget
rolebindings                             rbac.authorization.k8s.io/v1   true         RoleBinding
roles                                    rbac.authorization.k8s.io/v1   true         Role
```

### 네임스페이스 내부에 컴포넌트를 만드는 법

이전에 설정파일들로 만들어보았지만, 별도로 네임스페이스를 지정한 적이 없다. 이 경우에는 기본값으로 default 네임스페이스에 생성되어버린다.

```bash
» kubectl apply -f mongo-configmap.yaml --namespace=my-namespace
configmap/mongodb-configmap created
```

또는, `metadata.namespace`에 기재하는 방법 있다.

```yaml
» cat mongo-configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: mongodb-configmap
  namespace: my-namespace
data:
  database_url: mongodb-service # 서비스 메타데이터 네임을 그대로 가져온다.%
```

이를 가져오기 위해서는, `-n`을 활용하면 된다.

```bash
» kubectl get configmap -n my-namespace
NAME                DATA   AGE
kube-root-ca.crt    1      19m
mongodb-configmap   1      97s
```

귀찮으니 설정파일 내부에 기재해두자. 문서화에도 도움이되고, 까먹지도 않고 자동으로 편리하게 적용할 수 있다.

### 디폴트 네임스페이스 변경하기

앞서 살펴보았던 것처럼, 기본값은 `default`다. 이 기본값을 바꿔주는 것이 [kubens](https://github.com/ahmetb/kubectx)다.

```bash
» brew install kubectx
==> Downloading https://ghcr.io/v2/homebrew/core/kubectx/manifests/0.9.3
######################################################################## 100.0%
==> Downloading https://ghcr.io/v2/homebrew/core/kubectx/blobs/sha256:30c0b39d23e542bc936994a8c1a47705f0205e42e59cb043adaed21
==> Downloading from https://pkg-containers.githubusercontent.com/ghcr1/blobs/sha256:30c0b39d23e542bc936994a8c1a47705f0205e42
######################################################################## 100.0%
==> Pouring kubectx--0.9.3.all.bottle.tar.gz
==> Caveats
zsh completions have been installed to:
  /usr/local/share/zsh/site-functions
==> Summary
🍺  /usr/local/Cellar/kubectx/0.9.3: 12 files, 37.8KB
```

```bash
» kubens
default
kube-node-lease
kube-public
kube-system
my-namespace
```

활성화 되어있는 네임스페이스가 색이 칠해져서 보일 것이다.

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

```bash
» kubens my-namespace
Context "minikube" modified.
Active namespace is "my-namespace".
```


무지성에서 시작하는 K8s 공부해보기 시리즈(4) namespace의 정의를 정확히 알아야지

K8s 공부 (4)

ECMAScript (ES2015, ES) 모듈이란 자바스크립트에서 각 코드를 하나의 청크로 구성할 수 있게 해주는 방법을 제공한다. 먼저, 자바스크립트의 값을 외부로 노출을 시킨다.

```javascript
export const sum = (a, b) => a + b
```

그리고 이 값(함수)을 필요로 하는 곳에서 아래와 같이 사용한다.

```javascript
import { sum } from './test'

sum(1, 2)
```

대부분의 경우에는 위의 예제 처럼 상단에 필요한 모듈들을 static하게 import하는 것이 일반적이지만, 떄때로 이를 필요에 따라 조건부로 불러올 수도 있다. [dynamic import](https://caniuse.com/?search=dynamic%20import)라고 불리며, 이는 ES2020(ES11)에 포함된 기능이다.

```javascript
const sum = await import('./test')
```

`await import`는 프로미스를 리턴하고 이 때부터 동적으로 모듈을 불러오기 시작한다. 그리고 모듈을 성공적으로 불러오면, promise는 모듈을 resolve하거나 실패할 경우 reject 하게 된다.

그리고 `import`내의 구문은 모듈의 위치를 가리키는 string이면 되기 때문에, 함수 외부에서 인수로 받거나 계산된 string을 받는 것들도 가능하다.

```javascript
export const sum = (a, b) => a + b
```

```javascript
async function calc(a, b) {
  const { sum } = await import('./test')
  sum(a, b)
}

calc(1, 2) // 3
```

이제 default 의 경우를 살펴보자.

```javascript
const sum = (a, b) = > a + b
export default sum
```

이 경우에는 `default` 키워드를 사용하면 된다.

```javascript
async function calc() {
  const { default: sum } = await import('./test')
  sum(1, 2)
}
```

한가지 유의 할 것은,

```javascript
const sum = await import('./test')
```

이렇게는 안된다는 것이다.

default와 그 외의 것들이 섞여있는 경우라면 아래와 같이 처리하면 된다.

```javascript
const sum = (a, b) => a + b
export const sum1 = (a, b) => a + b
export const sum2 = (a, b) => a + b

export default sum
```

```javascript
const { default: sum, sum1, sum2 } = await import('./test')
```


ESModule을 동적으로 import 하기

소프트웨어 개발 원칙 중의 하나인 [DRY, don't repeat yourself](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) 는 너무나도 유명해서 별로 설명할게 없긴한다. type을 잘 사용하면, 조금 더 효과적으로 소프트웨러를 설계할 수 있다.

## 타입 확장하기

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

// don't
interface PersonWithBirthday {
  name: string
  age: number
  birth: Date
}

// do
interface PersonWithBirth extends {
  birth: Date
}
```

`type`을 사용한다면, `&`으로도 가능하다.

```typescript
type PersonWithBirth = Person & { birth: Date }
```

## 타입 좁히기

이전 예제와 반대의 예제를 들어보자. 이번엔 큰 타입에서 작은 타입의 subset이 필요한 경우다.

```typescript
interface User {
  userId: string
  name: string
  age: number
  email: string
}

interface SelectedUser {
  userId: string
  email: string
}
```

이 역시 중복이 발생하므로, 좋지 못한 방법이다.

```typescript
type SelectedUser = {
  userId: User['userId']
  email: User['email']
}

interface SelectedUser {
  userId: User['userId']
  email: User['email']
}
```

오오 놀랍다. 타입의 값을 마치 객체에서 값을 꺼내온 것마냥 썼다. 이렇게 해두면, `User`의 `userId`가 number로 바뀌게되도, 자동으로 그 타입도 따라가게 될 것이다.

하지만 이 역시도 번거로운 점이 있다. key조차도 나는 똑같이 할 건데, 굳이 키를 다시 선언할 필요가 있을까?

```typescript
type SelectedUser = {
  [k in 'userId' | 'email']: User[k]
}
```

![type-operations1](./images/type-operation1.png)

오옹 신기하다. 하지만 이미 우리는 이것보다 더 편한 방법을 알고 있다.

```typescript
type SelectedUser = Pick<User, 'userId' | 'email'>
```

[Pick](https://www.typescriptlang.org/docs/handbook/utility-types.html#picktype-keys) 을 쓰면 간단하게 해결할 수 있다.

## 공통타입 추출하기

```typescript
interface Save {
  action: 'save'
  body: string
  id: string
}

interface Load {
  action: 'load'
  body: string
  id: string
}

type Action = Save | Load
type ActionType = 'save' | 'load' // Repeat!
```

두 타입은 `action`의 값 외엔 모든게 똑같은데, 여기서 `action`을 또다른 타입으로 추려내기 위해서 `'save' | 'load'`를 썼다. 이것도 마찬가지로, 아래 처럼 바꿀 수 있다.

```typescript
type ActionType = Action['action'] // type ActionType = "save" | "load"
```

## 타입 옵셔널하게 사용하기

객체의 모든 키가 옵셔널 하다면 어떻게 해야할까? 일일히 모두 물음표를 달아야할까?

```typescript
interface Person {
  age?: number
  name?: string
  email?: string
  gender?: string
}
```

그렇지 않다. `Partial<Person>`을 사용하면, 안에 있는 모든 키를 옵셔널하게 바꿔준다. 이는 옵셔널한 값을 받는 상황 (api로 값을 업데이트 한다던지)에 매우 유용하게 쓸 수 있다.

```typescript
function update(options: Partial<Person>) {
  // .. 적당히 값을 받아서 처리한다.
}
```

## 값으로 부터 타입을 추출하기

기본적으로 개발 흐름은 타입을 선언하고 값을 쓰는 형태로 가지만, 반대인 경우가 있을 수 있다. 이 경우에는 아래와 같이 하면 된다.

```typescript
const INIT_VALUES = {
  width: 640,
  height: 480,
  price: 150_000,
  name: 'monitor',
}

type Options = typeof INIT_VALUES
// 위 타입은 아래와 같다.
// type Options = {
//     width: number;
//     height: number;
//     price: number;
//     name: string;
// }
```

한가지 조심해야 할 것은, `typeof`의 사용이다. 아래 두 코드는 엄연히 다르다.

```typescript
const t = typeof INIT_VALUES // "object"
type o = typeof options
// type Options = {
//     width: number;
//     height: number;
//     price: number;
//     name: string;
// }
```

값을 선언한 코드에 `typeof`를 때리면 자바스크립트 런타임의 [typeof](https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Operators/typeof)를 실행하게 된다. 값을 가져오고 싶은건지, type을 가져오고 싶은건지 확실히 해야 한다. 조건문 같은 곳에 `typeof`를 둔다면 자바스크립트 런타임의 `typeof`를 실행한다는 것을 명심하자. `type`에 `typeof`를 쓰면, 타입스크립트만 알아듣는다.

이렇게 쓰긴했지만, 어디까지나, 타입을 먼저쓰고 값을 쓰는 경우가 훨씬 더 일반적이고 정확하다.

## 함수의 결과를 타이핑 하기

함수의 결과를 타이핑하고 싶다면, [ReturnType](https://www.typescriptlang.org/docs/handbook/utility-types.html#returntypetype)과 제네릭을 활용하면 된다.

```typescript
function getUserInfo(userId: string) {
  // ...

  return {
    userId,
    name: 'hello',
    age: (Math.random() * 100) / 100,
    email: 'random@email.com',
  }
}

type userInfo = ReturnType<typeof getUserInfo>
// 위와 같다.
// type userInfo = {
//     userId: string;
//     name: string;
//     age: number;
//     email: string;
// }
```

이러한 패턴은 라이브러리에서 함수의 리턴을 emit할 때 많이 쓴다. 주의할 점은, 제네릭에 `getUserInfo`가 아니고 `typeof gerUserInfo`가 들어갔다는 점이다. `ReturnType`는 타입을 제네릭으로 받아야 한다.

```typescript
type t = typeof getUserInfo

// 위와 같다.
// type t = (userId: string) => {
//     userId: string;
//     name: string;
//     age: number;
//     email: string;
// }
```

이로써 함수만 바꾸더라도, 타입까지 자동으로 바뀌어서 [single source of truth](https://ko.wikipedia.org/wiki/%EB%8B%A8%EC%9D%BC_%EC%A7%84%EC%8B%A4_%EA%B3%B5%EA%B8%89%EC%9B%90)를 지킬 수 있었다.

## 제네릭으로 파라미터 제한하기

제네릭 타입은 함수를 위한 타입과 같다. 그리고 함수가 DRY 원칙을 지키기 위한 수단인 것을 감안했을때, 제네릭도 마찬가지로 타입의 DRY를 위한 필수 요소라고 볼 수 있다.

```typescript
interface Name {
  first: string
  last: string
}

type PairProgrammer<T extends Name> = [T, T]

const day1: PairProgrammer<Name> = [
  { last: 'KIM', first: 'YONGCHAN' },
  { last: 'LEE', first: 'JAEYONG' },
]

const day2: PairProgrammer<Name> = [
  { last: 'KIM' }, // Property 'first' is missing in type '{ last: string; }' but required in type 'Name'.
  { last: 'LEE' }, // Property 'first' is missing in type '{ last: string; }' but required in type 'Name'.
]
```

> 한가지 조금 개인적으로 아쉬운것은, 제네릭 파라미터를 생략할 수 없다는 점이다. `PairProgrammer<Name>` 대신 `PairProgrammer`를 쓸 수 없다는 점이다.

## Pick 구현해보기

이렇게 `extends` 키워드까지 활용한다면, `Pick`과 동일한 타입을 추출하는 나만의 `Pick`을 만들 수 있다.

```typescript
type MyPick<T, K extends keyof T> = {
  [k in K]: T[k]
}
```


interface를 더 좋아하지만 type이 더 간지남

타입스크립트의 타입과 제네릭 적극 활용하기

무지성에서 시작하는 K8s 공부해보기 시리즈(3)

Latest

Nextjs 11 릴리즈 노트 살펴보고 블로그에 적용하기

K8s 공부 (4)

ESModule을 동적으로 import 하기

타입스크립트의 타입과 제네릭 적극 활용하기

K8s 공부 (3)