+
declare function define(...args: any[]): any;
-이러한 호출들은 제거하고 import에 TypeScript 구문을 사용하는 것이 좋습니다.
-먼저 TypeScript의 module 플래그를 설정하여 일부 모듈 시스템을 활성화해야 합니다.
유효한 옵션은commonjs,amd,system 그리고 umd입니다.
-다음 Node/CommonJS 코드를 가지고 있는 경우:
+이러한 호출을 제거하고 import를 위한 TypeScript 구문을 사용하는 것이 더 낫습니다.
+먼저, TypeScript module 플래그를 설정함으로써 모듈 시스템을 활성화해야 합니다.
+유효한 옵션은 commonjs, amd, system, 그리고 umd입니다.
+만약 다음과 같은 Node/CommonJS 코드를 갖고 있다면:
var foo = require("foo");
foo.doStuff();
-또는 다음 RequireJS / AMD 코드:
+또는 다음의 RequireJS/AMD 코드를 갖고 있다면:
define(["foo"], function(foo) {
foo.doStuff();
})
-그러면 다음과 같은 TypeScript 코드를 작성하게 됩니다:
+그러면 다음의 TypeScript 코드를 작성해야 합니다:
import foo = require("foo");
foo.doStuff();
-선언 파일 가져 오기 (Getting Declaration Files)
-TypeScript로 전환하기 시작하면 Cannot find module 'foo'.과 같은 오류가 발생할 수 있습니다.
여기서 문제는 라이브러리를 설명할 수 있는 선언 파일(declaration files) 을 가지고 있지 않다는 것입니다.
다행히도 이것은 꽤 쉽습니다.
TypeScript에서 lodash와 같은 패키지에 대해 불평하는 경우 그냥 작성할 수 있습니다.
+선언 파일 시작하기 (Getting Declaration Files)
+만약 TypeScript import로 전환을 시작했다면, Cannot find module 'foo'. 같은 오류가 발생할 수 있습니다.
+여기서 문제는 라이브러리를 설명하는 선언 파일이 없을 가능성이 높다는 것입니다.
+다행히 해결 방법은 꽤 쉽습니다.
+만약 TypeScript가 lodash 같은 패키지에 대해 경고를 발생시키면, 그냥 작성하면 됩니다
npm install -S @types/lodash
-commonjs가 아닌 다른 모듈 옵션을 사용한다면 moduleResolution 옵션을 node로 설정해야 합니다.
-그런 다음 문제없이 Lodash를 가져올 수 있으며 자동 완성을 얻을 수 있습니다.
-모듈 내보내기 (Exporting from Modules)
-전형적으로 모듈에서 내보내기는 exports 나 module.exports와 같은 값에 프로퍼티를 추가하는 것을 포함합니다.
TypeScript를 사용하면 최상위 레벨 내보내기 명령문을 허용할 수 있습니다.
-예를 들어 이와 같은 함수를 내보낸 경우:
+commonjs 말고 다른 모듈 옵션을 사용한다면, moduleResolution을 node로 설정해야 합니다.
+그 후, lodash를 문제없이 import 할 수 있고, 정확하게 완성할 수 있습니다.
+모듈 export 하기 (Exporting from Modules)
+전형적으로, 모듈을 export 하는 것은exports 혹은 module.exports 같은 값을 프로퍼티에 추가하는 것을 포함합니다.
+TypeScript는 최상위-레벨의 export 문을 허용합니다.
+예를 들어, 함수를 이렇게 export 했다면:
module.exports.feedPets = function(pets) {
}
-다음과 같이 작성할 수 있습니다:
+그것을 다음과 같이 작성할 수 있습니다:
export function feedPets(pets) {
}
-때로는 exports 객체를 완전히 덮어쓰기도 합니다.
-이것은 모듈을 이 코드처럼 즉시 호출 가능한 모듈로 만들기 위해 사용하는 일반적인 패턴입니다:
+때로 exports 객체를 완전히 재작성할 수 있습니다.
+아래 예제처럼 즉시 호출하기 위해 이러한 흔한 패턴을 사용합니다:
var express = require("express");
var app = express();
-이전에는 이렇게 작성했을 수도 있습니다 :
+전에는 이렇게 작성했을 수 있습니다:
function foo() {
}
module.exports = foo;
-TypeScript에서는 이것을 export = 구조로 모델링할 수 있습니다.
+TypeScript에서, 이것을 export = 구문을 사용하여 모델링 할 수 있습니다.
function foo() {
}
export = foo;
-너무 많거나 적은 인수 (Too many/too few arguments)
-때때로 너무나 많거나 적은 인수를 가진 함수를 호출할 때가 있습니다.
전형적으로 이것은 버그이지만 어떤 경우에는 매개 변수를 쓰는 대신 arguments 객체를 사용하는 함수를 선언했을 수도 있습니다:
+너무 많은/너무 적은 인수 (Too many/too few arguments)
+때로 너무 많은/너무 적은 인수를 갖고 있는 함수를 호출할 때가 있습니다.
+전형적인 버그이지만, 그러나 몇몇 경우, 어떠한 매개변수를 쓰는 대신 arguments 객체를 사용하는 함수를 선언할 수 있습니다:
function myCoolFunction() {
if (arguments.length == 2 && !Array.isArray(arguments[1])) {
var f = arguments[0];
@@ -920,7 +1053,7 @@ myCoolFunction(function(x) { console.log(x) }, [1, 2, 3, 4]);
myCoolFunction(function(x) { console.log(x) }, 1, 2, 3, 4);
-이런 경우에는 TypeScript를 사용하여 myCoolfunction이 함수 오버로드를 통해 호출될 수 있는 방법에 대해 알려주어야 합니다.
+이 경우, TypeScript를 사용해서 호출자에게 함수 오버로드를 사용해 myCoolFunction이 호출되는 방법을 알려주어야 합니다.
function myCoolFunction(f: (x: number) => void, nums: number[]): void;
function myCoolFunction(f: (x: number) => void, ...nums: number[]): void;
function myCoolFunction() {
@@ -932,54 +1065,65 @@ // ...
}
-myCoolFunction에 두 개의 오버로드를 추가했습니다.
-첫 번째 검사는 myCoolFunction가 (number를 갖는) 함수에 number의 목록을 가집니다.
-두번째는 함수도 갖춰야 한다는 것이고 그 뒤에 오는 인수가 숫자여야 한다는 것을 알리기 위해 나머지 매개변수(...nums)를 사용합니다.
-순차적으로 추가되는 프로퍼티 (Sequentially Added Properties)
-어떤 사람들은 다음과 같이 즉시 객체를 생성하고 속성을 추가하는 것이 더 예술적으로 즐겁다는 것을 알게됩니다:
+myCoolFunction에 오버로드 시그니처 두 개를 추가했습니다.
+첫 번째 검사는 myCoolFunction이 (number를 인수로 갖는) 함수와 number 배열을 가진다는 것을 명시합니다.
+두 번째 검사는 myCoolFunction이 마찬가지로 함수를 가지고, 나머지 연산자(...nums)를 사용하여 그 외의 인수는 몇개의 인수든 number가 되어야 함을 명시합니다.
+순차적으로 추가된 프로퍼티 (Sequentially Added Properties)
+어떤 사람들은 객체를 생성하고 다음과 같이 동적으로 프로퍼티를 추가하는 것이 미관상 더 보기 좋다고 생각합니다:
var options = {};
options.color = "red";
options.volume = 11;
-TypeScript는 options의 타입을 어떠한 프로퍼티도 갖지 않는 {}로 먼저 찾아냈기 때문에 volume과 color에 할당할 수 없다고 말할 것입니다.
대신 선언을 객체 리터럴 자체로 옮기면 오류가 발생하지 않습니다:
+TypeScript는 options을 프로퍼티가 없는 {}로 인식했기 때문에 color와 volume을 할당할 수 없다고 할 것입니다.
+만약 선언을 리터럴 객체로 변경하면, 오류가 발생하지 않습니다:
let options = {
color: "red",
volume: 11
};
-options의 타입을 정의하고 객체 리터럴에 타입 단언(type assertion)을 추가 할 수도 있습니다.
+또한 options의 타입을 정의해야 하고 객체 리터럴에 대한 타입 단언을 추가해야 합니다.
interface Options { color: string; volume: number }
let options = {} as Options;
options.color = "red";
options.volume = 11;
-또는 options에 any 타입이라고 하는 것이 가장 쉬운 방법이지만 가장 이득이 적은 일이 될 것입니다.
-any와 Object 그리고 {} (any, Object, and {})
-대부분의 경우 Object가 가장 일반적인 타입이기 때문에 Object 또는 {}를 사용하여 값에 프로퍼티를 포함할 수 있다고 말할 수 있습니다.
하지만 any가 가장 유연한 타입이기 때문에 이러한 상황에서 실제로 사용하려는 타입입니다.
-예를 들어 Object 타입을 가지고 있다면 toLowerCase()와 같은 메서드를 호출할 수 없습니다.
-좀 더 일반적이라는 것은 보통 타입을 사용하는 것이 적다는 것을 의미하지만 가장 일반적인 타입인 any는 여전히 어떤 것이든 할 수 있게 허용해준다는 점에서 특별합니다.
즉 호출하여 구성하고 프로퍼티를 조작할 수 있습니다.
하지만 any를 사용하면 TypeScript가 제공하는 대부분의 오류 검사 및 편집기 지원을 잃어 버리게 됩니다.
-Object와 {}로 판결났다면 {}을 선호해야 합니다.
그것들은 대체로 같지만 비밀스러운 경우에는 기술적으로 {}가 Object보다 더 일반적인 타입입니다.
-엄격한 검사 받기 (Getting Stricter Checks)
-TypeScript는 프로그램의 안전성과 분석을 제공하기 위해 특정 검사를 제공합니다.
일단 코드 베이스를 TypeScript로 변환한 후에는 이러한 검사를 활성화하여 안전성을 높일 수 있습니다.
-암시적인 any는 No (No Implicit any)
-타이프 스크립트가 어떤 타입이어야 할지 모르는 특정한 경우가 있습니다.
가능하면 관대하기 위해 그 자리에 any 타입을 사용하기로 결정할 것입니다.
이는 마이 그레이션에는 매우 유용하지만 any를 사용하면 어떠한 유형의 안전도 확보할 수 없으며 다른 곳에서 얻을 수 있는 것과 도구의 지원을 받을 수 없습니다.
TypeScript에서 이러한 위치를 기록하도록 지시하고 noImplicitAny 옵션으로 오류를 표시할 수 있습니다.
-엄격한 null과 undefined 체크 (Strict null & undefined Checks)
-기본적으로 TypeScript는 null과 undefined이 모든 타입의 범위에 있다고 가정합니다.
즉 number 타입으로 선언된 모든 것이 null 또는 undefined 일 수 있음을 의미합니다.
-null과 undefined는 JavaScript와 TypeScript에서 자주 발생하는 버그의 원천이기 때문에 TypeScript는 이에 대한 걱정을 덜어주기 위해 strictNullChecks 옵션을 가지고 있습니다.
-strictNullChecks가 활성화되면 null과 undefined는 null과 undefined 각각의 타입을 갖습니다.
-혹시 null 일 수 있는 항목이 있을 때 원래 타입을 union 타입으로 사용할 수 있습니다.
그렇기 때문에 타입이 number(이)거나 null 일 수 있는 경우 해당 타입을 number | null로 쓰면 됩니다.
-TypeScript가 null /undefined라고 생각하는 값을 가지고 있지만 더 잘 알고 있다면 후위 연산자 !를 사용하여 다르게 사용할 수 있습니다.
+대신, options이 단순히 타입any를 갖는다고 명시할 수 있는데, 이 방법은 가장 쉬운 방법이지만 가장 적은 장점을 가지고 있습니다.
+any, Object, and {}
+Object는 대부분의 경우 가장 일반적인 타입이므로, 값이 어떤 프로퍼티도 가질 수 있다고 말하기 위해 Object 나 {}를 사용하고 싶을 수 있습니다.
+하지만 any가 가장 유연한 타입이므로, 이러한 경우에는 실제로 any가 가장 적절한 타입 입니다.
+예를 들어, Object를 타입으로 선언한 경우 toLowerCase()같은 메서드를 호출할 수 없습니다.
+더 일반적으로 사용한다는 것은 타입으로 더 적은 일을 할 수 있다는 것을 의미하지만, any는 어떤 일이든 할 수 있게 하는 동시에 가장 일반적인 타입이라는 점에서 특별합니다.
+그것은 any를 호출하고, 구성하고, 프로퍼티에 접근하는 등의 일을 할 수 있다는 것을 의미합니다.
+그러나 any를 사용하면 TypeScript가 제공하는 대부분의 타입 검사와 에디터 지원을 받을 수 없다는 것을 명심하세요.
+만약 Object와 {}로 결정이 내려지면, {}를 선택해야 합니다.
+이 둘은 거의 같지만, 특정 난해한 상황에서 기술적으로 {}이 Object보다 더 일반적인 타입입니다.
+더 엄격한 체크하기 (Getting Stricter Checks)
+TypeScript는 프로그램에 대한 안정성과 분석을 제공하는 특정한 검사를 갖고 있습니다.
+TypeScript로 코드베이스를 시작하면, 향상된 안전성을 위한 검사를 활성화할 수 있습니다.
+암시적인 any는 피하기 (No Implicit any)
+어떤 타입이어야 하는지 TypeScript가 파악할 수 없는 경우가 있습니다.
+최대한 유연하게 대응하기 위해, 그 자리에 any를 사용하기로 결정할 것입니다.
+이것은 마이그레이션에는 좋지만, any를 사용한다는 것은 다른 곳에서 받을 수 있는 어떠한 타입 안정성과 툴링 지원도 받지 못한다는 것을 의미합니다.
+TypeScript가 이런 부분에 플래그와 에러를 띄울 수 있도록 noImplicitAny옵션을 사용할 수 있습니다.
+엄격한 null & undefined 검사 (Strict null & undefined Checks)
+기본적으로, TypeScript는 null 과 undefined이 모든 타입의 도메인에 존재한다고 가정합니다.
+number로 선언된 타입이 null 혹은 undefined이 될 수 있다는 의미입니다.
+null 과 undefined는 JavaScript 와 TypeScript 에서 빈번한 버그 원인이기 때문에, TypeScript 에는 이러한 문제의 걱정을 덜어주는 strictNullChecks 옵션이 있습니다.
+strictNullChecks가 활성화되면, null과 undefined는 각각 null과 undefined라는 자체 유형을 가져옵니다.
+어떤 것이 null이 될 가능성이 있는 상황에서, 원래 타입과 함께 유니언 타입을 사용할 수 있습니다.
+예를 들어, 만약 number나 null이 될수 있는 경우, number | null로 타입을 작성할 수 있습니다.
+TypeScript가 null/undefined라고 생각할 수 있는 값을 갖고 있지만, 타입에 대해 더 잘 알고 있는 경우, 후위 연산자 !를 사용해 다르게 사용할 수 있습니다.
declare var foo: string[] | null;
-foo.length;
+foo.length;
-foo!.length;
+foo!.length;
-참고로 strictNullChecks를 사용할 때는 strictNullChecks도 사용하기 위해 의존성을 업데이트해야 할 수도 있습니다.
-묵시적인 this의 any No! (No Implicit any for this)
-클래스 밖에서 this 키워드를 사용할 때 기본적으로 any 타입을 가집니다.
-예를 들어 Point 클래스를 생각하여 메서드로 추가하고자 하는 함수를 작성해보세요 :
+앞으로, strictNullChecks를 사용할 때, 의존성이 strictNullChecks를 사용하도록 업데이트 되어야 할 수 있습니다.
+this에 대한 암시적 any 피하기 (No Implicit any for this)
+this 키워드를 클래스 밖에서 사용할 때, 기본적으로 any 타입을 가집니다.
+예를 들어, Point 클래스를 상상해 보세요, 그리고 메서드로 추가하고 싶은 함수를 상상해보세요:
class Point {
constructor(public x, public y) {}
getDistance(p: Point) {
@@ -990,7 +1134,7 @@ // ...
-
+
interface Point {
distanceFromOrigin(point: Point): number;
}
@@ -998,8 +1142,10 @@ return this.getDistance({ x: 0, y: 0});
}
-이것은 위에서 언급한 것과 동일한 문제를 가지고 있습니다 - getDistance의 철자가 틀리거나 오류가 발생하지 않을 수 있습니다.
이러한 이유로 TypeScript는 noImplicitThis 옵션을 가지고 있습니다.
이 옵션을 설정하면 TypeScript에서 명시적(또는 추론된) 타입 없이 this를 사용할 경우 오류가 발생합니다.
-해결책은 인터페이스나 함수 자체에 this-매개변수를 사용하여 명확한 타입을 제공하는 것입니다:
+위에서 언급 한 것과 같은 문제가 있습니다 - getDistance의 철자를 틀리기 쉽고 에러가 발생하지 않았습니다.
+이러한 이유 때문에, TypeScript 에 noImplicitThis 옵션이 있습니다.
+이 옵션이 설정되면, TypeScript는 this가 명시적 타입 없이 사용될 때 에러를 발생시킵니다.
+해결책은 인터페이스나 함수 자체에서 명시적 타입을 전달하기 위해 this-매개변수를 사용하는 것입니다:
Point.prototype.distanceFromOrigin = function(this: Point, point: Point) {
return this.getDistance({ x: 0, y: 0});
}
@@ -1047,7 +1193,7 @@ No results matching "
var gitbook = gitbook || [];
gitbook.push(function() {
- gitbook.page.hasChanged({"page":{"title":"JavaScript에서 마이그레이션","level":"2.4","depth":1,"next":{"title":"리액트 & 웹팩","level":"2.5","depth":1,"path":"pages/tutorials/React & Webpack.md","ref":"pages/tutorials/React & Webpack.md","articles":[]},"previous":{"title":"걸프","level":"2.3","depth":1,"path":"pages/tutorials/Gulp.md","ref":"pages/tutorials/Gulp.md","articles":[]},"dir":"ltr"},"config":{"gitbook":"*","theme":"default","variables":{},"plugins":["theme-darkblue","addcssjs","highlight-1","custom-favicon","forkmegithub","sitemap-general","sitemap","ga"],"pluginsConfig":{"github":{"url":"https://github.com/typescript-kr/typescript-kr.github.io"},"search":{},"addcssjs":{"js":[],"css":["assets/css/atom-one-dark.css"]},"lunr":{"maxIndexSize":1000000,"ignoreSpecialCharacters":false},"sitemap-general":{"prefix":"https://typescript-kr.gitbooks.io/"},"fontsettings":{"theme":"white","family":"sans","size":2},"theme-darkblue":{},"highlight":{},"favicon":"assets/images/favicon.ico","sitemap":{"hostname":"https://typescript-kr.github.io/"},"highlight-1":{},"custom-favicon":{},"ga":{"configuration":"auto","token":"UA-163809183-2"},"sharing":{"facebook":true,"twitter":true,"google":false,"weibo":false,"instapaper":false,"vk":false,"all":["facebook","google","twitter","weibo","instapaper"]},"forkmegithub":{"color":"darkblue","url":"https://github.com/typescript-kr/typescript-kr.github.io"},"theme-default":{"styles":{"website":"styles/website.css","pdf":"styles/pdf.css","epub":"styles/epub.css","mobi":"styles/mobi.css","ebook":"styles/ebook.css","print":"styles/print.css"},"showLevel":false}},"structure":{"langs":"LANGS.md","readme":"README.md","glossary":"GLOSSARY.md","summary":"SUMMARY.md"},"pdf":{"pageNumbers":true,"fontSize":12,"fontFamily":"Arial","paperSize":"a4","chapterMark":"pagebreak","pageBreaksBefore":"/","margin":{"right":62,"left":62,"top":56,"bottom":56}},"styles":{"website":"assets/css/website.css"}},"file":{"path":"pages/tutorials/Migrating from JavaScript.md","mtime":"2020-04-29T12:45:06.687Z","type":"markdown"},"gitbook":{"version":"3.2.3","time":"2020-04-29T13:40:19.688Z"},"basePath":"../..","book":{"language":""}});
+ gitbook.page.hasChanged({"page":{"title":"JavaScript에서 마이그레이션","level":"2.4","depth":1,"next":{"title":"리액트 & 웹팩","level":"2.5","depth":1,"path":"pages/tutorials/React & Webpack.md","ref":"pages/tutorials/React & Webpack.md","articles":[]},"previous":{"title":"걸프","level":"2.3","depth":1,"path":"pages/tutorials/Gulp.md","ref":"pages/tutorials/Gulp.md","articles":[]},"dir":"ltr"},"config":{"gitbook":"*","theme":"default","variables":{},"plugins":["theme-darkblue","addcssjs","highlight-1","custom-favicon","forkmegithub","sitemap-general","sitemap","ga"],"pluginsConfig":{"github":{"url":"https://github.com/typescript-kr/typescript-kr.github.io"},"search":{},"addcssjs":{"js":[],"css":["assets/css/atom-one-dark.css"]},"lunr":{"maxIndexSize":1000000,"ignoreSpecialCharacters":false},"sitemap-general":{"prefix":"https://typescript-kr.gitbooks.io/"},"fontsettings":{"theme":"white","family":"sans","size":2},"theme-darkblue":{},"highlight":{},"favicon":"assets/images/favicon.ico","sitemap":{"hostname":"https://typescript-kr.github.io/"},"highlight-1":{},"custom-favicon":{},"ga":{"configuration":"auto","token":"UA-163809183-2"},"sharing":{"facebook":true,"twitter":true,"google":false,"weibo":false,"instapaper":false,"vk":false,"all":["facebook","google","twitter","weibo","instapaper"]},"forkmegithub":{"color":"darkblue","url":"https://github.com/typescript-kr/typescript-kr.github.io"},"theme-default":{"styles":{"website":"styles/website.css","pdf":"styles/pdf.css","epub":"styles/epub.css","mobi":"styles/mobi.css","ebook":"styles/ebook.css","print":"styles/print.css"},"showLevel":false}},"structure":{"langs":"LANGS.md","readme":"README.md","glossary":"GLOSSARY.md","summary":"SUMMARY.md"},"pdf":{"pageNumbers":true,"fontSize":12,"fontFamily":"Arial","paperSize":"a4","chapterMark":"pagebreak","pageBreaksBefore":"/","margin":{"right":62,"left":62,"top":56,"bottom":56}},"styles":{"website":"assets/css/website.css"}},"file":{"path":"pages/tutorials/Migrating from JavaScript.md","mtime":"2020-05-09T11:07:22.075Z","type":"markdown"},"gitbook":{"version":"3.2.3","time":"2020-05-13T15:58:00.482Z"},"basePath":"../..","book":{"language":""}});
});
diff --git a/pages/tutorials/React & Webpack.html b/pages/tutorials/React & Webpack.html
index bf9c0f2c..ef9b443f 100644
--- a/pages/tutorials/React & Webpack.html
+++ b/pages/tutorials/React & Webpack.html
@@ -571,6 +571,103 @@
+
+
