Closed MofuMofu2 closed 4 days ago
➜ typescript-sandbox git:(learning-typescript-4) ✗ git commit husky - DEPRECATED Please remove the following two lines from .husky/pre-commit: #!/usr/bin/env sh . "$(dirname -- "$0")/_/husky.sh" They WILL FAIL in v10.0.0
interfaceの方が好まれるとあった。なぜだろうか。柔軟に型が結合できるとか？あまり違いがわからない。 人によってはtypeの方を好む人もいるが。
構造的型付けという概念を知らなかった。
構造的型付けと過剰プロパティの違いがわからなかった。
互換性があればOK。必要なプロパティが含まれていれば不足があってもOKと判断される。 オブジェクトの変数を代入とかするときはこちらになる。
オブジェクトリテラル（{name: "sample"}のようなプロパティ）を直接変数や定数に割り当てるときだけチェックされる。 こちらは過不足があればNG扱いになる。
{name: "sample"}
4.9以降はsatisfies演算子を使うことでも判断できる。プロパティにtypeを割り当ててしまうと柔軟性に欠けるパターンがあるため、柔軟にやりたいときはsatisfiesを使うといい。でもAPI連携する箇所とかだったら使わないほうがと思ってしまう。
TypeScriptの構造的型付けと過剰プロパティチェックは、それぞれの特性を活かして異なるシナリオで使い分けることが重要です。以下に、具体的な場面での使い分けを示します。 ### 構造的型付けを使う場面 1. **柔軟なAPI設計**: - オブジェクトが指定した型の必要なプロパティを満たしていれば、追加のプロパティを許容したい場合。 - 例えば、ライブラリやフレームワークの設定オブジェクトでは、必要なプロパティを持っていればその他のプロパティは無視する場合が多いです。 ```typescript interface Config { host: string; port: number; } const myConfig = { host: "localhost", port: 8080, timeout: 1000, // 追加のプロパティがあってもOK }; function setup(config: Config) { // ... } setup(myConfig); // OK ``` 2. **データマッピング**: - さまざまなデータソースから取得したオブジェクトを型にマッピングする際に、プロパティの一部だけを使用したい場合。 - データベースのレコードやAPIレスポンスなどが該当します。 ### 過剰プロパティチェックを使う場面 1. **厳密な型チェックが必要な場合**: - 受け取るオブジェクトリテラルが正確であることを強制したい場合。特に、誤って余分なプロパティを渡すことがバグの原因となる場合に役立ちます。 ```typescript interface User { id: number; name: string; } const createUser = (user: User) => { // ... }; createUser({ id: 1, name: "Alice", age: 30, // このエラーを防ぎたい場合 }); // エラーになる ``` 2. **外部からのデータを扱う場合**: - APIレスポンスやユーザー入力など、外部からのデータを受け取るときに過剰プロパティチェックを利用して、予期しないプロパティの追加を防ぎたいとき。 ### まとめ - **構造的型付け**は柔軟性が必要な場面で使います。特に、追加のプロパティを持つオブジェクトを受け入れたいときに便利です。 - **過剰プロパティチェック**は、型の厳密さが求められる場合や、外部からのデータを扱う際に使用します。これにより、不正なデータを早期に検出できます。 使い分けることで、コードの安全性と柔軟性を両立させることができます。
タグ付き合併型は2パターンのオブジェクト構造があるとき、絞り込みができていないとNGになる機能。 コードを書いてみるとこれか〜となるが、名前はサッと出てこないので、調べるときに役立ちそうだと思った。
URL
その他
4-1-2
interfaceの方が好まれるとあった。なぜだろうか。柔軟に型が結合できるとか？あまり違いがわからない。 人によってはtypeの方を好む人もいるが。
4-2
構造的型付けという概念を知らなかった。
4-2-2
構造的型付けと過剰プロパティの違いがわからなかった。
構造的型付け
互換性があればOK。必要なプロパティが含まれていれば不足があってもOKと判断される。 オブジェクトの変数を代入とかするときはこちらになる。
過剰プロパティ
オブジェクトリテラル（
{name: "sample"}のようなプロパティ）を直接変数や定数に割り当てるときだけチェックされる。 こちらは過不足があればNG扱いになる。4.9以降はsatisfies演算子を使うことでも判断できる。プロパティにtypeを割り当ててしまうと柔軟性に欠けるパターンがあるため、柔軟にやりたいときはsatisfiesを使うといい。でもAPI連携する箇所とかだったら使わないほうがと思ってしまう。
使い分けについてGPTに聞いてみたもの
TypeScriptの構造的型付けと過剰プロパティチェックは、それぞれの特性を活かして異なるシナリオで使い分けることが重要です。以下に、具体的な場面での使い分けを示します。 ### 構造的型付けを使う場面 1. **柔軟なAPI設計**: - オブジェクトが指定した型の必要なプロパティを満たしていれば、追加のプロパティを許容したい場合。 - 例えば、ライブラリやフレームワークの設定オブジェクトでは、必要なプロパティを持っていればその他のプロパティは無視する場合が多いです。 ```typescript interface Config { host: string; port: number; } const myConfig = { host: "localhost", port: 8080, timeout: 1000, // 追加のプロパティがあってもOK }; function setup(config: Config) { // ... } setup(myConfig); // OK ``` 2. **データマッピング**: - さまざまなデータソースから取得したオブジェクトを型にマッピングする際に、プロパティの一部だけを使用したい場合。 - データベースのレコードやAPIレスポンスなどが該当します。 ### 過剰プロパティチェックを使う場面 1. **厳密な型チェックが必要な場合**: - 受け取るオブジェクトリテラルが正確であることを強制したい場合。特に、誤って余分なプロパティを渡すことがバグの原因となる場合に役立ちます。 ```typescript interface User { id: number; name: string; } const createUser = (user: User) => { // ... }; createUser({ id: 1, name: "Alice", age: 30, // このエラーを防ぎたい場合 }); // エラーになる ``` 2. **外部からのデータを扱う場合**: - APIレスポンスやユーザー入力など、外部からのデータを受け取るときに過剰プロパティチェックを利用して、予期しないプロパティの追加を防ぎたいとき。 ### まとめ - **構造的型付け**は柔軟性が必要な場面で使います。特に、追加のプロパティを持つオブジェクトを受け入れたいときに便利です。 - **過剰プロパティチェック**は、型の厳密さが求められる場合や、外部からのデータを扱う際に使用します。これにより、不正なデータを早期に検出できます。 使い分けることで、コードの安全性と柔軟性を両立させることができます。
4-3-4
タグ付き合併型は2パターンのオブジェクト構造があるとき、絞り込みができていないとNGになる機能。 コードを書いてみるとこれか〜となるが、名前はサッと出てこないので、調べるときに役立ちそうだと思った。