Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Interface vs Types ~型推論が過多推論~
Search
Hiroki Omote
May 26, 2025
Programming
1
260
Interface vs Types ~型推論が過多推論~
tskaigi 2025 LT Day1で発表したスライドです。
「推論のパフォーマンスで困ったらInterafaceを使いましょう」
Hiroki Omote
May 26, 2025
Tweet
Share
Other Decks in Programming
See All in Programming
商品比較サービス「マイベスト」における パーソナライズレコメンドの第一歩
ucchiii43
0
130
「テストは愚直&&網羅的に書くほどよい」という誤解 / Test Smarter, Not Harder
munetoshi
0
200
#QiitaBash MCPのセキュリティ
ryosukedtomita
1
1.5k
レベル1の開発生産性向上に取り組む − 日々の作業の効率化・自動化を通じた改善活動
kesoji
0
280
なんとなくわかった気になるブロックテーマ入門/contents.nagoya 2025 6.28
chiilog
1
280
顧客の画像データをテラバイト単位で配信する 画像サーバを WebP にした際に起こった課題と その対応策 ~継続的な取り組みを添えて~
takutakahashi
4
1.2k
ソフトウェア品質を数字で捉える技術。事業成長を支えるシステム品質の マネジメント
takuya542
2
15k
Git Sync を超える!OSS で実現する CDK Pull 型デプロイ / Deploying CDK with PipeCD in Pull-style
tkikuc
4
320
AIエージェントはこう育てる - GitHub Copilot Agentとチームの共進化サイクル
koboriakira
0
720
#kanrk08 / 公開版 PicoRubyとマイコンでの自作トレーニング計測装置を用いたワークアウトの理想と現実
bash0c7
1
920
はじめてのWeb API体験 ー 飲食店検索アプリを作ろうー
akinko_0915
0
140
NPOでのDevinの活用
codeforeveryone
0
890
Featured
See All Featured
GraphQLとの向き合い方2022年版
quramy
49
14k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
138
34k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
StorybookのUI Testing Handbookを読んだ
zakiyama
30
5.9k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Agile that works and the tools we love
rasmusluckow
329
21k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
750
Typedesign – Prime Four
hannesfritz
42
2.7k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
830
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
48
2.9k
Transcript
None
はじめに どちらかの派閥を決めたい方 vsとかついてるけれど、決着をつけたいわけではないです。 きのこvsたけのこ戦争ほど、不毛な戦いはないと思います。 ちなみに、私はたけのこ派です。 笑いに厳しい方 タイトルからスベってるって思った人はお帰りください。 傷つくので。
omote 表 洋樹 マラソ ガンダム 趣味 Design Engineer
Manager Tech Lead Freelancer 2012 2019 2022 Scheeme BUBO
ポリモーフィック
as=”button” Prop 社内のデザインシステム配信するため、 Buttonコンポーネントを作っていた時のお話。
実際の実装
そして結果
ん?
見間違いかな?
もう一回確認しよう
何度見返しても結果は同じ(それはそう)
いやいやいや
焦りは最高潮に達する ・開発時は推論できたのに裏切られた恐怖 ・そもそもデザインシステムで配信している、anyとか曖昧なのヤバい ・慣れないライブラリを使いつつ、型を組み合わせた努力が…!?
エニーは型を知らない キラキラ
なぜ、anyになったのか 複雑な交差型 特定のケースで最終的に any 型に落ち る。 TypeScriptの型システムの計算の限界 と推論の妥協に起因。 Mantineの型 ×
自前の型 これにより計算量が爆増した。 ライブラリ内にあった型を流用し、交 差型として使用した。 落とし穴 開発時は推論できていた。 ビルド時に内部的に複雑化し、最終結 果がanyになった。 エニーは型を知らない キラキラ
計算量が増えるケース 1 2 3 4 5 6 7 8 9
10 11 12 13 14 15 type type extends infer const const typeof DeepArray DeepArray []; Flatten ( )[] Flatten ; deeplyNested DeepArray DeepArray DeepArray [ [[ ], [ ]], [[[ ]]] ]; flattened Flatten deeplyNested ; < > = | < > < > = ? < > : : < < <number>>> = : < > = T T T T T U U T // 再帰的にすべてのネストを展開する型 // 型推論が限界を超えると、ここで `any` として扱われる可能性あり 1 2 3 1 Recursive Type 再帰的にネストが展開され、無限に近 い計算が発生します。 TypeScriptはこのようなケースで型の 推論を放棄し、any にフォールバック することがあります。 ※ver3.7でRecursive typeの扱いは改善 エニーは型を知らない キラキラ
型推論が過多推論やん----------------------
推論のリベリオン
宣言をinterfaceに変えただけです。 型自体は何も編集していません。 Interfaceを使え、とAIが言っている type → interface 1 2 3 4
5 type keyof Props Omit ComponentPropsWithoutRef , ButtonProps Omit ButtonProps, { variant ; color ; }; = < < > > & < > & ?: | | ?: | | 'button' 'unstyled' 'filled' 'outlined' 'text' 'default' 'subdued' 'caution' 1 2 3 4 interface extends keyof Props Omit ComponentPropsWithoutRef , ButtonProps , Omit ButtonProps, { variant ; color ; } < < > > < > ?: | | ?: | | 'button' 'unstyled' 'filled' 'outlined' 'text' 'default' 'subdued' 'caution'
なぜこれで解決できるか typeにおける交差型は型演算の対象 型レベルで演算されて解決される必要がある。 型の深さや複雑さによって any に落ちる可能性が高くなる。 interface はマージベースで解決される interface はマージされるため、TypeScriptの型解決の負荷が
下がる。 interface 同士は「拡張」に近い 「構造の統合」ではなく、型計算を遅延させた構文にる。 TypeScriptの型システムとしては「負担が少ない」=any に落 ちにくくなるという特性がある。
type interaface 条件型 ・使用可 不可 拡張(継承) H & を使って交差型として合8 H
同名のtypeは許可しない H extends で継承可能(複数継承も可y H 同名の interface を自動で統合 パフォーマンス(型計算) H 計算量によっては型爆発の可能性 H 遅延評価するので、パフォーマンス高 typeとInterfaceの比較表
遅延評価、なるほど!と思ってたが
いや、書いてあったわ ライブラリのドキュメントはinterface使用してい るし、素直に従えばよかっただけ! “Polymorphic components have performance overhead for tsserver
(no impact on runtime performance)”
まとめ 計算量次第ではinterface使う interfaceは遅延評価 typeとinterface どちらかに寄せるなど、流派とかもあるかもしれないが、対立 構造ではない。 使い分けするシーンはしっかりある。 ドキュメント読もう それはそう それはそう
それはそう
Thank You When the going gets tough, the tough get
going.