KnowHub

TypeScript言語の紹介

概要

TypeScript (略して TS) は、Microsoft によって開発された JavaScript (略して JS) に基づくプログラミング言語です。

その目的は、新しい言語を作成することではなく、JavaScript の機能を強化し、多くの人が共同作業するエンタープライズ レベルのプロジェクトにより適したものにすることです。

TypeScript は JavaScript のスーパーセットとみなすことができます。つまり、JavaScript のすべての構文を継承し、すべての JavaScript スクリプトを TypeScript スクリプトとみなすことができます (ただし、エラーが報告される場合があります)。また、独自の構文もいくつか追加されています。

TypeScript が JavaScript に追加する最も重要なことは、独立した型システムです。

型の概念

タイプとは、同じ特性を持つ値のセットを指します。 2 つの値に共通の特徴がある場合、それらは同じタイプであると言われます。

たとえば、「123」と「456」という 2 つの値の共通の特徴は、数値演算を実行できることであるため、両方とも「数値」タイプに属します。

値の型が決まると、その値はその型のすべての特性を持ち、その型のすべての操作を実行できることになります。この値は、このタイプが適用できる場合はどこでも使用できますが、このタイプが適用できない場合は、この値を使用するとエラーが報告されます。

** タイプは、人為的に追加されたプログラミング制約と使用プロンプトであることが理解できます。 ** 主な目的は、ソフトウェア開発プロセス中にコンパイラと開発ツールにさらなる検証と支援を提供し、コードの品質を向上させ、エラーを減らすことです。

以下は、型システムの役割を示す簡単な TypeScript コードです。

関数 addOne(n:number) {
  n + 1 を返します。
}

上記の例では、関数 addOne() にはパラメータ n があり、型は数値 (数値) です。これは、この位置では数値のみを使用できることを意味し、他の値を使用した場合はエラーが報告されます。値の型が渡されます。

addOne('hello') // エラーレポート

上記の例では、文字列「hello」に渡された関数「addOne()」は型が間違っていることを検出し、この位置では値だけを渡すことができ、渡すことはできないことを指摘してエラーを報告しました。文字列。

JavaScript 言語にはこの機能がなく、型が正しいかどうかをチェックしません。開発段階ではこの問題が発見されず、コードがそのまま公開されてしまい、ユーザーが使用時にエラーが発生する可能性があります。

比較のために、TypeScript は開発段階でエラーを報告するため、エラーを早期に検出し、使用中のエラー報告を回避するのに役立ちます。一方、関数定義に型を追加すると、プロンプト効果があり、開発者にこの関数の使用方法を伝えることができます。

動的型と静的型

前述したように、TypeScript の主な機能は、JavaScript に型システムを追加することです。ご存知かもしれませんが、JavaScript 言語自体には、値 123 や文字列 Hello などの独自の型システムがあります。

ただし、JavaScript の型システムは非常に弱いため、演算子はさまざまな型の値を受け入れることができます。構文的には、JavaScript は動的に型指定される言語です。

以下の JavaScript コードをご覧ください。

//例1
x = 1 とします。
x = 'こんにちは';

//例2
y = { foo: 1 }; とします。
y.fooを削除します。
y.バー = 2;

上記の例 1 では、変数 x を宣言したとき、値の型は数値ですが、後で文字列に変更することができます。したがって、変数の型が何であるかを事前に知ることは不可能です。つまり、変数の型は動的です。

上記の 2 番目の例では、変数 'y' はオブジェクトであり、属性 'foo' を持っていますが、この属性は削除でき、他の属性を追加できます。したがって、オブジェクトがどのような属性を持っているか、またその属性がまだ存在しているかどうかも動的であり、事前に知ることはできません。

JavaScript の型システムが動的であり、それほど制限的ではないのは、まさにこれらの動的な変更のためです。これは、コードエラーを事前に検出する上で非常に有害です。

TypeScript は、より強力で厳密な型システムを導入しており、静的に型付けされる言語です。

上記のコードは TypeScript でエラーを報告します。

//例1
x = 1 とします。
x = 'hello'; // エラーレポート

//例2
y = { foo: 1 }; とします。
y.foo を削除します // エラーを報告します
y.bar = 2; // エラーを報告します。

上記の例では、例 1 で報告されたエラーは、TypeScript が変数を割り当てるときにすでに型を推論しており、それ以降は他の型の値への代入を許可しないためです。つまり、変数の型は静的です。例 2 で報告されるエラーは、オブジェクトのプロパティも静的であり、任意の追加や削除ができないためです。

TypeScript の役割は、この静的型機能を JavaScript に導入することです。

静的型付けの利点

静的型付けには多くの利点があり、それが TypeScript の目標です。

(1) コードの静的分析に役立ちます。

静的型付けを使用すると、コードを実行せずに変数の型を判断し、コードにエラーがあるかどうかを推測できます。これをコードの静的解析と呼びます。

これは大規模なプロジェクトにとって非常に重要です。開発段階で静的チェックを実行するだけで、多くの問題を発見し、問題のあるコードの提供を回避し、オンラインのリスクを大幅に軽減できます。

(2) エラーの発見に役立ちます。

すべての値、すべての変数、すべての演算子には厳密な型制約があるため、TypeScript ではスペル エラー、セマンティック エラー、メソッド呼び出しエラーを簡単に検出でき、プログラマの時間を節約できます。

let obj = { メッセージ: '' };
console.log(obj.messege); // エラーレポート

上の例では、message が誤ってスペルを間違えて messege と書かれてしまいました。 TypeScript は、このプロパティが定義されていないことを示すエラーを報告します。この状況が発生した場合、JavaScript はエラーを報告しません。

定数 a = 0;
const b = true;
const result = a + b; // エラーレポート

上記の例は正当な JavaScript コードですが、意味がありません。数値 'a' をブール値 'b' に加算するべきではありません。 TypeScript はエラーを直接報告し、演算子「+」を数値とブール値の加算に使用できないことを通知します。

関数 hello() {
  「Hello World」を返します。
}

hello().find('hello'); // エラーレポート

上記の例では、hello() は文字列を返します。TypeScript はその文字列に find() メソッドがないことが検出されるため、エラーが報告されます。 JavaScript の場合、エラーは実行フェーズでのみ報告されます。

(3) 構文プロンプトや自動補完など、IDE サポートの向上。

IDE (VSCode などの統合開発環境) は通常、型情報を使用して、構文プロンプト機能 (エディターが関数の使用方法、パラメーターなどを自動的にプロンプ​​ト表示します) と自動補完機能 (変数名または関数名の一部のみを入力し、編集者が後半を完了します）。

(4) コードドキュメントが提供されます。

型情報は、コードの使用方法を説明するコード ドキュメントの一部を置き換えることができ、多くの場合、型を見るだけでコードの機能を推測できます。多くのツールは、型情報を使用してドキュメントを直接生成できます。

(5) コードのリファクタリングに役立ちます。

他の人の JavaScript コードを変更することは、プロジェクトが大きければ大きいほど、その変更がコードの他の部分に影響を与えるかどうかが分からないため、非常に苦痛になることがよくあります。

型情報により、リファクタリングのコストが大幅に削減されます。一般に、関数またはオブジェクトのパラメータと戻り値が同じ型である限り、リファクタリングされたコードは基本的に正常に実行されることが確実です。サポートする単体テストがある場合は、自信を持ってリファクタリングできます。プロジェクトが大規模になり、複数の人によるコラボレーションが行われるほど、より多くのヘルプ タイプの情報が提供されます。

要約すると、TypeScript はコードの品質を向上させ、コードのセキュリティを確保するのに役立ち、大規模なエンタープライズ レベルのプロジェクトでの使用により適しています。これが、多数の JavaScript プロジェクトが TypeScript に変換される理由です。

静的型付けの欠点

静的型付けにはいくつかの欠点もあります。

(1) 動的型のコードの柔軟性が失われます。

動的型付けには非常に高い柔軟性があり、静的型付けではプログラマーに多くの自由が与えられます。

(2) プログラミングの負荷が増加します。

型を取得した後、プログラマは関数を記述するだけでなく、型が正しいことを確認するために型宣言も記述する必要があります。これにより多くの作業が追加され、プロジェクトの開発時間が大幅に長くなる場合があります。

(3) 学習コストが高くなります。

通常、型システムはより複雑で、より多くのことを学習する必要があり、開発者はより高い学習コストを支払う必要があります。

(4) 独立したコンパイル手順が導入されます。

ネイティブ JavaScript コードは、JavaScript エンジンで直接実行できます。型システムを追加した後、型が正しいかどうかを確認し、実行できるように TypeScript コードを JavaScript コードに変換する別のコンパイル手順があります。

(5) 互換性の問題。

TypeScript は JavaScript エコシステムに依存しており、多くの外部モジュールを使用する必要があります。ただし、これまでほとんどの JavaScript プロジェクトは TypeScript の適応を行っていませんでしたが、それを自分で行うこともできますが、使用する際には互換性の問題がいくつか発生します。

全体として、これらの欠点により、TypeScript は小規模で短期的な個人プロジェクトには必ずしも適していません。

TypeScript の歴史

以下に、TypeScript の開発の歴史を簡単に紹介します。

2012 年、Microsoft は、C# と .NET の設計者でもある有名なプログラミング言語設計の達人、Anders Hejlsberg によって設計された TypeScript 言語の発売を発表しました。

Microsoft がこの言語を発表した主な目的は、JavaScript プログラマーが Windows 8 アプリケーションの開発に参加できるようにすることです。

当時は Windows 8 がリリースされようとしており、そのアプリケーション開発では C# や Visual Basic に加えて HTML + JavaScript も使用できました。 Microsoft は、TypeScript によって JavaScript プログラマがすぐに始められるようになるだけでなく、.Net プログラマも親しみを感じられるようになることを期待しています。

とはいえ、TypeScript の元々の動機は、.NET プログラマーの移行コストと学習コストを削減することでした。したがって、その構文概念の多くは .NET と非常に似ています。

なお、TypeScriptはコミュニティ参加を受け付けたオープンソースプロジェクトであり、コアコンパイラはApache 2.0ライセンスを採用しています。 Microsoft は、このアプローチを通じて、コミュニティでのこの言語の受け入れが急速に高まることを期待しています。

2013 年に、Microsoft の Visual Studio 2013 に TypeScript 言語のサポートが組み込まれ始めました。

2014 年に TypeScript 1.0 バージョンがリリースされました。同年、コード リポジトリは GitHub に移動されました。

2016 年に TypeScript 2.0 がリリースされ、多くの主要な文法機能が導入されました。

2018 年に TypeScript 3.0 バージョンがリリースされました。

2020 年に TypeScript 4.0 バージョンがリリースされました。

2023 年に TypeScript 5.0 バージョンがリリースされる予定です。

学習方法

TypeScript を学習するには、まず JavaScript の構文を理解する必要があります。実際の機能は JavaScript エンジンによって実行されるため、TypeScript は型システムを追加するだけです。

この本は、読者が JavaScript 言語をすでに知っていることを前提としており、その構文については紹介しません。TypeScript によって導入された新しい構文 (主に型システム) のみを紹介します。

JavaScript に詳しくない場合は、"JavaScript チュートリアル" および "ES6 チュートリアル" を読む前に読むことをお勧めします。この本。

作者: wangdoc

アドレス: https://wangdoc.com/

ライセンス: クリエイティブ・コモンズ 3.0

次の章