패턴 매칭 그리고 ts-pattern에 대해 알아보고, 이를 활용하여 문제들을 해결했던 사례들을 소개합니다.

ts-pattern을 활용하여 해결했던 것

이 글에서는 마이크로 프론트엔드에 관한 고찰과 [웹팩 5의 Module Federation](https://webpack.kr/concepts/module-federation/) 일부 기능에 대해 알아보고, 적당한 예시 코드 작성을 통해 얻은 생각을 나눠 볼 생각이다.

내가 마이크로 프론트엔드 아키텍처에 관심을 가지고 고찰을 하게 된 계기는 현재 개발/운영 중인 [배민상회](https://mart.baemin.com/)라는 서비스의 환경과 관련이 있다.
( 배민상회는 요식업 사장님들을 대상으로 필요한 상품들을 판매하는 이커머스 서비스 )

여느 쇼핑몰들과 마찬가지로 많은 페이지가 존재하고, 지난 수년 간 많은 개발자들의 열정과 노력으로 생산된 코드의 양도 풍족한 상황이다. `Webpack Bundle Analyzer` 를 통해 분석한 결과를 잠깐 확인을 해보면,

![https://www.kimcoder.io/assets/images/baeminmart-158.png](https://www.kimcoder.io/assets/images/baeminmart-158.png)

쇼핑몰에서 제공하는 **약 120개의 페이지는 14M에 육박하는 번들 코드가 158개의 청크로 분리**되어 있다.

( 서버사이드 코드와 프로젝트 외부에 있는 디자인 시스템과 같은 코드들까지 고려하면 조금 더 많을 것 같다. )
과거 개발 초기 단계에서 선택된 모노리스한 Single-Page-Application 방식의 개발은 현재까지 고수되어 왔고,

비대해진 애플리케이션의 빌드 퍼포먼스, 코드 탐사, 의존 관리 등의 비용은 점차 증가하고 있다.

개발 편의성과 생산성을 위해 아키텍처 개선이 필요한 시간이 된 것이라고 생각이 들었다.

여러가지 방식을 통해 개선이 가능하겠지만,

나는 **마이크로 프론트엔드에 대한 고찰**과 **게임 체인저라고 불리우는 [웹팩 5의 Module Federation](https://webpack.kr/concepts/module-federation/)**의 일부 기능에 대해 알아 볼 예정이고, 예시 코드 작성 경험을 통해 리팩터링의 밑거름을 만들 생각이다.

## Micro Frontend?

마이크로 프론트엔드의 개념은 수많은 개발자, 그리고 조직들이 모노리스 아키텍처에서 마이크로 서비스 아키텍처로 전환하면서 얻은 이점들을 웹 애플리케이션 개발 환경과 생태계에도 적용하고자 했던 접근으로부터 나온 것이다.

마이크로 프론트엔드에 대한 설명과 세부적인 구현 예는 [마틴파울러 글](https://martinfowler.com/articles/micro-frontends.html#TheMicroFrontends)에도 소개된 [Cam Jackson](https://camjackson.net/)의 글에 잘 설명이 되어있다. 이 글에서는 마이크로 프론트엔드의 구현으로 여러 가지 방식의 예를 들었지만 결과적으로 채택한 방식은 **컨테이너 애플리케이션와 마이크로 애플리케이션을 분리하고** **런타임에서 컨테이너 애플리케이션이 마이크로 애플리케이션들을 통합**하는 방식이었다. 애플리케이션들은 모두 독립된 환경에서 개발할 수 있으며, 필요에 의해 공통 UI 구성 요소들을 사용할 수도 있다. 컨테이너 애플리케이션 통합하는 역할을 맡아 라우팅 경로에 따라 각 마이크로 애플리케이션을 제공할 수 있도록 처리된다.

![https://www.kimcoder.io/assets/images/micro-frontend-1.png](https://www.kimcoder.io/assets/images/micro-frontend-1.png)

마이크로 프론트엔드의 주요한 장단점은 아래와 같이 요약할 수 있다.

**장점**

- 마이크로 애플리케이션들의 **기술 스택, 코드 베이스, 외부 패키지 버전 관리는 개별적으로 처리**할 수 있다.
- 마이크로 애플리케이션들의 **개발, 테스트, 배포는 독립적**이다.
 - 코드베이스는 모두 각 애플리케이션의 명세에 맞게 단순하게 설계 가능.
- **사용자에게는 단일 애플리케이션처럼 동작**한다.
 - 각 기능에서 개별로 구현된 UI/UX는 동일한 룩앤필과 경험을 제공.

**단점**

- **사용자로부터의 외부 패키지 번들 중복 요청**.
 - ex) react와 같은 패키지가 애플리케이션 A와 B의 번들링 코드에 중복으로 들어갈 수 있음.
- **개발 환경.**
 - 독립적인 개발 환경을 보장받을 수 있지만, 통합된 애플리케이션의 환경과 차이가 있으므로 발생할 수 있는 문제점.
- **운영 복잡도**
 - 기술 스택, 개발 관습의 파편화 가능성.
 - 코드 저장소, 배포 파이프라인, 테스트 및 릴리즈 프로세스 증가 가능성.

아키텍처에는 항상 다양한 관점과 상황에서의 해법이 여럿 있고 마이크로 프론트엔드에 대해 생각하는 것도 마찬가지일 것이다. 나는 [Cam Jackson 글](https://martinfowler.com/articles/micro-frontends.html#TheMicroFrontends)에 소개된 마이크로 프론트엔드에 대한 해법에 전적으로 동의한다.

애플리케이션들은 런타임 환경에서 통합이 되어야 하고, 각자의 개발 생명 주기를 가질 수 있어야 한다. 이는 CI/CD도 모두 독립적으로 구성이 될 수 있다는 뜻이며, 일부 변경된 기능을 위해 애플리케이션 전체가 다시 빌드, 배포가 되지 않아도 된다는 것이다.

이제, 마이크로 프론트엔드 구성을 손쉽게 해줄 [웹팩 5의 Module Federation](https://webpack.kr/concepts/module-federation/)에 대해서 알아보도록 하자.

## Module Federation?

웹팩 5 버전의 출시와 함께 나온 기능 중 하나인 **모듈 페더레이션은 특정 애플리케이션(모듈)에서 동적으로 다른 빌드의 모듈 코드를 불러와 실행을 할 수 있게 해준다.**

즉, 여러 개의 개별 빌드 코드가 하나의 어플리케이션 내에서 구동되는 것이다. 또한, 개별 빌드는 서로 의존성이 없어 개별적으로 빌드, 배포가 가능하다.

모듈 페더레이션의 몇 가지 용어와 특징을 ( _고수준 관점으로_ )요약해 보겠다.
( 상세한 내용은 [공식 문서](https://webpack.kr/concepts/module-federation/)에서 확인할 수 있다. )

- **각각의 빌드는 컨테이너 역할을 한다.**
- **각각의 빌드는 호스트와 리모트 모두 될 수 있다.**
 - **host :** 호스트는 페이지 로드 시 가장 먼저 초기화되는 빌드.
 - **remote :** 리모트는 호스트에 의해 소비되는 빌드.
 - 빌드 된 **모듈은 런타임에서 모두 양방향(Bidirectional)으로 소비될 수 있다.**
- 각 컨테이너들에서 공통적인 외부 패키지의 디펜던시는 설정으로 청크의 중복을 막을 수 있다.
 - 특정 버전을 명시한다면, 해당 버전으로 사용할 수 있다.
 - ex) react, react-dom, etc..
- 위의 **설정들은 웹팩의 ModuleFederationPlugin을 통해 할 수 있다.**
- 환경에 의존하지 않는다.
 - ex) browser, node.js 등에서 사용 가능.

### 유즈케이스

- **공용 컴포넌트 라이브러리의 컨테이너로 사용**
 여러 애플리케이션에서 사용하는 디자인 시스템과 같은 공용 컴포넌트 혹은 추상화된 코드들을 라이브러리 컨테이너로 만들어 공유하는 방법이다.
 이는 애플리케이션과 공용 코드들의 독립적인 개발, 배포가 가능하다.
 공용 컴포넌트의 업데이트가 일어날 경우, 애플리케이션들은 배포 없이 런타임에서 최신 버전의 컴포넌트 라이브러리를 자동으로 사용할 수 있다.

 

![https://www.kimcoder.io/assets/images/federation-component-libarary-container.png](https://www.kimcoder.io/assets/images/federation-component-libarary-container.png)

 

- **페이지별 독립적 빌드 시 사용**
 단일 페이지 애플리케이션에서 각 페이지를 분리하여 독립적인 개발과 배포 프로세스를 가질 수 있다.
 애플리케이션 쉘을 상위 레벨에 두고, 페이지 라우팅에 맞는 각 애플리케이션을 원격 모듈로 참조하는 방식이다. 애플리케이션 쉘은 일반적으로 사용되는 라이브러리를 공유 모듈로 정의할 수 있고, 라우팅 경로의 변경이 있어날 경우에 배포를 하게 된다. 각 페이지 애플리케이션은 다른 페이지와 상관없이 독립적인 배포가 가능하다.

 

![https://www.kimcoder.io/assets/images/federation-page-seperation.png](https://www.kimcoder.io/assets/images/federation-page-seperation.png)

 

리모트와 호스트 사이의 화살표는 **모듈들이 런타임에서 모두 양방향(Bidirectional)으로 소비가 가능한 것을 보여준다.** 이는 예제에서 조금 더 자세히 다루겠다.

위의 두 가지의 사례를 적절하게 조합하여 다음 예제를 구성해 보자.

## 예제

![https://www.kimcoder.io/assets/images/federation-example.png](https://www.kimcoder.io/assets/images/federation-example.png)

위와 같은 구조로 설계를 한다고 가정하여, 몇 가지 설정에 대해 구체적인 코드를 작성해 보자

## 디렉토리 구조

```tsx
- packages
	- core
		- ...
		- webpack.config.js
		- package.json
	- order
		- core와 유사
	- shell
		- core와 유사
	- products
		- core와 유사
	- ...
- ...
- package.json // 패키지 스크립트 병렬 실행을 위한 스크립트
```

- 각 모듈은 packages 디렉토리 하위에 위치한다.
- 각 모듈은 webpack을 사용하며, 독립적으로 외부 패키지 의존성을 가진다.
- 루트 디렉토리의 package.json은 각 모듈의 스크립트를 병렬로 실행할 수 있게 설정한다.

## Shell Module

### webpack.config.js

- **shell**의 webpack 설정은 아래와 같은 내용을 따르도록 한다.
 - 호스트 애플리케이션으로써, 모든 리모트 애플리케이션 모듈 소비.
 - order와 같은 다른 애플리케이션들에서 페더레이트가 가능하도록 `Shell App` 을 리모트로 노출.
 - 만약, 페이지 전역에서 사용될 Context 등과 같은 코드가 있다면 노출.
 - 코어 라이브러리 컨테이너 모듈 소비.
 - 로컬에서 3000번 포트로 동작.
 - 공용 외부 패키지는 중복된 청크가 발생되지 않도록 선언.

```tsx
plugins: [
 new ModuleFederationPlugin({
 name: 'shell',
 filename: 'shell.remoteEntry.js', // shell의 리모트 엔트리
 remotes: {
				core: 'core@http://localhost:2000/core.remoteEntry.js',
				main: "main@http://localhost:3001/main.remoteEntry.js",
 products: "products@http://localhost:3002/products.remoteEntry.js",
 order: "order@http://localhost:3003/order.remoteEntry.js",
 },
 exposes: {
 './Shell': './src/Shell'
 },
 shared: [
 {
 react: {
 singleton: true,
 requiredVersion: deps.react,
 },
 'react-dom': {
 singleton: true,
 requiredVersion: deps['react-dom'],
 },
 },
 ],
 }),
]
```

### Entry of webpack

- 모듈 페더레이션 시, 일반적으로 비동기 경계를 사용하는 것이 추천되기 때문에 이 내용을 따른다.
 - 비동기 경계가 추천되는 이유는 성능 향상을 위해 청크의 초기화 코드를 분할하기 위함.

```tsx
// index.js
import('bootstrap');

// bootstrap.js
import ShellApp from "./ShellApp";
import React from "react";
import { createRoot } from "react-dom/client";

const root = createRoot(document.getElementById("root"));

root.render(<ShellApp />);
```

### React App

- 코어 컴포넌트, 혹은 디자인 시스템 컴포넌트는 **코어 컴포넌트 라이브러리 컨테이너 모듈에서** **가져온다**.
- 각 **페이지들은 개별 페이지 애플리케이션 모듈에서 가져온다**.

```tsx
const Tabs = React.lazy(() => import('core/Tabs'));

const MainPage = React.lazy(() => import('main/MainPage'));
const ProductsPage = React.lazy(() => import('products/ProductsPage'));
....

const ShellApp = () => {
	return (
	 <Provider>
			<React.Suspense fallback={'Loading'}>
				<GNB>
					<Tabs>
	 <Link to="/">...</Link>
	 <Link to="/products">Products</Link>
							....
	 </Tabs>
				</GNB>
			</React.Suspense>
			<React.Suspense fallback={'Loading'}>
				<Routes>
 <Route path="/" element={<MainPage />} />
 <Route path="products/*" element={<ProductsPage />} />
						....
				</Routes>
			</React.Suspense>
		</Provider>
	)
};

export default ShellApp;
```

## Core Component Library Module

### webpack.config.js

- **Core Component Library**의 webpack 설정은 아래와 같은 내용을 따르도록 한다.
 - 리모트 모듈로만 사용.
 - 로컬에서 2000번 포트로 동작.
 - 공용 외부 패키지는 중복된 청크가 발생되지 않도록 선언.

```tsx
plugins: [
 new ModuleFederationPlugin({
 name: 'core',
 filename: 'core.remoteEntry.js',
 exposes: {
 './Button': './src/Button'
 './Tabs': './src/Tabs'
 },
 shared: {
 react: {
 singleton: true,
 requiredVersion: deps.react,
 },
 'react-dom': {
 singleton: true,
 requiredVersion: deps['react-dom'],
 },
 },
 }),
 ],
```

**Components**

- 컴포넌트들은 일반적인 코어 컴포넌트 혹은 디자인 시스템의 설계 패턴으로 구현한다.

## Page Application Module

### webpack.config.js

- **page application**들**의** webpack 설정은 아래와 같은 내용을 따르도록 한다.
 - 리모트 애플리케이션이지만, 로컬에서는 호스트가 될 수 있다.
 - 페이지를 리모트로 노출.
 - 코어 라이브러리 컨테이너 모듈 소비.
 - 로컬에서 3000번 이상의 포트에서 호스트로 동작.
 - 공용 외부 패키지는 중복된 청크가 발생되지 않도록 선언.

```tsx
plugins: [
 new ModuleFederationPlugin({
 name: 'main',
 filename: 'main.remoteEntry.js',
 remotes: {
 shell: 'shell@http://localhost:3000/shell.remoteEntry.js',
 core: 'core@http://localhost:2000/core.remoteEntry.js',
 },
 exposes: {
 "./MainApplication": "./src/MainApplication",
 },
 shared: {
 react: {
 singleton: true,
 requiredVersion: deps.react,
 },
 'react-dom': {
 singleton: true,
 requiredVersion: deps['react-dom'],
 }
 },
 }),
 new HtmlWebpackPlugin({
 template: './public/index.html',
 }),
 ],
```

### Entry of webpack

- `Shell` 과 마찬가지로 엔트리는 비동기로 구현되도록 처리한다.
- 로컬 개발 시, Shell을 소비하여 단일 애플리케이션처럼 동작할 수 있도록 한다.

```tsx
// index.js
import('bootstrap');

// bootstrap.js
import ShellApp from "./ShellApp";
import React from "react";
import { createRoot } from "react-dom/client";

const root = createRoot(document.getElementById("root"));

root.render(<ShellApp />);

// app.js
import React from "react";

const Shell = React.lazy(() => import("shell/Shell"));

function App() {
 return (
 <React.Suspense fallback={"Loading Shell"}>
 <Shell />
 </React.Suspense>
 );
}

export default App;
```

### Consumed React App

- 코어 컴포넌트, 혹은 디자인 시스템 컴포넌트는 **코어 컴포넌트 라이브러리 컨테이너 모듈에서** **가져온다**.

```tsx

import React from "react";

const Button = React.lazy(() => import("core/Button"));

const MainApplication = () => {
 return (
 <div>
 <section>
 <h1>MAIN PAGE</h1>
 </section>
 <section>
 <React.Suspense fallback="fallback">
 <Button>Button of MAIN</Button>
 </React.Suspense>
 </section>
 </div>
 );
};

export default MainApplication;
```

위와 같이 구현 후 웹 페이지의 네트워크 로그는 아래와 같은 모습으로 나타난다.

![https://www.kimcoder.io/assets/images/federation-example-network.png](https://www.kimcoder.io/assets/images/federation-example-network.png)

공용 외부 패키지로 선언한 리액트는 하나의 청크로 구성되어 로드되고, 각 모듈들은 원격 엔트리를 통해 로드된다.
네트워크 로그만 보았을 때는, 단순히 코드 스플리팅이 된 것처럼 보이지만 **가장 중요한 것은 각 모듈들이 독립적으로 개발, 운영, 배포가 되었다는 것**이다.

**단일 애플리케이션으로써의 통합은 런타임에서 일어나게 된다.**

이 예제의 코드들은 모두 아래에서 확인이 가능하다.

- Github : [https://github.com/kimcoder/module-federation-example](https://github.com/kimcoder/module-federation-example)
- CodeSandbox : [https://codesandbox.io/s/stupefied-kapitsa-gd5255](https://codesandbox.io/s/stupefied-kapitsa-gd5255)
- CodeSandbox Page : [https://gd5255.sse.codesandbox.io/order](https://gd5255.sse.codesandbox.io/order)

<iframe
 src='https://codesandbox.io/embed/stupefied-kapitsa-gd5255?fontsize=14&hidenavigation=1&theme=dark'
 className='w-full overflow-hidden rounded-md border-none'
 style={{ height: 500 }}
 title='stupefied-kapitsa-gd5255'
 allow='accelerometer; ambient-light-sensor; camera; encrypted-media; geolocation; gyroscope; hid; microphone; midi; payment; usb; vr; xr-spatial-tracking'
 sandbox='allow-forms allow-modals allow-popups allow-presentation allow-same-origin allow-scripts'
/>

## 마치며

이 장문의 글에서 소개한 **Micro Frontend Architecture**의 지향점과 **Webpack 5의 Module Federation**의 주요한 포인트는 아래 2가지라고 생각된다.

- **각 모듈은 독립적으로 개발, 운영, 배포**를 할 수 있다.
- **런타임에서 여러 모듈들이 통합되고, 사용자에게는 모듈들이 단일 애플리케이션처럼 동작**한다.

단일 모듈의 독립적이고 유연한 개발 프로세스를 가질 수 있고, 배포와 롤백도 보다 더 민첩하게 할 수 있다는 추가적인 장점이 있을 수 있다. 하지만 분명한 것은 좋은 방식의 설계에 대한 그만한 비용이 발생할 것이며 거버넌스 측면에서도 많은 고민과 협의, 그리고 합리적인 정책들이 필요하다는 것이다.

추가적으로 Angular, Vue, Server Side Rendering, React & Vue 등 이 [링크](https://github.com/module-federation/module-federation-examples)에서 다양한 Module Federation의 예제들도 있으니 확인해 보면 좋을 것 같다.

## 참고

- [https://www.thoughtworks.com/radar/techniques/micro-frontends](https://www.thoughtworks.com/radar/techniques/micro-frontends)
- [https://microfrontends.com/](https://microfrontends.com/)
- [https://martinfowler.com/articles/micro-frontends.html](https://martinfowler.com/articles/micro-frontends.html)
- [https://webpack.kr/concepts/module-federation/](https://webpack.kr/concepts/module-federation/)
- [https://github.com/module-federation/module-federation-examples](https://github.com/module-federation/module-federation-examples)
- [https://github.com/kimcoder/module-federation-example](https://github.com/kimcoder/module-federation-example)
- [https://codesandbox.io/s/stupefied-kapitsa-gd5255](https://codesandbox.io/s/stupefied-kapitsa-gd5255)
- [https://gd5255.sse.codesandbox.io/order](https://gd5255.sse.codesandbox.io/order)

마이크로 프론트엔드에 관한 고찰, 그리고 웹팩의 모듈 페더레이션

Micro Frontend, 그리고 Webpack Module Federation

**_소프트웨어는 항상 부드러워야 한다_**

이 글에서는 위의 인용구처럼 **변경에 유연한 프론트엔드 아키텍처를 구성하는 하나의 방법과 방법의 근거, 그리고 이를 제어해 줄 수 있는 ESLint의 규칙까지 소개하고자 한다.** 

나는 지난 몇 년간 잦은 이직으로 꽤나 많고 다양한 프로젝트를 경험한 바가 있다. 
대부분은 `React`로 구성이 되어있었고, 이를 개발하고 유지 보수하는 많은 개발자분들도 알게 되었다. 
웹 애플리케이션의 규모, 운영 기간, 플랫폼, 인프라, 개발 환경, 투입 인력, 컨벤션과 같은 것은 모두 달랐지만, 
`React` 와 동반되는 라이브러리, 코드 패턴, 그리고 이를 유지 보수하기 위한 개발자들의 열정과 노력들은 비슷한 점이 많았다. 

많은 개발자들이 항상 옳은 선택을 하려고 노력하지만, 
크고 작은 피쳐들, 유지 보수, 버그/ 장애 대응, 필수적인 플랫폼 버전 대응 등 다양한 업무들과 타이트한 일정 속에 편의적인 선택들을 하는 경우도 많이 보았다. 
이러한 편의적인 선택은 언젠가 다시 우리들의 발목을 잡게 될 것이다. 

자유로운 발목과 함께 훨훨 날아가기 좋은 아키텍처를 구성해 보자.

## 좋은 아키텍처? 프론트엔드에서는?

`클린 아키텍처 (로버트 C.마틴 )`에서 좋은 아키텍처에 대해 설명한 것 중 몇 가지를 추려보았다.

- **좋은 아키텍처는 세부사항을 정책으로부터 신중하게 가려내고, 둘이 결합되지 않도록 엄격하게 분리한다.**
- **좋은 아키텍처는 의존성의 방향이 컴포넌트 수준을 기반으로 연결되도록 만들어야 한다.**
- **좋은 아키텍트는 결정되지 않은 사항의 수를 최대화한다.**
 - ( 향후 시스템에 변경이 필요할 때 어떤 방향으로든 쉽게 변경할 수 있도록 한다. )

위의 내용과 나의 이해를 바탕으로 어떠한 목적과 원칙을 가지고 프론트엔드 아키텍처에 적용을 하였는지 간략히 정리를 해보자면..

### 목적

> **좋은 아키텍처**의 궁극적인 목적은 소프트웨어를 개발하고 유지 보수하는 데 있어, **최소한의 노력으로 최대의 효율을 얻게 해주는 것**이다.

이는 개발자가 시스템을 쉽게 이해하도록 해주고, 쉽게 개발하게 해주며, 유지 보수 및 배포까지 쉽게 해줄 수 있게 한다는 것으로 풀어서 표현이 가능하다. 

아키텍처 관점에서 쉽게 이해하고, 개발, 유지 보수한다는 것은 어떤 의미일까? 
적어도 나에게는 애플리케이션의 구조가 한 눈에 드러나 누구나 쉽게 파악할 수 있으며, 기능별 모듈화가 잘 되어 있고, 독립적이며 쉽게 배포까지 할 수 있어야 한다는 것으로 이해하고 있다. 

웹 애플리케이션의 규모에 따라 차이가 있을 수 있고 좋은 아키텍처를 구성하는 여러 선택지가 있겠지만, 
여기서는 **단일 소스 수준으로 모노리틱한 구조에서 모듈 간 의존성을 제어하는 방식을 통해 구성**해 볼 것이다. 

변화가 많고 기술의 발전 속도도 빠른 생태계 속에서 유연한 아키텍처를 구성하여 최소한의 노력으로 최대의 효율을 가질 수 있도록 해보자.

### 규칙

- 웹 애플리케이션 로직과 세부적인 도메인 로직을 분리한다.
- 분리된 로직간의 의존 방향을 명확하게 한다.
- 변화가 많은 외부 모듈을 감추고, 추상화된 인터페이스를 사용할 수 있게한다.

## 디렉토리 구조

이 글에서는 `Next.js` 프로젝트를 대상으로 위의 규칙을 준수하여 구성해 보겠다. 
[Next.js](https://github.com/vercel/next.js/tree/canary/examples)의 많은 예제들의 수준과 비슷하게 한다면, 아래와 같은 계층을 가진 구조의 모양이 나올 수 있다.

![https://www.kimcoder.io/assets/images/clean-architecture-frontend-1.png](https://www.kimcoder.io/assets/images/clean-architecture-frontend-1.png)

### Core

입력과 출력으로부터 거리가 멀기 때문에 고수준이라고 볼 수 있는 계층이다. 
앞서 말한 원칙에서 세부적인 도메인 로직이 아닌, 웹 애플리케이션 로직과 추상화된 코드들이 들어간다. 
예를 들면 아래와 같은 성격의 코드들이 들어갈 수 있다.

- 애플리케이션이 외부와의 통신을 위해 필요한 구현체
- 도메인과 연관이 없는 고수준의 유틸리티
- 재사용가능한 컴포넌트
 - ex) Button, Input, Select
- 중요도가 높은 외부 모듈(라이브러리)의 어댑터

**Core 계층에 있는 코드들은 절대 Core 원의 외부에 있는 계층**(lib/components, pages)**을 참조하면 안 된다.**

### Components / Lib

이 계층은 도메인에 종속적이며, Core 계층의 코드들을 참조할 수 있고, 아래 예시와 같은 코드들이 들어간다. 
( 주문이라는 도메인이 속한 프로젝트라고 가정. )

```tsx
- src
	- lib
		- order
			- constatns
			- hooks
			- mutations
			- queries
			- utils
			- ....

- src
	- components
		- order
			- ItemList.tsx
			- Price.tsx
			- Payment.tsx
			- ...
```

- **Lib**
 - 도메인에 관련되어 있는 로직들.
 - components 계층과 pages 계층에서 참조되어진다.
- **Components**
 - 도메인에 관련되어 있는 컴포넌트.
 - 도메인에 국한되어 재사용성은 낮다.
 - pages 계층에서 참조되어진다.

### **Pages**

도메인에 의존도가 높은 계층. 입력/출력과 밀접해있으며, 가장 저수준이라고 볼 수 있다. 
`Next.js`의 기본 설정 값인 파일 시스템 기반으로 라우팅 처리를 하며, **Components**와 **Lib** 계층의 코드들을 참조하여 구성할 수 있다.

```tsx
- src
 - pages
 - api
 - order
 - [...slug].tsx // src/lib/order/.. 참조
 - ...
 - order
 - [id].tsx // src/components/order/.. 참조
 - _middleware.tsx // src/lib/order/.. 참조
 - ...
```

### Dependency diagram

위의 구조와 규칙을 가지고 간략히 의존성 그래프로 표현하면 아래와 같은 모양이 될 것이다.

![https://www.kimcoder.io/assets/images/clean-architecture-frontend-2.png](https://www.kimcoder.io/assets/images/clean-architecture-frontend-2.png)

의존성은 모두 단방향으로만 흘러가고, 역으로 참조해서는 안 된다. 

예를 들어, core 계층에 API 통신을 위한 구현체가 있다고 가정해 보자. 
이 구현체는 UI의 형태 혹은 상태, 세부적인 도메인 로직를 알아서는 안되며, 알아도 좋을 게 없다. 
마찬가지로 도메인에 종속적인 코드들 또한, 이 구현체가 비동기 통신을 위하여 어떤 객체를 사용하여 구현이 되었는지, 어떻게 API 서버와 통신을 하는지 전혀 알 필요가 없다. 

이러한 **관심사의 분리로 인해 각 모듈은 여러 책임에서 벗어나기 쉽고, 테스트하기도 더 쉬워지며, 유지 보수 비용도 줄어들 것**이다.

## ESLint 플러그인 활용

앞서 소개했던 아키텍처의 계층과 경계를 효과적으로 다루기 위해 ESLint를 활용하고, 이것이 개발 주기에 자연스레 녹아들 수 있게 해보자.
ESLint 기본 규칙에도 참조를 제한할 수 있는 `no-restricted-imports`가 있지만 이것으로는 위의 의존성 규칙을 해결할 수는 없다. 

따라서, `eslint-plugin-import`라는 플러그인을 사용하여 **계층 간의 의존성 제어**를 다뤄보고, 
추가적으로 **외부 모듈의 의존성 제어**도 같이 다뤄보도록 하겠다.

### 소개

[eslint-plugin-import](https://github.com/import-js/eslint-plugin-import)는 [creact-react-app](https://www.npmjs.com/package/eslint-config-react-app)과 [next.js](https://www.npmjs.com/package/next)에서도 사용하고 있는 플러그인이며, 
이것으로 ESLint의 import 관련한 기본 규칙들보다 조금 더 확장된 기능들로 린팅을 할 수 있다. 
플러그인 하위에 여러 룰이 있지만, 이 글에서는 [no-restricted-paths](https://github.com/import-js/eslint-plugin-import/blob/main/docs/rules/no-restricted-paths.md)만 다루도록 하겠다.

### 계층 간 의존성 제어

위의 의존성 규칙을 린트 룰로 표현하면 아래와 같다.

```jsx
"rules": {
 "import/no-restricted-paths": [
 "error",
 {
 "zones": [
 {
 "target": "src/core",
 "from": "src/components"
 },
 {
 "target": "src/core",
 "from": "src/lib"
 },
 {
 "target": "src/core",
 "from": "src/pages"
 },
 {
 "target": "src/lib",
 "from": "src/pages"
 },
 {
 "target": "src/components",
 "from": "src/pages"
 }
 ]
 }
 ]
 },
 "settings": {
 "import/resolver": {
 "typescript": {
 "project": "."
 }
 }
 }
```

타입스크립트를 사용하는 프로젝트라면 아래 [import/resolver](https://github.com/import-js/eslint-plugin-import#typescript)의 설정이 추가로 필요하다.

### 오류 화면

룰을 지키지 않았을 경우 IDE에서 아래와 같은 모습들을 볼 수 있다. 
또한, 절대 경로, 상대 경로, 별칭 경로 등 모두 인식이 가능하다.

![https://www.kimcoder.io/assets/images/clean-architecture-frontend-3.png](https://www.kimcoder.io/assets/images/clean-architecture-frontend-3.png) 
![https://www.kimcoder.io/assets/images/clean-architecture-frontend-5.png](https://www.kimcoder.io/assets/images/clean-architecture-frontend-5.png)

코드 편집기에서 보여주는 오류를 예시 화면으로 들었지만, 당연하게도 린트 명령어로도 규칙에 대한 검증을 할 수 있다.

### 오류 메시지 추가

린트 규칙에 아래와 같은 메시지를 추가하여 동료에게 조금 더 개발 친화적인 오류를 안내해 줄 수도 있다.

```rust
"rules": {
 "import/no-restricted-paths": [
 "error",
 {
 "zones": [
 ....
 {
 "target": "src/core",
 "from": "src/lib",
						"message": "\n의존성 규칙에 어긋나는 참조입니다."
 },
 ....
 ]
 }
 ]
 },
```

![https://www.kimcoder.io/assets/images/clean-architecture-frontend-4.png](https://www.kimcoder.io/assets/images/clean-architecture-frontend-4.png)

### 외부 모듈 의존성 제어

앞서 설명한 것처럼, core 계층에 API 통신을 위한 구현체가 있으며 `axios`를 사용한다고 가정한 뒤, 아래의 원칙을 바탕으로 린트 규칙 설정을 해 보자.

1. `axios`는 core 계층의 특정한 API 모듈 구현체에서만 존재를 알고 있다.
2. 특정 구현체는 추상화된 인터페이스를 구현하고 이를 다른 모듈들이 사용할 수 있게 한다.
3. 다른 모듈들은 `axios`를 알지도 못하고 참조할 수 없으며, 오직 특정 구현체가 제공하는 인터페이스만 알 수있다.

```tsx
"rules": {
	"no-restricted-imports": [
		"error",
		{
	 "paths": [{
	 "name": "axios",
		 "message": "\naxios는 @core/utils/ApiUtil.ts에서만 참조가 가능합니다."
			}]
		}
	],
	"import/no-restricted-paths": [
		"error",
		{
	 "zones": [
				....
			]
		}
	],

	....

"overrides": [
	{
		"files": ["src/core/utils/ApiUtil.ts"],
		"rules": {
			"no-restricted-imports": "off"
		}
	}
],

....
```

### 오류 화면과 추가된 메시지

특정 구현체 외에서 axios 참조 시 아래와 같은 오류가 발생한다. 
또한, 친화적인 오류 메시지를 추가할 수 있다.

![https://www.kimcoder.io/assets/images/clean-architecture-frontend-6.png](https://www.kimcoder.io/assets/images/clean-architecture-frontend-6.png) 
![https://www.kimcoder.io/assets/images/clean-architecture-frontend-7.png](https://www.kimcoder.io/assets/images/clean-architecture-frontend-7.png) 
![https://www.kimcoder.io/assets/images/clean-architecture-frontend-8.png](https://www.kimcoder.io/assets/images/clean-architecture-frontend-8.png)

예시와 같이 외부 모듈의 의존성을 제어하고 코드를 유지해 나갈 수 있다면, 
외부 모듈의 버저닝 대응, 모듈 교체와 같은 변화가 생길 시 **최소의 노력으로 최대의 효율**을 낼 수 있을 것이다.

## 마치며

모든 문제 해결에 대한 정답이 정해져있지 않은 것처럼, 아키텍처에 관한 접근도 마찬가지이다. 
**이 글에서 말하는 내용은 모든 환경과 상황을 만족시키는 정답이 아니다.** 

하지만, 아래와 같은 상황에 놓여있다면 한번 즈음은 고려해 볼 만한 내용이 될 수 있을 것 같다.

- _단일 소스 수준의 모노리스 아키텍처로 프로젝트가 관리되고 있을 경우._
- _엔터프라이즈급 혹은 어느 정도 규모 있는 웹 애플리케이션._
- _테스트하기 쉬운 애플리케이션을 만들고 싶은 경우._
- _계층 간의 의존성 규칙을 개발주기에 자연스레 포함시키고 싶은 경우._

또, **이 글의 내용을 통해 계층 간의 경계는 명확해졌지만, 이 외에도 신경 써야 할 것이 많다.** 
**도메인 간의 경계를 어떻게 다뤄야 할지, 어떤 외부 모듈을 추상화시키고 기준을 어떻게 세울 것인지, 테스트 경계는 어떻게 다룰지 등.** 
글의 제목에서 볼 수 있듯이, 여기서는 단지 **첫걸음**을 내딛였을 뿐이다. 

중요한 사실은 **아키텍처는 지속적으로 상황에 맞게 성장해야 하며, 이를 위해 개발자들의 부단한 노력이 필요하다는 것이다.**

## 참고

- [http://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html](http://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html)
- [https://github.com/vercel/next.js/tree/canary/examples](https://github.com/vercel/next.js/tree/canary/examples)
- [https://eslint.org/docs/rules/no-restricted-imports](https://eslint.org/docs/rules/no-restricted-imports)
- [https://github.com/import-js/eslint-plugin-import](https://github.com/import-js/eslint-plugin-import)
- [https://github.com/import-js/eslint-plugin-import/blob/main/docs/rules/no-restricted-paths.md](https://github.com/import-js/eslint-plugin-import/blob/main/docs/rules/no-restricted-paths.md)
- [https://github.com/import-js/eslint-plugin-import#typescript](https://github.com/import-js/eslint-plugin-import#typescript)
- [https://www.npmjs.com/package/eslint-config-react-app](https://www.npmjs.com/package/eslint-config-react-app)
- [https://www.npmjs.com/package/next](https://www.npmjs.com/package/next)

클린한 프론트엔드 아키텍처를 향한 첫 걸음

자바스크립트는 **느슨한 타입(loosely typed)의 동적(dynamic) 언어**이다. 
언어에서 사용할 수 있는 데이터 타입의 종류와 몇가지 특징들을 알아보자.

## 데이터 타입 종류

자바스크립트의 데이터 타입은 크게 2가지로 나눌 수 있다.

- **원시형 타입(Primitive type)**
- **참조형 타입(Reference type)**

위의 2가지를 나누는 기준은 **할당이나 연산시 값을 복제하냐 혹은 참조하냐**라고 볼 수 있겠다. 
엄격하게 말하면 사실 둘 다 복제를 하지만, 복제를 하는 대상이 다르다. 
이는 아래에서 조금씩 더 다뤄보도록 하겠다.

### 원시형

원시형으로 다뤄지는 타입들은 아래와 같다. 
`Number`, `String`, `Boolean`, `null`, `undefined`, `Symbol`, `BigInt` 
이들은 일반적으로 **불변성**을 가지는 데이터 타입이라고 표현된다. 

원시형 타입의 몇 가지의 특징을 살펴보자.

#### 특징

- 값 자체는 **불변**하며 변형이 불가능 하다.
- 값은 고정된 크기로 메모리에 저장된다. (ex) 숫자의 경우 64비트)
- 같은 값을 사용한다면 하나의 메모리를 사용한다.

#### 원시형 타입과 메모리

원시형 타입 변수의 할당과 연산시, 메모리의 변화를 파악해보자.

```js
let name = '김대현'; // 변수 선언과 값 할당
name = 'kimcoder'; // 변수 값 재할당
```

위의 코드에서 `name`이라는 변수 선언시에는 메모리에서 2개의 주소를 할당한다. 
하나는 **변수 식별자(변수명)**을 위한 것이고, 하나는 **변수 값(데이터)**를 위한 것이다.

<table>
 <tbody>
 <tr>
 <th className='w-28 p-1.5 text-center border border-gray-500 bg-gray-300' rowSpan={2}>
 변수 영역
 </th>
 <th className='w-28 p-1.5 text-center border border-gray-300 bg-gray-100'>주소</th>
 <td className='w-28 p-1.5 text-center border border-gray-300'>1002</td>
 <td className='w-28 p-1.5 text-center border border-gray-300'>1003</td>
 <td className='w-28 p-1.5 text-center border border-gray-300'>1004</td>
 <td className='w-28 p-1.5 text-center border border-gray-300'>...</td>
 </tr>
 <tr>
 <th className='p-1.5 border border-gray-300 bg-gray-100'>데이터</th>
 <td className='p-1.5 border border-gray-300'></td>
 <td className='p-1.5 border border-gray-300'>
 이름 : name
 값: @5003
 </td>
 <td className='p-1.5 border border-gray-300'></td>
 <td className='p-1.5 border border-gray-300'></td>
 </tr>
 <tr>
 <th className='p-1.5 text-center border border-gray-500 bg-gray-300' rowSpan={2}>
 데이터 영역
 </th>
 <th className='p-1.5 text-center border border-gray-300 bg-gray-100'>주소</th>
 <td className='p-1.5 text-center border border-gray-300'>5002</td>
 <td className='p-1.5 text-center border border-gray-300'>5003</td>
 <td className='p-1.5 text-center border border-gray-300 '>5004</td>
 <td className='p-1.5 text-center border border-gray-300'>...</td>
 </tr>
 <tr>
 <th className='p-1.5 border border-gray-300 bg-gray-100'>데이터</th>
 <td className='p-1.5 border border-gray-300'></td>
 <td className='p-1.5 text-center border border-gray-300'>'김대현'</td>
 <td className='p-1.5 border border-gray-300'></td>
 <td className='p-1.5 border border-gray-300'></td>
 </tr>
 </tbody>
</table>

1003의 식별자는 `name`이고, 데이터는 `김대현`이라는 값의 메모리 상 주소(`@5003`)이다. 
이제, 변수 값을 `kimcoder`로 재할당시 변화를 확인해 보자.

<table>
 <tbody>
 <tr>
 <th className='w-28 p-1.5 text-center border border-gray-500 bg-gray-300' rowSpan={2}>
 변수 영역
 </th>
 <th className='w-28 p-1.5 text-center border border-gray-300 bg-gray-100'>주소</th>
 <td className='w-28 p-1.5 text-center border border-gray-300'>1002</td>
 <td className='w-28 p-1.5 text-center border border-gray-300'>1003</td>
 <td className='w-28 p-1.5 text-center border border-gray-300'>1004</td>
 <td className='w-28 p-1.5 text-center border border-gray-300'>...</td>
 </tr>
 <tr>
 <th className='p-1.5 border border-gray-300 bg-gray-100'>데이터</th>
 <td className='p-1.5 border border-gray-300'></td>
 <td className='p-1.5 border border-gray-300 bg-yellow-50'>
 이름 : name
 값: @5004
 </td>
 <td className='p-1.5 border border-gray-300'></td>
 <td className='p-1.5 border border-gray-300'></td>
 </tr>
 <tr>
 <th className='p-1.5 text-center border border-gray-500 bg-gray-300' rowSpan={2}>
 데이터 영역
 </th>
 <th className='p-1.5 text-center border border-gray-300 bg-gray-100'>주소</th>
 <td className='p-1.5 text-center border border-gray-300'>5002</td>
 <td className='p-1.5 text-center border border-gray-300'>5003</td>
 <td className='p-1.5 text-center border border-gray-300 bg-yellow-50'>5004</td>
 <td className='p-1.5 text-center border border-gray-300'>...</td>
 </tr>
 <tr>
 <th className='p-1.5 border border-gray-300 bg-gray-100'>데이터</th>
 <td className='p-1.5 border border-gray-300'></td>
 <td className='p-1.5 text-center border border-gray-300'>'김대현'</td>
 <td className='p-1.5 text-center border border-gray-300 bg-yellow-50'>'kimcoder'</td>
 <td className='p-1.5 border border-gray-300'></td>
 </tr>
 </tbody>
</table>

`console.log(name)`으로 확인해보면 `kimcoder`가 출력되므로 의도한대로 변수 값의 변화가 되었다고 보인다! 
하지만 실제 `@5003`에 저장된 문자열 값의 변화는 일어나지 않았다. 단지 변수 `name`의 값(메모리 주소)이 `@5003` 에서 `@5004`으로 변한 것이다.
`name`에, `kimcoder`라는 값을 할당하기 전에 이미 `kimcoder`라는 값을 사용하여서 메모리에 저장이 되어있는 상황이라면 그 주소로 변하게 된다.

만약, `김대현`이란 값을 더 이상 사용하지 않게되면, 가바지 콜렉션의 대상이 된다.

### 참조형

참조형은 포괄적으로 보자면 모든 `Object`라고 볼 수 있는데, 
여기에는 `Array`, `Function`, `Date`, `RegExp`, `Map`, `WeakMap`, `Set`, `WeakSet` 등이 있다. 
원시형이 아닌 타입들은 모두 참조형이라고 생각하여도 좋다. 

#### 특징

- 참조형(객체)는 키와 값으로 구성된 프로퍼티들의 집합이다.
 - 프로퍼티 값으로는 자바스크립트의 모든 값을 사용할 수 있다.
- 변수에 값을 할당할 때, 값이 아닌 데이터 객체의 주소를 저장한다.
- 고정된 크기의 메모리를 사용하지 않는다.

#### 참조형 타입 변수의 메모리 구조

참조형도 데이터를 변수에 할당하는 과정이 메모리상에서 어떻게 처리되는지 확인해보자.

```js
let data = {
 name: 'kimcoder',
 nation: 'korea',
};
```

<table>
 <tbody>
 <tr>
 <th className='w-28 p-1.5 text-center border border-gray-500 bg-gray-300' rowSpan={2}>
 변수 영역
 </th>
 <th className='w-28 p-1.5 text-center border border-gray-300 bg-gray-100'>주소</th>
 <td className='w-28 p-1.5 text-center border border-gray-300'>1002</td>
 <td className='w-28 p-1.5 text-center border border-gray-300'>1003</td>
 <td className='w-28 p-1.5 text-center border border-gray-300'>1004</td>
 <td className='w-28 p-1.5 text-center border border-gray-300'>1005</td>
 <td className='w-28 p-1.5 text-center border border-gray-300'>...</td>
 </tr>
 <tr>
 <th className='p-1.5 border border-gray-300 bg-gray-100'>데이터</th>
 <td className='p-1.5 border border-gray-300'></td>
 <td className='p-1.5 border border-gray-300'>
 이름 : data
 값: @5002
 </td>
 <td className='p-1.5 border border-gray-300'></td>
 <td className='p-1.5 border border-gray-300'></td>
 <td className='p-1.5 border border-gray-300'></td>
 </tr>
 <tr>
 <th className='p-1.5 text-center border border-gray-500 bg-gray-300' rowSpan={2}>
 데이터 영역
 </th>
 <th className='p-1.5 text-center border border-gray-300 bg-gray-100'>주소</th>
 <td className='p-1.5 text-center border border-gray-300'>5002</td>
 <td className='p-1.5 text-center border border-gray-300'>5003</td>
 <td className='p-1.5 text-center border border-gray-300'>5004</td>
 <td className='p-1.5 text-center border border-gray-300'>5005</td>
 <td className='p-1.5 text-center border border-gray-300'>...</td>
 </tr>
 <tr>
 <th className='p-1.5 border border-gray-300 bg-gray-100'>데이터</th>
 <td className='p-1.5 border border-gray-300'>@7002 ~ ?</td>
 <td className='p-1.5 text-center border border-gray-300'></td>
 <td className='p-1.5 border border-gray-300'>'kimcoder'</td>
 <td className='p-1.5 border border-gray-300'>'korea'</td>
 <td className='p-1.5 text-center border border-gray-300'></td>
 </tr>
 <tr>
 <th className='p-1.5 text-center border border-gray-500 bg-gray-300' rowSpan={2}>
 객체 @5002의 변수 영역
 </th>
 <th className='p-1.5 text-center border border-gray-300 bg-gray-100'>주소</th>
 <td className='p-1.5 text-center border border-gray-300'>7002</td>
 <td className='p-1.5 text-center border border-gray-300'>7003</td>
 <td className='p-1.5 text-center border border-gray-300'>7004</td>
 <td className='p-1.5 text-center border border-gray-300'>7005</td>
 <td className='p-1.5 text-center border border-gray-300'>...</td>
 </tr>
 <tr>
 <th className='p-1.5 border border-gray-300 bg-gray-100'>데이터</th>
 <td className='p-1.5 border border-gray-300'>
 이름: name
 
 값: @5004
 </td>
 <td className='p-1.5 border border-gray-300'>
 이름: nation
 
 값: @5005
 </td>
 <td className='p-1.5 text-center border border-gray-300'></td>
 <td className='p-1.5 text-center border border-gray-300'></td>
 <td className='p-1.5 text-center border border-gray-300'></td>
 </tr>
 </tbody>
</table>

원시형 데이터와의 차이는 `객체의 변수(프로퍼티) 영역`이 별도로 존재한다는 것이다. 객체가 별도로 할애한 영역은 변수 영역일 뿐 `데이터 영역`은 기존의 메모리 공간을 그대로 활용 하고 있다.
또한, 데이터 영역에 저장된 값은 모두 불변값이다(=원시형). 
그러나 변수에는 다른 값을 얼마든지 대입할 수 있으며, 이러한 성질 때문에 흔히 참조형은 불변하지 않다라고 표현하는 것이다.

객체 내 요소의 값 변경시 어떤 변화가 일어나는지도 확인해 보자.

```js
let data = {
 name: 'kimcoder',
 nation: 'korea',
};

data.name = '김대현';
```

<table>
 <tbody>
 <tr>
 <th className='w-28 p-1.5 text-center border border-gray-500 bg-gray-300' rowSpan={2}>
 변수 영역
 </th>
 <th className='w-28 p-1.5 text-center border border-gray-300 bg-gray-100'>주소</th>
 <td className='w-28 p-1.5 text-center border border-gray-300'>1002</td>
 <td className='w-28 p-1.5 text-center border border-gray-300'>1003</td>
 <td className='w-28 p-1.5 text-center border border-gray-300'>1004</td>
 <td className='w-28 p-1.5 text-center border border-gray-300'>1005</td>
 <td className='w-28 p-1.5 text-center border border-gray-300'>...</td>
 </tr>
 <tr>
 <th className='p-1.5 border border-gray-300 bg-gray-100'>데이터</th>
 <td className='p-1.5 border border-gray-300'></td>
 <td className='p-1.5 border border-gray-300'>
 이름 : data
 값: @5002
 </td>
 <td className='p-1.5 border border-gray-300'></td>
 <td className='p-1.5 border border-gray-300'></td>
 <td className='p-1.5 border border-gray-300'></td>
 </tr>
 <tr>
 <th className='p-1.5 text-center border border-gray-500 bg-gray-300' rowSpan={2}>
 데이터 영역
 </th>
 <th className='p-1.5 text-center border border-gray-300 bg-gray-100'>주소</th>
 <td className='p-1.5 text-center border border-gray-300'>5002</td>
 <td className='p-1.5 text-center border border-gray-300 bg-yellow-50'>5003</td>
 <td className='p-1.5 text-center border border-gray-300'>5004</td>
 <td className='p-1.5 text-center border border-gray-300'>5005</td>
 <td className='p-1.5 text-center border border-gray-300'>...</td>
 </tr>
 <tr>
 <th className='p-1.5 border border-gray-300 bg-gray-100'>데이터</th>
 <td className='p-1.5 border border-gray-300'>@7002 ~ ?</td>
 <td className='p-1.5 text-center border border-gray-300 bg-yellow-50'>'김대현'</td>
 <td className='p-1.5 text-center border border-gray-300'>'kimcoder'</td>
 <td className='p-1.5 text-center border border-gray-300'>'korea'</td>
 <td className='p-1.5 text-center border border-gray-300'></td>
 </tr>
 <tr>
 <th className='p-1.5 text-center border border-gray-500 bg-gray-300' rowSpan={2}>
 객체 @5002의 변수 영역
 </th>
 <th className='p-1.5 text-center border border-gray-300 bg-gray-100'>주소</th>
 <td className='p-1.5 text-center border border-gray-300'>7002</td>
 <td className='p-1.5 text-center border border-gray-300'>7003</td>
 <td className='p-1.5 text-center border border-gray-300'>7004</td>
 <td className='p-1.5 text-center border border-gray-300'>7005</td>
 <td className='p-1.5 text-center border border-gray-300'>...</td>
 </tr>
 <tr>
 <th className='p-1.5 border border-gray-300 bg-gray-100'>데이터</th>
 <td className='p-1.5 border border-gray-300 bg-yellow-50'>
 이름: name
 
 값: @5003
 </td>
 <td className='p-1.5 border border-gray-300'>
 이름: nation
 
 값: @5005
 </td>
 <td className='p-1.5 text-center border border-gray-300'></td>
 <td className='p-1.5 text-center border border-gray-300'></td>
 <td className='p-1.5 text-center border border-gray-300'></td>
 </tr>
 </tbody>
</table>

변화된 영역을 살펴보자. 변수 `data`가 바라보고 있는 주소는 `@5002`로 변하지 않았다. 다만, 객체 내부 요소의 값만 변경이 되었다. 
**객체 내부의 요소는 추가 및 삭제, 수정이 가능하기 때문에 참조형 타입은 가변값이라고 표현**한다.

#### 참조형 객체 복사

```js
let otherData = data;
```

위와 같은 코드가 있다고 생각해보자

<table>
 <tbody>
 <tr>
 <th className='w-28 p-1.5 text-center border border-gray-500 bg-gray-300' rowSpan={2}>
 변수 영역
 </th>
 <th className='w-28 p-1.5 text-center border border-gray-300 bg-gray-100'>주소</th>
 <td className='w-28 p-1.5 text-center border border-gray-300'>1002</td>
 <td className='w-28 p-1.5 text-center border border-gray-300'>1003</td>
 <td className='w-28 p-1.5 text-center border border-gray-300'>1004</td>
 <td className='w-28 p-1.5 text-center border border-gray-300'>1005</td>
 <td className='w-28 p-1.5 text-center border border-gray-300'>...</td>
 </tr>
 <tr>
 <th className='p-1.5 border border-gray-300 bg-gray-100'>데이터</th>
 <td className='p-1.5 border border-gray-300'></td>
 <td className='p-1.5 border border-gray-300'>
 이름 : data
 값: @5002
 </td>
 <td className='p-1.5 border border-gray-300 bg-yellow-50'>
 이름 : otherData
 값: @5002
 </td>
 <td className='p-1.5 border border-gray-300'></td>
 <td className='p-1.5 border border-gray-300'></td>
 </tr>
 <tr>
 <th className='p-1.5 text-center border border-gray-500 bg-gray-300' rowSpan={2}>
 데이터 영역
 </th>
 <th className='p-1.5 text-center border border-gray-300 bg-gray-100'>주소</th>
 <td className='p-1.5 text-center border border-gray-300'>5002</td>
 <td className='p-1.5 text-center border border-gray-300'>5003</td>
 <td className='p-1.5 text-center border border-gray-300'>5004</td>
 <td className='p-1.5 text-center border border-gray-300'>5005</td>
 <td className='p-1.5 text-center border border-gray-300'>...</td>
 </tr>
 <tr>
 <th className='p-1.5 border border-gray-300 bg-gray-100'>데이터</th>
 <td className='p-1.5 border border-gray-300'>@7002 ~ ?</td>
 <td className='p-1.5 text-center border border-gray-300'>'김대현'</td>
 <td className='p-1.5 text-center border border-gray-300'>'kimcoder'</td>
 <td className='p-1.5 text-center border border-gray-300'>'korea'</td>
 <td className='p-1.5 text-center border border-gray-300'></td>
 </tr>
 <tr>
 <th className='p-1.5 text-center border border-gray-500 bg-gray-300' rowSpan={2}>
 객체 @5002의 변수 영역
 </th>
 <th className='p-1.5 text-center border border-gray-300 bg-gray-100'>주소</th>
 <td className='p-1.5 text-center border border-gray-300'>7002</td>
 <td className='p-1.5 text-center border border-gray-300'>7003</td>
 <td className='p-1.5 text-center border border-gray-300'>7004</td>
 <td className='p-1.5 text-center border border-gray-300'>7005</td>
 <td className='p-1.5 text-center border border-gray-300'>...</td>
 </tr>
 <tr>
 <th className='p-1.5 border border-gray-300 bg-gray-100'>데이터</th>
 <td className='p-1.5 border border-gray-300 '>
 이름: name
 
 값: @5003
 </td>
 <td className='p-1.5 border border-gray-300'>
 이름: nation
 
 값: @5005
 </td>
 <td className='p-1.5 text-center border border-gray-300'></td>
 <td className='p-1.5 text-center border border-gray-300'></td>
 <td className='p-1.5 text-center border border-gray-300'></td>
 </tr>
 </tbody>
</table>

`otherData`를 위해 변수 영역에 추가로 공간이 할당되었고, 데이터는 그대로 `@5002 객체`를 바라보고 있다. 
따라서 원본 `data`의 `name` 속성 값을 변경하면 `otherData`의 `name` 속성 값도 같이 변하게 된다.

위와 같은 성질로 인해 참조형 데이터를 사용할 때, 불변성을 유지하고자 추가적인 처리를 해주는 것이다.

> 대표적인 예시의 상황으로 함수 인자로 전달하고 참조시, 원본 데이터의 값 변경을 막기 위해 추가 처리를 한다.

```js
let data = {
 name: 'kimcoder',
};

data = {
 age: '12',
};
```

위와 같이 객체의 프로퍼티가 변경되는 것이 아니라 변수의 데이터 자체가 변경되는 경우에는 해당되지 않는다.

## 마치며

**원시형 타입은 값을 변경할 때 값 자체가 변경되는게 아닌 변수영역의 메모리가 변경되는 것**이다. 
**참조형 타입**은 원시형 타입과 달리 변수의 **데이터가 프로퍼티의 집합으로 구성**되어 있다. 
내부 프로퍼티의 값의 변경이 일어날 데이터 객체는 변경되지 않은 상태로 내부 프로퍼티만 변경된다. 
사용할 때는 별도의 불변성 처리를 위한 코드를 작성해야 하는 것이 좋다. 

## References

- https://developer.mozilla.org/ko/docs/Web/JavaScript/Data_structures

자바스크립트에서 사용할 수 있는 데이터 타입의 종류와 몇가지 특징들을 알아봅니다.

자바스크립트의 데이터 타입과 메모리

자바스크립트 개발을 하는 많은 조직과 팀들이 코드 정적 분석 도구로 `eslint`를 사용 중에 있을 것이다. 
또한, 여러 코드 컨벤션을 만들고 이를 준수하고자 많은 노력들을 하고 있을거라고 생각한다. 
코드 정적 분석이 CI/CD 단계에 자동화되어 자연스럽게 녹아있으면 더할 나위 없이 좋을 것이다. 
여러 컨벤션 중에서도 **`import`구문의 정렬** 규칙 적용의 이점에 대해 소개해보고자 한다.

## import rule?

`import` 구문의 **정렬 규칙**에 대한 조건들은 아래 내용들을 제어한다.

- 임포트 구문들에 대해 순서 적용을 할 것이냐.
- 임포트 구문의 멤버 변수들에 대해 순서 적용을 할 것이냐.
- 임포트 구문 그룹에 대한 순서와 이를 공백을 통해 분리할 것이냐.
 - 그룹화에 설정은 `eslint`의 기본 규칙, 플러그인마다 다르다.

여기서 순서는 `alphabetize` 되는 것을 말하며, [eslint의 기본 규칙인 sort-imports](https://eslint.org/docs/rules/sort-imports) 외에 정렬에 관련된 여러 플러그인들의 제어 조건들도 유사하다.

## 컨벤션과 적용

팀내에 아래와 같은 컨벤션이 있다고 가정해 보자.

### 컨벤션

| 우선순위 | 임포트 그룹 | 비고 |
| -------- | --------------------------------------------- | ------------------------------------------------------------- |
| 1 | react, next.js와 같은 메인 프레임워크 모듈 | react-router와 같은 react에 의존이 있는 외부 모듈도 포함한다. |
| 2 | node_modules에 있는 외부 모듈 | |
| 3 | node_modules에 있지만 팀에서 개발한 외부 모듈 | ex) 디자인시스템, 플랫폼 관련 모듈 |
| 4 | 절대 경로로 임포트한 프로젝트 내 모듈 | |
| 5 | 상대 경로로 임포트한 프로젝트 내 모듈 | ex) 이미지, CSS |

- 위와 같이 임포트 구문들을 그룹화하고 우선 순위대로 정렬한다.
- 각 그룹 사이에는 개행 문자를 넣는다. 

코드로 표현된 모습은 아래와 같을 것이다.

```js
import { useEffect } from 'react';
import { Link } from 'react-router-dom';

import A from 'moduleA';
import B from 'moduleB';

import { Button, ButtonProps } from '@MyDesignSystem/Button';

import Thumbnail from 'src/components/Thumbnail';

import image from './a.png';
import style from './style.module.css';
```

위와 같은 컨벤션은 그룹화를 커스터마이즈할 수 있는 플러그인을 추가로 설치해야 한다. 
이 글에서는 [eslint-plugin-import](https://www.npmjs.com/package/eslint-plugin-import)를 예시로 하겠다.

### 적용

아래와 같이 `import` 컨벤션에 대한 내용을 `eslint` 설정에 추가한다. 
설정에 대한 자세한 내용은 [import/order의 문서](https://github.com/import-js/eslint-plugin-import/blob/main/docs/rules/order.md)에서 참조할 수 있다.

```js title=".eslintrc"
{
 // ...
 "plugins": [ /*... ,*/ "import"],
 "rules": {
 "sort-imports": [
 "error",
 {
 "ignoreCase": true,
 "ignoreDeclarationSort": true,
 "ignoreMemberSort": false,
 "allowSeparatedGroups": true
 }
 ],
 "import/order": [
 "error",
 {
 "newlines-between": "always",
 "groups": [["builtin", "external"], "internal", "parent", "sibling", "index"],
 "pathGroups": [
 {
 "pattern": "next",
 "group": "builtin"
 },
 {
 "pattern": "react",
 "group": "builtin"
 },
 {
 "pattern": "@MyDesignSystem/**",
 "group": "internal"
 },
 {
 "pattern": "src/**",
 "group": "internal"
 },
 ],
 "pathGroupsExcludedImportTypes": ["src/**", "@MyDesignSystem/**"],
 "alphabetize": {
 "order": "asc",
 "caseInsensitive": true
 }
 }
 ]
 }
}
```

### 적용의 이점

필자가 생각하는 컨벤션 적용의 이점은 **코드 리뷰시 diff가 발생하지 않는다**는 점이다. 
물론, `import 구문`이 정말로 변경된 것이라면 합당한 diff가 발생하는 것이 맞겠지만, 
여러명과 협업하는 경우에는 개인마다 사용하는 IDE도 다르고, 설정 값들이 다 다를 수 있다. 
**이로인해 코드리뷰시 의도치 않은 diff를 보여주고 또 봐야할 수 있는 상황이 발생할 수 있다.** 

아래 코드리뷰 이미지를 확인해보자.

<img src='/assets/images/eslint-import-example.png' alt='컨벤션 룰이 적용 안 된 코드 리뷰 예제' />
 
개발자 A가 아래와 같은 순서로 작업을 하였다고 가정해 보자.
 
 

1. 커밋 1에서 `useCallback`을 사용을 하지 않게 되어, 해당 import member 삭제.
2. 커밋 3에서 다시 `useCallback`를 사용하게 됨.
3. 정렬되지 않은 채 import member가 추가 됨.
4. import한 멤버들은 변함이 없는 상태이지만 정렬이 바뀌었다는 이유로 **불필요한 diff 발생**.
5. ( ImagePreLoader도 비슷한 맥락에서 순서가 변경 됨. )

 
예시를 위해 극단적인 상황을 만든 것으로 보일 수도 있으나,
 
단순히 개인 IDE 설정 값이 실행되어 정렬 순서가 언제나 바뀔 수 있는 상황도 있다.
 

## 마치며

사실, `import` 구문 순서가 비지니스 로직에 영향을 끼친다거나 예기치 못한 상황을 발생시킬 일은 없다고 생각한다. 
순서는 중요하지 않다. 
생산성이 좋은 개발 문화를 지향한다면, `import` 구문 정렬에 대한 규칙도 lint할 수 있도록 하자!

## References

- https://eslint.org/docs/rules/sort-imports
- https://github.com/import-js/eslint-plugin-import/blob/main/docs/rules/order.md

import구문의 정렬 규칙 적용의 이점에 대해 소개합니다.

eslint import rule 설정의 이점

`enum`은 자바스크립트의 타입 레벨에서는 존재하지 않지만 타입스크립트에서는 존재하는 몇 안되는 기능 중 하나이다.
흔히 프로그래밍 중 연관된 상수들을 묶을때 열거형이라고 불리우는 `enum`을 통해 표현하고 한다.

```ts
enum Direction {
 Up,
 Down,
 Left,
 Right,
}

function moveTo(direction: Direciton) {
 if (direction === Direciton.UP) {
 // Do something..
 }

 // Do something..
}
```

타입스크립트로 개발을 하다보면 위와 같은 코드를 흔히 작성하게 된다. 
앞서 말한것 처럼, `enum`은 자바스크립트에서는 존재하지 않기 때문에 타입스크립트로 `enum`을 사용했을 때, 이 코드가 컴파일이 된 후 자바스크립트에서는 어떤식으로 표현이 되는지 고찰을 해보고 사용하는 것이 좋겠다.

## Enum의 특징과 분류

- Enum은 값으로 아래와 같은 값들을 가질 수 있다.
 - 문자열 리터럴 ( e.g. `'hello'`, `'a'`, `'bye'` )
 - 숫자 리터럴 ( e.g. `0`, `1`, `0.2`, `1000` )
 - 부호가 있는 숫자( 음수 ) 리터럴 ( e.g. `-1`, `-0.2`, `-1000` )
- 이 값들은 또한, 모두 계산되어진 값들이어야 한다.

### Numeric enums

- `numeric enum`의 멤버는 초기값을 할당해 주지 않으면, 기본적으로 **그 전의 멤버로부터 1씩 증가되는 숫자가 값으로 할당**된다.
- 첫 멤버가 값을 할당받지 않았다면 `0`을 값으로 가지게 된다.

아래 코드를 보면 확실하게 이해할 수 있다.

```ts
enum Direction {
 Up, // 0
 Down, // 1
 Left, // 2
 Right, // 3
}

enum Speed {
 VeryLow = -1, // -1
 Low, // 0
 Normal = -0.2, // -0.2
 Fast, // 0.8
 VeryFast // 1.8
 SuperFast = 100, // 100
 UltraFast // 101
}
```

**`numeric enum`은 컴파일 시, `reverse mapping`이 된다.**

#### after compile

```ts
// before compile
enum Direction {
 Up,
 Down,
 Left,
 Right,
}

let up = Direction.Up; // 0
let nameOfUp = Direction[up]; // 'Up'

// after compile
var Direction;
(function (Direction) {
 Direction[(Direction['Up'] = 0)] = 'Up';
 Direction[(Direction['Down'] = 1)] = 'Down';
 Direction[(Direction['Left'] = 2)] = 'Left';
 Direction[(Direction['Right'] = 3)] = 'Right';
})(Direction || (Direction = {}));
```

```ts
console.log(Direciton);

{0: 'Up', 1: 'Down', 2: 'Left', 3: 'Right', Up: 0, Down: 1, Left: 2, Right: 3}
```

- reverse mapping이 된 후의 실제 `Direction`은 위와 같은 형태를 이룬다.
- **숫자를 값으로 가지는 enum의 멤버들은 모두 `reverse mapping`이 된다.**

### String enums

- `string enum`의 멤버들은 모두 초기 값을 할당 받아야 한다.
- `numeric enum`처럼 자동 증가되는 값을 가지지 않지만, 직렬화가 잘 된다는 장점이 있다.
 - 멤버의 이름에 관계 없이, **코드 동작시 의미 있고 읽을 수 있는 값을 제공할 수 있다.**

```ts
enum Direction {
 Up = 'UP',
 Down = 'Down',
 Left = 'Left',
 Right = 'Right',
}
```

#### after compile

```ts
var Direction;
(function (Direction) {
 Direction['Up'] = 'UP';
 Direction['Down'] = 'Down';
 Direction['Left'] = 'Left';
 Direction['Right'] = 'Right';
})(Direction || (Direction = {}));
```

### Heterogeneous enums

- 기술적으로 `enum`은 `string enum`과 `numeric enum`의 멤버가 혼합이 될 수 있지만, 목적이 불분명한 코드가 될 수 있다.
- 자바스크립트 런타임의 동작을 영리한 방법으로 활용하는 이유가 아니라면 **사용하지 않는 것을 권장한다.**
- 혼합하여 사용할때도 마찬가지로 `numeric enum`의 자동 증가되는 값 할당, `reverse mapping` 등의 특징은 동일하다.

```ts
enum Direction {
 Up,
 Down = 'Down',
 Left = 1,
 Right,
}
```

#### after compile

```ts
var Direction;
(function (Direction) {
 Direction[(Direction['Up'] = 0)] = 'Up';
 Direction['Down'] = 'Down';
 Direction[(Direction['Left'] = 1)] = 'Left';
 Direction[(Direction['Right'] = 2)] = 'Right';
})(Direction || (Direction = {}));
```

### Declaration Merging

- `enum`도 **declaration merging(선언 병합)**의 대상이 된다.
- `numeric enum`의 선언 병합시, 2번째 enum은 초기 값을 항상 가져야 한다.

```ts
enum Direction {
 Up,
 Down,
 Left,
}

enum Direciton {
 Right = 4,
}
```

#### after compile

```ts
var Direction;
(function (Direction) {
 Direction[(Direction['Up'] = 0)] = 'Up';
 Direction[(Direction['Down'] = 1)] = 'Down';
 Direction[(Direction['Left'] = 2)] = 'Left';
})(Direction || (Direction = {}));
(function (Direction) {
 Direction[(Direction['Right'] = 4)] = 'Right';
})(Direction || (Direction = {}));

console.log(Direciton);

{0: 'Up', 1: 'Down', 2: 'Left', 3: 'Right', Up: 0, Down: 1, Left: 2, Right: 3}
```

### Immediately invoked function expression

- 모든 `enum`은 컴파일 후 **즉시실행 함수 표현식(IIFE)**의 형식으로 코드가 변환된다.
- rollup과 같은 번들러는 IIFE의 사용 여부를 판단할 수 없기 때문에, Tree-shaking 되지 않는다.
 - `enum`이 죽은 코드가 되더라도 컴파일된 코드의 번들에는 존재하게 된다.
 - [여기서](https://rollupjs.org/repl/?version=2.26.11&shareable=JTdCJTIybW9kdWxlcyUyMiUzQSU1QiU3QiUyMm5hbWUlMjIlM0ElMjJtYWluLmpzJTIyJTJDJTIyY29kZSUyMiUzQSUyMmltcG9ydCUyMCU3QkRpcmVjdGlvbiU3RCUyMGZyb20lMjAnLiUyRmVudW0uanMnJTVDbmltcG9ydCUyMCU3QmhlbGxvJTdEJTIwZnJvbSUyMCcuJTJGdHJlZXNoYWtlZCclNUNuaW1wb3J0JTIwJTdCaGklN0QlMjBmcm9tJTIwJy4lMkZub3RUcmVlc2hha2VkJyU1Q24lNUNuY29uc29sZS5sb2coaGVsbG8pJTVDbiUyMiUyQyUyMmlzRW50cnklMjIlM0F0cnVlJTdEJTJDJTdCJTIybmFtZSUyMiUzQSUyMmVudW0uanMlMjIlMkMlMjJjb2RlJTIyJTNBJTIyJ3VzZSUyMHN0cmljdCclNUNuZXhwb3J0JTIwdmFyJTIwRGlyZWN0aW9uJTVDbiUzQihmdW5jdGlvbiUyMChEaXJlY3Rpb24pJTIwJTdCJTVDbiUyMCUyMERpcmVjdGlvbiU1QidVcCclNUQlMjAlM0QlMjAnVVAnJTVDbiUyMCUyMERpcmVjdGlvbiU1QidEb3duJyU1RCUyMCUzRCUyMCdET1dOJyU1Q24lMjAlMjBEaXJlY3Rpb24lNUInTGVmdCclNUQlMjAlM0QlMjAnTEVGVCclNUNuJTIwJTIwRGlyZWN0aW9uJTVCJ1JpZ2h0JyU1RCUyMCUzRCUyMCdSSUdIVCclNUNuJTdEKShEaXJlY3Rpb24lMjAlN0MlN0MlMjAoRGlyZWN0aW9uJTIwJTNEJTIwJTdCJTdEKSklMjIlN0QlMkMlN0IlMjJuYW1lJTIyJTNBJTIydHJlZXNoYWtlZC5qcyUyMiUyQyUyMmNvZGUlMjIlM0ElMjJleHBvcnQlMjB2YXIlMjBoZWxsbyUyMCUzRCUyMCdoZWxsbyclMjIlN0QlMkMlN0IlMjJuYW1lJTIyJTNBJTIybm90VHJlZXNoYWtlZC5qcyUyMiUyQyUyMmNvZGUlMjIlM0ElMjJleHBvcnQlMjB2YXIlMjBoaSUyMCUzRCUyMCdoaSclMjIlN0QlNUQlMkMlMjJvcHRpb25zJTIyJTNBJTdCJTIyZm9ybWF0JTIyJTNBJTIyZXMlMjIlMkMlMjJuYW1lJTIyJTNBJTIybXlCdW5kbGUlMjIlMkMlMjJhbWQlMjIlM0ElN0IlMjJpZCUyMiUzQSUyMiUyMiU3RCUyQyUyMmdsb2JhbHMlMjIlM0ElN0IlN0QlN0QlMkMlMjJleGFtcGxlJTIyJTNBbnVsbCU3RA==) 직접 확인할 수 있다.

## const enum

- `enum`의 추가 코드 생성과 간접 참조 코드를 피하고 싶으면 `const enum`을 사용하는게 방안이 될 수 있다.
- `const enum`은 컴파일 중에 완전히 제거되고, 참조하는 코드영역에서 값만 인라인되어진다.

```ts
const enum Direction {
 Up,
 Down,
 Left,
 Right,
}

console.log(Direction.Up);
```

위와 같은 코드가 컴파일이 되면, 아래와 같이 인라인된 코드만 남게 된다.

```ts
console.log(0 /* Up */);
```

기본 `enum`과 비교했을 때, 컴파일 후에는 많은 차이가 생기는 것으로 볼 수 있다. 
불필요한 코드들이 생성되지 않아, 메모리와 번들링 된 코드의 사이즈가 조금 더 줄어든다는 이점이 있다. 
하지만 `d.ts` 파일을 생성해야하거나, 라이브러리로써 제공해야 될 경우에는 타입추론이 불가하다는 단점도 있다. 
이럴 경우엔, `tsconfig`의 [preserveConstEnums](https://www.typescriptlang.org/tsconfig#preserveConstEnums) 옵션을 `true`로 설정하여 해결할 수 있다. 

또, `tsconfig`의 [isolatedModules](https://www.typescriptlang.org/tsconfig#isolatedModules) 옵션을 `true`로 설정하고
`cosnt enum`을 사용하면 컴파일시 오류가 나게 되니, 사용 전에 이러한 부분을 꼭 숙지하여야 한다.

## Object Literal const assertions

타입스크립트 3.4 버전에 나온 **const assertions**을 사용하면 `enum`을 사용하지 않아도 동일하게 상수들을 열거하는 표현을 쉽게 할 수 있다.

```ts
const Direction = {
 Up: 'Up',
 Down: 'Down',
 Left: 'Left',
 Right: 'Right',
} as const;

type EnumerateDirection = typeof Direction[keyof typeof Direction];
// EnumerateDirection = 'Up' | 'Down' | 'Left' | 'Right'

function moveTo(direction: EnumerateDirection) {
 if (direction === 'Up') {
 // Do something..
 }
}
```

위의 코드와 같이 타입을 추론하기 위해 type aliasing을 한 번 해주어야하는 번거로움이 있지만, `enum`으로부터 얻을 수 없는 몇 가지의 장점이 존재한다.

1. 컴파일을 하면 타입스크립트에서 작성한 형식이 유지된 채로 자바스크립트로 변환된다.
2. Tree-shaking이 적용된다.
3. (의도하지 않은)선언 병합의 대상이 되지 않는다.

#### after compile

```ts
const Direction = {
 Up: 'Up',
 Down: 'Down',
 Left: 'Left',
 Right: 'Right',
};

// EnumerateDirection = 'Up' | 'Down' | 'Left' | 'Right'
function moveTo(direction) {
 if (direction === 'Up') {
 // Do something..
 }
}
```

## 마치며

위의 내용을 요약하자면,

1. `enum` 멤버들의 값은 계산된 문자열 혹은 숫자만 할당될 수 있다.
2. `enum`도 선언 병합이 가능하다.
3. `numeric enum`은 컴파일 후 `reverse mapping`이 된다.
4. `enum`은 IIFE로 변환되기 때문에 Tree-shaking이 되지 않는다.
5. `const enum`은 해당 값을 참조하는 부분의 코드만 인라인된다.
6. TS 3.4 이상의 버전은 객체 리터럴을 `const assertions` 해주는 것으로 상수의 열거를 표현할 수 있다.

## References

- https://www.typescriptlang.org/docs/handbook/enums.html
- https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-4.html#const-assertions

Typescript의 Enum에 대해 알아봅니다.

Enum에 대한 고찰

> **Kent C. Dodds**의 [JavaScript Pass By Value Function Parameters](https://kentcdodds.com/blog/javascript-pass-by-value-function-parameters) 글을 번역하였습니다.

왜 아래 코드가 동작하지 않을까요?

````js
function getLogger(arg) {
 function logger() {
 console.log(arg);
 }
 return logger;
}

let fruit = 'raspberry';
const logFruit = getLogger(fruit);

logFruit(); // "raspberry"
fruit = 'peach';
logFruit(); // "raspberry" Wait what!? Why is this not "peach"?```
````

여기서 일어나고 있는 일을 이야기하기 위해, 나는 fruit이라는 변수를 생성했고 문자열 raspberry를 할당했다.
그런 다음, 나는 호출되었을 때 fruit를 출력하는 logger라고 불리는 함수를 생성하고 반환해주는 함수에 fruit를 전달했다.
함수를 호출했을 때, 예상대로 raspberry를 console.log 출력 값으로 받는다. 

하지만, 나는 fruit에 peach를 재할당했고 logger를 다시 호출했다. fruit의 새로운 값을 console.log의 출력으로 얻는 것 대신에, fruit의 이전 값을 얻었다!
getLogger를 다시 호출하여 새로운 logger를 얻는 것으로 이것을 피할 수 있다.

```js
const logFruit2 = getLogger(fruit);
logFruit2(); // "peach" what a relief...
```

하지만 왜 단순히 변수의 값을 바꾸고, logger가 마지막 값을 가져올 수 없는 이유가 뭘까? 

정답은 자바스크립트 안에 있다. 함수를 인자와 함께 호출할 때, 인자는 참조가 아닌 값으로 전달된다는 것이다. 여기서 무슨 일이 일어나는지 간단하게 설명하겠다.

````js
function getLogger(arg) {
 function logger() {
 console.log(arg);
 }
 return logger;
}

// side-note, this could be written like this too
// and it wouldn't make any difference whatsoever:
// const getLogger = arg => () => console.log(arg)
// I just decided to go more verbose to keep it simple```
````

getLogger가 호출될 때, logger 함수는 생성된다. 이것은 새로운 함수이다. 새로운 함수가 생성될 때, 이것은 접근이 가능한 모든 변수를 둘러보고, closure라고 불리우는 형태로 닫혀진다. 이것은 이 logger 함수가 존재하는동안, 다른 모듈 레벨의 변수들과 부모의 함수 안에 있는 변수들에 접근이 가능하다는 것을 의미한다. 

그래서 logger가 생성될 때, 접근이 가능한 변수가 무엇일까? 예제 코드를 다시 보자. 이것은 fruit, getLogger, arg, logger(자기 자신)에 접근할 수 있다. 목록을 다시 확인해라. 왜냐하면 코드가 동작하는 방법에 매우 중요하기 때문이다. 뭔가 눈치채셨나요? fruit와 arg과 모두 동일한 값임에도 불구하고 둘 다 나열되었다! 

단지 두 개의 변수는 같은 값이 할당 되었지, 같은 변수를 의미하는 것은 아니다. 이 컨셉의 간단한 예제가 여기 있다:

```js
let a = 1;
let b = a;

console.log(a, b); // 1, 1

a = 2;
console.log(a, b); // 2, 1 ‼️
```

b가 변수 a의 값을 가리키게 만들었음에도 불구하고 변수 a의 값을 바꿀 수 있었고, b가 가리키고 있는 값은 변하지 않았음을 주의해라. 이것은 b를 그 자체로 가리키지 않았기 때문이다. 우리는 그 당시에 a가 가리켰던 값을 b가 가리키도록 했었다! 

나는 변수들을 컴퓨터의 메모리에 있는 공간을 가리키는 작은 화살표로 생각하는 것을 좋아한다. 그래서 let a = 1라고 말하면, 우리는 "자바스크립트 엔진아, 나는 메모리에 값이 1인 장소를 만들고, 메모리의 해당 장소를 기리키는 a라고 부르는 화살표를 생성하기를 원해."라고 말한다. 

같은 방법으로, 우리가 함수를 호출할 때 자바스크립트 엔진은 함수 인자를 위해 새로운 변수를 생성한다. 우리의 경우에, getLogger(fruit)를 호출했고 자바스크립트 엔진은 기본적으로 이것을 수행했다:

```js
let arg = fruit;
```

그래서 나중에 fruit = 'peach'를 수행할 때, arg는 fruit과는 완전히 다른 변수이기 때문에 영향을 미치지 않는다. 

이것을 한계로 생각하든 기능으로 생각하든, 사실은 이것이 동작하는 방식이라는 것이다. 만약, 2개의 변수를 각자 최신으로 유지하고 싶다면, 그렇게 하는 방법이 있다! 자. 아이디어는 이와 같다: 화살표가 가리키는 위치를 바꾸는 것 대신에 가르키는 것을 바꿀 수 있다! 예를 들어: 

```js
let a = { current: 1 };
let b = a;

console.log(a.current, b.current); // 1, 1

a.current = 2;
console.log(a.current, b.current); // 2, 2 🎉
```

이 경우에는, a를 재할당하는 것아 이나리, 가리키고 있는 값을 변경하였다. 그리고 b는 같은 값을 가리키고 있기 때문에, 둘 다 업데이트되었다.

그럼, 우리의 logger 문제를 위해 이 해결책을 적용해보자:

```js
function getLatestLogger(argRef) {
 function logger() {
 console.log(argRef.current);
 }
 return logger;
}

const fruitRef = { current: 'raspberry' };

const latestLogger = getLatestLogger(fruitRef);

latestLogger(); // "raspberry"
fruitRef.current = 'peach';
latestLogger(); // "peach" 🎉
```

## 결론

Ref 접미사는 변수가 가리키고 있는 값이 단순히 다른 값을 참조하는데 사용됨을 말해주는 reference의 줄임말이다. ( 여기서는 오브젝트의 current 속성 값이다. ) 

이것은 자연스럽게 절충점이 있지만, 나는 자바스크립트 명세가 함수의 인자들을 참조가 아닌 값으로 전달하여 호출하는 것에 만족한다.
그리고 해결방법은 필요할 때 큰 문제가 되지 않는다. (가변성은 프로그램을 보통 더 이해하기 어렵게 만들기 때문에 매우 드물다.) 도움이 되었기를 바란다! 굿 럭!

## References

- https://kentcdodds.com/blog/javascript-pass-by-value-function-parameters

Kent C. Dodds의 JavaScript Pass By Value Function Parameters 글을 번역하였습니다.

JavaScript Pass By Value Function Parameters

타입스크립트에서는 아래 2가지 방식으로 타입 정의를 할 수 있다. 

- **Interface**
- **Type Aliases**

타입 정의를 하고 추론하는데에 있어 어떤 방식을 사용해도 기능 구현에 문제가 없을테지만, 
이 방식들이 어떤 특징을 가지고 있고 방식간 차이점이 무엇인지 알아보자.

## Interfaces

- **Interface 선언은 Object Type의 이름을 지정하는 또 다른 방식이다.**
 > 이는 Object Type으로 표현 가능한 타입에 대해서만 interface로의 선언이 가능하다는 것을 의미한다.

```ts
function track(point: { x: number; y: number }) {
 // ..
}

interface Point {
 x: number;
 y: number;
}

function track(point: Point) {
 // ..
}
```

위의 예제에서와 같이 `{ x: number, y: number }`를 `interface Point`로 선언하여 대체할 수 있다.

### Extending

- `interface`는 `extends` 키워드를 통해 **타입의 확장**이 가능하다.

```ts
interface Point {
 x: number;
 y: number;
}

interface Point3D extends Point {
 z: number;
}

// 선언된 interface는 class가 구현해야 할 인터페이스 혹은 객체의 타입으로 사용이 가능하다.
class Pointer implements Point {
 x = 0;
 y = 1;

 //...
}

const pointB: Point3D = {
 x: 0,
 y: 1,
 z: 2,
};

function getPointer({ x, y }: Point) {
 return new Pointer({ x, y });
}
```

### Declaration Merging

- `interface`는 동일한 이름으로 추가 선언을 통해 **병합**이 가능하다.
 - 여기서 동일한 이름의 선언한 `interface` 갯수는 중요하지 않다. 모두 병합이 된다.

```ts
interface Point {
 x: number;
 y: number;
}

interface Point {
 z: number;
}

const pointA: Point = {
 x: 0,
 y: 1,
 z: 3,
};
```

이를 **선언 병합(Declaration Merging)**이라고 한다. 

> 선언 병합은 interface 뿐만아니라 namespace, enum도 같은 방식으로 선언 병합이 된다. 
>
> namespace는 class, function, enum, interface, type aliasing과도 이름이 같다면 선언 병합이 된다.

```ts
interface Point {
 x: number;
 y: number;
 getDistance: (x: number) => number;
}

// Error: Property 'x' must be of type 'number';
interface Point {
 x: string;
}
```

선언 병합시, 같은 이름으로 되어있는 속성 중복된다면, 타입이 변해서는 안된다. 
[개방 폐쇄 원칙](https://ko.wikipedia.org/wiki/%EA%B0%9C%EB%B0%A9-%ED%8F%90%EC%87%84_%EC%9B%90%EC%B9%99)을 준수한 것이라고 생각해도 좋을 것 같다.

```ts
interface Point {
 x: number;
 y: number;
 equal(x: number, y: number): number;
}

interface Point {
 equal({ x, y }: { x: number; y: number }): number;
}
```

또한, 선언 병합시, [함수 오버로드](https://www.typescriptlang.org/docs/handbook/2/functions.html#function-overloads)도 위와 같이 가능하다.

## Type Aliases

- **Type Aliasing은 특정 타입에 대해 다른 이름을 지어주는 것이다.**
- 타입 종류에 대한 제약은 없다.

```ts
type Point = {
 x: number;
 y: number;
};

type Name = string;

type ID = string | number;

type SomeFunction = () => any;
```

위와 같이 `string`과 같이 자바스크립트의 원시타입에 대해 별칭을 할 수 있으며, `Object Type`, `Union Type`에 대해서도 별칭이 가능하다.

> Union Type은 2가지 이상의 다른 타입으로 구성된 타입을 말한다.

- **Type Aliasing은 단지 다른 이름일 뿐이다.**

```ts
type UserInputSanitizedString = string;

function sanitizeInput(str: string): UserInputSanitizedString {
 return sanitize(str);
}

let userInput = sanitizeInput(getInput());

// 문자열 할당
userInput = 'new input';
```

> `UserInputSanitizedString`는 `string`의 다른 이름이기 때문에 결과적으로는 `string`과 동일한 타입으로 추론이 되어, 
> 위와 같이 `UserInputSanitizedString`의 타입으로 추론되는 변수에 다른 문자열의 할당이 가능하다.

### Extending

- `Type Aliasing`는 `intersection`을 통해 **타입의 확장**이 가능하다.

```ts
type Animal = {
 name: string;
};

type Bear = Animal & {
 honey: boolean;
};

const bear = getBear();
bear.name;
bear.honey;
```

- `Type Aliasing`은 선언 병합(Declaration Merging)이 되지 않는다.
 - 따라서, 동일한 이름의 `Type`에 새로운 속성을 추가 할 수 없다.
 - 이는 `interface`와 가장 큰 차이라고 볼 수 있다.

```ts
type Window = {
 title: string;
};

type Window = {
 ts: TypeScriptAPI;
};
// Error: Duplicate identifier 'Window'.
```

### Use with extends, implements

- `Type Aliasing`은 Object Type일 경우에 `Extends`, `implements` 키워드와도 같이 사용이 가능하다.

```ts
type Point = {
 x: number;
 y: number;
};

interface Point3D extends Point {
 z: number;
}

class Pointer implements Point {
 x = 0;
 y = 1;

 //...
}
```

## 마치며

타입 정의하는데 2가지의 방법과 각 특징들에 대해 알아보았다. 
가장 주된 차이점은 **어떤 타입을 정의할 수 있는가**와 **선언 병합이 되는가**라고 생각한다. 
타입스크립트 공식 문서에는 둘 중 하나의 **선택은 개인의 취향이고, 직접적인 경험을 통해 판단하고자 한다면, `type`의 기능에 대한 필요성을 느끼기 전까지 먼저 `interface`를 사용**하라고 한다.

## References

- https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#interfaces
- https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#type-aliases
- https://www.typescriptlang.org/docs/handbook/declaration-merging.html

Typescript의 Interface와 Type Aliasing에 대해 알아봅니다.

Interfaces vs Type Aliases

웹 페이지 성능 향상 방법 중 하나인 이미지 최적화. 
웹에서 자주 사용되어지는 이미지에 대해 알아보고, 최적화 원리와 방식에 대해 알아보자.

## Image

이미지 파일 형식은 **디지털 이미지를 구성하고 저장하는 표준적인 방법**을 의미한다. 
따라서, 이미지 파일은 모니터나 프린터로 **레스터화**할 수 있는 **데이터의 모음**이라고 생각하면 된다. 

> 래스터화(Rasterization)란, 벡터 그래픽으로 설명된 이미지를 래스터이미지(=비트맵이미지)로 변환하는 작업.

이미지(데이터의 모음)는 일반적으로 아래와 같은 포맷으로 저장할 수 있다.

- Raster formats
 - 데이터를 사각형 그리드(해상도) 안에 각 픽셀의 값을 인코딩하여 저장.
 - 인코딩시, 압축 or 무압축 처리가 된다. (압축시 데이터 손실이 발생할 수 있음.)
 - 해상도가 크고, 각 픽셀을 표현하는 색의 정보가 많을 수록 수록 데이터의 크기가 커진다.
- Vector formats
 - 데이터를 점, 선, 도형으로 저장.

### file types

2가지 포맷으로 되어 있는 많은 이미지 파일들이 있지만, 웹에서 흔히 사용되어지는 이미지 파일 타입들에 대해서만 알아보자.

| type | File format | MIME type | File extension(s) | Summary |
| ---- | ------------------------------------- | ------------- | -------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| GIF | Graphics Interchange Format | image/gif | .gif | 래스터 포맷, 무손실 압축 8비트 256색상과 단일 투명색 지원 여러 프레임을 데이터로 가질 수 있음(애니메이션 가능) |
| JPEG | Joint Photographic Expert Group image | image/jpeg | .jpg, .jpeg, .jfif, .pjpeg, .pjp | 래스터 포맷, 손실 압축 압축률이 높을 경우, 이미지 손실 발생 동일한 이미지를 여러번 편집/저장시 점점 퀄리티 저하 가장 많이 사용되는 포맷 |
| PNG | Portable Network Graphics | image/png | .png | 래스터 포맷, 무손실 압축 GIF를 대체하기 위해 만들어짐 8비트(투명도 옵션 존재), 24비트 트루컬러(1600만 색), 48비트 트루컬러, 알파채널(옵셔널) 지원 애니메이션은 APNG 포맷으로 가능 |
| SVG | Scalable Vector Graphics | image/svg+xml | .svg | 벡터 포맷 xml 형식으로 데이터 저장. |

> [MDN](https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Image_types)에서는 몇가지의 타입(WebP, AVIF, APNG)에 대해 더 설명해 주고 있지만, 이 글에서는 브라우저 호환성을 고려하여(IE..) 작성하였다.

## Optimize

이미지는 대체로 웹 페이지의 HTML, CSS, Javascript 등의 리소스보다 많은 바이트를 필요로 한다. 
가장 좋은 최적화 전략은 이미지를 대체할 수 있는 방식(ex. css 표현, 웹폰트 사용 등)를 활용하여 사용자에게 컨텐츠를 전달하는 것이겠지만 이미지 또한 좋은 표현 수단이므로
올바른 포맷을 선택하는 기준, 최적화를 하는 방식/방법에 대해 알아보자. 

> 포맷을 선택하는데에 있어, 정답은 없지만, 최선의 노력은 존재한다.

### svg

**로고, 텍스트, 아이콘과 같은 기하학적인 모양**으로 구성된 이미지 
또한, 해상도 및 배율에 독립적이므로 다양한 크기로 표현해야하는 경우에도 좋다. 
이미지가 복잡하여 svg 마크업 양이 많아지는 경우에는 사용하면 좋지 않다.

**최적화**

- svg를 서빙해 주는 서버에서 svg에 대한 gzip 설정.
- xml내 불필요한 요소들 제거 / xml node 구조 변경.
 - 플러그인 아키텍처로 이루어진 [SVGO](https://github.com/svg/svgo)(SVG Optimizer)의 플러그인 리스트들을 확인하면 어떤 항목들을 최적화시킬 수 있는지 알 수 있다.

```
removeDoctype
removeXMLProcInst
removeComments
removeMetadata
removeEditorsNSData
cleanupAttrs
mergeStyles
inlineStyles
minifyStyles
cleanupIDs
removeUselessDefs
cleanupNumericValues
convertColors
removeUnknownsAndDefaults
removeNonInheritableGroupAttrs
removeUselessStrokeAndFill
removeViewBox
cleanupEnableBackground
removeHiddenElems
removeEmptyText
convertShapeToPath
convertEllipseToCircle
moveElemsAttrsToGroup
moveGroupAttrsToElems
collapseGroups
convertPathData
convertTransform
removeEmptyAttrs
removeEmptyContainers
mergePaths
removeUnusedNS
sortDefsChildren
removeTitle
removeDesc
```

### gif

**간단한 도형, 로고, 만화 그림처럼 색이 별로 필요 없는 이미지와 애니메이션을 표현하고자 할 때** 
애니메이션 표현시 loop, delay에 대한 설정이 이미지 내에 저장되기 때문에 여러 환경에서 편리하게 사용할 수 있다. 
무손실 압축을 하기 때문에 프레임이 많아지면 용량도 매우 비대해지므로, 이럴 땐 다른 방식을 활용하는게 좋다. 
웹 페이지가 모던 브라우저만 지원해도 된다면, `APNG`, `AVIF`를 사용하는게 훨씬 좋을 수 있다. 
(avif는 edge와 safari에서는 지원되지 않는다..)

**최적화**

gif를 최적화를 할 수 있는 방법은.. **해상도 줄이기, 사용 색상 줄이기, 애니메이션 프레임 줄이기**와 같은 원초적인 행위 밖에 없는데, 
이는 이미지의 표현을 의도한대로 사용자에게 전달할 수 있는 방법이 아니다. 

### jpeg

**사진과 같이 복잡한 패턴과 색상을 갖는 이미지** 
**웹 페이지 전체를 뒤덮는 배경 이미지** 
PC 웹의 배경 이미지는 대부분 고해상도로 되어 있는데 어느정도 이미지 손실을 감안하더라도 성능을 위해 jpeg를 사용하는 것이 좋다. 
고주파 성분이 많은 문자, 선, 격자 등 단색이나 뚜렷한 윤곽선을 가지는 이미지에서는 품질 저하(뭉개짐, 노이즈)가 다소 뚜렷하게
보이는 현상이 있다. 이러한 이미지는 PNG와 같은 다른 형식을 사용하자.

> 주파수는 전자기파의 주파수를 말하는 것이 아니라, 데이터를 격자 상에 늘어 놓았을 때의 공간적인 변화를 말하는 것

**최적화**

- 불필요한 메타데이터 제거.
 - **EX**changable **I**mage **F**ile, Adobe's **E**xtensible **M**etadata **P**latform 등
- jpeg 퀄리티를 (적당히)낮은 값으로 설정.
 - 퀄리티가 낮아지면 손실율이 올라가기 때문에 절충점을 찾아 여러 품질로 시도하자.

**예시**

위의 최적화 방법이 적용된 [tinyjpg](https://tinyjpg.com/)를 통한 비교예시

| | orginal | compressed |
| ----- | -------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ |
| Image | <img src="https://tinyjpg.com/images/jpg/example-original.jpg" alt="https://tinyjpg.com/images/jpg/example-original.jpg"/> | <img src="https://tinyjpg.com/images/jpg/example-compressed.jpg" alt="https://tinyjpg.com/images/jpg/example-compressed.jpg"/> |
| Size | 614KB | 162KB |
| 출처 | https://tinyjpg.com/ |

### png

**문자, 선, 격자 등 단색이나 뚜렷한 윤곽선을 가지는 이미지** 
**알파 채널을 표현해야되는 이미지** 
무손실 압축을 하기 때문에 웹상에서 이미지가 추가적으로 편집/저장될 가능성이 있을 경우에 사용해도 좋다. 
애니메이션을 표현해야 한다면 확장 포맷인 APNG 형식을 사용할 수도 있다. 
이미지에 사용되어지는 색상이 많을 경우, png의 용량이 비대해질 수 있으므로 다른 형식을 사용하자.

**최적화**

- 불필요한 메타데이터 제거.
- 각 픽셀을 표현하는 `color depth`(색 심도)를 8-bit indexed color로 설정.

**예시**

위의 최적화 방법이 적용된 [tinypng](https://tinypng.com/)를 통한 비교예시

| | orginal | compressed |
| ----- | ---------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- |
| Image | <img src="https://tinypng.com/images/example-orig.png" alt="https://tinypng.com/images/example-orig.png"/> | <img src="https://tinypng.com/images/example-shrunk.png" alt="https://tinypng.com/images/example-shrunk.png"/> |
| Size | 57KB | 15KB |
| 출처 | https://tinypng.com/ |

`color depth`(색 심도)에 따른 비교예시

| | 24 bit | 8 bit |
| ----- | ------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| Image | <img src="https://upload.wikimedia.org/wikipedia/commons/9/9f/24_bit.png" alt="https://upload.wikimedia.org/wikipedia/commons/9/9f/24_bit.png"/> | <img src="https://upload.wikimedia.org/wikipedia/commons/f/ff/8_bit.png" alt="https://upload.wikimedia.org/wikipedia/commons/f/ff/8_bit.png"/> |
| Size | 98KB | 37KB(-62%) |
| 출처 | https://en.wikipedia.org/wiki/Color_depth |

## 마치며

1. 이미지를 사용하지 않아도 되는 상황이라면 사용 X.
2. 표현하는 컨텐츠에 적합한 최적의 이미지 형식 선택.
3. 각 이미지 타입에 맞는 최적화 적용.
4. 웹 페이지에서 보여주는 이미지의 해상도와 최대한 동일한 해상도를 가진 레스터 이미지 제공. 
 가능하다면 `srcSet`, `sizes` 속성을 통하여 반응형 이미지 제공.

## References

- https://en.wikipedia.org/wiki/Image_file_format
- https://en.wikipedia.org/wiki/Rasterisation
- https://en.wikipedia.org/wiki/Color_depth
- https://web.dev/fast/#optimize-your-images
- https://developer.mozilla.org/ko/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images

웹에서 자주 사용되어지는 이미지에 대해 알아보고, 최적화 원리와 방식에 대해 알아봅니다.

이미지 파일 최적화를 통한 웹 성능 향상

컴포넌트 제작의 마지막인 이번 포스팅은,
npm에 publish하는 과정과 관리에 대해 다루고자 한다.

[react-simple-image-slider](https://github.com/kimcoder/react-simple-image-slider)를 제작하면서 쓰는 포스팅.

## npm

npm에 먼저 배포를 하고자하려면 계정이 있어야 한다. 
[npm](https://www.npmjs.com)에 방문하여 가입을 먼저 하자. 
그리고 아래와 같은 단계를 거치면 손쉽게 배포할 수 있다.

### npm init

아래 명령어를 통해 package.json의 기본 정보들을 초기화할 수 있다. 
이미 npm package가 존재하는 디렉토리에서도 실행이 가능하며, 
비어있는 디렉토리에서 명령어를 실행해도 가능하다. 
( 단, 이미 package.json이 존재한다면 입력받는 정보들을 overwrite 하게 된다. )

```js
npm init
```

위의 터미널에 명령어를 입력하면, 아래와 같은 순으로 데이터 입력을 받는다. 

- package name
- version
- description
- git repository
- keywords
- author
- license

여기서 개발한 컴포넌트의 package.json을 예시로 확인해보자.

```js
{
 "name": "react-simple-image-slider",
 "version": "1.0.2",
 "description": "simple image slider component for react",
 "main": "dist/ImageSlider.js",
 "scripts": {
 "example": "webpack-dev-server --inline --mode development",
 "build": "rollup -c",
 "build:watch": "rollup -c --watch"
 },
 "keywords": [
 "reactjs",
 "react",
 "react-component",
 "react gallery",
 "react slider",
 "image gallery",
 "image slider"
 ],
 "repository": {
 "type": "git",
 "url": "https://github.com/kimcoder/react-simple-image-slider.git"
 },
 "author": {
 "name": "kimcoder",
 "email": "kimcoder@me.com"
 },
 "license": "MIT",
 "bugs": {
 "url": "https://github.com/kimcoder/react-simple-image-slider/issues"
 },
 "homepage": "https://github.com/kimcoder/react-simple-image-slider#readme",
 "dependencies": {
 ...
 },
 "devDependencies": {
 ...
 }
}
```

여기에 크게 부가적인 설명이 필요할 것 같지 않지만 조금 신경써야 할 부분이 있다면, 
컴포넌트 제작시 `dependencies`와 `devDependencies`를 잘 구분하여 모듈을 설치하고 작업을 해야한다. 
배포가 될 필요가 없고 컴포넌트 개발에만 필요한 모듈들은 `devDependencies`로 설치를 해주어야 한다. 

### npm ignore

git과 마찬가지로 npm에도 특정 디렉토리, 파일들을 ignore 할 수 있다. 

```js
.DS_Store
.vscode
.git*

example
node_modules
npm-debug.log
yarn-debug.log
yarn-error.log
```

이것은 역시 환경에 따라 다르겠지만, 기본적으로 컴포넌트 사용시에만 필요한 파일들을 기준으로 배포하자. 
개발시 사용하였던 테스트나 예제, 모듈들, 로그 등의 파일들은 필요가 없으니 추가해주자.

### npm adduser

배포 전, 아래와 같은 npm cli를 통해 로그인을 해주도록 하자.

```js
npm adduser
```

로그인이 완료되면 아래와 같이 **Logged in as 유저**라는 메시지를 볼 수 있을 것이다. 

<img src='/assets/images/react-component-3-adduser.png' alt='npm adduser' />

### test for npm publish

테스트는 실제 npm install을 통하여 하는 것이 좋다. 
물론, 아직 배포를 하지 않았기 때문에 아래와 같이 컴포넌트의 루트디렉토리 경로를 통해 설치해보자. 

```
npm install /Users/KIMCODER/Documents/react-simple-image-slider/
or
npm install ../react-simple-image-slider/
```

실제 컴포넌트를 사용하는 환경에서 import하여 정상적으로 사용이 가능하다면, 배포해도 좋을 것이다. 

#### npm publish

배포를 위한 명령어는 아래와 같다.

```
npm publish
```

package.json의 version에 따라 배포가 되며, 만약 최초배포가 아닌 경우는 version을 업그레이드하여 publish를 하면 된다. 
배포가 정상적으로 완료가 되면, `https://www.npmjs.com/package/이름`의 URL에서 확인할 수 있다. 
또는, `https://www.npmjs.com/settings/${계정 아이디}/packages`에서도 확인이 가능하다. 
npm에 모듈 배포를 직접 한 번 경험을 해보면 어렵지않다는 것을 느낄 수 있다. 

### Git

추가적으로 npm 외에 git 관련 내용도 조금 다루어보자. 
npm과 git의 소스는 기본적으로 동일한 버전으로 관리가 되어야 한다. 
하지만, git에서 ignore 대상은 조금 다를 수 있다. 
npm에서는 사용되는 중심으로 소스가 배포되어야 한다면, git은 컴포넌트 개발중심의 소스가 배포하도록 하자. 
npm과 github의 역할에 대해 생각하면 충분히 납득이 가능하리라 예상한다. 

[CHANGELOG.md](https://github.com/kimcoder/react-simple-image-slider/blob/master/CHANGELOG.md)를 생성하여 버전별로 어떤 것들이 바뀌는지에 대해 기록하면 좋을 것 같다.

## 마치며

컴포넌트 제작의 결과물은 [Git repository](https://github.com/kimcoder/react-simple-image-slider)에서 확인할 수 있으며 [NPM Package](https://www.npmjs.com/package/react-simple-image-slider)에서도 볼 수 있다. 
거창한 모듈, 컴포넌트가 아니더라도 개발자들이 꼭 한 번쯤은 경험하면 좋을 것 같다 :)

## References

- https://www.npmjs.com/
- https://docs.npmjs.com/getting-started/publishing-npm-packages
- https://docs.npmjs.com/cli/publish
- https://github.com/kimcoder/react-simple-image-slider
- https://www.npmjs.com/package/react-simple-image-slider

react-simple-image-slider 컴포넌트의 개발/배포의 과정에 대한 경험을 서술합니다.

React 컴포넌트 제작기 3 / 3

이번 포스팅의 내용은 비교적 간단하다.

컴포넌트를 제작시 실제로 고려해야 되는 부분들에 대하여 쓰고자 한다.
[react-simple-image-slider](https://github.com/kimcoder/react-simple-image-slider)를 제작하면서 쓰는 포스팅.

## 컴포넌트 제작시 고려할 사항

1. 사용목적에 맞는 다양한 환경에서의 접근성을 고려.
2. 캡슐화 및 실제 개발 코드상에서의 사용성 고려.
3. 외부적인 요인에 의한 부작용 방지.

컴포넌트가 어떤 종류의 것인지, 어떤 특징들이 있는지에 대해 먼저 생각해 보아야하며, 
이 컴포넌트를 실제 사용하는 여러 개발자들의 개발 환경을 고려해주어야 한다. 
여기서는 React 컴포넌트를 제작 후 기록하는 포스팅이기 때문에, 이미 모두 고려된부분이라 할 수 있겠다. 
또, 컴포넌트 소스의 캡슐화가 잘 되어있어, 독립적으로 특정 기능들이 실행되는지, 외부요인의 영향을 받거나 끼치는 등의 부작용을 방지하는지, 다른 개발자들에게 편리한 인터페이스가 제공되는지 등을 생각해보아야 한다. 

물론, 컴포넌트의 성격이나 종류에 따라 차이가 있겠지만, 아마 대부분 위의 사항들을 고려해야하지 않을까 싶다.

## 컴포넌트 기능 정의

내가 여기서 만들고자하였던 것은 이미지슬라이더였다. 

사실 프론트엔드개발자라면 이미지슬라이더는 매우 많이 접해보았을 것이고, 외부모듈을 가져다쓰기도하며, 직접 개발하여 작업한 적도 많이 있을 것이다. 이미지슬라이더를 제작하고자 마음을 먹은 이유는, 외부모듈을 가져다쓰는데 아쉬움이 있어 실제로 제작하여 배포를 해보면 좋을 것 같다고 생각했었다. 
만들고자할 때, 가장 염두에 두었던 사항들은 아래와 같았다. 

- 현재 인덱스에 맞게 다음 인덱스의 이미지를 사전에 로드.
- 슬라이더를 정적인 크기로 지정하면 이미지도 비율에 맞춰 잘 보이도록.(이미지의 크기와 상관없이)
- 2개의 객체를 활용하여 슬라이드 이미지들 표현.
- 그 외 기본적인 사항들 지원.
 - 네비게이션의 유무
 - bullet 네비게이션의 유무
 - GPU 렌더링 지원 유무
 - 슬라이딩 속도 조절.
 - 여러 이벤트에 대한 콜백 함수.

## PropsTypes를 활용하여 React Component Prop 체크

컴포넌트를 제작하고 배포하는 입장에서는, 
사용하는 개발자들이 정확한 값을 전달하도록하여 오류없이 컴포넌트의 기능들을 사용하게끔 해야한다. 

이는 `prop-types`를 사용하여 해결 할 수 있는데, 
`ReactComponent` Props의 유효성 검사 및 기본 값 지정, 타입체크를 할 수 있게 해준다. 
`prop-types`는 react v15.5부터는 별도로 설치를 해주어야한다. ( npm 등을 통해 설치하자 ) 
어떤 값들이 필수적으로 전달되어야 하는지, 선택적으로 전달되어야 하는지, 또 기본 값은 있는지를 구분지어보자. 
결과적으로 아래와 같이 컴포넌트 클래스에 propTypes와 defaultProps 지정하면 된다.

```js
import React from "react";
import PropTypes from "prop-types";
...

class SimpleImageSlider extends React.Component {
 ...
}

SimpleImageSlider.propTypes = {
 // Required
 width: PropTypes.number.isRequired,
 height: PropTypes.number.isRequired,
 images: PropTypes.arrayOf(PropTypes.shape({
 url: PropTypes.string.isRequired,
 })).isRequired,

 // Optional
 style: PropTypes.objectOf(PropTypes.string),
 slideDuration: PropTypes.number,
 showNavs: PropTypes.bool,
 showBullets: PropTypes.bool,
 bgColor: PropTypes.string,
 useGPURender: PropTypes.bool,
 onClickNav: PropTypes.func,
 onClickBullets: PropTypes.func,
 onStartSlide: PropTypes.func,
 onCompleteSlide: PropTypes.func,

 // Optional, Navigation Arrow Style
 navStyle: (props, propName, componentName) => {
 if (!isValidNavStyle(props[propName])) {
 return new Error(`Invalid prop ${propName} supplied to ${componentName}. Validation failed.`);
 }
 return null;
 }
};

SimpleImageSlider.defaultProps = {
 slideDuration: 0.5,
 showNavs: true,
 showBullets: true,
 bgColor: "#000000",
 useGPURender: true,
 navStyle: 1
};
```

이제 위의 내용을 readme 혹은 다른 문서에 아래와 같이 정의를 해주자. 
이러한 작업들은 컴포넌트를 사용할 개발자들에게 좋은 사용성을 제공해줄 것이다. 
또, 고품질의 컴포넌트의 조건 중 일부라고 생각한다. 

| Name | Type | Required | Description | Default |
| ------------------- | ---------- | ---------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------- |
| **width** | `Number` | `Required` | Image Slider Width | |
| **height** | `Number` | `Required` | Image Slider Height | |
| **images** | `Array` | `Required` | Images, Array Elements should be like this structure, { url: "" } | |
| **style** | `String` | `Optional` | css object | |
| **slideDuration** | `Number` | `Optional` | css transition-duration property | `0.5` |
| **navStyle** | `Number` | `Optional` | Arrow Navgation Style, 1 or 2 | `1` |
| **showNavs** | `Boolean` | `Optional` | Toggle Arrow Navgation | `true` |
| **showBullets** | `Boolean` | `Optional` | Toggle Bullets | `true` |
| **useGPURender** | `Boolean` | `Optional` | Toggle GPU Render | `true` |
| **bgColor** | `String` | `Optional` | slider container's css background-color property | `#000000` |
| **onClickNav** | `Function` | `Optional` | Arrow Navigation Callback function, `onClickNav = (toRight) => { }` toRight : Boolean : slide direction | |
| **onClickBullets** | `Function` | `Optional` | Bullets Callback function, `onClickBullets = (idx) => { }` idx : Number : clicked bullet index (begin from 0) | |
| **onStartSlide** | `Function` | `Optional` | Slide Transition Start function, `onStartSlide = (idx, length) => { }` idx : Number : start index (begin from 1) length : Number : image length | |
| **onCompleteSlide** | `Function` | `Optional` | Slide TransitionEnd Callback function, `onCompleteSlide = (idx, length) => { }` idx : Number : start index (begin from 1) length : Number : image length | |

[Props 정의 Gitub에서 보기](https://github.com/kimcoder/react-simple-image-slider)

## Typescript를 위한 index.d.ts

Typescript 개발 환경도 고려하여 index.d.ts파일을 컴포넌트 루트 경로에 생성하여 아래와 같이 작성하자. 
파일명의 d는 일반적으로 declare의 약자로 표현하여 사용하고, 이 파일은 Typescript에서 
특정 모듈, 인터페이스, 변수 등에 대한 타입 선언을 하는 역할을 한다. 
컴포넌트와 같이 개발자가 커스텀하여 정의한 컴포넌트 클래스는 Typescript에서 인식을 하지 못하기 때문에, 
아래와 같이 index.d.ts라는 파일을 통해 선언을 해주어야 한다.

```js
import * as React from 'react';

// RSIS = React Simple Image Slider
export interface RSISImage {
 url: string;
}

export interface RSISProps {
 width: number;
 height: number;
 images: RSISImage[];

 style?: CSSStyleDeclaration;
 slideDuration?: number;
 showNavs?: boolean;
 showBullets?: boolean;
 bgColor?: string;
 useGPURender?: boolean;
 navStyle?: 1 | 2;
 onClickNav?: (toRight: boolean) => void;
 onClickBullets?: (idx: number) => void;
 onStartSlide?: (current: number, length: number) => void;
 onCompleteSlide?: (current: number, length: number) => void;
}

declare class ReactSimpleImageSlider extends React.Component<RSISProps> {}

export default ReactSimpleImageSlider;
```

index.d.ts파일을 컴포넌트 디렉토리에 추가하지 않고도 [@types/패키지](https://github.com/DefinitelyTyped/DefinitelyTyped)를 추가하여 해결할 수도 있다. 
( 이 경우 사용하는 개발자가 npm에서 `@types/패키지`을 별도로 설치해주어야 한다. )

## 마치며

여기까지의 과정들은 [Git Repository](https://github.com/kimcoder/react-simple-image-slider)에서 확인할 수 있다. 

React 컴포넌트의 구현 소스는 사실 React를 조금 다루어보았다면 크게 어려운 부분은 아니다. 
그러하여 포스팅의 주된 내용을 어떤 것들을 고려해서 개발해야 하는지, 좋은 사용성과 높은 품질의 컴포넌트를 만들려면 어떤 것들을 생각해보아야 하는지로 선정하였다. 
사실 부족한 부분이 많겠지만 아주 마이너하고 심플한 컴포넌트이기 때문에 최대한 간략히 정리를 해보았다.

## References

- https://reactjs.org/docs/typechecking-with-proptypes.html
- http://definitelytyped.org/

React 컴포넌트 제작기 2 / 3

react 컴포넌트 제작부터 배포까지의 과정을 다뤄보고자 한다.

이번 포스팅은 컴포넌트 제작을 위환 환경 구축 과정까지 할 예정이다.
[react-simple-image-slider](https://github.com/kimcoder/react-simple-image-slider)를 제작하면서 쓰는 포스팅.

## React 컴포넌트 제작을 위한 환경 구축

세부적인 내용을 확인하기 전에, 대략적으로 필요한 것들을 정리해보자.

1. **React 컴포넌트 모듈 번들 도구 설정**.
2. jsx, ES6 이상의 문법 등 모던한 문법을 통해 개발을 할 예정이므로, 이를 위한 **babel 설정**.
3. 작업하는 컴포넌트 배포 전, **실제 테스트 환경 설정**.
4. 코드 컨벤션 적용을 위한 eslint 설정 등 기타 필요 플러그인들 설치.

대략 정리를 해보면 위와 같지만, 사실 실제 할 일들은 그리 많지 않다.

### 1. rollup

나는 그동안 개발을 해오면서 `gulp`와 `webpack` 이 2가지를 사용한 경험이 있다.
하지만, 이번 컴포넌트 제작은 `rollup`이라는 번들 도구를 사용할 예정이다.
리액트를 제작한 페이스북에서도 rollup으로 현재 빌드를 하고 있고,

[Webpack and Rollup: the same but different](https://medium.com/webpack/webpack-and-rollup-the-same-but-different-a41ad427058c)란 제목의 재밌는 글을 읽은 이유도 있다.

이 글에서 `Use webpack for apps, and Rollup for libraries`구문이 눈에 들어왔다.

또, rollup은 `react`, `vue`, `ember`, `D3`, `ThreeJs` 등에서도 사용하는 도구로 소개를
하고 있으니, 이정도면 한 번 경험해 볼 만한 가치는 충분할 것이다.

[Rollup 공식홈페이지](https://rollupjs.org/guide/en#quick-start)의 소개를 보면, `rollup`은 작거나 큰 단위 조각의 코드, 혹은 라이브러리나 애플리케이션과 같이 더 복잡한 조각들의 코드들을 컴파일해주는 도구로 소개되어 있다. 또한, ES6, CommonJS, AMD와 같은 방식들의 모듈 제작 환경을 모두 지원한다.

**install**

제작하고자하는 컴포넌트 디렉토리를 생성 후, 설치를 해주자.

```js
mkdir react-simple-image-slider
cd react-simple-image-slider

..
( npm init을 통해 package.json을 생성 )
..

npm install rollup rollup-plugin-babel --save-dev
```

위에서 설명했던대로 babel을 사용할 예정이므로 plugin도 설치를 같이 해준다.
babel에 대한 자세한 설정은 아래에서 다시 다루겠다.

**rollup.config.js**

rollup config 파일을 아래와 같이 작성하였다.

```js
import babel from 'rollup-plugin-babel';
import pkg from './package.json';

const external = (id) => !id.startsWith('/') && !id.startsWith('.');

export default {
 input: './src/ImageSlider.jsx',
 output: {
 file: pkg.main,
 format: 'cjs',
 },
 plugins: [babel({ runtimeHelpers: true })],
 external,
};
```

- input : 번들링 할 소스의 index 파일의 path.
- output : 번들링 결과물 파일의 path와 모듈 방식. ( cjs는 CommonJS방식 )
- plugins : 필요한 플러그인들 지정. ( 초기에는 babel plugin만 추가 )
- external : 소스에서 import하는 모듈들이 외부 의존적인 모듈 지정.

만약, external에서 외부 의존성이 있는 모듈이라면 해당 모듈은 번들링시 포함하지 않게 된다.
예를 들어 지금은 react 컴포넌트를 제작하는 것이므로 reactjs와 같은 모듈은 npm으로 설치하여 import하여 사용을 하게 될 것이다.
여기서 이러한 external한 외부 모듈들은 번들링 결과물에 포함이 되지 않는다.

```js
external: ['react'];
```

위와 같이 직접 모듈명을 작성해주어도 되지만, 외부 모듈들이 많아지면 번거롭게 다 지정해주어야 하기 때문에, 함수를 하나 작성하여 처리해주었다.
아래와 같이 import하는 모듈들의 경로를 기준으로 판단하면 쉽게 외부 모듈인지 확인이 가능하다.

```js
import React from 'react';
import ImageSliderPropTypes from './ImageSliderPropTypes';
import ImagePreLoader from './ImageSliderPreLoader';
```

**package.json**

scripts에 rollup 명령어를 아래와 같이 추가해준다.

```js
{
 "scripts": {
 "build": "rollup -c",
 "build:watch": "rollup -c --watch"
 }
}
```

`-c` flag는 `--config`와 동일하며, config파일명이 `rollup.config.js`일 경우, 파일명은 적지 않아도 된다.
`--config` 뒤에 파일명을 적어 특정 파일의 설정을 참조할 수 도 있다.
또, watch flag을 통해 소스 변경시마다 번들링이 되게 해준다.

### 2. babel

babel에 대해선 따로 설명을 하진 않겠으나, 간략하게 말하자면 ES2015+ 자바스크립트 코드를 구형 브라우저, 환경에서 적용할 수 있게 해주는 컴파일러이다.
babel은 버전이 바뀌면서 셋팅값들이 바뀌는 부분이 있으므로 꼭 [Babel 공식홈페이지](https://babeljs.io/docs/en/)에서 필요한 부분을 확인하자. 

**install**

설치해야 할 리스트는 아래와 같다.

- @babel/core : babel.
- @babel/preset-env : babel preset을 지정할 수 있게 해주는 모듈. ( babel7부터 사용 )
- @babel/preset-react : babel react preset.
- @babel/plugin-proposal-class-properties : Class에서 멤버 변수 관련 문법을 위한 플러그인.
- @babel/plugin-transform-runtime : 컴포넌트 소스 중 필요한 부분만 polyfill 적용을 위한 플러그인.
- @babel/polyfill : 테스트 환경 App 빌드시 사용 될 polyfill.
- babel-loader : 테스트 환경을 위한 webpack 설정시 쓸 babel loader.

위의 리스트들을 모두 설치해주자.

```js
npm install ... --save-dev
```

**.babelrc**

babel의 설정은 아래와 같이 해준다.

```js
{
 "presets": [
 ["@babel/preset-env", {
 "loose": true,
 "modules": false,
 "targets": "> 0.25%, not dead"
 }],
 "@babel/preset-react"
 ],
 "plugins": [
 "@babel/plugin-transform-runtime",
 "@babel/plugin-proposal-class-properties"
 ]
}
```

어떤 preset과 plugin들을 쓸 것인지 명시만 해주면 된다.
잠깐, 확인할 부분이 있다면 babel 7.0에서부터는 preset 설정이 조금 바뀌었다는 것이다.
기존에 `es-2015`, `stage-0`과 같은 preset들은 deprecated 되었고 위처럼 target을 지정해주면 된다. 
`> 0.25%, not dead`은 점유율이 0.25%인 브라우저들을 타겟으로 컴파일 된다는 의미이다.
( IE10, Blackberry와 같은 보안업데이트가 중단된 브라우저는 무시한다고 한다. )

[Babel 공식홈페이지](https://babeljs.io/docs/en/v7-migration)에서 더 자세히 확인 할 수 있다.

### 3. 테스트 개발 환경

테스트 개발 환경 설정은, 실제 제작한 컴포넌트가 react App에서 import하여 잘 작동이 되는지를 위한 것이다.
4.x대의 버전의 Webpack으로 테스트 환경을 설정할 예정이다.
Webpack에 대한 소개나 설정 방법 등의 자세한 설명은 생략할 예정이다.
( Webpack을 주목적으로 다루는 내용이 아니므로. )

**install**

아래와 같이 설치해준다.

```js
npm install webpack webpack-cli webpack-dev-server --save-dev

// "webpack": "^4.17.2",
// "webpack-cli": "^3.1.0",
// "webpack-dev-server": "^3.1.7"
```

webpack 4.x버전부터는 webpack-cli를 같이 설치해줘야 커맨드라인에서 webpack 명령어를 사용할 수 있다.
또, 개발모드 지원을 위해 webpack-dev-server를 설치하자.

**webpack.config.js**

```js
const path = require('path');

module.exports = {
 entry: {
 index: ['@babel/polyfill', './example/App.jsx'],
 },
 output: {
 filename: '[name].js',
 path: path.join(__dirname, 'example'),
 },
 module: {
 rules: [
 {
 test: /\.jsx$/,
 exclude: /node_modules/,
 use: 'babel-loader',
 },
 ],
 },
 mode: 'production',
 plugins: [],
 devServer: {
 contentBase: './example',
 host: '0.0.0.0',
 },
};
```

테스트 App을 위한 Webpack 설정파일이다.
현재 컴포넌트의 디렉토리에서 테스트 App의 경로를 `./example`로 설정하였고,
`babel-loader`와 `webpack-dev-server` 관련된 내용을 확인할 수 있다.
( babel의 preset과 plugin인 설정 등은 위에서 생성한 .babelrc 파일을 따른다. )
이외에 기본적인 React App을 빌드 시 필요한 html파일과 reactjs 설치 등은 생략하겠다.

**./example/App.jsx**

간략하게 React 소스의 index부분만 잠깐 살펴보자.

```js
import React from 'react';
import ReactDOM from 'react-dom';
import ImageSlider from '..';

class App extends React.Component {
 render() {
 return (
 <div>
 <h1>Image Slider Example</h1>
 <ImageSlider />
 </div>
 );
 }
}

ReactDOM.render(<App />, document.getElementById('App'));
```

`import ImageSlider from "..";`를 보면 상위 디렉토리( =컴포넌트 루트 디렉토리 )에서 모듈을 import하는 것을
확인할 수 있다.
( rollup으로 빌드한 컴포넌트의 소스가 `package.json`의 `main` 값으로 지정하였기 때문 )

**package.json**

scripts에 webpack 명령어를 아래와 같이 추가해준다.

```js
 "scripts": {
 "example": "webpack-dev-server --mode development",
 "build": "rollup -c",
 "build:watch": "rollup -c --watch"
 },
```

`npm run example`을 통해 webpack-dev-server를 실행시키면 된다.
`--inline`이나 `--hot`과 같은 flag를 추가하여 Live Reloading, Hot Module Reloading의 기능을
쓰면 더 편리할 수도 있다.
Live Reloading은 전체 페이지가 리로드 되고, Hot Module Reloading은 수정된 소스의 해당 모듈만 리로딩이 된다.

### 4. 기타 설정

마지막으로 eslint 설정, 폴더구조 등 정리를 하자면..

**eslint**

아마 react를 사용하고 babel을 사용한다면 대부분 비슷한 설정이 될 수도 있겠지만,
자신들의 코딩컨벤션을 적용하여 설정을 해두자.
나는 여기서 아래와 같이 설정하였다.

- eslint
- eslint-config-airbnb
- eslint-plugin-import
- eslint-plugin-jsx-a11y
- eslint-plugin-react
- babel-eslint

**directory structure**

- dist : rollup으로 React 컴포넌트의 소스가 빌드되는 디렉토리. 배포를 위한 디렉토리.
- example : 개발한 React 컴포넌트를 webpack으로 테스트앱을 제작하여 테스트하는 디렉토리.
- node_modules : 개발시 사용되는 모듈들.
- src : React 컴포넌트의 소스가 있는 디렉토리.

현재 디렉토리의 index가 없지만, `package.json`에서 `main` 속성을 dist의 배포용 소스로 지정하였다.
따라서 추후에 컴포넌트를 import할 때 index를 못 찾거나 하는 문제가 발생하지 않는다.

## 마치며

React 컴포넌트 제작기를 총 3번에 나눠 포스팅 계획을 세웠는데,
2번째는 실제 React 컴포넌트 소스를 개발과정을,
3번째는 npm, git에 업로드까지의 과정을 다룰 예정이다.

## References

- https://medium.com/webpack/webpack-and-rollup-the-same-but-different-a41ad427058c
- https://rollupjs.org/guide/en#quick-start
- https://rollupjs.org/guide/en#configuration-files
- https://babeljs.io/docs/en/v7-migration
- https://webpack.js.org/
- https://webpack.js.org/concepts/#entry

React 컴포넌트 제작기 1 / 3

오늘은 TDZ, Temporal Dead Zone에 대해 글을 쓰고자 한다. 
TDZ에 대해 알려면, 호이스팅과 let, const, scope 등에 대한 기본적인 이해가 있어야 한다.

## Temporal Dead Zone

위에서 이야기한 것처럼 TDZ에 대해 알려면, `호이스팅`, `let & const`에 대해 알아야 한다.

### 호이스팅

호이스팅은 인터프리터가 변수와 함수의 메모리 공간을 선언 전에 미리 할당하는 것을 의미한다. 
`var`로 선언한 변수의 경우 호이스팅 시 undefined로 변수를 초기화하게 된다.

### let & const

`let`과 `const`는 ES5+부터 사용할 수 있고 block scope 기반으로 동작하는 변수타입이다. 
아래 코드를 보자.

```js
console.log(x); // undefined
console.log(y); // ReferenceError

var x = 'x';
let y = 'y';
```

변수의 선언부는 해당 scope의 최상단으로 끌어올려져 해석된다. 
하지만 위의 코드에서 `let`으로 선언한 변수 y에 접근시에는 `ReferenceError`를 내뱉는다. 

그럼 let은 호이스팅이 되지 않는 것인가? 
그렇지 않다. `let`과 `const`도 마찬가지로 호이스팅되지만, 변수의 초기화가 실행되지 않는다. 

위의 코드에서 let변수에 접근이 불가능한 이유가 바로 **TDZ**때문이다. 
MDN문서의 내용을 참고하자면, 아래와 같이 한마디로 정의할 수 있다. 
`let`과 `const`는 블록의 시작부터 초기화가 실행되기전까지 TDZ에 존재하게 된다는 것. 
따라서, TDZ에 존재하면 위와 같이 접근을 할 수 없다. 

### Temporal

DeadZone 형성이 **시간상**(Temporal)인 이유는 이유는 
사각지대가 코드의 작성 순서(위치)가 아니라 코드의 실행 순서(시간)에 의해 형성되기 때문이다.

```js
{
 // TDZ가 스코프 맨 위에서부터 시작
 const func = () => console.log(letVar); // OK

 // TDZ 안에서 letVar에 접근하면 ReferenceError

 let letVar = 3; // letVar의 TDZ 종료
 func(); // TDZ 밖에서 호출함
}
```

위 코드의 경우 let 변수 선언 코드가 그 변수에 접근하는 함수보다 아래에 위치하지만, 함수의 호출 시점이 사각지대 밖이므로 정상 동작한다.

## 여러가지 상황들

### TDZ with Lexical Scope

```js
function test() {
 var foo = 33;
 if (true) {
 let foo = foo + 55; // ReferenceError
 console.log(foo);
 }
}
test();
```

MDN에 있는 예제 소스이다. 
함수 내부의 조건문 block의 소스에서, foo 참조시 TDZ로 인한 `ReferenceError`가 발생한다. 
foo의 초기화 구문에서 (foo + 55)의 foo가 TDZ에 있기(아직 초기화가 되지 않았기) 때문이다.

### TDZ with Default Function Parameter

```js
(function (a = b, b) {})(undefined, 1); // ReferenceError
```

```js
(function (a = a) {})(); // ReferenceError
```

위의 2가지 예제들도 똑같이 에러가 발생한다. 
함수의 디폴트 파라미터가 TDZ에 있는(초기화실행이 되지 않은 상태의) 값을 참조하고 있기 때문이다. 
위의 경우에선, a가 b를 참조하는데, b의 초기화가 아직 되지 않은 상태이다. 
(디폴트 파라미터는 왼쪽에서 오른쪽으로 실행) 
아래에선, 위의 foo 예제와 같은 케이스이다. a의 초기화 구문에서 접근하려는 a가 TDZ에 있기 때문이다. 

## 마치며

var로 변수를 선언하고 사용할 때도 마찬가지이지만, 초기화 후 사용에 대한 안전한 방식의 코딩스타일을 지향하는 것이 좋다. 
확실한 것은, `let`과 `const`를 사용하고 `TDZ`에 대한 개념을 잘 알고 있다면, 여러 부작용을 방지할 수 있을것이다. 

## References

- https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/let#Temporal_Dead_Zone
- https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Functions/Default_parameters

TDZ(Temporal Dead Zone)에 대해 알아봅니다.

@kimcoder

Blog 📝