From f234d0941bbeb6a6a3aba39979b93e9401baf9dc Mon Sep 17 00:00:00 2001 From: Joy C Date: Tue, 27 Sep 2022 19:08:03 -0600 Subject: [PATCH 1/2] fix italic --- .../ko/handbook-v2/Everyday Types.md | 90 +++++++++---------- 1 file changed, 45 insertions(+), 45 deletions(-) diff --git a/docs/documentation/ko/handbook-v2/Everyday Types.md b/docs/documentation/ko/handbook-v2/Everyday Types.md index 67a2b83b..0a0a9136 100644 --- a/docs/documentation/ko/handbook-v2/Everyday Types.md +++ b/docs/documentation/ko/handbook-v2/Everyday Types.md @@ -8,7 +8,7 @@ oneline: "언어의 원시 타입들." 이번 장에서는 JavaScript 코드에서 찾아볼 수 있는 가장 흔한 타입들을 다루고, 이 타입들을 TypeScript에서 어떻게 기술하는지 각각의 대응하는 방식에 대하여 설명하겠습니다. 이 문서에서 빠짐없이 전부 다루고자 하는 것이 아니며, 타입을 만들고 사용하는 더 많은 방법들은 이후 이어지는 장에서 다룰 것입니다. -타입은 단지 타입 표기 이외에도 훨씬 다양한 _위치_에 나타날 수 있습니다. +타입은 단지 타입 표기 이외에도 훨씬 다양한 *위치*에 나타날 수 있습니다. 타입 자체에 대하여 배우는 것과 더불어, 새로운 구조체를 만들고자 할 때 타입을 참조하는 경우들에 대하여 알아볼 것입니다. 우선 JavaScript 또는 TypeScript 코드를 작성할 때 가장 기본적이면서 흔히 만날 수 있는 타입들을 다시 살펴보는 데에서 시작해보겠습니다. @@ -24,15 +24,15 @@ JavaScript에서 아주 흔하게 사용되는 세 가지의 [원시 타입](htt - `number`은 `42`와 같은 숫자를 나타냅니다. JavaScript는 정수를 위한 런타임 값을 별도로 가지지 않으므로, `int` 또는 `float`과 같은 것은 존재하지 않습니다. 모든 수는 단순히 `number`입니다 - `boolean`은 `true`와 `false`라는 두 가지 값만을 가집니다 -> `String`, `Number`, `Boolean`와 같은 (대문자로 시작하는) 타입은 유효한 타입이지만, 코드상에서 이러한 특수 내장 타입을 사용하는 경우는 극히 드뭅니다. _항상_ `string`, `number`, `boolean` 타입을 사용하세요. +> `String`, `Number`, `Boolean`와 같은 (대문자로 시작하는) 타입은 유효한 타입이지만, 코드상에서 이러한 특수 내장 타입을 사용하는 경우는 극히 드뭅니다. *항상* `string`, `number`, `boolean` 타입을 사용하세요. ## 배열 `[1, 2, 3]`과 같은 배열의 타입을 지정할 때 `number[]` 구문을 사용할 수 있습니다. 이 구문은 모든 타입에서 사용할 수 있습니다(예를 들어, `string[]`은 문자열의 배열입니다). 위 타입은 `Array`와 같은 형태로 적을 수 있으며, 동일한 의미를 가집니다. -`T` 구문에 대한 내용은 _제네릭_을 다룰 때 좀 더 알아보겠습니다. +`T` 구문에 대한 내용은 *제네릭* 을 다룰 때 좀 더 알아보겠습니다. -> `[number]`는 전혀 다른 의미를 가집니다. _튜플 타입_ 부분을 참조하세요. +> `[number]`는 전혀 다른 의미를 가집니다. *튜플 타입* 부분을 참조하세요. ## `any` @@ -71,10 +71,10 @@ let myName: string = "Alice"; ``` > TypeScript는 `int x = 0;`과 같이 "타입을 왼쪽에 쓰는" 식의 표기법을 사용하지 않습니다. -> 타입 표기는 항상 타입의 대상 _뒤쪽에_ 위치합니다. +> 타입 표기는 항상 타입의 대상 *뒤쪽에* 위치합니다. 하지만 대부분의 경우, 타입 표기는 필요하지 않습니다. -가능하다면 TypeScript는 자동으로 코드 내의 있는 타입들을 _추론_하고자 시도합니다. +가능하다면 TypeScript는 자동으로 코드 내의 있는 타입들을 *추론*하고자 시도합니다. 예를 들어, 변수의 타입은 해당 변수의 초깃값의 타입을 바탕으로 추론됩니다. ```ts twoslash @@ -158,13 +158,13 @@ names.forEach((s) => { 매개 변수 `s`에는 타입이 표기되지 않았음에도 불구하고, TypeScript는 `s`의 타입을 알아내기 위하여 배열의 추론된 타입과 더불어 `forEach` 함수의 타입을 활용하였습니다. -이 과정은 _문맥적 타입 부여_라고 불리는데, 왜냐하면 함수가 실행되는 _문맥_을 통하여 해당 함수가 가져야 하는 타입을 알 수 있기 때문입니다. -추론 규칙과 비슷하게, 이 과정이 어떻게 일어나는지를 명시적으로 배울 필요는 없지만, 이것이 _실제로 일어나는 과정_이라는 것을 이해하면 타입 표기가 불필요한 경우를 구분하는 데에 도움이 됩니다. +이 과정은 *문맥적 타입 부여*라고 불리는데, 왜냐하면 함수가 실행되는 *문맥*을 통하여 해당 함수가 가져야 하는 타입을 알 수 있기 때문입니다. +추론 규칙과 비슷하게, 이 과정이 어떻게 일어나는지를 명시적으로 배울 필요는 없지만, 이것이 *실제로 일어나는 과정*이라는 것을 이해하면 타입 표기가 불필요한 경우를 구분하는 데에 도움이 됩니다. 값이 발생하는 문맥이 해당 값의 타입에 영향을 끼치는 예시들은 이후에 살펴보도록 하겠습니다. ## 객체 타입 -원시 타입을 제외하고 가장 많이 마주치는 타입은 _객체 타입_입니다. +원시 타입을 제외하고 가장 많이 마주치는 타입은 *객체 타입*입니다. 객체는 프로퍼티를 가지는 JavaScript 값을 말하는데, 대부분의 경우가 이에 해당하죠! 객체 타입을 정의하려면, 해당 객체의 프로퍼티들과 각 프로퍼티의 타입들을 나열하기만 하면 됩니다. @@ -188,7 +188,7 @@ printCoord({ x: 3, y: 7 }); ### 옵셔널 프로퍼티 -객체 타입은 일부 또는 모든 프로퍼티의 타입을 선택적인 타입, 즉 _옵셔널_로 지정할 수 있습니다. +객체 타입은 일부 또는 모든 프로퍼티의 타입을 선택적인 타입, 즉 *옵셔널*로 지정할 수 있습니다. 프로퍼티 이름 뒤에 `?`를 붙이면 됩니다. ```ts twoslash @@ -201,7 +201,7 @@ printName({ first: "Alice", last: "Alisson" }); ``` JavaScript에서는 존재하지 않는 프로퍼티에 접근하였을 때, 런타임 오류가 발생하지 않고 `undefined` 값을 얻게 됩니다. -이 때문에 옵셔널 프로퍼티를 _읽었을_ 때, 해당 값을 사용하기에 앞서 `undefined`인지 여부를 확인해야 합니다. +이 때문에 옵셔널 프로퍼티를 *읽었을* 때, 해당 값을 사용하기에 앞서 `undefined`인지 여부를 확인해야 합니다. ```ts twoslash // @errors: 2532 @@ -221,13 +221,13 @@ function printName(obj: { first: string; last?: string }) { ## 유니언 타입 TypeScript의 타입 시스템에서는 기존의 타입을 기반으로 다양한 연산자를 사용하여 새로운 타입을 만들 수 있습니다. -몇몇 타입들을 사용하는 법을 알았으니, 이제 이 타입들을 _조합하여_ 흥미로운 방식으로 사용해볼 시간입니다. +몇몇 타입들을 사용하는 법을 알았으니, 이제 이 타입들을 *조합하여* 흥미로운 방식으로 사용해볼 시간입니다. ### 유니언 타입 정의하기 -타입을 조합하는 첫 번째 방법은 _유니언_ 타입을 사용하는 것입니다. -유니언 타입은 서로 다른 두 개 이상의 타입들을 사용하여 만드는 것으로, 유니언 타입의 값은 타입 조합에 사용된 타입 중 _무엇이든 하나_를 타입으로 가질 수 있습니다. -조합에 사용된 각 타입을 유니언 타입의 _멤버_라고 부릅니다. +타입을 조합하는 첫 번째 방법은 *유니언* 타입을 사용하는 것입니다. +유니언 타입은 서로 다른 두 개 이상의 타입들을 사용하여 만드는 것으로, 유니언 타입의 값은 타입 조합에 사용된 타입 중 *무엇이든 하나*를 타입으로 가질 수 있습니다. +조합에 사용된 각 타입을 유니언 타입의 *멤버*라고 부릅니다. 문자열 또는 숫자를 받을 수 있는 함수를 작성해보겠습니다. @@ -246,10 +246,10 @@ printId({ myID: 22342 }); ### 유니언 타입 사용하기 -유니언 타입에 맞는 값을 _제공하는_ 것은 간단합니다. 유니언 타입의 멤버 중 하나에 해당하는 타입을 제공하면 됩니다. -유니언 타입인 값이 코드상에 _존재할 때_, 이를 어떻게 사용해야 할까요? +유니언 타입에 맞는 값을 *제공하는* 것은 간단합니다. 유니언 타입의 멤버 중 하나에 해당하는 타입을 제공하면 됩니다. +유니언 타입인 값이 코드상에 *존재할 때*, 이를 어떻게 사용해야 할까요? -TypeScript에서 유니언을 다룰 때는 해당 유니언 타입의 _모든_ 멤버에 대하여 유효한 작업일 때에만 허용됩니다. +TypeScript에서 유니언을 다룰 때는 해당 유니언 타입의 *모든* 멤버에 대하여 유효한 작업일 때에만 허용됩니다. 예를 들어 `string | number`라는 유니언 타입의 경우, `string` 타입에만 유효한 메서드는 사용할 수 없습니다. ```ts twoslash @@ -259,8 +259,8 @@ function printId(id: number | string) { } ``` -이를 해결하려면 코드상에서 유니언을 _좁혀야_ 하는데, 이는 타입 표기가 없는 JavaScript에서 벌어지는 일과 동일합니다. -_좁히기_란 TypeScript가 코드 구조를 바탕으로 어떤 값을 보다 구체적인 타입으로 추론할 수 있을 때 발생합니다. +이를 해결하려면 코드상에서 유니언을 *좁혀야* 하는데, 이는 타입 표기가 없는 JavaScript에서 벌어지는 일과 동일합니다. +*좁히기*란 TypeScript가 코드 구조를 바탕으로 어떤 값을 보다 구체적인 타입으로 추론할 수 있을 때 발생합니다. 예를 들어, TypeScript는 오직 `string` 값만이 `typeof` 연산의 결괏값으로 `"string"`을 가질 수 있다는 것을 알고 있습니다. @@ -304,18 +304,18 @@ function getFirstThree(x: number[] | string) { } ``` -> 유니언은 의미상 _합집합_을 뜻하는데, 실제로는 유니언 타입이 프로퍼티들의 _교집합_을 가리키는 것처럼 보여 헷갈리게 느낄 수 있습니다. -> 이는 지극히 우연이 아닙니다. _유니언_이라는 명칭은 타입 이론에서 비롯된 것입니다. -> `number | string` _유니언_ 타입은 각각의 타입을 가지는 _값들에 대하여_ 합집합을 취하여 구성됩니다. -> 두 집합과 각각의 집합에 대한 특성이 주어졌을 때, 두 집합의 _유니언_에는 각각의 특성들의 _교집합_만이 적용된다는 점에 유의하시기 바랍니다. -> 예를 들어, 한 방에는 모자를 쓰고 키가 큰 사람들이 있고 다른 방에는 모자를 쓰고 스페인어를 사용하는 사람들이 있다고 합시다. 이때 두 방을 합친다면, _모든_ 사람들에 대하여 우리가 알 수 있는 사실은 바로 누구나 반드시 모자를 쓰고 있다는 것입니다. +> 유니언은 의미상 *합집합*을 뜻하는데, 실제로는 유니언 타입이 프로퍼티들의 *교집합*을 가리키는 것처럼 보여 헷갈리게 느낄 수 있습니다. +> 이는 지극히 우연이 아닙니다. *유니언*이라는 명칭은 타입 이론에서 비롯된 것입니다. +> `number | string` *유니언* 타입은 각각의 타입을 가지는 *값들에 대하여* 합집합을 취하여 구성됩니다. +> 두 집합과 각각의 집합에 대한 특성이 주어졌을 때, 두 집합의 *유니언*에는 각각의 특성들의 *교집합*만이 적용된다는 점에 유의하시기 바랍니다. +> 예를 들어, 한 방에는 모자를 쓰고 키가 큰 사람들이 있고 다른 방에는 모자를 쓰고 스페인어를 사용하는 사람들이 있다고 합시다. 이때 두 방을 합친다면, *모든* 사람들에 대하여 우리가 알 수 있는 사실은 바로 누구나 반드시 모자를 쓰고 있다는 것입니다. ## 타입 별칭 지금까지는 객체 타입과 유니언 타입을 사용할 때 직접 해당 타입을 표기하였습니다. 이는 편리하지만, 똑같은 타입을 한 번 이상 재사용하거나 또 다른 이름으로 부르고 싶은 경우도 존재합니다. -_타입 별칭_은 바로 이런 경우를 위하여 존재하며, _타입_을 위한 _이름_을 제공합니다. +*타입 별칭*은 바로 이런 경우를 위하여 존재하며, *타입*을 위한 *이름*을 제공합니다. 타입 별칭의 구문은 아래와 같습니다. ```ts twoslash @@ -340,9 +340,9 @@ printCoord({ x: 100, y: 100 }); type ID = number | string; ``` -타입 별칭은 _단지_ 별칭에 지나지 않는다는 점에 유의하시기 바랍니다. 즉, 타입 별칭을 사용하여도 동일 타입에 대하여 각기 구별되는 "여러 버전"을 만드는 것은 아닙니다. +타입 별칭은 *단지* 별칭에 지나지 않는다는 점에 유의하시기 바랍니다. 즉, 타입 별칭을 사용하여도 동일 타입에 대하여 각기 구별되는 "여러 버전"을 만드는 것은 아닙니다. 별칭을 사용하는 것은, 별도로 이름 붙인 타입을 새로 작성하는 것입니다. -다시 말해, 아래 코드는 틀린 것처럼 _보일 수_ 있지만, TypeScript에서는 이것이 정상인데 그 이유는 각각의 타입들이 동일 타입에 대한 별칭들이기 때문입니다. +다시 말해, 아래 코드는 틀린 것처럼 *보일 수* 있지만, TypeScript에서는 이것이 정상인데 그 이유는 각각의 타입들이 동일 타입에 대한 별칭들이기 때문입니다. ```ts twoslash declare function getInput(): string; @@ -363,7 +363,7 @@ userInput = "new input"; ## 인터페이스 -_인터페이스 선언_은 객체 타입을 만드는 또 다른 방법입니다. +*인터페이스 선언*은 객체 타입을 만드는 또 다른 방법입니다. ```ts twoslash interface Point { @@ -380,8 +380,8 @@ printCoord({ x: 100, y: 100 }); ``` 타입 별칭을 사용한 경우와 마찬가지로, 위 예시 코드는 마치 타입이 없는 임의의 익명 객체를 사용하는 것처럼 동작합니다. -TypeScript는 오직 `printCoord`에 전달된 값의 _구조_에만 관심을 가집니다. 즉, 예측된 프로퍼티를 가졌는지 여부만을 따집니다. -이처럼, 타입이 가지는 구조와 능력에만 관심을 가진다는 점은 TypeScript가 _구조적_ 타입 시스템이라고 불리는 이유입니다. +TypeScript는 오직 `printCoord`에 전달된 값의 *구조*에만 관심을 가집니다. 즉, 예측된 프로퍼티를 가졌는지 여부만을 따집니다. +이처럼, 타입이 가지는 구조와 능력에만 관심을 가진다는 점은 TypeScript가 *구조적* 타입 시스템이라고 불리는 이유입니다. ### 타입 별칭과 인터페이스의 차이점 @@ -459,7 +459,7 @@ type Window = { - TypeScript 4.2 이전 버전에서는, 타입 별칭 이름이 오류 메시지에 [나타날 수 있고](/play?#code/PTAEGEHsFsAcEsA2BTATqNrLusgzngIYDm+oA7koqIYuYQJ56gCueyoAUCKAC4AWHAHaFcoSADMaQ0PCG80EwgGNkALk6c5C1EtWgAsqOi1QAb06groEbjWg8vVHOKcAvpokshy3vEgyyMr8kEbQJogAFND2YREAlOaW1soBeJAoAHSIkMTRmbbI8e6aPMiZxJmgACqCGKhY6ABGyDnkFFQ0dIzMbBwCwqIccabcYLyQoKjIEmh8kwN8DLAc5PzwwbLMyAAeK77IACYaQSEjUWZWhfYAjABMAMwALA+gbsVjoADqgjKESytQPxCHghAByXigYgBfr8LAsYj8aQMUASbDQcRSExCeCwFiIQh+AKfAYyBiQFgOPyIaikSGLQo0Zj-aazaY+dSaXjLDgAGXgAC9CKhDqAALxJaw2Ib2RzOISuDycLw+ImBYKQflCkWRRD2LXCw6JCxS1JCdJZHJ5RAFIbFJU8ADKC3WzEcnVZaGYE1ABpFnFOmsFhsil2uoHuzwArO9SmAAEIsSFrZB-GgAjjA5gtVN8VCEc1o1C4Q4AGlR2AwO1EsBQoAAbvB-gJ4HhPgB5aDwem-Ph1TCV3AEEirTp4ELtRbTPD4vwKjOfAuioSQHuDXBcnmgACC+eCONFEs73YAPGGZVT5cRyyhiHh7AAON7lsG3vBggB8XGV3l8-nVISOgghxoLq9i7io-AHsayRWGaFrlFauq2rg9qaIGQHwCBqChtKdgRo8TxRjeyB3o+7xAA), 때로는 동등한 익명 타입을 대신하여 나타날 수 있습니다(이는 경우에 따라 바람직할 수도 있고 아닐 수도 있습니다). 인터페이스는 항상 오류 메시지에 이름이 나타납니다. - 타입 별칭은 [선언 병합에 포함될 수 없지만, 인터페이스는 포함될 수 있습니다](/play?#code/PTAEEEDtQS0gXApgJwGYEMDGjSfdAIx2UQFoB7AB0UkQBMAoEUfO0Wgd1ADd0AbAK6IAzizp16ALgYM4SNFhwBZdAFtV-UAG8GoPaADmNAcMmhh8ZHAMMAvjLkoM2UCvWad+0ARL0A-GYWVpA29gyY5JAWLJAwGnxmbvGgALzauvpGkCZmAEQAjABMAMwALLkANBl6zABi6DB8okR4Jjg+iPSgABboovDk3jjo5pbW1d6+dGb5djLwAJ7UoABKiJTwjThpnpnGpqPBoTLMAJrkArj4kOTwYmycPOhW6AR8IrDQ8N04wmo4HHQCwYi2Waw2W1S6S8HX8gTGITsQA). - 인터페이스는 [오직 객체의 모양을 선언하는 데에만 사용되며, 기존의 원시 타입에 별칭을 부여하는 데에는 사용할 수는 없습니다](/play?#code/PTAEAkFMCdIcgM6gC4HcD2pIA8CGBbABwBtIl0AzUAKBFAFcEBLAOwHMUBPQs0XFgCahWyGBVwBjMrTDJMAshOhMARpD4tQ6FQCtIE5DWoixk9QEEWAeV37kARlABvaqDegAbrmL1IALlAEZGV2agBfampkbgtrWwMAJlAAXmdXdy8ff0Dg1jZwyLoAVWZ2Lh5QVHUJflAlSFxROsY5fFAWAmk6CnRoLGwmILzQQmV8JmQmDzI-SOiKgGV+CaYAL0gBBdyy1KCQ-Pn1AFFplgA5enw1PtSWS+vCsAAVAAtB4QQWOEMKBuYVUiVCYvYQsUTQcRSBDGMGmKSgAAa-VEgiQe2GLgKQA). -- 인터페이스의 이름은 [항상 있는 그대로](/play?#code/PTAEGEHsFsAcEsA2BTATqNrLusgzngIYDm+oA7koqIYuYQJ56gCueyoAUCKAC4AWHAHaFcoSADMaQ0PCG80EwgGNkALk6c5C1EtWgAsqOi1QAb06groEbjWg8vVHOKcAvpokshy3vEgyyMr8kEbQJogAFND2YREAlOaW1soBeJAoAHSIkMTRmbbI8e6aPMiZxJmgACqCGKhY6ABGyDnkFFQ0dIzMbBwCwqIccabcYLyQoKjIEmh8kwN8DLAc5PzwwbLMyAAeK77IACYaQSEjUWY2Q-YAjABMAMwALA+gbsVjNXW8yxySoAADaAA0CCaZbPh1XYqXgOIY0ZgmcK0AA0nyaLFhhGY8F4AHJmEJILCWsgZId4NNfIgGFdcIcUTVfgBlZTOWC8T7kAJ42G4eT+GS42QyRaYbCgXAEEguTzeXyCjDBSAAQSE8Ai0Xsl0K9kcziExDeiQs1lAqSE6SyOTy0AKQ2KHk4p1V6s1OuuoHuzwArMagA) 오류 메시지에 나타납니다. 단, 이는 _오직_ 코드상에서 해당 인터페이스가 이름으로 사용되었을 때에만 해당합니다. +- 인터페이스의 이름은 [항상 있는 그대로](/play?#code/PTAEGEHsFsAcEsA2BTATqNrLusgzngIYDm+oA7koqIYuYQJ56gCueyoAUCKAC4AWHAHaFcoSADMaQ0PCG80EwgGNkALk6c5C1EtWgAsqOi1QAb06groEbjWg8vVHOKcAvpokshy3vEgyyMr8kEbQJogAFND2YREAlOaW1soBeJAoAHSIkMTRmbbI8e6aPMiZxJmgACqCGKhY6ABGyDnkFFQ0dIzMbBwCwqIccabcYLyQoKjIEmh8kwN8DLAc5PzwwbLMyAAeK77IACYaQSEjUWY2Q-YAjABMAMwALA+gbsVjNXW8yxySoAADaAA0CCaZbPh1XYqXgOIY0ZgmcK0AA0nyaLFhhGY8F4AHJmEJILCWsgZId4NNfIgGFdcIcUTVfgBlZTOWC8T7kAJ42G4eT+GS42QyRaYbCgXAEEguTzeXyCjDBSAAQSE8Ai0Xsl0K9kcziExDeiQs1lAqSE6SyOTy0AKQ2KHk4p1V6s1OuuoHuzwArMagA) 오류 메시지에 나타납니다. 단, 이는 *오직* 코드상에서 해당 인터페이스가 이름으로 사용되었을 때에만 해당합니다. 대부분의 경우 개인적 선호에 따라 인터페이스와 타입 중에서 선택할 수 있으며, 필요하다면 TypeScript가 다른 선택을 제안할 것입니다. 잘 모르겠다면, 우선 `interface`를 사용하고 이후 문제가 발생하였을 때 `type`을 사용하기 바랍니다. @@ -467,9 +467,9 @@ type Window = { 때로는 TypeScript보다 당신이 어떤 값의 타입에 대한 정보를 더 잘 아는 경우도 존재합니다. -예를 들어 코드상에서 `document.getElementById`가 사용되는 경우, TypeScript는 이때 `HTMLElement` 중에 _무언가_가 반환된다는 것만을 알 수 있는 반면에, 당신은 페이지 상에서 사용되는 ID로는 언제나 `HTMLCanvasElement`가 반환된다는 사실을 이미 알고 있을 수도 있습니다. +예를 들어 코드상에서 `document.getElementById`가 사용되는 경우, TypeScript는 이때 `HTMLElement` 중에 *무언가*가 반환된다는 것만을 알 수 있는 반면에, 당신은 페이지 상에서 사용되는 ID로는 언제나 `HTMLCanvasElement`가 반환된다는 사실을 이미 알고 있을 수도 있습니다. -이런 경우, _타입 단언_을 사용하면 타입을 좀 더 구체적으로 명시할 수 있습니다. +이런 경우, *타입 단언*을 사용하면 타입을 좀 더 구체적으로 명시할 수 있습니다. ```ts twoslash const myCanvas = document.getElementById("main_canvas") as HTMLCanvasElement; @@ -486,7 +486,7 @@ const myCanvas = document.getElementById("main_canvas"); > 기억하세요: 타입 단언은 컴파일 시간에 제거되므로, 타입 단언에 관련된 검사는 런타임 중에 이루어지지 않습니다. > 타입 단언이 틀렸더라도 예외가 발생하거나 `null`이 생성되지 않을 것입니다. -TypeScript에서는 _보다 구체적인_ 또는 _덜 구체적인_ 버전의 타입으로 변환하는 타입 단언만이 허용됩니다. +TypeScript에서는 *보다 구체적인* 또는 *덜 구체적인* 버전의 타입으로 변환하는 타입 단언만이 허용됩니다. 이러한 규칙은 아래와 같은 "불가능한" 강제 변환을 방지합니다. ```ts twoslash @@ -506,7 +506,7 @@ const a = (expr as any) as T; ## 리터럴 타입 -`string`과 `number`와 같은 일반적인 타입 이외에도, _구체적인_ 문자열과 숫자 값을 타입 위치에서 지정할 수 있습니다. +`string`과 `number`와 같은 일반적인 타입 이외에도, *구체적인* 문자열과 숫자 값을 타입 위치에서 지정할 수 있습니다. 이를 이해하려면, JavaScript에서 변수 선언에 제공되는 다양한 방법들을 떠올려보시기 바랍니다. `var`와 `let` 모두 변수에 저장 가능한 값의 종류를 변경할 수 있으며, `const`는 이것이 불가능합니다. 이러한 특징들은 TypeScript가 리터럴 값을 위한 타입을 생성하는 방식에 그대로 반영됩니다. @@ -538,7 +538,7 @@ x = "howdy"; 단 하나의 값만을 가질 수 있는 변수는 그다지 쓸모가 없죠! -하지만 리터럴을 유니언과 _함께 사용하면_, 보다 유용한 개념들을 표현할 수 있게 됩니다. 예를 들어, 특정 종류의 값들만을 인자로 받을 수 있는 함수를 정의하는 경우가 있습니다. +하지만 리터럴을 유니언과 *함께 사용하면*, 보다 유용한 개념들을 표현할 수 있게 됩니다. 예를 들어, 특정 종류의 값들만을 인자로 받을 수 있는 함수를 정의하는 경우가 있습니다. ```ts twoslash // @errors: 2345 @@ -591,7 +591,7 @@ if (someCondition) { ``` 기존에 값이 `0`이었던 필드에 `1`을 대입하였을 때 TypeScript는 이를 오류로 간주하지 않습니다. -이를 달리 말하면 `obj.counter`는 반드시 `number` 타입을 가져야 하며, `0` 리터럴 타입을 가질 수 없다는 의미입니다. 왜냐하면 타입은 _읽기_ 및 _쓰기_ 두 동작을 결정하는 데에 사용되기 때문입니다. +이를 달리 말하면 `obj.counter`는 반드시 `number` 타입을 가져야 하며, `0` 리터럴 타입을 가질 수 없다는 의미입니다. 왜냐하면 타입은 *읽기* 및 *쓰기* 두 동작을 결정하는 데에 사용되기 때문입니다. 동일한 사항이 문자열에도 적용됩니다. @@ -618,7 +618,7 @@ handleRequest(req.url, req.method); handleRequest(req.url, req.method as "GET"); ``` - 수정 1은 `req.method`가 항상 _리터럴 타입_ `"GET"`이기를 의도하며, 이에 따라 해당 필드에 `"GUESS"`와 같은 값이 대입되는 경우를 미연에 방지하겠다"는 것을 의미합니다. + 수정 1은 `req.method`가 항상 *리터럴 타입* `"GET"`이기를 의도하며, 이에 따라 해당 필드에 `"GUESS"`와 같은 값이 대입되는 경우를 미연에 방지하겠다"는 것을 의미합니다. 수정 2는 "무슨 이유인지, `req.method`가 `"GET"`을 값으로 가진다는 사실을 알고 있다"는 것을 의미합니다. 2. `as const`를 사용하여 객체 전체를 리터럴 타입으로 변환할 수 있습니다. @@ -636,18 +636,18 @@ handleRequest(req.url, req.method); JavaScript에는 빈 값 또는 초기화되지 않은 값을 가리키는 두 가지 원시값이 존재합니다. 바로 `null`과 `undefined`입니다. -TypeScript에는 각 값에 대응하는 동일한 이름의 두 가지 _타입_이 존재합니다. 각 타입의 동작 방식은 `strictNullChecks` 옵션의 설정 여부에 따라 달라집니다. +TypeScript에는 각 값에 대응하는 동일한 이름의 두 가지 *타입*이 존재합니다. 각 타입의 동작 방식은 `strictNullChecks` 옵션의 설정 여부에 따라 달라집니다. ### `strictNullChecks`가 설정되지 않았을 때 -`strictNullChecks`가 _설정되지 않았다면_, 어떤 값이 `null` 또는 `undefined`일 수 있더라도 해당 값에 평소와 같이 접근할 수 있으며, `null`과 `undefined`는 모든 타입의 변수에 대입될 수 있습니다. +`strictNullChecks`가 *설정되지 않았다면*, 어떤 값이 `null` 또는 `undefined`일 수 있더라도 해당 값에 평소와 같이 접근할 수 있으며, `null`과 `undefined`는 모든 타입의 변수에 대입될 수 있습니다. 이는 Null 검사를 하지 않는 언어(C#, Java 등)의 동작 방식과 유사합니다. Null 검사의 부재는 버그의 주요 원인이 되기도 합니다. 별다른 이유가 없다면, 코드 전반에 걸쳐 `strictNullChecks` 옵션을 설정하는 것을 항상 권장합니다. ### `strictNullChecks` 설정되었을 때 -`strictNullChecks`가 _설정되었다면_, 어떤 값이 `null` 또는 `undefined`일 때, 해당 값과 함께 메서드 또는 프로퍼티를 사용하기에 앞서 해당 값을 테스트해야 합니다. -옵셔널 프로퍼티를 사용하기에 앞서 `undefined` 여부를 검사하는 것과 마찬가지로, _좁히기_를 통하여 `null`일 수 있는 값에 대한 검사를 수행할 수 있습니다. +`strictNullChecks`가 *설정되었다면*, 어떤 값이 `null` 또는 `undefined`일 때, 해당 값과 함께 메서드 또는 프로퍼티를 사용하기에 앞서 해당 값을 테스트해야 합니다. +옵셔널 프로퍼티를 사용하기에 앞서 `undefined` 여부를 검사하는 것과 마찬가지로, *좁히기*를 통하여 `null`일 수 있는 값에 대한 검사를 수행할 수 있습니다. ```ts twoslash function doSomething(x: string | undefined) { @@ -672,11 +672,11 @@ function liveDangerously(x?: number | undefined) { } ``` -다른 타입 단언과 마찬가지로 이 구문은 코드의 런타임 동작을 변화시키지 않으므로, `!` 연산자는 반드시 해당 값이 `null` 또는 `undefined`가 _아닌_ 경우에만 사용해야 합니다. +다른 타입 단언과 마찬가지로 이 구문은 코드의 런타임 동작을 변화시키지 않으므로, `!` 연산자는 반드시 해당 값이 `null` 또는 `undefined`가 *아닌* 경우에만 사용해야 합니다. ## 열거형 -열거형은 TypeScript가 JavaScript에 추가하는 기능으로, 어떤 값이 _이름이 있는 상수 집합_에 속한 값 중 하나일 수 있도록 제한하는 기능입니다. 대부분의 TypeScript 기능과 달리, 이 기능은 JavaScript에 타입 수준이 _아닌_, 언어와 런타임 수준에 추가되는 기능입니다. 따라서 열거형이 무엇인지는 알 필요가 있겠으나, 그 사용법을 명확하게 파악하지 않았다면 실제 사용은 보류하는 것이 좋습니다. 열거형에 대한 자세한 내용을 확인하려면 [열거형 문서](https://www.typescriptlang.org/ko/docs/handbook/enums.html)를 읽어보시기 바랍니다. +열거형은 TypeScript가 JavaScript에 추가하는 기능으로, 어떤 값이 *이름이 있는 상수 집합*에 속한 값 중 하나일 수 있도록 제한하는 기능입니다. 대부분의 TypeScript 기능과 달리, 이 기능은 JavaScript에 타입 수준이 *아닌*, 언어와 런타임 수준에 추가되는 기능입니다. 따라서 열거형이 무엇인지는 알 필요가 있겠으나, 그 사용법을 명확하게 파악하지 않았다면 실제 사용은 보류하는 것이 좋습니다. 열거형에 대한 자세한 내용을 확인하려면 [열거형 문서](https://www.typescriptlang.org/ko/docs/handbook/enums.html)를 읽어보시기 바랍니다. ## 자주 사용되지 않는 원시형 타입 From 840594ae631b7d74a3c2dfb1f55417a2cc04fbab Mon Sep 17 00:00:00 2001 From: Joy C Date: Mon, 3 Oct 2022 19:28:08 -0600 Subject: [PATCH 2/2] fix Italic --- .../ko/declaration-files/By Example.md | 48 +++++++++---------- .../TS for Functional Programmers.md | 6 +-- .../ko/get-started/TS for JS Programmers.md | 4 +- .../ko/get-started/TS for OOPers.md | 28 +++++------ .../get-started/TS for the New Programmer.md | 40 ++++++++-------- docs/documentation/ko/handbook-v2/Basics.md | 42 ++++++++-------- .../Type Manipulation/Conditional Types.md | 10 ++-- .../ko/handbook-v2/Understanding Errors.md | 12 ++--- .../ko/project-config/Configuring Watch.md | 8 ++-- .../Integrating with Build Tools.md | 2 +- .../ko/reference/Declaration Merging.md | 2 +- docs/documentation/ko/reference/Decorators.md | 2 +- .../ko/reference/Iterators and Generators.md | 2 +- docs/documentation/ko/reference/JSX.md | 18 +++---- .../ko/reference/Namespaces and Modules.md | 2 +- .../ko/reference/Triple-Slash Directives.md | 14 +++--- .../ko/release-notes/TypeScript 4.0.md | 28 +++++------ .../ko/tutorials/Babel with TypeScript.md | 2 +- .../ko/tutorials/DOM Manipulation.md | 28 +++++------ 19 files changed, 149 insertions(+), 149 deletions(-) diff --git a/docs/documentation/ko/declaration-files/By Example.md b/docs/documentation/ko/declaration-files/By Example.md index e73f5066..6e20b592 100644 --- a/docs/documentation/ko/declaration-files/By Example.md +++ b/docs/documentation/ko/declaration-files/By Example.md @@ -26,12 +26,12 @@ oneline: "How to create a d.ts file for a module" ## 프로퍼티를 갖는 객체 (Objects with Properties) -_문서_ +*문서* > 전역 변수 `myLib`에는 인사말을 만드는 함수 `makeGreeting`와, > 지금까지 생성한 인사말의 수를 가리키는 `numberOfGreetings` 프로퍼티가 있습니다. -_코드_ +*코드* ```ts let result = myLib.makeGreeting("hello, world"); @@ -40,7 +40,7 @@ console.log("The computed greeting is:" + result); let count = myLib.numberOfGreetings; ``` -_선언_ +*선언* 점 표기법으로 접근하는 타입이나 값을 설명하기 위해 `declare namespace`를 사용하세요. @@ -53,11 +53,11 @@ declare namespace myLib { ## 오버로드된 함수 (Overloaded Functions) -_문서_ +*문서* `getWidget` 함수는 숫자를 인자로 받아 Widget을 반환하거나, 문자열을 인자로 받아 Widget 배열을 반환합니다. -_코드_ +*코드* ```ts let x: Widget = getWidget(43); @@ -65,7 +65,7 @@ let x: Widget = getWidget(43); let arr: Widget[] = getWidget("all of them"); ``` -_선언_ +*선언* ```ts declare function getWidget(n: number): Widget; @@ -74,7 +74,7 @@ declare function getWidget(s: string): Widget[]; ## 재사용 가능한 타입 (인터페이스) (Reusable Types (Interfaces)) -_문서_ +*문서* > greeting을 명시할 때, 반드시 `GreetingSettings` 객체를 전달해야 합니다. > 이 객체는 다음의 프로퍼티를 갖고 있습니다: @@ -85,7 +85,7 @@ _문서_ > > 3 - color: 선택적 문자열, 예. '#ff00ff' -_코드_ +*코드* ```ts greet({ @@ -94,7 +94,7 @@ greet({ }); ``` -_선언_ +*선언* 프로퍼티를 갖는 타입을 정의하기 위해 `interface`를 사용하세요. @@ -110,11 +110,11 @@ declare function greet(setting: GreetingSettings): void; ## 재사용 가능한 타입 (타입 별칭) (Reusable Types (Type Aliases)) -_문서_ +*문서* > 인사말이 예상되는 어느 곳에나, `string`, `string`을 반환하는 함수, 또는 `Greeter` 인스턴스를 전달할 수 있습니다. -_코드_ +*코드* ```ts function getGreeting() { @@ -127,7 +127,7 @@ greet(getGreeting); greet(new MyGreeter()); ``` -_선언_ +*선언* 타입에 대한 약칭으로 타입 별칭을 사용할 수 있습니다: @@ -139,12 +139,12 @@ declare function greet(g: GreetingLike): void; ## 타입 구조화하기 (Organizing Types) -_문서_ +*문서* > `greeter` 객체는 파일에 로그를 작성하거나 경고 창을 띄울 수 있습니다. > 로그 옵션을 `.log(...)` 내부에, 경고 창 옵션을 `.alert(...)` 내부에 전달할 수 있습니다. -_코드_ +*코드* ```ts const g = new Greeter("Hello"); @@ -152,7 +152,7 @@ g.log({ verbose: true }); g.alert({ modal: false, title: "Current Greeting" }); ``` -_선언_ +*선언* 타입을 구조화하기 위해 네임스페이스를 사용하세요. @@ -187,11 +187,11 @@ declare namespace GreetingLib.Options { ## 클래스 (Classes) -_문서_ +*문서* > `Greeter` 객체를 인스턴스화해서 greeter를 생성하거나, 이 객체를 상속해서 커스텀 greeter를 생성할 수 있습니다. -_코드_ +*코드* ```ts const myGreeter = new Greeter("hello, world"); @@ -205,7 +205,7 @@ class SpecialGreeter extends Greeter { } ``` -_선언_ +*선언* 클래스 혹은 클래스-같은 객체를 설명하기 위해 `declare class`를 사용하세요. 클래스는 생성자 뿐만 아니라 프로퍼티와 메서드를 가질 수 있습니다. @@ -221,17 +221,17 @@ declare class Greeter { ## 전역 변수 (Global Variables) -_문서_ +*문서* > 전역 변수 `foo`는 존재하는 위젯의 수를 포함합니다. -_코드_ +*코드* ```ts console.log("Half the number of widgets is " + (foo / 2)); ``` -_선언_ +*선언* 변수를 선언하기 위해 `declare var`를 사용하세요. 만약 변수가 읽기-전용이라면, `declare const`를 사용하세요. @@ -244,17 +244,17 @@ declare var foo: number; ## 전역 함수 (Global Functions) -_문서_ +*문서* > 사용자에게 인사말을 보여주기 위해 `greet` 함수를 호출할 수 있습니다. -_코드_ +*코드* ```ts greet("hello, world"); ``` -_선언_ +*선언* 함수를 선언하기 위해 `declare function`을 사용하세요. diff --git a/docs/documentation/ko/get-started/TS for Functional Programmers.md b/docs/documentation/ko/get-started/TS for Functional Programmers.md index 552ff2bc..a4c7d0c1 100644 --- a/docs/documentation/ko/get-started/TS for Functional Programmers.md +++ b/docs/documentation/ko/get-started/TS for Functional Programmers.md @@ -366,7 +366,7 @@ type Size = [number, number]; let x: Size = [101.1, 999.9]; ``` -`newtype`과 가장 유사한 것은 _태그된 교차 타입(tagged intersection)_ 입니다: +`newtype`과 가장 유사한 것은 *태그된 교차 타입(tagged intersection)* 입니다: ```ts type FString = string & { __compileTimeOnly: any }; @@ -462,7 +462,7 @@ TypeScript는 일반적으로 인자 타입에 기반하여 호출로부터 타 왜냐하면 TypeScript는 구조적이기 때문에, 이름 기반의 시스템만큼 타입 매개 변수를 필요로 하지 않습니다. 특히 함수를 다형성으로 만들 필요는 없습니다. 타입 매개변수는 매개변수를 같은 타입으로 -제한하는 것처럼 타입 정보를 _전파하는데만_ +제한하는 것처럼 타입 정보를 *전파하는데만* 쓰여야 합니다: ```ts @@ -534,7 +534,7 @@ function g() { } ## `readonly` 와 `const` (`readonly` and `const`) JavaScript에서, 수정 가능함이 기본이지만, -_참조_가 수정 불가능함을 선언하기 위해 `const`로 변수를 선언할 수 있습니다. +*참조*가 수정 불가능함을 선언하기 위해 `const`로 변수를 선언할 수 있습니다. 참조 대상은 여전히 수정 가능합니다: ```js diff --git a/docs/documentation/ko/get-started/TS for JS Programmers.md b/docs/documentation/ko/get-started/TS for JS Programmers.md index 850b01f1..2c65db89 100644 --- a/docs/documentation/ko/get-started/TS for JS Programmers.md +++ b/docs/documentation/ko/get-started/TS for JS Programmers.md @@ -137,7 +137,7 @@ JavaScript에서 사용할 수 있는 적은 종류의 원시 타입이 이미 type MyBool = true | false; ``` -_참고:_ `MyBool`위에 마우스를 올린다면, `boolean`으로 분류된 것을 볼 수 있습니다 - 구조적 타입 시스템의 프로퍼티며, 나중에 살펴보겠습니다. +*참고:* `MyBool`위에 마우스를 올린다면, `boolean`으로 분류된 것을 볼 수 있습니다 - 구조적 타입 시스템의 프로퍼티며, 나중에 살펴보겠습니다. 유니언 타입이 가장 많이 사용된 사례 중 하나는 값이 다음과 같이 허용되는 `string` 또는 `number`의 [리터럴](/docs/handbook/literal-types.html)집합을 설명하는 것입니다: @@ -214,7 +214,7 @@ backpack.add(23); ## 구조적 타입 시스템 (Structural Type System) -TypeScript의 핵심 원칙 중 하나는 타입 검사가 값이 있는 _형태_에 집중한다는 것입니다. +TypeScript의 핵심 원칙 중 하나는 타입 검사가 값이 있는 *형태*에 집중한다는 것입니다. 이는 때때로 "덕 타이핑(duck typing)" 또는 "구조적 타이핑" 이라고 불립니다. 구조적 타입 시스템에서 두 객체가 같은 형태를 가지면 같은 것으로 간주됩니다. diff --git a/docs/documentation/ko/get-started/TS for OOPers.md b/docs/documentation/ko/get-started/TS for OOPers.md index 14344438..cf936ea2 100644 --- a/docs/documentation/ko/get-started/TS for OOPers.md +++ b/docs/documentation/ko/get-started/TS for OOPers.md @@ -17,16 +17,16 @@ TypeScript는 이러한 개발자에게 친숙한 기능을 많이 제공하지 만약 JavaScript에 이미 익숙하지만 주로 Java또는 C#을 사용하는 프로그래머라면, 이 소개 페이지는 흔히 접할 수 있는 오해와 함정에 대한 설명에 도움을 줄 수 있습니다. TypeScript 모델이 유형화하는 방법 중 일부는 Java나 C#과 상당히 다르며, TypeScript를 학습하는 데에 있어 이 부분을 염두에 두는 것이 중요합니다. -만약 JavaScript를 처음 접하는 Java나 C# 프로그래머라면, JavaScript의 런타임 동작을 이해하기 위해 우선적으로 타입을 _제외한_ JavaScript의 일부분을 배우는 것이 좋습니다. -TypeScript는 코드를 _실행하는_ 방식을 바꾸지 않기 때문에, 실제로 무언가 동작하는 코드를 작성하기 위해서는 여전히 JavaScript가 어떻게 작동하는지 배워야 합니다! +만약 JavaScript를 처음 접하는 Java나 C# 프로그래머라면, JavaScript의 런타임 동작을 이해하기 위해 우선적으로 타입을 *제외한* JavaScript의 일부분을 배우는 것이 좋습니다. +TypeScript는 코드를 *실행하는* 방식을 바꾸지 않기 때문에, 실제로 무언가 동작하는 코드를 작성하기 위해서는 여전히 JavaScript가 어떻게 작동하는지 배워야 합니다! TypeScript가 JavaScript와 동일한 *런타임*을 사용하므로, 특정한 런타임 동작(문자열을 숫자로 변환하기, 경고 표시, 디스크에 파일 쓰기 등)을 구현하려는 리소스는 항상 TypeScript 프로그램에 똑같이 잘 적용된다는 점을 기억하는 것은 매우 중요합니다. TypeScript에 특정된 리소스에만 제한을 두지 마십시오! ## 클래스 다시 생각하기 (Rethinking the Class) -C#과 Java는 _의무적 OOP_ 언어라고 부릅니다. -이러한 언어에서 *클래스*는 코드 구성의 기본 단위일 뿐만 아니라 런타임 시 모든 데이터 _그리고_ 동작의 기본적인 컨테이너입니다. +C#과 Java는 *의무적 OOP* 언어라고 부릅니다. +이러한 언어에서 *클래스*는 코드 구성의 기본 단위일 뿐만 아니라 런타임 시 모든 데이터 *그리고* 동작의 기본적인 컨테이너입니다. 기능과 데이터를 전부 클래스에 담도록 강제하는 것은 일부 문제에 대해선 좋은 도메인 모델이 될 수 있지만, 모든 도메인이 이러한 방식으로 표현될 *필요*는 없습니다. ### 자유로운 함수와 데이터 (Free Functions and Data) @@ -66,7 +66,7 @@ C#과 Java에서 주어진 값과 객체는 ‘null’, 원시 타입, 또는 C# 또는 Java에서 런타임 타입과 해당 컴파일 타임 선언 사이의 일대일 대응관계는 중요합니다. TypeScript에서 타입은 공통의 무언가를 공유하는 *값의 집합*으로 생각하는 것이 좋습니다. -타입은 집합에 불과하기 때문에, 특정한 값은 동시에 _수많은_ 집합에 속할 수 있습니다. +타입은 집합에 불과하기 때문에, 특정한 값은 동시에 *수많은* 집합에 속할 수 있습니다. 일단 타입을 집합으로 생각하기 시작하면, 특정 연산이 매우 자연스러워집니다. 예를 들어, C#에서는 ‘string’과 ‘int’ *둘 다 가능한* 타입이 존재하지 않기 때문에 이 값을 인자로 전달하는 것은 이상합니다. @@ -79,7 +79,7 @@ TypeScript는 집합론에 의거해 타입을 이용하는 여러 방법을 제 ### 삭제된 구조적 타입 (Erased Structural Types) -TypeScript에서, 객체는 정확히 단일 타입이 _아닙니다_. +TypeScript에서, 객체는 정확히 단일 타입이 *아닙니다*. 예를 들어 인터페이스를 만족하는 객체를 생성할 때, 둘 사이의 선언적인 관계가 없더라도 해당 인터페이스가 예상되는 곳에 해당 객체를 사용할 수 있습니다. ``` @@ -109,13 +109,13 @@ printPoint(obj); printName(obj); ``` -TypeScript의 타입 시스템은 명목이 아닌 _구조적_입니다: `obj`는 숫자인 `x`와 `y` 프로퍼티를 가지고 있으므로, `Pointlike`로써 사용될 수 있습니다. +TypeScript의 타입 시스템은 명목이 아닌 *구조적*입니다: `obj`는 숫자인 `x`와 `y` 프로퍼티를 가지고 있으므로, `Pointlike`로써 사용될 수 있습니다. 타입 간의 관계는 특정 관계로 선언되었는지가 아닌, 포함된 프로퍼티에 의해 결정됩니다. -TypeScript의 타입 시스템은 또한 _구체화되지 않았습니다_: 런타임에 `obj`가 `Pointlike`임을 알려주지 않습니다. -사실, `Pointlike` 타입은 런타임에 _어떤 형태로도_ 존재하지 않습니다. +TypeScript의 타입 시스템은 또한 *구체화되지 않았습니다*: 런타임에 `obj`가 `Pointlike`임을 알려주지 않습니다. +사실, `Pointlike` 타입은 런타임에 *어떤 형태로도* 존재하지 않습니다. -_집합으로서의 타입_ 개념으로 보면, `obj`를 `Pointlike` 값 집합이나 `Named` 값 집합의 멤버로 간주할 수 있습니다. +*집합으로서의 타입* 개념으로 보면, `obj`를 `Pointlike` 값 집합이나 `Named` 값 집합의 멤버로 간주할 수 있습니다. ### 구조적 타입화의 결과 (Consequences of Structural Typing) @@ -123,7 +123,7 @@ _집합으로서의 타입_ 개념으로 보면, `obj`를 `Pointlike` 값 집합 #### 빈 타입 (Empty Types) -첫 번째로 _빈 타입_은 예상을 무시하는 것처럼 보입니다: +첫 번째로 *빈 타입*은 예상을 무시하는 것처럼 보입니다: ``` class Empty {} @@ -138,11 +138,11 @@ fn({ k: 10 }); TypeScript는 주어진 인수가 유효한 `Empty`인지 확인하여 `fn`의 호출이 유효한지를 검사합니다 `{ k: 10 }`과 `class Empty { }`의 _구조를 확인하여 유효성을 검사합니다. -`Empty`에 프로퍼티가 없으므로 `Empty`가 수행하는 _모든_ 프로퍼티가 `{ k: 10 }`에 속해있습니다. +`Empty`에 프로퍼티가 없으므로 `Empty`가 수행하는 *모든* 프로퍼티가 `{ k: 10 }`에 속해있습니다. 그러므로, 유효한 호출입니다: 놀랍지만, 최종적으로 명목적인 객체지향프로그래밍 언어와 매우 비슷하게 사용됩니다. -파생 클래스와 파생 클래스의 기본 사이의 자연스러운 하위 타입 관계가 파괴되기 때문에, 하위 클래스는 _삭제_할 수 없습니다. +파생 클래스와 파생 클래스의 기본 사이의 자연스러운 하위 타입 관계가 파괴되기 때문에, 하위 클래스는 *삭제*할 수 없습니다. 구조적 타입 시스템은 호환 가능한 유형의 속성을 갖는 측면에서 하위 타입을 설명하므로 위의 관계를 암시적으로 구별합니다 #### 동일한 타입 (Identical Types) @@ -165,7 +165,7 @@ class Golfer { let w: Car = new Golfer(); ``` -다시 말하지만, 오류가 아닌 이유는 클래스의 _구조_가 동일하기 때문입니다. +다시 말하지만, 오류가 아닌 이유는 클래스의 *구조*가 동일하기 때문입니다. 잠재적인 혼란의 이유가 될 수도 있겠지만, 사실 상관없는 클래스가 동일한 경우는 일반적이지 않습니다. 차후에 클래스 챕터에서 클래스가 서로 어떻게 관련되는지에 대해 자세히 알아볼 것입니다. diff --git a/docs/documentation/ko/get-started/TS for the New Programmer.md b/docs/documentation/ko/get-started/TS for the New Programmer.md index 17d74460..11d89dda 100644 --- a/docs/documentation/ko/get-started/TS for the New Programmer.md +++ b/docs/documentation/ko/get-started/TS for the New Programmer.md @@ -20,16 +20,16 @@ JavaScript가 처음 나왔을 때, 수십 줄 이상의 코드를 작성하는 웹 브라우저 개발자들은 위와 같이 늘어나는 JS 사용량에 대하여 실행 엔진(동적 컴파일)을 최적화시키고 최적화 된 것을 이용해 할 수 있는 일(API 추가)을 확장하여 웹 개발자가 더 많이 JS를 사용할 수 있게 했습니다. 현대 웹사이트에서, 브라우저는 수십만 줄의 코드로 구성된 어플리케이션을 자주 실행합니다. -이는 정적 페이지의 간단한 네트워크로 시작해서, 모든 종류의 만족스러울만한 _어플리케이션_을 위한 플랫폼으로 성장한 "웹"의 길고 점진적인 성장입니다. +이는 정적 페이지의 간단한 네트워크로 시작해서, 모든 종류의 만족스러울만한 *어플리케이션*을 위한 플랫폼으로 성장한 "웹"의 길고 점진적인 성장입니다. 이외에도, JS는 node.js를 사용하여 JS 서버들을 구현하는 것처럼, 브라우저 맥락에서 벗어나는 일에 사용하기 충분할 정도로 유명해졌습니다. "어디서든 작동됨"과 같은 JS의 성질은 교차 플랫폼(cross-platform) 개발을 위한 매력적인 선택지이기도 합니다. -오늘날 많은 개발자들은 _오직_ JavaScript만을 이용하여 전체 스택을 프로그래밍하고 있습니다! +오늘날 많은 개발자들은 *오직* JavaScript만을 이용하여 전체 스택을 프로그래밍하고 있습니다! 요약하자면, 우리에게는 빠른 사용을 위해 설계되었으며 수백만 줄의 어플리케이션들을 작성하기 위해 만들어진 완벽한 도구인 JavaScript가 있습니다. -모든 언어는 각자의 _별난 점_ - 이상한 점과 놀랄만한 점이 있으며, JavaScript의 자랑스럽지만은 않은 시작은 _많은_ 문제를 만들게 되었습니다. 예를 들어: +모든 언어는 각자의 *별난 점* - 이상한 점과 놀랄만한 점이 있으며, JavaScript의 자랑스럽지만은 않은 시작은 *많은* 문제를 만들게 되었습니다. 예를 들어: -* JavaScript의 동일 연산자는 (`==`) 인수를 _강제로 변환하여(coerces)_, 예기치 않은 동작을 유발합니다: +* JavaScript의 동일 연산자는 (`==`) 인수를 *강제로 변환하여(coerces)*, 예기치 않은 동작을 유발합니다: ```js if ("" == 0) { @@ -54,11 +54,11 @@ JavaScript가 처음 나왔을 때, 수십 줄 이상의 코드를 작성하는 ## TypeScript: 정적 타입 검사자 (TypeScript: A Static Type Checker) 앞서 몇 언어는 버그가 많은 프로그램을 아예 실행시키지 않는다고 했습니다. -프로그램을 실행시키지 않으면서 코드의 오류를 검출하는 것을 _정적 검사_라고 합니다. -어떤 것이 오류인지와 어떤 것이 연산 되는 값에 기인하지 않음을 정하는 것이 정적 _타입_ 검사입니다. +프로그램을 실행시키지 않으면서 코드의 오류를 검출하는 것을 *정적 검사*라고 합니다. +어떤 것이 오류인지와 어떤 것이 연산 되는 값에 기인하지 않음을 정하는 것이 정적 *타입* 검사입니다. -_정적 타입 검사자_인 TypeScript는 프로그램을 실행시키기 전에 _값의 종류_를 기반으로 프로그램의 오류를 찾습니다. -예를 들어, 위의 마지막 예시에 오류가 있는 이유는 `obj`의 _타입_ 때문입니다. +*정적 타입 검사자*인 TypeScript는 프로그램을 실행시키기 전에 *값의 종류*를 기반으로 프로그램의 오류를 찾습니다. +예를 들어, 위의 마지막 예시에 오류가 있는 이유는 `obj`의 *타입* 때문입니다. 다음은 TypeScript에서 볼 수 있는 오류입니다: ``` @@ -73,9 +73,9 @@ const area = obj.width * obj.heigth; #### 구문 (Syntax) -TypeScript는 JS의 구문이 허용되는, JavaScript의 _상위 집합_ 언어입니다. +TypeScript는 JS의 구문이 허용되는, JavaScript의 *상위 집합* 언어입니다. 구문은 프로그램을 만들기 위해 코드를 작성하는 방법을 의미합니다. -예를 들어, 다음 코드는 `)`이 없으므로 _구문_ 오류입니다: +예를 들어, 다음 코드는 `)`이 없으므로 *구문* 오류입니다: ``` // @errors: 1005 @@ -87,10 +87,10 @@ TypeScript는 독특한 구문 때문에 JavaScript 코드를 오류로 보지 #### 타입 (Types) -그러나 TypeScript는 다른 종류의 값들을 사용할 수 있는 방법이 추가된, _타입이 있는_ 상위 집합입니다. -위의 `obj.heigth` 오류는 _구문_ 오류가 아닌, 값의 종류(_타입_)를 잘못 사용해서 생긴 오류입니다. +그러나 TypeScript는 다른 종류의 값들을 사용할 수 있는 방법이 추가된, *타입이 있는* 상위 집합입니다. +위의 `obj.heigth` 오류는 *구문* 오류가 아닌, 값의 종류(*타입*)를 잘못 사용해서 생긴 오류입니다. -또 다른 예시로, 아래와 같은 JavaScript 코드가 브라우저에서 실행될 때, 다음과 같은 값이 출력될 _것입니다_: +또 다른 예시로, 아래와 같은 JavaScript 코드가 브라우저에서 실행될 때, 다음과 같은 값이 출력될 *것입니다*: ```js console.log(4 / []); @@ -104,17 +104,17 @@ console.log(4 / []); console.log(4 / []); ``` -실제로 어떤 일이 일어나는지 보려는 의도로 숫자를 배열로 나눌 수 _있지만_, 대부분은 프로그래밍 실수입니다. +실제로 어떤 일이 일어나는지 보려는 의도로 숫자를 배열로 나눌 수 *있지만*, 대부분은 프로그래밍 실수입니다. TypeScript의 타입 검사자는 일반적인 오류를 최대한 많이 검출하면서 올바른 프로그램을 만들 수 있게 설계되었습니다. (나중에 TypeScript가 코드를 얼마나 엄격하게 검사할 수 있는지에 대한 설정에 대해 알아봅시다.) -만약 JavaScript 파일의 코드를 TypeScript 코드로 옮기면, 코드를 어떻게 작성했는지에 따라 _타입 오류_를 볼 수 있습니다. +만약 JavaScript 파일의 코드를 TypeScript 코드로 옮기면, 코드를 어떻게 작성했는지에 따라 *타입 오류*를 볼 수 있습니다. 이는 코드 상의 문제이거나, TypeScript가 지나치게 보수적인 것일 수 있습니다. 위와 같은 오류를 제거하기 위해 가이드는 다양한 TypeScript 구문을 추가하는 방법을 보여줍니다. #### 런타임 특성 (Runtime Behavior) -TypeScript는 JavaScript의 _런타임 특성_을 가진 프로그래밍 언어입니다. +TypeScript는 JavaScript의 *런타임 특성*을 가진 프로그래밍 언어입니다. 예를 들어, JavaScript에서 0으로 나누는 행동은 런타임 예외로 처리하지 않고 `Infinity`값을 반환합니다. 논리적으로, TypeScript는 JavaScript 코드의 런타임 특성을 **절대** 변화시키지 않습니다. @@ -130,10 +130,10 @@ how JS code can be used in TS.) #### 삭제된 타입 (Erased Types) -개략적으로, TypeScript의 컴파일러가 코드 검사를 마치면 타입을 _삭제해서_ 결과적으로 "컴파일된" 코드를 만듭니다. +개략적으로, TypeScript의 컴파일러가 코드 검사를 마치면 타입을 *삭제해서* 결과적으로 "컴파일된" 코드를 만듭니다. 즉 코드가 한 번 컴파일되면, 결과로 나온 일반 JS 코드에는 타입 정보가 없습니다. -타입 정보가 없는 것은 TypeScript가 추론한 타입에 따라 프로그램의 _특성_을 변화시키지 않는다는 의미입니다. +타입 정보가 없는 것은 TypeScript가 추론한 타입에 따라 프로그램의 *특성*을 변화시키지 않는다는 의미입니다. 결론적으로 컴파일 도중에는 타입 오류가 표출될 수 있지만, 타입 시스템 자체는 프로그램이 실행될 때 작동하는 방식과 관련이 없습니다. 마지막으로, TypeScript는 추가 런타임 라이브러리를 제공하지 않습니다. @@ -153,8 +153,8 @@ that this document is maintained.) 정답은 JavaScript를 배우지 않고선 TypeScript를 배울 수 없다는 것입니다! TypeScript는 JavaScript와 구문과 런타임 특성을 공유하므로, JavaScript에서 배운 모든 것들은 동시에 TypeScript를 배울 때 도움이 될 것입니다. -프로그래머들을 위한 JavaScript 학습 자원이 많습니다; TypeScript를 작성할 때 그런 학습 자원을 무시해선 _안됩니다_. -예를 들어 `javascript`태그가 붙은 질문이 `typescript`태그가 붙은 질문보다 약 20배는 많지만, _모든_ `javascript`질문은 TypeScript에도 적용할 수 있습니다. +프로그래머들을 위한 JavaScript 학습 자원이 많습니다; TypeScript를 작성할 때 그런 학습 자원을 무시해선 *안됩니다*. +예를 들어 `javascript`태그가 붙은 질문이 `typescript`태그가 붙은 질문보다 약 20배는 많지만, *모든* `javascript`질문은 TypeScript에도 적용할 수 있습니다. 만약 "TypeScript에서 리스트를 정렬하는 법"과 같은 것을 찾는 경우, 기억하세요: **TypeScript는 컴파일-타임 타입 검사자가 있는 JavaScript의 런타임입니다**. 리스트를 TypeScript에서 정렬하는 방법은 JavaScript에서 똑같은 방법으로 할 수 있습니다. diff --git a/docs/documentation/ko/handbook-v2/Basics.md b/docs/documentation/ko/handbook-v2/Basics.md index b9b42db5..6d408066 100644 --- a/docs/documentation/ko/handbook-v2/Basics.md +++ b/docs/documentation/ko/handbook-v2/Basics.md @@ -49,7 +49,7 @@ TypeError: message is not a function 이와 같은 실수를 미리 방지할 수 있다면 참 좋을 것 같습니다. -JavaScript 런타임은 코드가 실행될 때 자신이 무엇을 해야 할지 결정하기 위하여 값의 _타입_, 즉 해당 값이 어떤 동작과 능력을 가지고 있는지를 확인합니다. +JavaScript 런타임은 코드가 실행될 때 자신이 무엇을 해야 할지 결정하기 위하여 값의 *타입*, 즉 해당 값이 어떤 동작과 능력을 가지고 있는지를 확인합니다. 이것이 바로 `TypeError`가 암시하는 바입니다. 위 예시에서는 문자열인 `"Hello World"`가 함수로서 호출될 수 없다고 말하고 있는 것이죠. 일부 값들, 이를테면 `string`과 `number`과 같은 원시 타입의 값의 경우 `typeof` 연산자를 사용하면 각 값들의 타입을 실행 시점에 알 수 있습니다. @@ -62,28 +62,28 @@ function fn(x) { } ``` -위 코드를 보면, 인자로 전달된 객체가 호출 가능한 프로퍼티인 `flip`을 가져야만 위 함수가 잘 작동할 것이라는 것을 우리는 코드를 읽음으로써 _알 수 있습니다._ 하지만 JavaScript는 우리가 알고 있는 이러한 정보를 코드가 실행되는 동안 알지 못합니다. +위 코드를 보면, 인자로 전달된 객체가 호출 가능한 프로퍼티인 `flip`을 가져야만 위 함수가 잘 작동할 것이라는 것을 우리는 코드를 읽음으로써 *알 수 있습니다.* 하지만 JavaScript는 우리가 알고 있는 이러한 정보를 코드가 실행되는 동안 알지 못합니다. 순수 JavaScript에서 `fn`가 특정 값과 어떤 동작을 수행하는지 알 수 있는 유일한 방법은 호출하고 무슨 일이 벌어지는지 보는 것입니다. 이와 같은 동작은 코드 실행 전에 예측을 어렵게 만듭니다. 다시 말해 코드가 어떤 동작 결과를 보일지 코드를 작성하는 동안에는 알기 어렵습니다. -이런 측면에서 볼 때, _타입_이란 어떤 값이 `fn`으로 전달될 수 있고, 어떤 값은 실행에 실패할 것임을 설명하는 개념입니다. -JavaScript는 오직 _동적_ 타입만을 제공하며, 코드를 실행해야만 어떤 일이 벌어지는지 비로소 확인할 수 있습니다. +이런 측면에서 볼 때, *타입*이란 어떤 값이 `fn`으로 전달될 수 있고, 어떤 값은 실행에 실패할 것임을 설명하는 개념입니다. +JavaScript는 오직 *동적* 타입만을 제공하며, 코드를 실행해야만 어떤 일이 벌어지는지 비로소 확인할 수 있습니다. -이에 대한 대안은 _정적_ 타입 시스템을 사용하여 코드가 실행되기 _전에_ 코드에 대하여 예측하는 것입니다. +이에 대한 대안은 *정적* 타입 시스템을 사용하여 코드가 실행되기 *전에* 코드에 대하여 예측하는 것입니다. ## 정적 타입 검사 앞서 살펴본, `string`을 함수로서 호출하고자 했을 때 얻은 `TypeError`의 이야기로 돌아가 봅시다. -_대부분의 사람들은_ 코드를 실행했을 때 오류를 보고 싶지 않습니다. 그것은 버그로 여겨집니다! +*대부분의 사람들은* 코드를 실행했을 때 오류를 보고 싶지 않습니다. 그것은 버그로 여겨집니다! 그리고 새로운 코드를 작성할 때 우리는 새로운 버그를 만들어내지 않도록 최선을 다합니다. 여기서 만약 약간의 코드를 추가하고 파일을 저장한 뒤, 코드를 다시 실행했을 때 바로 오류가 확인된다면, 문제를 신속하게 격리시킬 수 있을 것입니다. 하지만 항상 그렇게 되는 것은 아닙니다. 기능을 충분히 테스트하지 않아서, 잠재적인 오류를 미처 발견하지 못할 수도 있습니다! 또는 운 좋게 오류를 발견했더라도, 결국 상당한 규모의 리팩토링을 거치고 새 코드를 추가하면서 의도치 않게 코드를 깊게 파헤치게 될 수도 있습니다. -이상적으로는, 코드를 실행하기 _전에_ 이러한 버그를 미리 발견할 수 있는 도구가 있다면 좋을 것입니다. +이상적으로는, 코드를 실행하기 *전에* 이러한 버그를 미리 발견할 수 있는 도구가 있다면 좋을 것입니다. TypeScript와 같은 정적 타입 검사기의 역할이 바로 그것입니다. -_정적 타입 시스템_은 우리가 작성한 프로그램에서 사용된 값들의 형태와 동작을 설명합니다. +*정적 타입 시스템*은 우리가 작성한 프로그램에서 사용된 값들의 형태와 동작을 설명합니다. TypeScript와 같은 타입 검사기는 이 정보를 활용하여 프로그램이 제대로 작동하지 않을 때 우리에게 알려줍니다. ```ts twoslash @@ -127,7 +127,7 @@ user.location; ``` 비록 때로는 이로 인하여 표현의 유연성을 희생해야 하겠지만, 이렇게 함으로서 명시적인 버그는 아니지만 버그로 타당히 간주되는 경우를 잡아내는 데에 그 목적이 있습니다. -그리고 TypeScript는 이러한 겉으로 드러나지 않는 버그를 _꽤 많이_ 잡아냅니다. +그리고 TypeScript는 이러한 겉으로 드러나지 않는 버그를 *꽤 많이* 잡아냅니다. 예를 들어, 오타, @@ -169,10 +169,10 @@ if (value !== "a") { ## 프로그래밍 도구로서의 타입 TypeScript는 우리가 코드 상에서 실수를 저질렀을 때 버그를 잡아줍니다. -그거 좋죠, 그런데 TypeScript는 _여기서 더 나아가서_ 우리가 실수를 저지르는 바로 그 순간 이를 막아줍니다. +그거 좋죠, 그런데 TypeScript는 *여기서 더 나아가서* 우리가 실수를 저지르는 바로 그 순간 이를 막아줍니다. 타입 검사기는 우리가 변수 또는 다른 프로퍼티 상의 올바른 프로퍼티에 접근하고 있는지 여부를 검사할 수 있도록 관련 정보들을 가지고 있습니다. -이 정보를 활용하면 타입 검사기는 우리가 사용할 수 있는 프로퍼티를 _제안_할 수 있게 됩니다. +이 정보를 활용하면 타입 검사기는 우리가 사용할 수 있는 프로퍼티를 *제안*할 수 있게 됩니다. 즉, TypeScript는 코드 수정에 활용될 수 있고, 우리가 코드를 입력할 때 오류 메시지를 제공하거나 코드 완성 기능을 제공할 수 있습니다. 이는 TypeScript에서 도구(Tooling)를 논할 때에 흔히 언급되는 내용입니다. @@ -198,7 +198,7 @@ TypeScript를 지원하는 코드 편집기는 오류를 자동으로 고쳐주 ## `tsc`, TypeScript 컴파일러 -지금까지 계속 타입 검사에 대하여 이야기했지만, 아직 타입 _검사기_를 사용하지 않았습니다. +지금까지 계속 타입 검사에 대하여 이야기했지만, 아직 타입 *검사기*를 사용하지 않았습니다. 우리의 새로운 친구 `tsc`, TypeScript 컴파일러와 첫인사를 나누도록 합시다. 우선, npm을 사용하여 설치하도록 하겠습니다. @@ -225,13 +225,13 @@ tsc hello.ts 짜잔! -잠깐, 정확히 _무엇_이 "짜잔"하고 나왔다는 것이죠? +잠깐, 정확히 *무엇*이 "짜잔"하고 나왔다는 것이죠? `tsc`를 실행했지만 아무 일도 일어나지 않았습니다! 뭐, 타입 오류가 없었으니, 아무것도 보고될 것이 없고 그래서 콘솔에도 아무런 출력이 나타나지 않았습니다. -하지만 다시 확인해보면, 우리는 그 대신 _파일_ 출력을 얻었습니다. +하지만 다시 확인해보면, 우리는 그 대신 *파일* 출력을 얻었습니다. 현재 디렉토리를 보면, `hello.ts` 파일 옆에 `hello.js` 파일이 있는 것을 볼 수 있습니다. -이것이 `tsc`가 우리의 `hello.ts` 파일을 JavaScript 파일로 _컴파일_ 또는 _변형_한 결과물입니다. +이것이 `tsc`가 우리의 `hello.ts` 파일을 JavaScript 파일로 *컴파일* 또는 *변형*한 결과물입니다. 그리고 그 내용을 확인해보면, TypeScript가 `.ts` 파일을 처리한 뒤 뱉어낸 내용을 확인할 수 있습니다. ```js @@ -243,7 +243,7 @@ console.log("Hello world!"); 컴파일러는 사람이 작성한 듯이 깔끔하고 읽을 수 있는 코드를 만들어내고자 시도합니다. 물론 그것이 항상 쉬운 것은 아니지만, TypeScript는 일관성 있게 들여 쓰기를 수행하고, 여러 줄에 걸쳐 코드가 작성되는 것을 감안하고, 코드 주변에 작성된 주석도 잘 배치해둡니다. -만약 타입 검사 오류가 _주어지면_ 어떨까요? +만약 타입 검사 오류가 *주어지면* 어떨까요? `hello.ts`를 다시 작성해보겠습니다. ```ts twoslash @@ -301,7 +301,7 @@ function greet(person: string, date: Date) { } ``` -방금 우리는 `person`과 `date`에 대하여 _타입 표기_를 수행하여 `greet`가 호출될 때 함께 사용될 수 있는 값들의 타입을 설명했습니다. +방금 우리는 `person`과 `date`에 대하여 *타입 표기*를 수행하여 `greet`가 호출될 때 함께 사용될 수 있는 값들의 타입을 설명했습니다. 해당 시그니처는 "`greet`는 `string` 타입의 `person`과 `Date` 타입의 `date`을 가진다"고 해석할 수 있습니다. 이것이 있다면, TypeScript는 우리가 해당 함수를 올바르지 못하게 사용했을 경우 이를 알려줄 수 있게 됩니다. @@ -333,7 +333,7 @@ greet("Maddison", new Date()); ``` 명시적인 타입 표기를 항상 작성할 필요는 없다는 것을 꼭 기억해두세요. -많은 경우, TypeScript는 생략된 타입 정보를 _추론할 수_ (또는 "알아낼 수") 있습니다. +많은 경우, TypeScript는 생략된 타입 정보를 *추론할 수* (또는 "알아낼 수") 있습니다. ```ts twoslash let msg = "hello there!"; @@ -387,9 +387,9 @@ greet("Maddison", new Date()); 왜 이러한 일이 생겼을까요? -템플릿 문자열은 ECMAScript 2015(a.k.a. ECMAScript 6, ES2015, ES6, 등. _더 묻지 마세요_)라고 불리는 버전의 ECMAScript에서 등장한 기능입니다. +템플릿 문자열은 ECMAScript 2015(a.k.a. ECMAScript 6, ES2015, ES6, 등. *더 묻지 마세요*)라고 불리는 버전의 ECMAScript에서 등장한 기능입니다. TypeScript는 새 버전의 ECMAScript의 코드를 ECMAScript 3 또는 ECMAScript 5와 같은 보다 예전 버전의 것들로 다시 작성해 줍니다. -새로운 또는 "상위" 버전의 ECMAScript를 예전의 또는 "하위" 버전의 것으로 바꾸는 과정을 _다운레벨링_이라 부르기도 합니다. +새로운 또는 "상위" 버전의 ECMAScript를 예전의 또는 "하위" 버전의 것으로 바꾸는 과정을 *다운레벨링*이라 부르기도 합니다. TypeScript는 ES3라는 아주 구버전의 ECMAScript를 타겟으로 동작하는 것이 기본 동작입니다. `--target` 플래그를 설정하면 보다 최근 버전을 타겟으로 변환을 수행할 수도 있습니다. @@ -437,4 +437,4 @@ CLI에서 `--strict` 플래그를 설정하거나 [`tsconfig.json`](https://www. `null`과 `undefined`와 같은 값은 다른 타입의 값에 할당할 수 있는 것이 기본 동작입니다. 이는 코드 작성을 쉽게 만들어주지만, `null`과 `undefined`의 처리를 잊는 것은 세상의 셀 수 없이 많은 버그들의 원인입니다. 혹자는 이를 [백만 불 짜리 실수](https://www.youtube.com/watch?v=ybrQvs4x0Ps)라고 일컫기도 합니다! -`strictNullChecks` 플래그는 `null`과 `undefined`를 보다 명시적으로 처리하며, `null` 및 `undefined` 처리를 _잊었는지_ 여부를 걱정하는 데에서 우리를 _해방시켜_ 줍니다. +`strictNullChecks` 플래그는 `null`과 `undefined`를 보다 명시적으로 처리하며, `null` 및 `undefined` 처리를 *잊었는지* 여부를 걱정하는 데에서 우리를 *해방시켜* 줍니다. diff --git a/docs/documentation/ko/handbook-v2/Type Manipulation/Conditional Types.md b/docs/documentation/ko/handbook-v2/Type Manipulation/Conditional Types.md index 7372fd5f..49192e56 100644 --- a/docs/documentation/ko/handbook-v2/Type Manipulation/Conditional Types.md +++ b/docs/documentation/ko/handbook-v2/Type Manipulation/Conditional Types.md @@ -7,7 +7,7 @@ oneline: "타입 시스템에서 if문 처럼 동작하는 타입 생성하기." 대부분 유용한 프로그램의 핵심은, 입력에 따라 출력이 결정되어야 한다는 것입니다. JavaScript 프로그램도 크게 다르진 않지만, 값의 타입을 쉽게 검사할 수 있다는 사실을 고려할 때, 출력에 대한 결정은 또한 입력의 타입에도 기반합니다. -_조건부 타입_ 은 입력과 출력 타입간의 관계를 설명하는 데 도움을 줄 수 있습니다. +*조건부 타입* 은 입력과 출력 타입간의 관계를 설명하는 데 도움을 줄 수 있습니다. ```ts twoslash interface Animal { @@ -62,7 +62,7 @@ function createLabel(nameOrId: string | number): IdLabel | NameLabel { createLabel의 오버로드들은 입력 타입에 따른 단일 JavaScript 함수를 나타냅니다. 다음을 주목하세요. 1. 만약 라이브러리가 매번 API 전체에서 비슷한 종류의 함수를 만들어야 한다면 번거로워집니다. -2. 우린 3가지 오버로드 즉, 각 케이스별로 _확실한_ 타입을 가지거나 (각각 `number`와 `string`) 그리고 일반적인 케이스(`string | number`) 가져야 합니다. `createLabel`의 새로운 타입을 다루기 위해선 오버로드의 수는 기하급수적으로 증가합니다. +2. 우린 3가지 오버로드 즉, 각 케이스별로 *확실한* 타입을 가지거나 (각각 `number`와 `string`) 그리고 일반적인 케이스(`string | number`) 가져야 합니다. `createLabel`의 새로운 타입을 다루기 위해선 오버로드의 수는 기하급수적으로 증가합니다. 대신에 조건부 타입으로 로직을 인코딩할 수 있습니다. @@ -153,7 +153,7 @@ type DogMessageContents = MessageOf; // ^? ``` -"참"값 분기내에서는 TypeScript는 `T`가 `message` 프로퍼티를 가지고 _있을 것을_ 알 수 있습니다. +"참"값 분기내에서는 TypeScript는 `T`가 `message` 프로퍼티를 가지고 *있을 것을* 알 수 있습니다. 또 다른 예제에서 배열 타입이면 배열의 개별 요소 타입으로 평탄화 시키지만, 배열 타입이 아니면 그대로 유지하는 `Flatten` 타입을 만들 수 있습니다. @@ -205,7 +205,7 @@ type Bools = GetReturnType<(a: boolean, b: boolean) => boolean[]>; // ^? ``` -여러 호출 시그니처 (오버로트 함수 타입 같이)를 가진 타입을 추론할 때, _마지막_ 시그니처 (아마, 모든 케이스에 허용되는)로 추론하게 됩니다. 인자 타입의 목록에 기반해서 오버로드들을 처리할 수는 없습니다. +여러 호출 시그니처 (오버로트 함수 타입 같이)를 가진 타입을 추론할 때, *마지막* 시그니처 (아마, 모든 케이스에 허용되는)로 추론하게 됩니다. 인자 타입의 목록에 기반해서 오버로드들을 처리할 수는 없습니다. ```ts twoslash declare function stringOrNum(x: string): number; @@ -218,7 +218,7 @@ type T1 = ReturnType; ## 분산적인 조건부 타입 -제네릭 타입 위에서 조건부 타입은 유니언 타입을 만나면 _분산적으로_ 동작합니다. +제네릭 타입 위에서 조건부 타입은 유니언 타입을 만나면 *분산적으로* 동작합니다. 예를 들어 다음을 보겠습니다. ```ts twoslash diff --git a/docs/documentation/ko/handbook-v2/Understanding Errors.md b/docs/documentation/ko/handbook-v2/Understanding Errors.md index c86b6eca..91884b5d 100644 --- a/docs/documentation/ko/handbook-v2/Understanding Errors.md +++ b/docs/documentation/ko/handbook-v2/Understanding Errors.md @@ -14,17 +14,17 @@ TypeScript의 타입 시스템은 구조적이기 때문에, 문제를 발견한 오류 메시지에서 자주 등장하는 용어를 알면 이해하는 데 도움이 됩니다. -#### _할당할 수 있는_ (_assignable to_) +#### *할당할 수 있는* (*assignable to*) -TypeScript는 타입이 다른 타입으로 대체할 수 있을 때 타입을 다른 타입에 _할당할 수_ 있다 라고 표현합니다. -다시 말해 `고양이`는 `동물`을 대체할 수 있기 때문에 `동물`에게 _할당할 수_ 있습니다. +TypeScript는 타입이 다른 타입으로 대체할 수 있을 때 타입을 다른 타입에 *할당할 수* 있다 라고 표현합니다. +다시 말해 `고양이`는 `동물`을 대체할 수 있기 때문에 `동물`에게 *할당할 수* 있습니다. 이름에서 보이듯, 이런 관계는 `t`와 `s`의 타입을 검사하여 `t = s;`의 할당 타당성을 확인하는 데 사용됩니다. 또한 두 가지 타입이 상호 작용하는 대부분의 위치에서 확인할 때에도 사용됩니다. -예를 들어, 함수를 호출할 때 각 인수의 타입은 매개 변수로 선언된 유형에 _할당할 수_ 있어야 합니다. +예를 들어, 함수를 호출할 때 각 인수의 타입은 매개 변수로 선언된 유형에 *할당할 수* 있어야 합니다. -비공식적으로 `T is not assignable to S`라고 하면 TypeScript는 "_`T`와 `S`는 호환되지 않는다"_.고 말한다고 생각하면됩니다. -그러나, 이것은 _방향성이 있는_ 관계라는 점에 유의하세요: `S`가 `T`에 할당될 수 있다고 해서 `T`가 `S`에 할당될 수 있는 것은 아닙니다. +비공식적으로 `T is not assignable to S`라고 하면 TypeScript는 "*`T`와 `S`는 호환되지 않는다"*.고 말한다고 생각하면됩니다. +그러나, 이것은 *방향성이 있는* 관계라는 점에 유의하세요: `S`가 `T`에 할당될 수 있다고 해서 `T`가 `S`에 할당될 수 있는 것은 아닙니다. ## 예시들 (Examples) diff --git a/docs/documentation/ko/project-config/Configuring Watch.md b/docs/documentation/ko/project-config/Configuring Watch.md index 127bf2ec..fe1ec592 100644 --- a/docs/documentation/ko/project-config/Configuring Watch.md +++ b/docs/documentation/ko/project-config/Configuring Watch.md @@ -45,7 +45,7 @@ translatable: true You can read more about this in [the release notes](/docs/handbook/release-notes/typescript-3-8.html#better-directory-watching-on-linux-and-watchoptions). -## 환경 변수 `TSC_WATCHFILE`을 사용하여 파일 감시 설정 (Configuring file watching using environment variable `TSC_WATCHFILE`) +## 환경 변수 `TSC*WATCHFILE`을 사용하여 파일 감시 설정 (Configuring file watching using environment variable `TSC*WATCHFILE`) 옵션 | 설명 @@ -55,11 +55,11 @@ You can read more about this in [the release notes](/docs/handbook/release-notes `UseFsEvents` | 파일 시스템 이벤트를 사용하는 `fs.watch`를 사용하여 파일 변경/생성/삭제에 대한 알림을 받습니다. (`fs.watch`는 OS마다 다르게 작동할 수 있습니다.) 예를 들어. 리눅스는 watcher 수에 제한이 있으며 `fs.watch`를 사용하여 watcher를 만들지 못하면, `fs.watchFile`를 대신 사용하여 watcher를 만들게 됩니다. `UseFsEventsWithFallbackDynamicPolling` | 이 옵션은 `fs.watch`를 사용하여 감시자를 만들지 못한 경우 폴링이 동적 큐를 통해 수행된다는 것을 제외하고는 `UseFsEvents` 옵션과 비슷합니다.(동적 큐에 대한 것은 `DynamicPriorityPolling`옵션에서 설명하였습니다.). `UseFsEventsOnParentDirectory` | 이 옵션은 `fs.watch`(파일 시스템 이벤트 사용하는)로 파일의 상위 디렉터리를 감시합니다. 다만, CPU 사용량이 늘어나고 정확도는 떨어질 수 있습니다. -default (no value specified) | 환경 변수`TSC_NONPOLLING_WATCHER`가 true로 설정되면 파일의 상위 디렉터리를 감시합니다. (`UseFsEventsOnParentDirectory`와 동일).false 일 때는 `fs.watchFile`을 사용하여 `250ms` 시간 제한과 함께 모든 파일들을 감시합니다. +default (no value specified) | 환경 변수`TSC*NONPOLLING*WATCHER`가 true로 설정되면 파일의 상위 디렉터리를 감시합니다. (`UseFsEventsOnParentDirectory`와 동일).false 일 때는 `fs.watchFile`을 사용하여 `250ms` 시간 제한과 함께 모든 파일들을 감시합니다. -## 환경 변수`TSC_WATCHDIRECTORY`를 사용하여 디렉터리 감시 설정 (Configuring directory watching using environment variable `TSC_WATCHDIRECTORY`) +## 환경 변수`TSC*WATCHDIRECTORY`를 사용하여 디렉터리 감시 설정 (Configuring directory watching using environment variable `TSC*WATCHDIRECTORY`) -기본적으로 node에서 디렉터리의 재귀적인 감시를 지원하지 않는 플랫폼에서, 디렉터리 감시 기능은 `TSC_WATCHDIRECTORY`에서 선택한 다양한 옵션을 사용하여 하위 디렉터리에 대한 디렉터리 watcher를 재귀적으로 생성함으로써 지원됩니다. 기본적으로 재귀 디렉터리 감시(예: windows)를 지원하는 플랫폼에서는 이 환경 변수의 값이 무시됩니다. +기본적으로 node에서 디렉터리의 재귀적인 감시를 지원하지 않는 플랫폼에서, 디렉터리 감시 기능은 `TSC*WATCHDIRECTORY`에서 선택한 다양한 옵션을 사용하여 하위 디렉터리에 대한 디렉터리 watcher를 재귀적으로 생성함으로써 지원됩니다. 기본적으로 재귀 디렉터리 감시(예: windows)를 지원하는 플랫폼에서는 이 환경 변수의 값이 무시됩니다. 옵션 | 설명 diff --git a/docs/documentation/ko/project-config/Integrating with Build Tools.md b/docs/documentation/ko/project-config/Integrating with Build Tools.md index 842c7286..f5be39b2 100644 --- a/docs/documentation/ko/project-config/Integrating with Build Tools.md +++ b/docs/documentation/ko/project-config/Integrating with Build Tools.md @@ -182,7 +182,7 @@ gulp.task("default", function () { npm install -g jspm@beta ``` -_주의사항: 현재 jspm의 TypeScript 지원은 0.16beta 입니다._ +*주의사항: 현재 jspm의 TypeScript 지원은 0.16beta 입니다.* 자세한 내용: [TypeScriptSamples/jspm](https://github.com/Microsoft/TypeScriptSamples/tree/master/jspm) diff --git a/docs/documentation/ko/reference/Declaration Merging.md b/docs/documentation/ko/reference/Declaration Merging.md index db742ded..8b2cee96 100644 --- a/docs/documentation/ko/reference/Declaration Merging.md +++ b/docs/documentation/ko/reference/Declaration Merging.md @@ -92,7 +92,7 @@ interface Cloner { 각 그룹의 요소는 동일한 순서를 유지하지만, 그룹 자체는 나중에 오버로드 될수록 첫 번째에 위치하는 것에 유의하세요. 이 규칙엔 특수 시그니처(specialized signatures)라는 예외가 존재합니다. -만약 _단일_ 문자열 리터럴 타입(예. 문자열 리터럴이 유니온이 아닌 경우)인 매개변수가 있을 경우, 시그니처는 병합된 오버로드 목록의 맨 위로 올라오게 됩니다. +만약 *단일* 문자열 리터럴 타입(예. 문자열 리터럴이 유니온이 아닌 경우)인 매개변수가 있을 경우, 시그니처는 병합된 오버로드 목록의 맨 위로 올라오게 됩니다. 예를 들어, 아래의 인터페이스들이 병합됩니다: diff --git a/docs/documentation/ko/reference/Decorators.md b/docs/documentation/ko/reference/Decorators.md index fb857f99..5f36347f 100644 --- a/docs/documentation/ko/reference/Decorators.md +++ b/docs/documentation/ko/reference/Decorators.md @@ -214,7 +214,7 @@ const bug = new BugReport("Needs dark mode"); console.log(bug.title); // Prints "Needs dark mode" console.log(bug.type); // Prints "report" -// Note that the decorator _does not_ change the TypeScript type +// Note that the decorator *does not* change the TypeScript type // and so the new property `reportingURL` is not known // to the type system: bug.reportingURL; diff --git a/docs/documentation/ko/reference/Iterators and Generators.md b/docs/documentation/ko/reference/Iterators and Generators.md index eced3fa0..e5413b34 100644 --- a/docs/documentation/ko/reference/Iterators and Generators.md +++ b/docs/documentation/ko/reference/Iterators and Generators.md @@ -27,7 +27,7 @@ for (let entry of someArray) { ### `for..of` vs. `for..in`문 -`for..of`와 `for..in`문은 모두 리스트를 반복하지만 반복하는 값이 다릅니다. `for..in`은 반복하는 객체의 _키_ 리스트를 반환하지만 `for..of`는 반복하는 객체의 숫자 프로퍼티인 _값_ 리스트를 반환합니다. +`for..of`와 `for..in`문은 모두 리스트를 반복하지만 반복하는 값이 다릅니다. `for..in`은 반복하는 객체의 *키* 리스트를 반환하지만 `for..of`는 반복하는 객체의 숫자 프로퍼티인 *값* 리스트를 반환합니다. 다음은 이러한 차이를 보여주는 예시입니다: diff --git a/docs/documentation/ko/reference/JSX.md b/docs/documentation/ko/reference/JSX.md index 8e4096df..66796fb4 100644 --- a/docs/documentation/ko/reference/JSX.md +++ b/docs/documentation/ko/reference/JSX.md @@ -65,7 +65,7 @@ JSX를 통한 타입 검사를 이해하기 위해서는 먼저 내장 요소와 1. React에서 내장 요소는 문자열 (`React.createElement("div")`)로 방출되지만 생성한 구성 요소는 (`React.createElement(MyComponent)`)가 아닙니다. 2. JSX 요소에 전달되는 속성의 타입은 다르게 조회되어야 합니다. - 내장 요소의 속성은 _내재적으로_ 알려져야 하지만, 컴포넌트는 각자의 속성 집합을 지정하고자 합니다. + 내장 요소의 속성은 *내재적으로* 알려져야 하지만, 컴포넌트는 각자의 속성 집합을 지정하고자 합니다. TypeScript는 이를 구분하기 위해 [React와 같은 규칙](http://facebook.github.io/react/docs/jsx-in-depth.html#html-tags-vs.-react-components)을 사용합니다. 내장 요소는 항상 소문자로 시작하고, 값-기반 요소는 항상 대문자로 시작합니다. @@ -74,7 +74,7 @@ TypeScript는 이를 구분하기 위해 [React와 같은 규칙](http://faceboo 내장 요소는 특별한 인터페이스인 `JSX.IntrinsicElements`에서 조회됩니다. 기본적으로 인터페이스가 지정되지 않으면 그대로 진행되어 내장 함수는 타입 검사가 이루어지지 않을 것입니다. -그러나 이 인터페이스가 _있는_ 경우 내장 함수의 이름이 `JSX.IntrinsicElements` 인터페이스에 있는 프로퍼티로 조회됩니다. +그러나 이 인터페이스가 *있는* 경우 내장 함수의 이름이 `JSX.IntrinsicElements` 인터페이스에 있는 프로퍼티로 조회됩니다. 예를 들어: ```ts @@ -166,9 +166,9 @@ function MainButton(prop: SideProps): JSX.Element { ### 클래스형 컴포넌트 클래스형 컴포넌트 타입을 정의하는 것도 가능합니다. -하지만 이를 위해서는 _요소 클래스 타입(element class type)_ 과 _요소 인스턴스 타입(element instance type)_이라는 두 가지 용어를 이해하는 것이 좋습니다. +하지만 이를 위해서는 *요소 클래스 타입(element class type)* 과 *요소 인스턴스 타입(element instance type)*이라는 두 가지 용어를 이해하는 것이 좋습니다. -``가 주어지면, _요소 클래스 타입_은 `Expr`타입입니다. +``가 주어지면, *요소 클래스 타입*은 `Expr`타입입니다. 따라서 위의 예시에서 `MyComponent`가 ES6 클래스인 경우, 해당 클래스의 타입은 클래스의 생성자이고 전역입니다. 만약 `MyComponent`가 팩토리 함수인 경우, 해당 클래스의 타입은 해당 함수입니다. @@ -230,7 +230,7 @@ function NotAValidFactoryFunction() { ## 속성 타입 검사 -속성 타입 검사를 위해서는 먼저 _요소 속성 타입_을 결정해야 합니다. +속성 타입 검사를 위해서는 먼저 *요소 속성 타입*을 결정해야 합니다. 이는 내장 요소와 값-기반 요소에서 약간의 차이가 있습니다. 내장 요소의 경우, 요소 속성 타입은 `JSX.IntrinsicElements` 내 프로퍼티의 타입입니다. @@ -247,7 +247,7 @@ declare namespace JSX { ``` 값-기반 요소의 경우, 이는 약간 더 복잡합니다. -요소 속성 타입은 이전에 결정된 _요소 인스턴스 타입_ 의 프로퍼티 타입으로 결정됩니다. +요소 속성 타입은 이전에 결정된 *요소 인스턴스 타입* 의 프로퍼티 타입으로 결정됩니다. 사용할 프로퍼티는 `JSX.ElementAttributesProperty`에 의해 결정됩니다. 이는 단일 프로퍼티로 선언되어야 합니다. 이후에는 해당 프로퍼티의 이름을 사용합니다. @@ -305,8 +305,8 @@ var badProps = {}; ## 자식 타입 검사 -TypeScript 2.3부터, TS는 _자식(children)_ 타입 검사를 도입했습니다. _자식_은 자식 _JSXExpressions_이 속성에 삽입하고자 하는 _요소 속성 타입_의 특수 프로퍼티입니다. -TS가 _props_ 명을 결정하기 위해 `JSX.ElementAttributesProperty`를 사용하는 것과 유사하게, TS는 _자식_ 내의 props명을 결정하기 위하여 `JSX.ElementChildrenAttribute`를 사용합니다. +TypeScript 2.3부터, TS는 *자식(children)* 타입 검사를 도입했습니다. *자식*은 자식 *JSXExpressions*이 속성에 삽입하고자 하는 *요소 속성 타입*의 특수 프로퍼티입니다. +TS가 *props* 명을 결정하기 위해 `JSX.ElementAttributesProperty`를 사용하는 것과 유사하게, TS는 *자식* 내의 props명을 결정하기 위하여 `JSX.ElementChildrenAttribute`를 사용합니다. `JSX.ElementChildrenAttribute` 는 단일 프로퍼티로 정의되어야만 합니다. ```ts @@ -334,7 +334,7 @@ const CustomComp = (props) =>
{props.children}
``` -다른 속성과 같이_자식_의 타입도 지정할 수 있습니다. 예를 들어서 [React 타이핑](https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/react)을 사용하는 경우, 이는 기본 타입을 오버라이드 할 것입니다. +다른 속성과 같이*자식*의 타입도 지정할 수 있습니다. 예를 들어서 [React 타이핑](https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/react)을 사용하는 경우, 이는 기본 타입을 오버라이드 할 것입니다. ```ts interface PropsType { diff --git a/docs/documentation/ko/reference/Namespaces and Modules.md b/docs/documentation/ko/reference/Namespaces and Modules.md index 3030e8ea..a9b7d858 100644 --- a/docs/documentation/ko/reference/Namespaces and Modules.md +++ b/docs/documentation/ko/reference/Namespaces and Modules.md @@ -12,7 +12,7 @@ translatable: true ES 모듈에 대한 자세한 내용은 [모듈](./modules.md) 문서를 참고하세요. TypeScript 네임스페이스에 대한 자세한 내용은 [네임스페이스](./namespaces.md) 문서를 참고하세요. -참고: _매우_ 오래된 버전의 TypeScript 네임스페이스는 이전의 JavaScript 모듈 시스템인 '내부 모듈'이라고 불렸습니다. +참고: *매우* 오래된 버전의 TypeScript 네임스페이스는 이전의 JavaScript 모듈 시스템인 '내부 모듈'이라고 불렸습니다. # 모듈 사용하기 (Using Modules) diff --git a/docs/documentation/ko/reference/Triple-Slash Directives.md b/docs/documentation/ko/reference/Triple-Slash Directives.md index d202f662..0d556359 100644 --- a/docs/documentation/ko/reference/Triple-Slash Directives.md +++ b/docs/documentation/ko/reference/Triple-Slash Directives.md @@ -16,7 +16,7 @@ translatable: true ## `/// ` `/// `지시어는 가장 일반적인 트리플-슬래시 지시어입니다. - 이 지시어는 파일 간의 _의존성_ 선언으로 사용됩니다. + 이 지시어는 파일 간의 *의존성* 선언으로 사용됩니다. 트리플-슬래시 참조는 컴파일러에게 추가 파일을 컴파일 과정에 포함할 것을 지시합니다. @@ -28,7 +28,7 @@ translatable: true 컴파일러는 모든 트리플-슬래시 참조 지시어를 분석하기 위해 입력 파일에 대해 전처리를 수행합니다. 이 과정 동안, 추가 파일이 컴파일에 추가됩니다. -이 과정은 _root files_ 집합에서 시작됩니다; +이 과정은 *root files* 집합에서 시작됩니다; 이 루트 파일은 명령 줄이나 `tsconfig.json`파일의 `"files"` 목록에 있는 파일 이름입니다. 이러한 파일은 지정된 순서대로 전처리됩니다. 목록에 파일을 추가하기 전에, 파일에 있는 모든 트리플-슬래시 참조가 처리되고, 그 대상들이 포함됩니다. @@ -47,7 +47,7 @@ translatable: true ## `/// ` -_의존성_ 선언 역할을 하는 `/// ` 지시어와 유사하게, `/// ` 지시어는 패키지의 의존성을 선언합니다. +*의존성* 선언 역할을 하는 `/// ` 지시어와 유사하게, `/// ` 지시어는 패키지의 의존성을 선언합니다. 패키지 이름을 처리하는 과정은 `import`문에서 모듈 이름을 처리하는 과정과 유사합니다. 트리플-슬래시-참조-타입 지시어를 선언 패키지의 `import`로 생각하면 이해하기 쉽습니다. @@ -65,9 +65,9 @@ _의존성_ 선언 역할을 하는 `/// ` 지시어와 ## `/// ` -이 지시어는 파일이 명시적으로 기존 내장 _lib_ 파일을 포함하게 합니다.. +이 지시어는 파일이 명시적으로 기존 내장 *lib* 파일을 포함하게 합니다.. -내장 _lib_ 파일은 _tsconfig.json_의 `"lib"` 컴파일러 옵션과 같은 방식으로 참조됩니다 (예.`lib="lib.es2015.d.ts"` 가 아닌 `lib="es2015"` 사용 등). +내장 *lib* 파일은 *tsconfig.json*의 `"lib"` 컴파일러 옵션과 같은 방식으로 참조됩니다 (예.`lib="lib.es2015.d.ts"` 가 아닌 `lib="es2015"` 사용 등). 내장 타입에 의존하는 선언 파일 작성자에게는 트리플-슬래시-참조 lib 지시어를 사용하는 것이 권장됩니다(내장 타입 : DOM APIs 또는 `Symbol`이나 `Iterable`과 같은 내장 JS 런-타임 생성자) 이전에는 이런 .d.ts 파일은 이러한 타입의 전달/중복 선언을 추가했어야 한다. @@ -81,10 +81,10 @@ _의존성_ 선언 역할을 하는 `/// ` 지시어와 ## `/// ` -이 지시어는 파일을 _기본 라이브러리_라고 표시합니다. +이 지시어는 파일을 *기본 라이브러리*라고 표시합니다. `lib.d.ts`와 이를 변형한 것들의 맨 상단에서 볼 수 있습니다. -이 지시어는 컴파일러 기본 라이브러리(예. `lib.d.ts`) 를 컴파일에 포함시키지 _않도록_ 지시합니다. +이 지시어는 컴파일러 기본 라이브러리(예. `lib.d.ts`) 를 컴파일에 포함시키지 *않도록* 지시합니다. 명령 줄에 `--noLib`을 넘겨주는 것과 비슷한 영향을 줍니다. 또한 `--skipDefaultLibCheck`를 넘겨주면, 컴파일러가 `/// `을 갖는 파일은 검사하지 않는다는 것을 유의하세요. diff --git a/docs/documentation/ko/release-notes/TypeScript 4.0.md b/docs/documentation/ko/release-notes/TypeScript 4.0.md index b1ef23cb..2ec56484 100644 --- a/docs/documentation/ko/release-notes/TypeScript 4.0.md +++ b/docs/documentation/ko/release-notes/TypeScript 4.0.md @@ -340,7 +340,7 @@ class Square { ## 단축 할당 연산자 (Short-Circuiting Assignment Operators) -JavaScript와 많은 언어는 _복합 할당 (compound assignment)_ 연산자라고 불리는 연산자 집합을 지원합니다. +JavaScript와 많은 언어는 *복합 할당 (compound assignment)* 연산자라고 불리는 연산자 집합을 지원합니다. 복합 할당 연산자는 두 개의 인수에 연산자를 적용한 다음 결과를 왼쪽에 할당합니다. 이전에 아래와 같은 것을 본 적이 있을 것입니다: @@ -371,7 +371,7 @@ a <<= b; ``` JavaScript의 많은 연산자에 위와 같은 할당 연산자가 있습니다! -그러나 최근까지도 논리 _and_ 연산자 (`&&`), 논리 _or_ 연산자 (`||`) 및 null과 같은 것을 병합하는 연산자 (nullish coalescing) (`??`)의 세 가지 주목할만한 예외가 있었습니다. +그러나 최근까지도 논리 *and* 연산자 (`&&`), 논리 *or* 연산자 (`||`) 및 null과 같은 것을 병합하는 연산자 (nullish coalescing) (`??`)의 세 가지 주목할만한 예외가 있었습니다. 이것이 TypeScript 4.0이 새로운 할당 연산자`&&=`,`||=`및`??=`를 추가하는 새로운 ECMAScript 기능을 지원하는 이유입니다. @@ -402,7 +402,7 @@ let values: string[]; (values ??= []).push("hello"); ``` -(보세요, 우리가 작성한 _모든_ 코드가 자랑스러운 것은 아닙니다...) +(보세요, 우리가 작성한 *모든* 코드가 자랑스러운 것은 아닙니다...) 드물지만 부수 효과(side-effects)가 있는 getter 또는 setter를 사용하는 경우 이러한 연산자가 필요한 경우에만 할당을 수행한다는 점에 유의할 필요가 있습니다. 그런 의미에서 연산자의 오른쪽이 "단축 (short-circuited)"될 뿐만 아니라 할당 자체도 마찬가지입니다. @@ -419,7 +419,7 @@ if (!obj.prop) { } ``` -[다음 예시를 실행해보세요](https://www.typescriptlang.org/play?ts=Nightly#code/MYewdgzgLgBCBGArGBeGBvAsAKBnmA5gKawAOATiKQBQCUGO+TMokIANkQHTsgHUAiYlChFyMABYBDCDHIBXMANoBuHI2Z4A9FpgAlIqXZTgRGAFsiAQg2byJeeTAwAslKgSu5KWAAmIczoYAB4YAAYuAFY1XHwAXwAaWxgIEhgKKmoAfQA3KXYALhh4EA4iH3osWM1WCDKePkFUkTFJGTlFZRimOJw4mJwAM0VgKABLcBhB0qCqplr63n4BcjGCCVgIMd8zIjz2eXciXy7k+yhHZygFIhje7BwFzgblgBUJMdlwM3yAdykAJ6yBSQGAeMzNUTkU7YBCILgZUioOBIBGUJEAHwxUxmqnU2Ce3CWgnenzgYDMACo6pZxpYIJSOqDwSkSFCYXC0VQYFi0NMQHQVEA) 예시를 통해 _항상_ 할당을 수행하는 것과 어떻게 다른지 확인해보세요. +[다음 예시를 실행해보세요](https://www.typescriptlang.org/play?ts=Nightly#code/MYewdgzgLgBCBGArGBeGBvAsAKBnmA5gKawAOATiKQBQCUGO+TMokIANkQHTsgHUAiYlChFyMABYBDCDHIBXMANoBuHI2Z4A9FpgAlIqXZTgRGAFsiAQg2byJeeTAwAslKgSu5KWAAmIczoYAB4YAAYuAFY1XHwAXwAaWxgIEhgKKmoAfQA3KXYALhh4EA4iH3osWM1WCDKePkFUkTFJGTlFZRimOJw4mJwAM0VgKABLcBhB0qCqplr63n4BcjGCCVgIMd8zIjz2eXciXy7k+yhHZygFIhje7BwFzgblgBUJMdlwM3yAdykAJ6yBSQGAeMzNUTkU7YBCILgZUioOBIBGUJEAHwxUxmqnU2Ce3CWgnenzgYDMACo6pZxpYIJSOqDwSkSFCYXC0VQYFi0NMQHQVEA) 예시를 통해 *항상* 할당을 수행하는 것과 어떻게 다른지 확인해보세요. ```ts const obj = { @@ -468,7 +468,7 @@ try { } ``` -The above has some undesirable behavior if we're trying to prevent _more_ errors from happening in our error-handling code! +The above has some undesirable behavior if we're trying to prevent *more* errors from happening in our error-handling code! Because these variables have the type `any` by default, they lack any type-safety which could have errored on invalid operations. That's why TypeScript 4.0 now lets you specify the type of `catch` clause variables as `unknown` instead. @@ -497,7 +497,7 @@ For more details you can [peek at the changes for this feature](https://github.c ## Custom JSX Factories -When using JSX, a [_fragment_](https://reactjs.org/docs/fragments.html) is a type of JSX element that allows us to return multiple child elements. +When using JSX, a [*fragment*](https://reactjs.org/docs/fragments.html) is a type of JSX element that allows us to return multiple child elements. When we first implemented fragments in TypeScript, we didn't have a great idea about how other libraries would utilize them. Nowadays most other libraries that encourage using JSX and support fragments have a similar API shape. @@ -597,7 +597,7 @@ That's why TypeScript 4.0 brings a new refactoring to convert common patterns to ![Converting `a && a.b.c && a.b.c.d.e.f()` to `a?.b.c?.d.e.f.()`](https://devblogs.microsoft.com/typescript/wp-content/uploads/sites/11/2020/08/convertToOptionalChain-4-0.gif) -Keep in mind that while this refactoring doesn't _perfectly_ capture the same behavior due to subtleties with truthiness/falsiness in JavaScript, we believe it should capture the intent for most use-cases, especially when TypeScript has more precise knowledge of your types. +Keep in mind that while this refactoring doesn't *perfectly* capture the same behavior due to subtleties with truthiness/falsiness in JavaScript, we believe it should capture the intent for most use-cases, especially when TypeScript has more precise knowledge of your types. For more details, [check out the pull request for this feature](https://github.com/microsoft/TypeScript/pull/39135). @@ -615,14 +615,14 @@ See [the pull request](https://github.com/microsoft/TypeScript/pull/38523) for m ### Partial Semantic Mode at Startup We've heard a lot from users suffering from long startup times, especially on bigger projects. -The culprit is usually a process called _program construction_. +The culprit is usually a process called *program construction*. This is the process of starting with an initial set of root files, parsing them, finding their dependencies, parsing those dependencies, finding those dependencies' dependencies, and so on. The bigger your project is, the longer you'll have to wait before you can get basic editor operations like go-to-definition or quick info. -That's why we've been working on a new mode for editors to provide a _partial_ experience until the full language service experience has loaded up. +That's why we've been working on a new mode for editors to provide a *partial* experience until the full language service experience has loaded up. The core idea is that editors can run a lightweight partial server that only looks at the current files that the editor has open. -It's hard to say precisely what sorts of improvements you'll see, but anecdotally, it used to take anywhere between _20 seconds to a minute_ before TypeScript would become fully responsive on the Visual Studio Code codebase. +It's hard to say precisely what sorts of improvements you'll see, but anecdotally, it used to take anywhere between *20 seconds to a minute* before TypeScript would become fully responsive on the Visual Studio Code codebase. In contrast, **our new partial semantic mode seems to bring that delay down to just a few seconds**. As an example, in the following video, you can see two side-by-side editors with TypeScript 3.9 running on the left and TypeScript 4.0 running on the right. @@ -630,7 +630,7 @@ As an example, in the following video, you can see two side-by-side editors with When restarting both editors on a particularly large codebase, the one with TypeScript 3.9 can't provide completions or quick info at all. -On the other hand, the editor with TypeScript 4.0 can _immediately_ give us a rich experience in the current file we're editing, despite loading the full project in the background. +On the other hand, the editor with TypeScript 4.0 can *immediately* give us a rich experience in the current file we're editing, despite loading the full project in the background. Currently the only editor that supports this mode is [Visual Studio Code](http://code.visualstudio.com/) which has some UX improvements coming up in [Visual Studio Code Insiders](http://code.visualstudio.com/insiders). We recognize that this experience may still have room for polish in UX and functionality, and we have [a list of improvements](https://github.com/microsoft/TypeScript/issues/39035) in mind. @@ -644,9 +644,9 @@ Auto-import is a fantastic feature that makes coding a lot easier; however, ever One specific issue that we heard from users was that auto-imports didn't work on dependencies that were written in TypeScript - that is, until they wrote at least one explicit import somewhere else in their project. Why would auto-imports work for `@types` packages, but not for packages that ship their own types? -It turns out that auto-imports only work on packages your project _already_ includes. -Because TypeScript has some quirky defaults that automatically add packages in `node_modules/@types` to your project, _those_ packages would be auto-imported. -On the other hand, other packages were excluded because crawling through all your `node_modules` packages can be _really_ expensive. +It turns out that auto-imports only work on packages your project *already* includes. +Because TypeScript has some quirky defaults that automatically add packages in `node_modules/@types` to your project, *those* packages would be auto-imported. +On the other hand, other packages were excluded because crawling through all your `node_modules` packages can be *really* expensive. All of this leads to a pretty lousy getting started experience for when you're trying to auto-import something that you've just installed but haven't used yet. diff --git a/docs/documentation/ko/tutorials/Babel with TypeScript.md b/docs/documentation/ko/tutorials/Babel with TypeScript.md index 8a096f5c..4aa99fcb 100644 --- a/docs/documentation/ko/tutorials/Babel with TypeScript.md +++ b/docs/documentation/ko/tutorials/Babel with TypeScript.md @@ -10,7 +10,7 @@ translatable: true 모던 JavaScript 프로젝트를 만들 때, TypeScript에서 JavaScript 파일로 변환하는 올바른 방법에 대해 고민할 수 있습니다. -많은 경우 그 대답은 프로젝트에 따라 _"~에 달려있다"_ 또는 _"누군가 여러분 대신 결정했을지도 모른다`_ 가 될 것입니다. 만약 [tsdx](https://www.npmjs.com/package/tsdx), [Angular](https://angular.io/), [NestJS](https://nestjs.com/)와 같은 기존 프레임워크 또는 [Getting Started](/docs/home)에 언급된 프레임워크를 사용하여 프로젝트를 만들고 있다면 이 결정은 여러분을 위해 자동으로 처리됩니다. +많은 경우 그 대답은 프로젝트에 따라 *"~에 달려있다"* 또는 *"누군가 여러분 대신 결정했을지도 모른다`* 가 될 것입니다. 만약 [tsdx](https://www.npmjs.com/package/tsdx), [Angular](https://angular.io/), [NestJS](https://nestjs.com/)와 같은 기존 프레임워크 또는 [Getting Started](/docs/home)에 언급된 프레임워크를 사용하여 프로젝트를 만들고 있다면 이 결정은 여러분을 위해 자동으로 처리됩니다. 하지만, 사용할만한 직관적인 방법은 다음과 같습니다: diff --git a/docs/documentation/ko/tutorials/DOM Manipulation.md b/docs/documentation/ko/tutorials/DOM Manipulation.md index 78abf512..83441592 100755 --- a/docs/documentation/ko/tutorials/DOM Manipulation.md +++ b/docs/documentation/ko/tutorials/DOM Manipulation.md @@ -8,19 +8,19 @@ translatable: true # DOM 조작 (DOM Manipulation) -### _`HTMLElement` 타입 탐구_ (_An exploration into the `HTMLElement` type_) +### *`HTMLElement` 타입 탐구* (*An exploration into the `HTMLElement` type*) 표준화 이후 20여 년 동안, JavaScript는 많은 발전을 이루었습니다. 2020년에는 서버, 데이터 사이언스, 그리고 IoT 기기에도 JavaScript를 사용할 수 있지만, 가장 인기 있는 활용 사례는 웹 브라우저인 것을 기억하는 것이 중요합니다. 웹 사이트는 HTML 및/또는 XML 문서로 구성됩니다. 이러한 문서들은 정적이어서, 변하지 않습니다. *문서 객체 모델(DOM)은* 정적 웹 사이트를 기능적으로 작동시키기 위해 브라우저에 의해 구현된 프로그래밍 인터페이스입니다. DOM API를 사용하면 문서의 구조, 스타일, 그리고 내용을 변경할 수 있습니다. API는 매우 강력해서 이를 바탕으로 보다 쉽게 동적인 웹사이트들 개발하기 위해 수많은 프런트엔드 프레임워크(jQuery, React, Angular 등)가 개발되었습니다. -TypeScript는 타입이 있는 JavaScript 상위 집합(superset)이며, DOM API에 대한 타입 정의를 제공합니다. 이러한 정의는 모든 기본 TypeScript 프로젝트에서 쉽게 사용 가능합니다. _lib.dom.d.ts_ 에 있는 2만여 줄의 정의 중에서, 가장 눈에 띄는 것은 `HTMLElement`입니다. 이 타입은 TypeScript를 사용한 DOM 조작의 중축입니다. +TypeScript는 타입이 있는 JavaScript 상위 집합(superset)이며, DOM API에 대한 타입 정의를 제공합니다. 이러한 정의는 모든 기본 TypeScript 프로젝트에서 쉽게 사용 가능합니다. *lib.dom.d.ts* 에 있는 2만여 줄의 정의 중에서, 가장 눈에 띄는 것은 `HTMLElement`입니다. 이 타입은 TypeScript를 사용한 DOM 조작의 중축입니다. > [DOM 타입 정의](https://github.com/microsoft/TypeScript/blob/master/lib/lib.dom.d.ts)에 대한 소스코드는 이곳에서 볼 수 있습니다. ## 기본 예제 (Basic Example) -간단한 예시 파일 _index.html_: +간단한 예시 파일 *index.html*: @@ -48,7 +48,7 @@ p.textContent = "Hello, World!"; app?.appendChild(p); ``` -_index.html_ 페이지를 컴파일하고 실행한 후, HTML 결과: +*index.html* 페이지를 컴파일하고 실행한 후, HTML 결과: ```html
@@ -58,7 +58,7 @@ _index.html_ 페이지를 컴파일하고 실행한 후, HTML 결과: ## `Document` 인터페이스 (The `Document` Interface) -TypeScript 코드의 첫 번째 줄은 전역변수 `document`를 사용하며, 그 변수를 검사하면 _lib.dom.d.ts_ 파일의 `Document` 인터페이스에 의해 정의된 것으로 표시됩니다. 그 코드의 스니펫(snippet)에는 `getElementById`와 `createElement`라는 두 가지 메서드 호출이 포함되어 있습니다. +TypeScript 코드의 첫 번째 줄은 전역변수 `document`를 사용하며, 그 변수를 검사하면 *lib.dom.d.ts* 파일의 `Document` 인터페이스에 의해 정의된 것으로 표시됩니다. 그 코드의 스니펫(snippet)에는 `getElementById`와 `createElement`라는 두 가지 메서드 호출이 포함되어 있습니다. ### `Document.getElementById` @@ -68,11 +68,11 @@ TypeScript 코드의 첫 번째 줄은 전역변수 `document`를 사용하며, getElementById(elementId: string): HTMLElement | null; ``` -문자열 id 요소가 전달되면 `HTMLElement` 또는 `null`이 반환됩니다. 이 메서드는 가장 중요한 타입들 중 하나인 `HTMLElement`를 도입합니다. 이 타입은 다른 모든 요소 인터페이스의 기본 인터페이스 역할을 합니다. 예를 들면, 예제 코드에서 `p` 변수는 `HTMLParagraphElement` 타입입니다. 다음으로, 이 메서드는 `null`을 반환할 수 있다는 점에 유의해야 합니다. 메서드가 실제로 지정된 요소를 찾을 수 있을지 없을지에 따라 확실한 사전 런타임이 될 수 없기 때문입니다. 스니펫 코드의 마지막 줄에는, `appendChild`를 호출하기 위해 새로운 _선택적 체이닝(optional chaining)_ 연산자가 사용되고 있습니다. +문자열 id 요소가 전달되면 `HTMLElement` 또는 `null`이 반환됩니다. 이 메서드는 가장 중요한 타입들 중 하나인 `HTMLElement`를 도입합니다. 이 타입은 다른 모든 요소 인터페이스의 기본 인터페이스 역할을 합니다. 예를 들면, 예제 코드에서 `p` 변수는 `HTMLParagraphElement` 타입입니다. 다음으로, 이 메서드는 `null`을 반환할 수 있다는 점에 유의해야 합니다. 메서드가 실제로 지정된 요소를 찾을 수 있을지 없을지에 따라 확실한 사전 런타임이 될 수 없기 때문입니다. 스니펫 코드의 마지막 줄에는, `appendChild`를 호출하기 위해 새로운 *선택적 체이닝(optional chaining)* 연산자가 사용되고 있습니다. ### `Document.createElement` -이 메서드의 정의는 다음과 같습니다(_deprecated_ 표기된 정의는 생략했습니다): +이 메서드의 정의는 다음과 같습니다(*deprecated* 표기된 정의는 생략했습니다): ```ts createElement(tagName: K, options?: ElementCreationOptions): HTMLElementTagNameMap[K]; @@ -100,7 +100,7 @@ interface HTMLElementTagNameMap { 일부 요소들은 고유한 프로퍼티를 나타내지 않아 `HTMLElement`를 반환하기도 하지만, 그 외 타입 요소들은 고유한 프로퍼티와 메서드를 가지고 특정 인터페이스(`HTMLElement`에서 확장되거나 구현됨)를 반환합니다. -이제, `createElement` 정의의 나머지 부분인 `(tagName: K, options?: ElementCreationOptions): HTMLElementTagNameMap[K]`를 살펴보겠습니다. 첫 번째 인수 `tagName`은 제네릭 매개변수 `K`로 정의됩니다. TypeScript 인터프리터는 이 인수로부터 제네릭 매개변수를 _추론_ 할 수 있는 충분한 성능을 가지고 있습니다. 이는 개발자가 메서드를 사용할 때 실제로 제네릭 매개변수를 지정할 필요가 없음을 의미하며, 어떤 값이 `tagName`인수로 전달되든 간에 `K`로 추론되므로 정의의 나머지 부분에 사용할 수 있을 것입니다. 정확히 무슨 일이 일어나는지를 보면 반환값 `HTMLElementTagNameMap[K]`는 `tagName`인수를 가지고 해당 타입을 반환합니다. 이 정의는 스니펫 코드 `p` 변수에서 `HTMLParagraphElement`타입을 얻는 방법입니다. 그리고 코드가 `document.createElement('a')`였다면, `HTMLAnchorElement`타입의 요소가 됩니다. +이제, `createElement` 정의의 나머지 부분인 `(tagName: K, options?: ElementCreationOptions): HTMLElementTagNameMap[K]`를 살펴보겠습니다. 첫 번째 인수 `tagName`은 제네릭 매개변수 `K`로 정의됩니다. TypeScript 인터프리터는 이 인수로부터 제네릭 매개변수를 *추론* 할 수 있는 충분한 성능을 가지고 있습니다. 이는 개발자가 메서드를 사용할 때 실제로 제네릭 매개변수를 지정할 필요가 없음을 의미하며, 어떤 값이 `tagName`인수로 전달되든 간에 `K`로 추론되므로 정의의 나머지 부분에 사용할 수 있을 것입니다. 정확히 무슨 일이 일어나는지를 보면 반환값 `HTMLElementTagNameMap[K]`는 `tagName`인수를 가지고 해당 타입을 반환합니다. 이 정의는 스니펫 코드 `p` 변수에서 `HTMLParagraphElement`타입을 얻는 방법입니다. 그리고 코드가 `document.createElement('a')`였다면, `HTMLAnchorElement`타입의 요소가 됩니다. ## `Node` 인터페이스 (The `Node` interface) @@ -108,7 +108,7 @@ interface HTMLElementTagNameMap { ### `Node.appendChild` -코드 스니펫의 마지막 줄은 `app?.appendChild(p)`입니다. 이전 섹션(`document.getElementById`)에서는 `app`이 런타임에 null일 가능성이 있기 때문에 _선택적 체이닝(optional chaining)_ 연산자가 여기에 사용된다고 설명했습니다. `appendChild`의 메서드는 다음과 같습니다: +코드 스니펫의 마지막 줄은 `app?.appendChild(p)`입니다. 이전 섹션(`document.getElementById`)에서는 `app`이 런타임에 null일 가능성이 있기 때문에 *선택적 체이닝(optional chaining)* 연산자가 여기에 사용된다고 설명했습니다. `appendChild`의 메서드는 다음과 같습니다: ```ts appendChild(newChild: T): T; @@ -118,7 +118,7 @@ appendChild(newChild: T): T; ## `children`과 `childNodes`의 차이점 (Difference between `children` and `childNodes`) -이전에 이 문서는 `HTMLElement` 인터페이스가 `Node`로부터 확장된 `Element`에서 확장된 개념이라고 설명했습니다. DOM API에는 _자식(children)_ 요소 개념이 있습니다. 예를 들어 HTML에서 `p` 태그는 `div` 요소의 자식입니다. +이전에 이 문서는 `HTMLElement` 인터페이스가 `Node`로부터 확장된 `Element`에서 확장된 개념이라고 설명했습니다. DOM API에는 *자식(children)* 요소 개념이 있습니다. 예를 들어 HTML에서 `p` 태그는 `div` 요소의 자식입니다. ```tsx
@@ -135,7 +135,7 @@ div.childNodes; // NodeList(2) [p, p] ``` -`div` 요소를 찾아낸 후 `children` 프로퍼티는 `HTMLParagraphElements`를 포함하는 `HTMLCollection` 리스트를 반환합니다. `childNodes` 프로퍼티는 위와 유사하게 노드 리스트인 `NodeList`를 반환합니다. 각 `p` 태그는 여전히 `HTMLParagraphElements` 타입이지만, `NodeList`는 추가적으로 `HTMLCollection` 리스트에는 없는 _HTML 노드_ 를 포함할 수 있습니다. +`div` 요소를 찾아낸 후 `children` 프로퍼티는 `HTMLParagraphElements`를 포함하는 `HTMLCollection` 리스트를 반환합니다. `childNodes` 프로퍼티는 위와 유사하게 노드 리스트인 `NodeList`를 반환합니다. 각 `p` 태그는 여전히 `HTMLParagraphElements` 타입이지만, `NodeList`는 추가적으로 `HTMLCollection` 리스트에는 없는 *HTML 노드* 를 포함할 수 있습니다. `p` 태그 중 하나를 제거하여 html을 수정하되 텍스트는 그대로 유지하십시오. @@ -158,7 +158,7 @@ div.childNodes; ## `querySelector`와 `querySelectorAll` 메서드 (The `querySelector` and `querySelectorAll` methods) -두 개의 메서드 모두 고유한 제약 조건 집합에 적합한 돔 요소 리스트를 가져오는 데 좋은 도구입니다. 메서드들은 _lib.dom.d.ts_ 에 다음과 같이 정의되어 있습니다: +두 개의 메서드 모두 고유한 제약 조건 집합에 적합한 돔 요소 리스트를 가져오는 데 좋은 도구입니다. 메서드들은 *lib.dom.d.ts* 에 다음과 같이 정의되어 있습니다: ```ts /** @@ -176,7 +176,7 @@ querySelectorAll(selectors: K): NodeListOf querySelectorAll(selectors: string): NodeListOf; ``` - `querySelectorAll` 정의는 `NodeListOf`라는 새로운 타입을 반환한다는 점을 제외하면 `getElementByTagName`과 유사합니다. 이 반환 타입은 기본적으로 표준 JavaScript 리스트 요소의 맞춤형으로 구현되었습니다. `NodeListOf`를 `E[]`로 바꿔보면 틀림없이 매우 유사한 사용자 경험을 제공할 것입니다. `NodeListOf`는 `length` , `item(index)`, `forEach((value, key, parent) => void)` , 그리고 숫자 인덱스 생성과 같은 프로퍼티 및 메서드만을 구현합니다. 또한, 메서드는 _노드_ 가 아닌 _요소_ 리스트를 반환하며 이는 `.childNodes` 메서드에서 `NodeList`가 반환한 것입니다. 모순처럼 보일 수 있지만, `Element` 인터페이스는 `Node`에서 확장된 점에 유의해야 합니다. + `querySelectorAll` 정의는 `NodeListOf`라는 새로운 타입을 반환한다는 점을 제외하면 `getElementByTagName`과 유사합니다. 이 반환 타입은 기본적으로 표준 JavaScript 리스트 요소의 맞춤형으로 구현되었습니다. `NodeListOf`를 `E[]`로 바꿔보면 틀림없이 매우 유사한 사용자 경험을 제공할 것입니다. `NodeListOf`는 `length` , `item(index)`, `forEach((value, key, parent) => void)` , 그리고 숫자 인덱스 생성과 같은 프로퍼티 및 메서드만을 구현합니다. 또한, 메서드는 *노드* 가 아닌 *요소* 리스트를 반환하며 이는 `.childNodes` 메서드에서 `NodeList`가 반환한 것입니다. 모순처럼 보일 수 있지만, `Element` 인터페이스는 `Node`에서 확장된 점에 유의해야 합니다. 두 개의 메서드가 동작하는 것을 보려면 기존 코드를 다음과 같이 수정하십시오: @@ -193,7 +193,7 @@ const all = document.querySelectorAll("li"); // 모든 li 요소를 포함하는 ## 더 자세히 알고 싶으십니까? (Interested in learning more?) -_lib.dom.d.ts_ 타입 정의에서 가장 좋은 부분은 Mozilla Developer Network (MDN) 문서 사이트에 표기된 타입들을 반영했다는 것입니다. 예를 들어, `HTMLElement` 인터페이스는 MDN에서 [HTMLElement 페이지](https://developer.mozilla.org/docs/Web/API/HTMLElement)에 문서화 되어 있습니다. 이 페이지에는 사용 가능한 모든 프로퍼티, 메서드, 때로는 예시까지 제공합니다. 해당 페이지가 훌륭한 다른 면은 표준 문서에 맞는 링크를 제공한다는 것입니다. 다음은 [HTMLElement의 W3C 권장사항](https://www.w3.org/TR/html52/dom.html#htmlelement)에 대한 링크입니다. +*lib.dom.d.ts* 타입 정의에서 가장 좋은 부분은 Mozilla Developer Network (MDN) 문서 사이트에 표기된 타입들을 반영했다는 것입니다. 예를 들어, `HTMLElement` 인터페이스는 MDN에서 [HTMLElement 페이지](https://developer.mozilla.org/docs/Web/API/HTMLElement)에 문서화 되어 있습니다. 이 페이지에는 사용 가능한 모든 프로퍼티, 메서드, 때로는 예시까지 제공합니다. 해당 페이지가 훌륭한 다른 면은 표준 문서에 맞는 링크를 제공한다는 것입니다. 다음은 [HTMLElement의 W3C 권장사항](https://www.w3.org/TR/html52/dom.html#htmlelement)에 대한 링크입니다. 소스코드 참조: