TypeScript Deep Dive 日本語版
  • TypeScript Deep Dive 日本語版
  • TypeScript入門 & 環境構築
    • なぜTypeScriptを使うのか?
  • JavaScript
    • 等価演算子の同一性
    • リファレンス
    • nullとundefined
    • this
    • クロージャ
    • Number型
    • Truthy
  • モダンなJavaScriptの機能
    • クラス
      • Classes Emit
    • アロー関数
    • 残余引数(Restパラメータ)
    • let
    • const
    • 分割代入
    • スプレッド演算子
    • for...of
    • Iterator
    • テンプレートリテラル
    • Promise
    • ジェネレータ
    • async await
  • プロジェクトの環境設定
    • コンパイルコンテキスト
      • tsconfig.json
      • コンパイル対象ファイルの設定
    • 宣言空間
    • ファイルモジュール
      • ファイルモジュールの詳細
      • global.d.ts
    • 名前空間
    • 動的インポート
  • Node.js & TypeScriptのプロジェクト作成
  • React & TypeScriptのプロジェクト作成
  • TypeScriptの型システム
    • JavaScriptからの移行ガイド
    • @types パッケージ (DefinitelyTyped)
    • アンビエント宣言(declare)
      • 型定義ファイル
      • グローバル変数の宣言
    • インターフェース
    • Enum
    • lib.d.ts
    • 関数の型
    • 呼び出し可能オブジェクト
    • Type Assertion(型アサーション)
    • Freshness
    • 型ガード
    • リテラル型
    • Readonly
    • ジェネリック型
    • 型推論
    • 型の互換性
    • never
    • 判別可能なUnion型
    • Index signature(インデックス型)
    • 型の移動
    • 例外のハンドリング
    • ミックスイン
  • JSX
    • React
    • React以外のJSX
  • オプション
    • noImplicitAny
    • strictNullChecks
  • TypeScriptのエラー
    • エラーの理解
    • 一般的なエラー
  • NPM
  • テスト
    • Jest
    • Cypress
  • ツール
    • Prettier
    • Husky
    • Changelog
  • その他のヒント
    • String Based Enums
    • Nominal Typing
    • Stateful Functions
    • Bind is Bad
    • Currying
    • Type Instantiation
    • Lazy Object Literal Initialization
    • Classes are Useful
    • Avoid Export Default
    • Limit Property Setters
    • outFile caution
    • JQuery tips
    • static constructors
    • singleton pattern
    • Function parameters
    • Build Toggles
    • Barrel
    • Create Arrays
    • Typesafe Event Emitter
  • スタイルガイド(コーディング規約)
  • TypeScriptコンパイラの内側
    • Program
    • AST
      • TIP: Visit Children
      • TIP: SyntaxKind enum
      • Trivia
    • Scanner
    • Parser
      • Parser Functions
    • Binder
      • Binder Functions
      • Binder Declarations
      • Binder Container
      • Binder SymbolTable
      • Binder Error Reporting
    • Checker
      • Checker Diagnostics
      • Checker Error Reporting
    • Emitter
      • Emitter Functions
      • Emitter SourceMaps
    • Contributing
GitBook提供
このページ内
  • as fooと<foo>の違い
  • 型アサーションとキャスト
  • アサーションは害
  • ダブルアサーション
  • TypeScriptが単一のアサーションが不十分と判断する方法

役に立ちましたか?

  1. TypeScriptの型システム

Type Assertion(型アサーション)

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 `{}`

ここでエラーが発生するのは、fooの推論された型が{}、すなわちプロパティがゼロのオブジェクトだからです。したがって、barやbasを追加することはできません。これは、単純に型アサーションas Fooで修正することができます:

interface Foo {
    bar: number;
    bas: string;
}
var foo = {} as Foo;
foo.bar = 123;
foo.bas = 'hello';

as fooと<foo>の違い

最初に追加された構文は<foo>でした。これは以下のとおりです:

var foo: any;
var bar = <string> foo; // bar is now of type "string"

しかし、JSXで<foo>スタイルのアサーションを使用する場合、言語文法にあいまいさがあります。

var foo = <string>bar;
</string>

したがって、一貫性のためにas fooを使うことをお勧めします。

型アサーションとキャスト

それが「型キャスト」と呼ばれない理由は、_キャスト_は一般的に何らかのランタイムサポートを意味するからです。しかし、_型アサーション_は純粋にコンパイル時の構造体であり、コードをどのように解析するかについてのヒントをコンパイラに提供する方法です。

アサーションは害

多くの場合、アサーションを使用すると、レガシーのコードを簡単に移行できます(また、コードベースにほかのコードのサンプルをコピー・ペーストしたりもできます)。しかし、アサーションの使用には注意が必要です。下記のように、必要なプロパティを実際に追加するのを忘れても、コンパイラはあなたを守りません:

interface Foo {
    bar: number;
    bas: string;
}
var foo = {} as Foo;
// ahhhh .... forget something?

また、別の一般的な考え方として、_autocomplete_を提供する手段としてアサーションを使用しています。

interface Foo {
    bar: number;
    bas: string;
}
var foo = <Foo>{
    // the compiler will provide autocomplete for properties of Foo
    // But it is easy for the developer to forget adding all the properties
    // Also this code is likely to break if Foo gets refactored (e.g. a new property added)
};

しかし、危険性は同じです。プロパティを忘れた場合、コンパイラは指摘しません。次のようにする方が優れています:

interface Foo {
    bar: number;
    bas: string;
}
var foo:Foo = {
    // the compiler will provide autocomplete for properties of Foo
};

場合によっては、一時変数を作成する必要があるかもしれませんが、少なくとも(おそらく嘘の)約束をしておらず、代わりに型推論に頼ってあなたのためのチェックを行います。

ダブルアサーション

タイプアサーションは、私たちが示したように少し安全ではありませんが、完全に禁止されるものではありません。例えば以下は非常に有効なユースケースです(たとえば、ユーザーが渡されたイベントは特定ケースのイベントだと考える場合)、タイプアサーションは期待通りに機能します。

function handler (event: Event) {
    let mouseEvent = event as MouseEvent;
}

ただし、次のようなエラーが発生する可能性が最も高く、ユーザーのタイプアサーションにもかかわらず、TypeScriptがこのように表示されます。

function handler(event: Event) {
    let element = event as HTMLElement; // Error: Neither 'Event' nor type 'HTMLElement' is assignable to the other
}

あなたがその型を依然として必要とするなら、二重アサーションを使うことができますが、最初にすべての型と互換性のあるanyをアサートするので、コンパイラはもう文句を言うことはありません:

function handler(event: Event) {
    let element = event as any as HTMLElement; // Okay!
}

TypeScriptが単一のアサーションが不十分と判断する方法

基本的に、SがTのサブタイプであるか TがSのサブタイプである場合、SからTへのアサーションは成功します。これは、タイプアサーションを行う際に特別な安全性を提供するためです。完全に任意の型アサーションは非常に安全でない可能性があります。そして、安全でない状態にするために、あなたはunknown(またはany)を使用する必要があります。

as any as vs as unknown as

Typescript に関する限りどちらも同じように安全ではありません。あなたが幸せになれるものを使ってください。考慮すること:

  • Linter は unknown のほうを好みます (no-explicit-any ルールを設定している場合)

  • any は unknown よりタイプする文字数が少ない

前へ呼び出し可能オブジェクト次へFreshness

最終更新 2 年前

役に立ちましたか?