私がTypeScriptで `interface` よりも `type` を好む理由 - kosui

はじめに TypeScriptで型を定義する際、interface と type のどちらを使うべきか。これは、多くの開発現場で一度は議論になるテーマではないかと思います。 世の中の多くのドキュメントや記事では、クラスへの implements のしやすさや、interface が持つ「宣言のマージ（Declaration Merging）」の利便性が紹介されることもあり、interface の利用が推奨されるケースもよく見かけます。 しかし、特にサーバサイドアプリケーションや、ある程度規模のあるシステムを開発する上で、私はこの「宣言のマージ」機能が、時として予期せぬ挙動や、場合によってはセキュリティ上のリスクを静かにもたらす要因になると感じています。 今回は、なぜ私がプロダクトコードにおいて interface の積極的な使用を避け、type エイリアスを好んで使うのか、具体的なシナリオ

[yash268925]

tsの型は構造的部分型なのだから、そもそも「○○しかもたない」という思い込みが危険なのでは。type Userにしていようが、いらんもの(hashedPassword)が入っててもUserで通るし。

[daketake]

言語設計どおりインターフェースにあたるものはinterface、型にあたるものはtypeで書くだけだよ。下手に代用しようとすると疲弊するだけだと思うな

[hatest]

拡張可能なことを意図する場合はinterface 、拡張できない型を意図する場合はtypeで使い分けてるな。メンバーには「型を宣言する時は、まず基本typeで宣言してもらって、拡張可能にするならinterfaceに変えてくれ」と言う

[turanukimaru]

TSは型で宣言していないものを持っていることが多いのと、内部構造をそのままAPIの外に出すのは内部構造を変更しにくくなるので明示的に出力データを作ったほうが良いと思うが。DBアクセス後のEntityは特に色々入りがち

[Fushihara]

既存のライブラリの型を追いかけている時も、interfaceで書かれているとこの型の定義はこういう意味だ と確定的に調べる事が出来なくなるんだよね

[jintrick]

"私が指摘したいのは、「型定義ファイルを見に行くだけでは、その型が最終的にどのような形状になるか断定できない」という interface の特性そのものが持つリスクです"

[Xibalba]

とてもわかりやすい

[hylom]

そもそもインターフェイスはそこで宣言されているプロパティやメソッドを持っていることを保証するためのものなんだけどTSにおいてはクラスやデータ型を宣言するもののように認識されているのではないか問題

[repon]

今日ChatGPTに「typeよりinterfaceが良いんでしょ？」って訊いたら叱られが起きた

[dbr0]

interfaceの宣言のマージ、一見非合理だけど既存の組み込みオブジェクトをprototype拡張してるJSライブラリを使う時にこれが無いと詰む場合があるんだよな。anyと同じで積極的に使うべきで無いが必要悪な機能だと思ってる。

[akymrk]

“アプリケーションのデータ構造」である、APIのレスポンス、DBのエンティティ、ドメインオブジェクトなどを定義する際には、その型が「閉じている（closed）」こと、つまり「定義ファイルに書かれているプロパティがす

[ka-ka_xyz]

tsのinterfaceをマージする仕様は個人的にかなりダメなやつだと思う(拡張が必要なら普通に extendsで良さそうな

[soulfulmiddleagedman]

私も何度も調べてるなぁ。