はてなブックマーク

Definitely Typed は、間違いなくTypeScriptの最大の強みの1つです。コミュニティは効率的にトップJavaScriptプロジェクトのほぼ90％の型ドキュメントを作成しました。 これは、これらのプロジェクトを非常にインタラクティブかつ探索的な方法で使用できることを意味します。タイプミスを防ぐためにドキュメントを別のウィンドウで開く必要はありません。

コピー{ "compilerOptions": { "sourceMap": true, "module": "commonjs", "esModuleInterop": true, "resolveJsonModule": true, "experimentalDecorators": true, "target": "es5", "jsx": "react", "lib": [ "dom", "es6" ] }, "include": [ "src" ], "compileOnSave": false } コピー{ "name": "react-typescript", "version": "0.0.0", "license": "MIT", "repository": { "type": "git", "url": "https://github.com/basarat/react

literal型のメンバを持つクラスがある場合、そのプロパティを使用して、Union型のメンバを判別することができます。 例として、SquareとRectangleのUnionを考えてみましょう。ここではkind（特定のリテラル型）は両方のUnion型のメンバに存在しています: コピーinterface Square { kind: "square"; size: number; } interface Rectangle { kind: "rectangle"; width: number; height: number; } type Shape = Square | Rectangle; 判別用のプロパティ(ここではkind)に対して、型安全なチェック(==、===、!=、!==)またはswitchを使用すると、TypeScriptはあなたのために、そのリテラル型を持つオブジェクトの

TypeScriptはJavaScriptのinstanceofとtypeof演算子の使用を認識しています。条件付きブロックでこれらを使用すると、TypeScriptはその条件ブロック内で異なる変数の型を理解します。ここでは、TypeScriptが特定の関数がstringに存在せず、おそらくユーザーのタイプミスであったことを指摘する簡単な例を示します： コピーfunction doSomething(x: number | string) { if (typeof x === 'string') { // Within the block TypeScript knows that `x` must be a string console.log(x.subtr(1)); // Error, 'subtr' does not exist on `string` console.log(x.

TypeScriptが推論、分析された型は、任意の方法で上書きできます。これは、型アサーション(type assertion)と呼ばれるメカニズムによって行われます。TypeScriptの型アサーションは、純粋にコンパイラよりもその型をより良く理解していることだけでなく、後で推測するべきではないことをコンパイラに伝えています。 型アサーションの一般的な使用例は、JavaScriptからTypeScriptへコードを移植する場合です。たとえば、次のパターンを考えてみましょう。 コピーvar foo = {}; foo.bar = 123; // Error: property 'bar' does not exist on `{}` foo.bas = 'hello'; // Error: property 'bas' does not exist on `{}` ここでエラーが発生するのは

TypeScript(およびJavaScript)クラスは、厳密な単一継承をサポートします。あなたはこれをすることはできません： コピーclass User extends Tagged, Timestamped { // ERROR : no multiple inheritance } 再使用可能なコンポーネントからクラスを構築する別の方法は、mixinと呼ばれるより単純な部分クラスを組み合わせてそれらを構築することです。 アイデアはシンプルです。クラスBの機能を得るために_クラスBを継承するクラスAを_定義するのではなく、その代わりに_クラスAを取る関数B_を定義して、機能を追加した新しいクラスを返すようにするのです。関数Bはミックスインです。 [mixinは] コピー// Needed for all mixins type Constructor<T = {}> = new (.

なぜTypeScriptを使うのか？について説明したとき、TypeScriptの型システムの主な機能を取り上げました。下記は、改めて説明する必要がない、いくつかのキーポイントです： TypeScriptの型システムは_使うかどうか選べるもの_として設計されているので、あなたが書いたJavaScriptはTypeScriptでもあります。

一般的なユースケースは、静的な文字列と変数を組み合わせて何らかの文字列を生成することです。このために何かしらのテンプレートロジック( templating logic )が必要です。これはテンプレート文字列( template strings )の由来になったものです。これらは、公式にテンプレートリテラル( template literals )という名前に変更されました。下記は、今まであなたがhtmlを生成する時に使っていたかもしれない方法です。

スプレッド演算子の主な目的は、配列またはオブジェクトの要素を_展開_することです。これは例を見るのが最も分かりやすいです。

思考実験として、次のことを想像してみてください： await のキーワードがPromiseに対して使われた場合、JavaScriptコードの実行を一時停止します。そして、その関数から返されたPromiseが完了した場合にだけ、コードの実行が再開されます。このようにJavaScriptランタイムを制御する方法を想像してみてください: コピー// 実際のコードではありません。ただの思考実験です。 async function foo() { try { var val = await getMeAPromise(); console.log(val); } catch(err) { console.log('Error: ', err.message); } }

TypeScriptはFreshness(厳密なオブジェクトリテラルチェックとも呼ばれます)という概念を提供します。それはオブジェクトリテラルや構造的に互換性がある型の型チェックを簡単にします。 構造型は非常に便利です。次のコードを考えてみましょう。これにより、型安全性のレベルを維持しながら、JavaScriptをTypeScriptに非常に便利にアップグレードすることができます： コピーfunction logName(something: { name: string }) { console.log(something.name); } var person = { name: 'matt', job: 'being awesome' }; var animal = { name: 'cow', diet: 'vegan, but has milk of own species' }

never型のビデオレッスン プログラミング言語の設計には、bottom型の概念があります。それは、データフロー解析を行うと現れるものです。TypeScriptはデータフロー解析(😎)を実行するので、決して起こりえないようなものを確実に表現する必要があります。 never型は、このbottom型を表すためにTypeScriptで使用されます。自然発生するケース：

これらの点のいくつかをさらに議論しましょう。 すべてのJavaScriptは_有効な_TypeScriptであることに注意してください。つまり、TypeScriptコンパイラにJavaScriptをいくつか与えると、TypeScriptコンパイラによって生成されたJavaScriptは元のJavaScriptとまったく同じように動作します。つまり、拡張子を.jsから.tsに変更しても、コードベースに悪影響はありません。 TypeScriptはすぐに型チェックを開始しますが、元のJavaScriptコードはあなたが思っていたほど整っていない可能性があります。したがって、エラーが発生します。これらのエラーの多くは、anyを使用して抑制することができます。例：

TypeScriptの型システムでは、インターフェース上の個々のプロパティをreadonlyとしてマークすることができます。これにより、関数的に作業することができます(予期しない変更は良くありません)。 コピーfunction foo(config: { readonly bar: number, readonly bas: number }) { // .. } let config = { bar: 123, bas: 123 }; foo(config); // You can be sure that `config` isn't changed 🌹 コピーtype Foo = { readonly bar: number; readonly bas: number; } // Initialization is okay let foo: Foo = { bar: 123, b

TypeScriptの型システムは構造的です。そして、これはTypeScriptを使う理由の一つです。しかし、同じ構造を持っていても、2つの変数が異なる_型名_を持つ2つの変数を区別する必要があるシステムのユースケースがあります。非常に一般的な使用例は、identity構造(一般的にC#/Javaなどの言語において_名前_と関連するセマンティクスを持つただの文字列)です。 コミュニティでは、いくつかのパターンが登場しています。私の個人的な好みで降順に説明します: コピー/** Generic Id type */ type Id<T extends string> = { type: T, value: string, } /** Specific Id types */ type FooId = Id<'foo'>; type BarId = Id<'bar'>; /** Optiona

列挙型は、関連する値の集合を編成する方法です。他の多くのプログラミング言語(C/C#/Java)はenumデータ型を持っていますが、JavaScriptはありません。しかし、TypeScriptにはあります。TypeScript列挙型の定義例を次に示します。 コピーenum CardSuit { Clubs, Diamonds, Hearts, Spades } // Sample usage var card = CardSuit.Clubs; // Safety card = "not a member of card suit"; // Error : string is not assignable to type `CardSuit`

Jest/TypeScriptに関するPro eggheadレッスン パーフェクトなテストのソリューションはありません。とはいえ、jestは優れたTypeScriptサポートを提供する素晴らしいユニットテストのオプションです。 注意：単純なノードのpackage.json setupで始めることを前提としています。また、すべてのTypeScriptファイルはsrcフォルダに置かれていなければなりません。このフォルダは、きれいなプロジェクト設定のために(Jestを使わなくても)常に推奨されます。

JavaScript(TypeScript)のObjectは、他のJavaScriptオブジェクトへの参照を保持し、文字列でアクセスできます。 簡単な例： コピーlet foo:any = {}; foo['Hello'] = 'World'; console.log(foo['Hello']); // World

動的インポートは新しい機能であり、ECMAScriptの一部で、ユーザーはプログラムの任意の時点でモジュールを非同期にロードできます。 TC39(JavaScript committee)が、その提案（import() proposal for JavaScript）を行っており、ステージ3の段階にあります。 また、webpackバンドラにはバンドルを分割することができるCode Splittingという機能があります。それは、コードをチャンクファイルに分割し、後で非同期にダウンロードされるようにすることができます。たとえば、これにより、最小の起動用のバンドルを最初に提供し、後で追加の機能を非同期にロードすることができます。 私たちの開発ワークフローでwebpackを使用している場合、TypeScript 2.4 dynamic import expressionsは自動的にチャンク化され

Promiseクラスは、多くのモダンなJavaScriptエンジンに存在しており、簡単にpolyfillすることができます。Promiseを使いたい理由は、非同期/コールバック的なスタイルのコードに対して、同期処理の書き方でエラーを取り扱うことができるからです。 Promiseを完全に理解するため、信頼性の高い非同期処理をコールバックだけで構築する難しさをサンプルコードで示します。ファイルからJSONをロードする処理の非同期バージョンを作成するケースを考えてみましょう。これの同期処理バージョンは非常にシンプルです: コピーimport fs = require('fs'); function loadJSONSync(filename: string) { return JSON.parse(fs.readFileSync(filename)); } // 正しいjsonファイル cons

TypeScriptは以下の分割(Destructuring)をサポートしています(文字通り、de-structuringから来ています。つまり、構造を分解します)。

thisはJavaScriptにおいて昔から頭痛の種でした。 ある賢い人は「thisの意味をすぐに忘れるJavaScriptが嫌いだ」と言いました。アロー関数は、それを囲んだコンテキストからthisを捕捉します。純粋なJavaScriptだけで書かれたクラスを使って考えてみましょう： コピーfunction Person(age) { this.age = age; this.growOld = function() { this.age++; } } var person = new Person(1); setTimeout(person.growOld,1000); setTimeout(function() { console.log(person.age); },2000); // 1, should have been 2

foo.ts(これはあなたのファイルの多くが参照しているものです)から、より多くのものをexportする必要がある場合、import構文をいじくる必要があります。

非公式のTypeScriptスタイルガイド スタイルガイドについて意見を求められることはよくあります。個人的には、私は自分のチームやプロジェクトにコーディングスタイルをあまり強制してはいませんが、コードに一貫性が必要だと思う人がいるような状況において、基準として以下で述べるようなスタイルガイドがあることが役に立つのは確かです。個人的にはスタイルよりもはるかに強い意見を持っている観点があり、それについてはヒントの章で説明しています（例えば、型アサーションはよくない、プロパティーsetterはよくない、など）🌹 主要セクション：

型の互換性は、あるものを別のものに割り当てることができるかどうかを決定します。例えばstringとnumberは互換性がありません： コピーlet str: string = "Hello"; let num: number = 123; str = num; // ERROR: `number` is not assignable to `string` num = str; // ERROR: `string` is not assignable to `number`

優れたインタラクティブなGoogle Chromeのデバッグ環境を提供します。これは、UI開発者が手動で作業する方法と非常によく似ています

文法(シンタックス)が正しいものが_意味_(セマンティクス)が正しいことを意味するわけではありません。以下のTypeScriptコードを考えてみましょう。文法は有効ですが、意味は間違っています:

コピー// variable annotation var sampleVariable: { bar: number } // function parameter annotation function foo(sampleParameter: { bar: number }) { }