TypeScriptの復習しまーす <h2 id="h59bec1c303">共用体型と交差型</h2> <h3 id="hcdd0d7216a">共用体型(UnionTypes、ユニオン型)</h3> 演算子|でプリミティブ型を並べることで、それらの内のいずれの型でも許容すると言う意味になる。<pre><code>let id: number | string = 11111;
id //11111
id = "あああああ"
id //"あああああ"</code></pre> オブジェクト型を共用体型にすることもできる。 プリミティブ型と同じでいずれのオブジェクトの型でも許容するという意味。<pre><code>type A = {
 foo: number;
 bar?: string;
};
type B = { foo: string };
type C = { bar: string };
type D = { baz: boolean };
type AorB = A | B; // { foo: number | string; bar?: string }
type AorC = A | C; // { foo: number; bar?: string } or { bar: string }
type AorD = A | D; // { foo: number; bar?: string } or { baz: boolean }</code></pre> <h3 id="h783bcf17ce">交差型(IntersectionTypes、インターセクション型)</h3> 演算子&amp;で型を並べることで、「A かつ B」である型と言う意味になる。オブジェクト型の合成に使われる。プリミティブ型には使われない。 プリミティブ型で使用されないのは、「number型 かつ string型」と言う型が存在し得ないから。 <img src="https://images.microcms-assets.io/assets/f772f1225a7a4d20a85cc60a89d909a9/9a3aef53bf364a73869ac295c7edf825/%E3%83%95%E3%82%9A%E3%83%AA%E3%83%9F%E3%83%86%E3%82%A3%E3%83%95%E3%82%99%E5%9E%8B_intersection.png" alt=""> オブジェクトの交差型は以下のように使用する。<pre><code>type A = { foo: number };
type B = { bar: string };
type C = {
 foo?: number;
 baz: boolean;
};
type AnB = A &amp; B; // { foo: number, bar: string }
type AnC = A &amp; C; // { foo: number, baz: boolean }
type CnAorB = C &amp; (A | B);
// { foo: number, baz: boolean } or { foo?: number, bar: string, baz: boolean }</code></pre>注意する点はこんな感じ<ul><li>AnC 型の foo プロパティのように、同じ型でありながら必須と省略可能が交差したら、必須のほうが優先される。</li><li>もし同じプロパティで型が共通点のないものだった場合は、never 型になる。</li></ul> <h2 id="hb7fa4528d7">非 Null アサーション演算子(!)</h2> オプショナルのプロパティにアクセスしようとするとtypescriptが「ここはnullの可能性がありますよ」とコンパイルエラーを吐く。 このコンパイルエラーを強制的に黙らせる方法として非Nullアサーション演算子(!)を使用すると言う方法がある。 これは「ここには絶対に null も undefined も入りませんよ」とコンパイラを強引に黙らせるもの。 ただこれはせっかくの null 安 全性を壊すもので、実際に値が null や undefined だったら実行時エラーになる。だから余程の保証がない限りは使うべきではない。 <h2 id="hc3cd8158a8">型表現に使われる演算子</h2> <h3 id="hd84ed8dfac">typeof演算子</h3>通常の式では渡された値の型の名前を文字列として返す。<pre><code>console.log(typeof 100); // 'number'

const arr = [1, 2, 3];
console.log(typeof arr); // 'object'</code></pre> 型の文脈で用いると変数から型を抽出してくれる。<pre><code>type NumArr = typeof arr;　//型推論でnuber[]型を抽出してくれる。
const val: NumArr = [4, 5, 6];
const val2: NumArr = ["foo", "bar", "baz"]; // compile error!</code></pre> <h3 id="hf72ac13fc4">in演算子</h3>通常の式では指定した値がオブジェクトのキーとして存在するかどうかの真偽値を返す。<pre><code>const obj = { a: 1, b: 2, c: 3 };
console.log('a' in obj); // objと言うオブジェクトの中にaと言うキーは存在する？
// true</code></pre> for...in文では、オブジェクトからキーを抽出するのに使われる。<pre><code>for (const key in obj) { console.log(key); } // a b c</code></pre> ※for...in文の一般的な構文。<pre><code>for( const 変数 in オブジェクト ) {
&nbsp;
 //ここに繰り返し処理を書く
&nbsp;
}</code></pre>オブジェクトのキーが一つずつ変数に格納されて処理を行うことができる。 型の文脈 で使用すると、列挙された型の中から各要素の型の値を抜き出して マップ型（Mapped Types）というものを作る。<pre><code>type Fig = "one" | "two" | "three"; //文字列リテラルの共用体型
type FigMap = { [k in Fig]?: number }; //マップ型を作成

const figMap: FigMap = {
 one: 1,
 two: 2,
 three: 3,
};

figMap.four = 4; // compile error!</code></pre> <h3 id="hb73438ea8b">keyof演算子</h3> 型の文脈のみで用いられる演算子。オブジェクトの型からキーを抜き出すことができる。<pre><code>type Foo = {
 a: number;
 b: string;
};

type A = keyof Foo; </code></pre> keyof typeof と繋げると、オブジェクトのキーの型を出力することができる。<pre><code>const permissions = {
 r: 0b100,
 w: 0b010,
 x: 0b001,
};
type PermsChar = keyof typeof permissions; // 'r' | 'w' | 'x'
const readable: PermsChar = "r";
const writable: PermsChar = "z"; // compile error!</code></pre> TypeScriptにはvalueof演算子はないので、バリューを抜き出したい場合はインデックスアクセス演算子[]を使うことでやりたいことができる。 <h3 id="he89cf1be50">型表現に使われる演算子まとめ</h3> それぞれの演算子を型の文脈で使用した場合の挙動をまとめます。 typeof ... 渡された値から型を抽出する in ... 列挙された型の中から各要素の型の値を抜き出して マップ型（Mapped Types）というものを作る。 keyof ... 型の文脈のみで用いられる演算子。オブジェクトの型からキーを抜き出すことができる。 <h2 id="h42b8810d6f">型アサーションと型ガード</h2> <h3 id="h4eff2c69f4">asによる型アサーション</h3> 型が分からない値をTypeScriptでうまく扱う一番手っ取り早い解決方法として、型アサーション(Tyep Assertion)を行うと言う手段がある。 型アノテーションと似てるけど単語の意味としては、「annotation」が「注釈」で、「assertion」が「断定」。 「これは〇〇型ですよ~」がアノテーションだとしたら、「いやこれは絶対〇〇型だから！」がアサーション。 アサーションした型がうまく適合している限りは問題なく動くが、適合していない場合は以下のようなことが起きてしまう。<pre><code>type User = { username: string; address: { zipcode: string; town: string } };
const str = `{ "username": "patty", "town": "Maple Town" }`;
const data: unknown = JSON.parse(str);
const user = data as User;
console.log(user.address.town); // TypeError: Cannot read property 'town' of undefined(実行時のエラー)</code></pre> コンパイル時にはエラーを吐かないが、実行時にエラーが出てしまう。 なので、型アサーションは根拠なく開発者の判断がまかり通ってしまう、型安全性が全く保証されていない方法であると言える。 <h3 id="h323d6d205a">型キャストと型アサーション</h3> 型キャストと型アサーションは別物<pre><code>export const n = 123;
const s1 = String(n); //型キャスト
console.log(typeof s1);
//string
const s2 = n as string; //型アサーション
// error</code></pre> 前半で行っている型キャストは、異なるデータ型の値を任意の型にコンバート(変換)するもの。 後半の型アサーションはあくまでコンパイラによる型の解釈が変わるだけであって、実際の値が変化するわけではない。 型キャストで数値の123を文字列の"123"にすることは可能だが、 誰がどうみてもリテラルnumber型の123に対して、型アサーションで「いやこれstring型だぜ！」って言えば当然エラーが出る。 型キャストと型アサーションの違いは、「実際の値を変えているか、型の解釈を変えているか」。 <h3 id="h2a004344ce">型ガード</h3> あるスコープ内での型を保証するチェックを行う式のことを、「型ガード(Type Guards)」と言う。 例えば以下のような処理も型ガードの一種である。<pre><code>export const foo: unknown = "1,2,3,4";
if (typeof foo === "string") {
 console.log(foo.split(","));
}
console.log(foo.split(",")); // compile error!</code></pre> unknown型を当てた変数fooをtypeofによってstring型である場合にのみ、split();を使用できるようにしている。 このifのスコープ外でfooに対してsplitを使用しようとすると、fooはunknown型なので当然split()が使用できず、コンパイルエラーが出る。 より安全なコードを書くためには、コンパイルを通すために場当たり的に型アサーションを行うのではなく、型ガードを積極的に行っていくべき。 クラスのインスタンスであればinstanceofを使用して型ガードを実装することができる。<pre><code>export class Base {
 common = "common";
}
class Foo extends Base {
 foo = () =&gt; {
 console.log("foo");
 };
}
class Bar extends Base {
 bar = () =&gt; {
 console.log("bar");
 };
}
const doDivide = (arg: Foo | Bar) =&gt; {
 if (arg instanceof Foo) { //引数がFooのインスタンスである場合に実行
 arg.foo();
 arg.bar(); // compile error!
 } else { //引数がBarのインスタンスである場合に実行
 arg.bar();
 arg.foo(); // compile error!
 }
 console.log(arg.common);
};
doDivide(new Foo());//インスタンス生成 &amp; 関数呼び出し
doDivide(new Bar());</code></pre> ただしクラスを下敷きにしていないただのオブジェクトではこの方法を使うことができないので、自前で型を絞り込むしくみを作ってあげる必要がある。 この方法は「ユーザー定義の型ガード 」と呼ばれる。 <pre><code>type User = { username: string; address: { zipcode: string; town: string } };
const isUser = (arg: unknown): arg is User =&gt; {
 const u = arg as User;
 return (
 typeof u?.username === "string" &amp;&amp;
 typeof u?.address?.zipcode === "string" &amp;&amp;
 typeof u?.address?.town === "string"
 );
};

const u1: unknown = JSON.parse("{}");
const u2: unknown = JSON.parse('{ "username": "patty", "address": "Maple Town" }');
const u3: unknown = JSON.parse(
 '{ "username": "patty", "address": { "zipcode": "111", "town": "Maple Town" } }'
);
[u1, u2, u3].forEach((u) =&gt; {
 if (isUser(u)) {
 console.log(`${u.username} lives in ${u.address.town}`);
 } else {
 console.log("It's not User");
 console.log(`${u.username} lives in ${u.address.town}`); // compile error!
 }
});</code></pre> 関数 isUser() の戻り値の型定義のarg is User と言う表現は、型述語（Type Predicate）という表現で、この関数が true を返す場合に引数 arg の型が User であると言うことをコンパイラに教えている的な意味になる。 ↓この関数の返り値がtrueなら、<pre><code>const isUser = (arg: unknown): arg is User =&gt; {
};</code></pre> こんな感じになるよ！って感じ。<pre><code>const inUser = (arg: User): boolean =&gt; {
 return(
 true
 )
}</code></pre> こんな感じでただのオブジェクトに対して事前に型を絞り込む方法を「ユーザー定義の型ガード」と呼ぶ。 <h3 id="h49e19216d3">型アサーションと型ガードのまとめ</h3> <ul><li>型アサーションとは、プログラマがコンパイラの判断を無視して型を断定する方法のこと。</li><li>unknown型などの、型がわからない値をTypeScriptうまく扱うために、一番手っ取り早いのが型アサーションを使用して型を断定する方法。</li><li>しかし型アサーションは根拠なく開発者の判断がまかり通る、型安全性が全く保証されていない方法なので、「型ガード」を使用する方が良いとされている。</li><li>型ガードとは、あるスコープ内での型を保証するチェックを行う式のこと。</li><li>プリミティブ型であればtypeofを使用してifの条件式で型を絞り込むことで型ガードを実装できる。</li><li>クラスのインスタンスであればinstanceofを使用して引数があるクラスのインスタンスであるかどうかを判断して型ガードを実装できる。</li><li>クラスが下敷きになっていないただのオブジェクトであれば、「ユーザー定義の型ガード」と言う型を絞り込むシステムを事前に作成する方法を使用して型ガードを実装できる。型述語(is)を使用して、引数に渡される型がある型であるかどうかを判断することができる。</li></ul> 今日はTypeScriptの色々を復習しました〜 最後までごらんいただきありがとうございました~！

TypeScript復習

<h3 id="h689793efd7">コピーサイト作成の進捗報告から</h3>初めに、UnBlogのコピーサイト作成は現在こんな感じです。↓ <a href="https://micro-cms-3hzpij77n-sakai-141014.vercel.app/blog/ku00q5qnb" target="_blank" rel="noopener noreferrer">https://micro-cms-3hzpij77n-sakai-141014.vercel.app/blog/ku00q5qnb</a> ※ブログ本文のスタイル適用はガチモンUnBlogのソースコードから拝借しました。ゲヘヘ。いつか自分でスタイル当てます！ 開発環境では数値のpropsが問題なく渡せてビューに反映されているのに、本番環境では反映されていない挙動が起きて悩んでます。 <img src="https://images.microcms-assets.io/assets/f772f1225a7a4d20a85cc60a89d909a9/64d5ecb5110549f688218ac6cd58a94d/%E6%9C%AC%E7%95%AA%E7%92%B0%E5%A2%83%E3%81%A6%E3%82%99props%E3%81%8B%E3%82%99%E6%B8%A1%E3%81%9B%E3%81%A6%E3%81%84%E3%81%AA%E3%81%84.png" alt=""> 投稿に関連づけられているタグを表示しているここのところですね。 こんな感じでpropsを渡しています。<pre><code>&lt;RelatedTags data={data} marginTop={2} /&gt;</code></pre>dataは投稿の情報ですね。tagの情報が配列で格納されているのでmapで反復処理を行って表示してます。 そしてタグが多くなったときに若干タグとタグの間のスペースを開けたかったので、marginTopを数値としてpropsで渡しています。 これが開発環境では問題なく反映されてるけど本番環境では反映されない... なんでだ~!! てか今気づいたけどボタンが表示されてないところがある...(°_°) なんで本番環境なった途端表示されなくなんの！せめてエラー出して！ まぁ一旦置いといて本題に入ります。 <h2 id="h7ab81cf170">interfaceとtypealiasの違い</h2> 今日はTypeScriptでオブジェクトの型を定義する際に使用するinterfaceと型エイリアス(type alias)の違いについて勉強していきたいと思います。 interface での型定義はこんな感じ<pre><code>interface Test {
 name: string;
 age: number;
}</code></pre> typealias での型定義はこんな感じ<pre><code>type Test = {
 name: string;
 age: number;
}</code></pre> 2021年時点のバージョンで、interface と typealiasは、「できることの多さ」と言う視点で見ると、大差はないようです。 特徴の違いとしては、interfaceはtypealiasよりも拡張性があるというところです。 具体的な例で言うと、interfaceは同名の型を宣言すると宣言が追加(マージ)されますが、typealiasは同名の型を定義するとエラーが出ます。 結論から言うと、ライブラリ開発などの不特定多数が利用する物に関しては拡張性を持たせるためにinterface。 アプリケーション等の全ての型が拡張性を持つとバグを生むような物に関してはtypealiasを使用するのがいい。 といったような感じになるようです。 それではinterfaceやtypeがどのような物なのかを見ていきましょう。 <h3 id="hf3f02a1059">intefaceの基本的な使い方と宣言のマージ</h3> interface宣言子で定義することができます。<pre><code>interface Person {
 name: string;
}</code></pre>classの宣言と似たような書き方ですね。 同じ名前のinterfaceを宣言すると型が追加(マージ)されます。 (name: string; age: number; にしたつもりだったけど逆になってましたすんまそん) <img src="https://images.microcms-assets.io/assets/f772f1225a7a4d20a85cc60a89d909a9/2788880c491e4fd18ae3e44ea5e35abb/interface_%E5%9E%8B%E3%81%AE%E3%83%9E%E3%83%BC%E3%82%B7%E3%82%99.png" alt=""> こんな感じで型を定義すると... nameとageのプロパティがないよ！と怒られました。 型の宣言がきちんとマージされている証拠ですね。 <img src="https://images.microcms-assets.io/assets/f772f1225a7a4d20a85cc60a89d909a9/7d853d77bf094e9aba39233268ee9b41/interface_%E3%83%9E%E3%83%BC%E3%82%B7%E3%82%99%E3%81%95%E3%82%8C%E3%81%9F%E5%9E%8B%E3%81%AE%E7%A2%BA%E8%AA%8D.png" alt=""> <h3 id="hb1f455f547">typealiasで型のマージを表現</h3> typealiasでも交差型(union型)を使えば型のマージを表現できます。 同名の型は定義できないのでそこは注意が必要です。 <img src="https://images.microcms-assets.io/assets/f772f1225a7a4d20a85cc60a89d909a9/61eabe4b913a4ef4ad0776d476d93b35/typealias_union%E5%9E%8B%E3%81%AB%E3%82%88%E3%82%8B%E5%9E%8B%E3%81%AE%E3%83%9E%E3%83%BC%E3%82%B7%E3%82%99.png" alt=""> <h3 id="hb0b26686a9">interfaceの拡張(継承)</h3> extendsを使用することで、あるinterfaceを拡張したサブinterfaceを作ることができます。 マージとの違いは継承元のinterfaceが変更されるわけではないので使い回しが効く点ですかね。 <img src="https://images.microcms-assets.io/assets/f772f1225a7a4d20a85cc60a89d909a9/e6fa89a133564b4ca518ade67893ef62/interface_extends%E3%81%AB%E3%82%88%E3%82%8B%E6%8B%A1%E5%BC%B5.png" alt=""> <h3 id="hc649b8d86a">typealiasを拡張してinterfaceを作る</h3> extendsを使用したinterfaceの拡張ですが、実はtypealiasを継承元とすることもできます。 <img src="https://images.microcms-assets.io/assets/f772f1225a7a4d20a85cc60a89d909a9/a0736f4bce9a491b9079d565f564767e/typealias%E3%82%92%E7%B6%99%E6%89%BF%E5%85%83%E3%81%ABinterface%E3%82%92%E4%BD%9C%E6%88%90.png" alt=""> <h3 id="h998e118398">implementsを使ってinterfaceでclassに型を定義する</h3> interfaceでclassの型を定義することもできます。 <img src="https://images.microcms-assets.io/assets/f772f1225a7a4d20a85cc60a89d909a9/f643c4fc84c840f9b0cbe37cad0e3984/interface_class%E3%81%AB%E5%9E%8B%E5%AE%9A%E7%BE%A9.png" alt=""> <h2 id="hd9143d2a65">typealiasとは？</h2> 「型に名前をつける為 」に使用するもの。 同名の型を宣言するとエラーが起きたり、継承ができなかったり、そういった「拡張しにくい」と言う特徴を持つtypealiasは「型に名前をつける為」に使用するのがいいですね。この不便さがバグを生み出しにくいという利点を生んでいると思います。ちなみにtypealiasはオブジェクトや関数以外のプリミティブ、配列、タブルでも型宣言が可能です。 <h2 id="h3fdc404aa2">Interfaceとは？</h2> オブジェクト、クラス、関数の「構造を定義する為 」に使用するもの。 同名の型を宣言するとマージ(追加)されたり、extendsによる型の継承ができたり、そういった「拡張しやすい」と言う特徴を持つinterfaceは、その拡張のしやすさを存分に生かすために、オブジェクトやクラス、関数の「構造」を定義する為に使用するのがいいですね。自分の中では、typeよりinterfeceの方が抽象的？なイメージです。ちなみにinterfectが定義できるのは、オブジェクトや関数の型のみです。 <h2 id="ha4d64f3b09">どっちを使えばいいの？</h2> 最初に言いましたが、ライブラリ開発などの不特定多数が利用する物に関しては拡張性を持たせるためにinterface。 アプリケーション等の全ての型が拡張性を持つとバグを生むような物に関してはtypealiasを使用するのがいい。 時と場合によるみたいな感じですね。 自分がライブラリ開発を行うことがほぼないと思うので、アプリケーションを作る機会が多い方は意図しない拡張を防ぐために基本的にはtypeを使用するのが良いのではないでしょうか。 と言うわけで今日はtypeとinterfaceについて勉強してみました。 両者の違いは「拡張のしやすさ」にあることが知れていい感じです。 では次の記事でお会いしましょ〜！ありがとうございました！

TypeScript復習

interfaceとtypealiasの違いを理解する。

Tags

About this Blog