Skip to content

Literal types issue115 #139

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 12 commits into from
Aug 15, 2020
9 changes: 9 additions & 0 deletions .all-contributorsrc
Original file line number Diff line number Diff line change
Expand Up @@ -261,6 +261,15 @@
"contributions": [
"translation"
]
},
{
"login": "seohyun0120",
"name": "SeohyunYoon",
"avatar_url": "https://avatars3.githubusercontent.com/u/35247295?v=4",
"profile": "https://github.com/seohyun0120",
"contributions": [
"translation"
]
}
],
"contributorsPerLine": 8,
Expand Down
3 changes: 2 additions & 1 deletion README.md
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
# TypeScript-Handbook 한글 문서

[![Build Status](https://api.travis-ci.com/typescript-kr/typescript-kr.github.io.svg?branch=master)](https://travis-ci.com/github/typescript-kr/typescript-kr.github.io) <!-- ALL-CONTRIBUTORS-BADGE:START - Do not remove or modify this section -->
[![All Contributors](https://img.shields.io/badge/all_contributors-28-orange.svg?style=flat-square)](#contributors-)
[![All Contributors](https://img.shields.io/badge/all_contributors-29-orange.svg?style=flat-square)](#contributors-)
<!-- ALL-CONTRIBUTORS-BADGE:END -->
[![Release Date](https://img.shields.io/github/release-date/typescript-kr/typescript-kr.github.io)](https://github.com/typescript-kr/typescript-kr.github.io/releases)<!-- RELEASE-DATE-BADGE:END -->
[![Stars](https://img.shields.io/github/stars/typescript-kr/typescript-kr.github.io)](https://github.com/typescript-kr/typescript-kr.github.io/stargazers)<!-- STARS-BADGE:END -->
Expand Down Expand Up @@ -63,6 +63,7 @@
<td align="center"><a href="https://velog.io/@eomttt"><img src="https://avatars2.githubusercontent.com/u/22593217?v=4" width="80px;" alt=""/><br /><sub><b>Hyuntae EOM</b></sub></a><br /><a href="#translation-eomttt" title="Translation">🌍</a></td>
<td align="center"><a href="http://samsara-ku.github.io"><img src="https://avatars3.githubusercontent.com/u/59246456?v=4" width="80px;" alt=""/><br /><sub><b>Yunhoe, Ku</b></sub></a><br /><a href="#translation-samsara-ku" title="Translation">🌍</a></td>
<td align="center"><a href="https://github.com/realgoways"><img src="https://avatars3.githubusercontent.com/u/15275415?v=4" width="80px;" alt=""/><br /><sub><b>realgo</b></sub></a><br /><a href="#translation-realgoways" title="Translation">🌍</a></td>
<td align="center"><a href="https://github.com/seohyun0120"><img src="https://avatars3.githubusercontent.com/u/35247295?v=4" width="80px;" alt=""/><br /><sub><b>SeohyunYoon</b></sub></a><br /><a href="#translation-seohyun0120" title="Translation">🌍</a></td>
</tr>
</table>

Expand Down
60 changes: 30 additions & 30 deletions pages/literal-types.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,35 +5,35 @@ permalink: /docs/handbook/literal-types.html
oneline: Using literal types with TypeScript
---

A literal is a more concrete sub-type of a collective type.
What this means is that `"Hello World"` is a `string`, but a `string` is not `"Hello World"` inside the type system.
리터럴 타입은 집합 타입의 보다 구체적인 하위 타입입니다.
이것이 의미하는 바는 타입 시스템 안에서 `"Hello World"``string`이지만, `string``"Hello World"`가 아니란 것입니다.

There are two sets of literal types available in TypeScript today, strings and numbers, by using literal types you can allow an exact value which a string or number must have.
오늘날 TypeScript에는 문자열과 숫자, 두 가지 리터럴 타입이 있는데 이를 사용하면 문자열이나 숫자에 정확한 값을 지정할 수 있습니다.

# Literal Narrowing
# 리터럴 타입 좁히기 (Literal Narrowing)

When you declare a variable via `var` or `let`, you are telling the compiler that there is the chance that this variable will change its contents.
In contrast, using `const` to declare a variable will inform TypeScript that this object will never change.
`var` 또는 `let`으로 변수를 선언할 경우 이 변수의 값이 변경될 가능성이 있음을 컴파일러에게 알립니다.
반면, `const`로 변수를 선언하게 되면 TypeScript에게 이 객체는 절대 변경되지 않음을 알립니다.

```ts twoslash
// We're making a guarantee that this variable
// helloWorld will never change, by using const.
```ts
// const를 사용하여 변수 helloWorld가
// 절대 변경되지 않음을 보장합니다.

// So, TypeScript sets the type to be "Hello World" not string
// 따라서, TypeScript는 문자열이 아닌 "Hello World"로 타입을 정합니다.
const helloWorld = "Hello World";

// On the other hand, a let can change, and so the compiler declares it a string
// 반면, let은 변경될 수 있으므로 컴파일러는 문자열이라고 선언할 것입니다.
let hiWorld = "Hi World";
```

The process of going from an infinite number of potential cases (there are an infinite number of possible string values) to a smaller, finite number of potential case (in `helloWorld`'s case: 1) is called narrowing.
무한한 수의 잠재적 케이스들 (문자열 값은 경우의 수가 무한대)을 유한한 수의 잠재적 케이스 (`helloWorld`의 경우: 1개)로 줄여나가는 것을 타입 좁히기 (narrowing)라 한다.

# String Literal Types
# 문자열 리터럴 타입 (String Literal Types)

In practice string literal types combine nicely with union types, type guards, and type aliases.
You can use these features together to get enum-like behavior with strings.
실제로 문자열 리터럴 타입은 유니언 타입, 타입 가드 그리고 타입 별칭과 잘 결합됩니다.
이런 기능을 함께 사용하여 문자열로 enum과 비슷한 형태를 갖출 수 있습니다.

```ts twoslash
```ts
// @errors: 2345
type Easing = "ease-in" | "ease-out" | "ease-in-out";

Expand All @@ -44,8 +44,8 @@ class UIElement {
} else if (easing === "ease-out") {
} else if (easing === "ease-in-out") {
} else {
// It's possible that someone could reach this
// by ignoring your types though.
// 하지만 누군가가 타입을 무시하게 된다면
// 이곳에 도달하게 될 수 있습니다.
}
}
}
Expand All @@ -55,41 +55,41 @@ button.animate(0, 0, "ease-in");
button.animate(0, 0, "uneasy");
```

You can pass any of the three allowed strings, but any other string will give the error
허용된 세 개의 문자열이 아닌 다른 문자열을 사용하게 되면 오류가 발생합니다.

```
Argument of type '"uneasy"' is not assignable to parameter of type '"ease-in" | "ease-out" | "ease-in-out"'
'"uneasy"' 타입은 '"ease-in" | "ease-out" | "ease-in-out"' 타입의 매개 변수에 할당할 수 없습니다.
```

String literal types can be used in the same way to distinguish overloads:
문자열 리터럴 타입은 오버로드를 구별하는 것과 동일한 방법으로 사용될 수 있습니다:

```ts
function createElement(tagName: "img"): HTMLImageElement;
function createElement(tagName: "input"): HTMLInputElement;
// ... more overloads ...
// ... 추가적인 중복 정의들 ...
function createElement(tagName: string): Element {
// ... code goes here ...
// ... 여기에 로직 추가 ...
}
```

# Numeric Literal Types
# 숫자형 리터럴 타입 (Numeric Literal Types)

TypeScript also has numeric literal types, which act the same as the string literals above.
TypeScript에는 위의 문자열 리터럴과 같은 역할을 하는 숫자형 리터럴 타입도 있습니다.

```ts twoslash
```ts
function rollDice(): 1 | 2 | 3 | 4 | 5 | 6 {
return (Math.floor(Math.random() * 6) + 1) as 1 | 2 | 3 | 4 | 5 | 6;
}

const result = rollDice();
```

A common case for their use is for describing config values:
이는 주로 설정값을 설명할 때 사용됩니다:

```ts twoslash
/** Creates a map centered at loc/lat */
```ts
/** loc/lat 좌표에 지도를 생성합니다. */
declare function setupMap(config: MapConfig): void;
// ---cut---
// ---생략---
interface MapConfig {
lng: number;
lat: number;
Expand Down
34 changes: 17 additions & 17 deletions pages/tutorials/babel-with-typescript.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,44 +5,44 @@ permalink: /docs/handbook/babel-with-typescript.html
oneline: How to create a hybrid Babel + TypeScript project
---

# Babel vs `tsc` for TypeScript
# Babel vs TypeScript의 `tsc`

When making a modern JavaScript project, you might ask yourself what the right way to convert files from TypeScript to JavaScript.
모던 JavaScript 프로젝트를 만들 때, TypeScript에서 JavaScript 파일로 변환하는 올바른 방법에 대해 고민할 수 있습니다.

A lot of the time the answer is _"it depends"_, or _"someone may have decided for you"_ depending on the project. If you are building your project with an existing framework like [tsdx](https://www.npmjs.com/package/tsdx), [Angular](https://angular.io/), [NestJS](https://nestjs.com/) or any framework mentioned in the [Getting Started](/docs/home) then this decision is handled for you.
많은 경우 그 대답은 프로젝트에 따라 _"~에 달려있다"_ 또는 _"누군가 여러분 대신 결정했을지도 모른다`_ 가 될 것입니다. 만약 [tsdx](https://www.npmjs.com/package/tsdx), [Angular](https://angular.io/), [NestJS](https://nestjs.com/)와 같은 기존 프레임워크 또는 [Getting Started](/docs/home)에 언급된 프레임워크를 사용하여 프로젝트를 만들고 있다면 결정은 여러분 손에 달려있습니다.

However, a useful heuristic could be:
하지만, 사용할만한 직관적인 방법은 다음과 같습니다:

* Is your build output mostly the same as your source input files? Use `tsc`
* Do you need a build pipeline with multiple potential outputs? Use `babel` for transpiling and `tsc` for type checking
* 빌드 출력 결과와 소스 입력 파일이 거의 비슷한가요? `tsc`를 사용하세요.
* 여러 잠재적인 결과물을 내는 빌드 파이프라인이 필요하신가요? `babel`로 트랜스파일링을 하고, `tsc`로 타입을 검사하세요.

## Babel for transpiling, `tsc` for types
## 트랜스파일링은 Babel, 타입은 `tsc` (Babel for transpiling, `tsc` for types)

This is a common pattern for projects with existing build infrastructure which may have been ported from a JavaScript codebase to TypeScript.
JavaScript 코드 베이스에서 TypeScript로 포팅되었을 수 있는 기존 빌드 인프라 구조를 가진 프로젝트의 일반적인 패턴입니다.

This technique is a hybrid approach, using Babel's [preset-typescript](https://babeljs.io/docs/en/babel-preset-typescript) to generate your JS files, and then using TypeScript to do type checking and `.d.ts` file generation.
이 기술은, Babel의 [preset-typescript](https://babeljs.io/docs/en/babel-preset-typescript)을 사용하여 JS 파일을 생성한 후, TypeScript를 사용하여 타입 검사 및 `.d.ts` 파일을 생성하는 복합 접근 방식입니다.

By using babel's support for TypeScript, you get the ability to work with existing build pipelines and are more likely to have a faster JS emit time because Babel does not type check your code.
Babel은 TypeScript를 지원하기 때문에, 기존 빌드 파이프라인으로 작업할 수 있고 Babel이 코드 타입을 검사하지 않기 때문에 JS 출력 시간이 더 빨라질 수 있습니다.

#### Type Checking and d.ts file generation
#### 타입 검사와 d.ts 파일 생성 (Type Checking and d.ts file generation)

The downside to using babel is that you don't get type checking during the transition from TS to JS. This can mean that type errors which you miss in your editor could sneak through into production code.
Babel 사용의 단점은 TS를 JS로 전환하는 동안 타입 검사를 할 수 없다는 점입니다. 즉, 에디터에서 타입 오류를 잡지 못하고 상용 코드에 포함될 수도 있단 뜻입니다.

In addition to that, Babel cannot create `.d.ts` files for your TypeScript which can make it harder to work with your project if it is a library.
또한, Babel은 TypeScript에 대한 `.d.ts` 파일을 만들 수 없기 때문에 여러분의 프로젝트가 라이브러리인 경우 작업하기가 더 어려워질 수 있습니다.

To fix these issues, you would probably want to set up a command to type check your project using TSC. This likely means duplicating some of your babel config into a corresponding [`tsconfig.json`](/tconfig) and ensuring these flags are enabled:
이러한 문제를 해결하려면 TSC를 사용하여 프로젝트의 타입을 검사할 수 있는 명령어를 설정하는 것이 좋습니다. 이는 Babel 구성의 일부를 해당 [`tsconfig.json`](/tconfig)에 복제하고, 다음 플래그가 활성화되었는지 확인하는 것을 의미합니다:

```json
"compilerOptions": {
// Ensure that .d.ts files are created by tsc, but not .js files
// tsc를 사용해 .js 파일이 아닌 .d.ts 파일이 생성되었는지 확인합니다.
"declaration": true,
"emitDeclarationOnly": true,
// Ensure that Babel can safely transpile files in the TypeScript project
// Babel이 TypeScript 프로젝트의 파일을 안전하게 트랜스파일할 수 있는지 확인합니다.
"isolatedModules": true
}
```

For more information on these flags:
해당 플래그에 대한 자세한 내용은 다음을 참고해주세요:

* [`isolatedModules`](/tsconfig#isolatedModules)
* [`declaration`](/tsconfig#declaration), [`emitDeclarationOnly`](/tsconfig#emitDeclarationOnly)