Skip to content

Commit ace961f

Browse files
jaryappjaryapp
committed
translate 4.9 "in", "auto-accessors"
1 parent e3cd858 commit ace961f

File tree

1 file changed

+33
-34
lines changed

1 file changed

+33
-34
lines changed

‎docs/documentation/ko/release-notes/TypeScript 4.9.md

+33-34
Original file line numberDiff line numberDiff line change
@@ -106,14 +106,13 @@ const greenNormalized = palette.green.toUpperCase();
106106
For more examples, you can see the [issue proposing this](https://github.com/microsoft/TypeScript/issues/47920) and [the implementing pull request](https://github.com/microsoft/TypeScript/pull/46827).
107107
We'd like to thank [Oleksandr Tarasiuk](https://github.com/a-tarasyuk) who implemented and iterated on this feature with us.
108108

109-
## Unlisted Property Narrowing with the `in` Operator
109+
## "in" 연산자를 사용하여 정의되지 않은 프로퍼티로 타입 좁히기
110110

111-
As developers, we often need to deal with values that aren't fully known at runtime.
112-
In fact, we often don't know if properties exist, whether we're getting a response from a server or reading a configuration file.
113-
JavaScript's `in` operator can check whether a property
114-
exists on an object.
111+
개발자들은 자주 런타임에서 알 수 없는 값을 처리해야 할 때가 있습니다.
112+
서버에서 응답받거나 설정 파일을 읽는 경우처럼 실제로 프로퍼티가 존재하는지 알 수 없는 경우가 흔하게 있습니다.
113+
JavaScript의 `in` 연산자를 활용하면 객체에 프로퍼티가 존재하는지 알 수 있습니다.
115114

116-
Previously, TypeScript allowed us to narrow away any types that don't explicitly list a property.
115+
이전에, TypeScript에서는 정의되지 않는 프로퍼티를 사용하여 타입을 좁힐 수 있었습니다.
117116

118117
```ts
119118
interface RGB {
@@ -130,24 +129,24 @@ interface HSV {
130129

131130
function setColor(color: RGB | HSV) {
132131
if ("hue" in color) {
133-
// 'color' now has the type HSV
132+
// 이제 'color' 는 HSV 타입을 갖게되었습니다.
134133
}
135134
// ...
136135
}
137136
```
138137

139-
Here, the type `RGB` didn't list the `hue` and got narrowed away, and leaving us with the type `HSV`.
138+
여기서, `RGB` 타입에 정의되지 않은 `hue`에 의해 타입이 좁혀지게 되어, `HSV` 타입이 남게 되었습니다.
140139

141-
But what about examples where no type listed a given property?
142-
In those cases, the language didn't help us much.
143-
Let's take the following example in JavaScript:
140+
그러나 프로퍼티가 주어진 타입이 없는 경우에는 어떨까요?
141+
그런 경우, 언어가 큰 도움이 되지 않습니다.
142+
여기 JavaScript로 된 예시를 살펴보겠습니다
144143

145144
```js
146145
function tryGetPackageName(context) {
147146
const packageJSON = context.packageJSON;
148-
// Check to see if we have an object.
147+
// 객체가 맞는지 확인합니다.
149148
if (packageJSON && typeof packageJSON === "object") {
150-
// Check to see if it has a string name property.
149+
// 문자열 타입의 name 프로퍼티를 가지고 있는지 확인합니다.
151150
if ("name" in packageJSON && typeof packageJSON.name === "string") {
152151
return packageJSON.name;
153152
}
@@ -157,8 +156,8 @@ function tryGetPackageName(context) {
157156
}
158157
```
159158

160-
Rewriting this to canonical TypeScript would just be a matter of defining and using a type for `context`;
161-
however, picking a safe type like `unknown` for the `packageJSON` property would cause issues in older versions of TypeScript.
159+
이것을 표준 Typescript로 다시 작성한다면 `context`에 대한 타입을 정의해서 사용하게 될 것입니다.
160+
하지만, `packageJSON`의 속성에 `unknown`과 같은 안전한 타입을 사용하면 이전 타입스크립트 버전들에서 문제가 발생할 수도 있습니다.
162161

163162
```ts
164163
interface Context {
@@ -167,9 +166,9 @@ interface Context {
167166

168167
function tryGetPackageName(context: Context) {
169168
const packageJSON = context.packageJSON;
170-
// Check to see if we have an object.
169+
// 객체가 맞는지 확인합니다.
171170
if (packageJSON && typeof packageJSON === "object") {
172-
// Check to see if it has a string name property.
171+
// 문자열 타입의 name 프로퍼티를 가지고 있는지 확인합니다.
173172
if ("name" in packageJSON && typeof packageJSON.name === "string") {
174173
// ~~~~
175174
// error! Property 'name' does not exist on type 'object.
@@ -183,14 +182,14 @@ function tryGetPackageName(context: Context) {
183182
}
184183
```
185184

186-
This is because while the type of `packageJSON` was narrowed from `unknown` to `object`, the `in` operator strictly narrowed to types that actually defined the property being checked.
187-
As a result, the type of `packageJSON` remained `object`.
185+
이는 `packageJSON`의 타입이 `unknown`에서 `object`로 좁혀졌으나, `in` 연산자는 실제로 정의한 타입으로 엄격하게 좁혔기 때문입니다.
186+
그 결과, `packageJSON`은 `object`로 남게 되었습니다.
188187

189-
TypeScript 4.9 makes the `in` operator a little bit more powerful when narrowing types that *don't* list the property at all.
190-
Instead of leaving them as-is, the language will intersect their types with `Record<"property-key-being-checked", unknown>`.
188+
TypeScript 4.9는 프로퍼티가 전혀 정의되지 _않은_ 타입을 좁힐 때, `in` 연산자를 사용하여 조금 더 강력하게 만듭니다.
189+
이전과는 다르게, 언어는 `Record<"property-key-being-checked", unknown>`과 타입을 교차합니다.
191190

192-
So in our example, `packageJSON` will have its type narrowed from `unknown` to `object` to `object & Record<"name", unknown>`
193-
That allows us to access `packageJSON.name` directly and narrow that independently.
191+
따라서 위 예시에서, `packageJSON`는 `unknown`에서 `object`로 그다음 `object & Record<"name", unknown>`로 타입이 좁혀집니다.
192+
이를 통해 `packageJSON.name`에 직접 접근이 가능해지고 독립적으로 좁혀집니다.
194193

195194
```ts
196195
interface Context {
@@ -199,11 +198,11 @@ interface Context {
199198

200199
function tryGetPackageName(context: Context): string | undefined {
201200
const packageJSON = context.packageJSON;
202-
// Check to see if we have an object.
201+
// 객체가 맞는지 확인합니다.
203202
if (packageJSON && typeof packageJSON === "object") {
204-
// Check to see if it has a string name property.
203+
// 문자열 타입의 name 프로퍼티를 가지고 있는지 확인합니다.
205204
if ("name" in packageJSON && typeof packageJSON.name === "string") {
206-
// Just works!
205+
// 동작!
207206
return packageJSON.name;
208207
}
209208
}
@@ -212,15 +211,15 @@ function tryGetPackageName(context: Context): string | undefined {
212211
}
213212
```
214213

215-
TypeScript 4.9 also tightens up a few checks around how `in` is used, ensuring that the left side is assignable to the type `string | number | symbol`, and the right side is assignable to `object`.
216-
This helps check that we're using valid property keys, and not accidentally checking primitives.
214+
TypeScript 4.9는 또한 `in`의 검사를 강화하여 left side에는 `string | number | symbol`, right side에는 `object`로만 할당할 수 있도록 보증합니다.
215+
이는 유효한 프로퍼티 키를 사용했는지, 실수로 프리미티브를 검증하고 있는지 확인하는 데 도움이 됩니다.
217216

218-
For more information, [read the implementing pull request](https://github.com/microsoft/TypeScript/pull/50666)
217+
더 많은 정보를 얻고 싶다면, [이를 구현한 pull request를 읽어보세요](https://github.com/microsoft/TypeScript/pull/50666)
219218

220-
## <a name="auto-accessors-in-classes"> Auto-Accessors in Classes
219+
## <a name="auto-accessors-in-classes"> 클래스의 자동 접근자
221220

222-
TypeScript 4.9 supports an upcoming feature in ECMAScript called auto-accessors.
223-
Auto-accessors are declared just like properties on classes, except that they're declared with the `accessor` keyword.
221+
TypeScript 4.9는 자동 접근자라고 하는 ECMAScript의 향후 기능을 지원합니다.
222+
자동 접근자는 `accessor` 키워드로 선언된다는 점을 제외하면 클래스의 속성처럼 선언됩니다.
224223

225224
```ts
226225
class Person {
@@ -232,7 +231,7 @@ class Person {
232231
}
233232
```
234233

235-
Under the covers, these auto-accessors "de-sugar" to a `get` and `set` accessor with an unreachable private property.
234+
내부적으로 이러한 자동 접근자는 도달할 수 없는 private 프로퍼티의 `get` 및 `set` 접근자로 "de-sugar"됩니다.
236235

237236
```ts
238237
class Person {
@@ -251,7 +250,7 @@ class Person {
251250
}
252251
```
253252

254-
You can [read up more about the auto-accessors pull request on the original PR](https://github.com/microsoft/TypeScript/pull/49705).
253+
[자세한 내용은 자동 접근자에 대한 원본 pull request](https://github.com/microsoft/TypeScript/pull/49705)에서 확인할 수 있습니다.
255254

256255
## Checks For Equality on `NaN`
257256

0 commit comments

Comments
 (0)