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
プロダクト開発でも使おう 関数のオーバーロード
Search
yoiwamoto
June 06, 2025
Programming
0
160
プロダクト開発でも使おう 関数のオーバーロード
yoiwamoto
June 06, 2025
Tweet
Share
More Decks by yoiwamoto
See All by yoiwamoto
標準最高!標準はださくないぞ! at fukuoka.ts #1
yoiwamoto
1
530
Other Decks in Programming
See All in Programming
生成AIで日々のエラー調査を進めたい
yuyaabo
0
650
KotlinConf 2025 現地で感じたServer-Side Kotlin
n_takehata
1
230
技術同人誌をMCP Serverにしてみた
74th
0
330
ReadMoreTextView
fornewid
1
480
AIエージェントはこう育てる - GitHub Copilot Agentとチームの共進化サイクル
koboriakira
0
380
既存デザインを変更せずにタップ領域を広げる方法
tahia910
1
240
なぜ「共通化」を考え、失敗を繰り返すのか
rinchoku
1
510
「Cursor/Devin全社導入の理想と現実」のその後
saitoryc
0
150
CursorはMCPを使った方が良いぞ
taigakono
1
170
来たるべき 8.0 に備えて React 19 新機能と React Router 固有機能の取捨選択とすり合わせを考える
oukayuka
2
850
エンジニア向け採用ピッチ資料
inusan
0
160
LT 2025-06-30: プロダクトエンジニアの役割
yamamotok
0
370
Featured
See All Featured
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Adopting Sorbet at Scale
ufuk
77
9.4k
Become a Pro
speakerdeck
PRO
28
5.4k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
181
53k
Testing 201, or: Great Expectations
jmmastey
42
7.5k
How to train your dragon (web standard)
notwaldorf
93
6.1k
Agile that works and the tools we love
rasmusluckow
329
21k
[RailsConf 2023] Rails as a piece of cake
palkan
55
5.6k
KATA
mclloyd
29
14k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
5
210
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
138
34k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
Transcript
プロダクト開発でも使おう 関数のオーバーロード Yo Iwamoto プロダクトエンジニア @SmartHR 2025.06.6 TSKaigi 2025 事後勉強会
LT
Yo Iwamoto / 岩元 陽 自己紹介 ❏ SmartHR で勤怠管理機能を作っています ❏
近況: Switch 2 って本当に当たるんですか? @yoiwamoto
None
話したいこと 1. 関数のオーバーロードについて 2. プロダクト開発で役に立った話 3. オーバーロードの性質と使いどころ
Function Overloads
関数のオーバーロード (Function Overload) https://www.typescriptlang.org/docs/handbook/2/functions.html#overload-signatures-and-the-implementation-signature 関数宣言を複数記述するような形式で関数のシグネチャを列挙し、 パターンマッチにより動的にシグネチャを決定させるような機能。
関数のオーバーロード (Function Overload) e.g. react-hook-form の watch() にキー、キーの配列、コールバックが渡せたりするあれ
❏ ライブラリとかでよく使われててなんか便利 ❏ 便利だけど、まあメタプロの類 プロダクト開発で使うかと言われるとあんまり? なイメージ。
うまく使うと実装がとても簡潔になったり 最強関数(いい意味)を作れる素敵な機能なので、 改めて概要 & 使い所を紹介します!
オーバーロードのモチベーション 特に型を工夫しない場合 🤔 引数が string なら string、 number なら number
を返すような関数 → 実際に渡した引数の型から動的に推論さ せることができず、常に `number | string`
Generics で対応してみる 💭 value を T と置いて、返り値型を分岐する (改行の問題ももちろんあるけど、) - 一定、実装が複雑になる。
- as T extends number ? number : string のような as の使用が避けられない オーバーロードのモチベーション
オーバーロードで解決 ✨ 宣言された順の優先度でパターンマッチでシグ ネチャを特定。 実装も型定義もとてもシンプル オーバーロードのモチベーション
要するに、 単一の宣言だと限界がある関数シグネチャを、 分割して宣言することによって容易に表現するめの機能 であって、場合によって単に関数を分割したり、Conditional Type を工夫した り、引数のみの分岐であれば Discriminated Union で表現するなど、
基本的に他の方法が取れる。 → より簡潔な型表現にする / ユーティリティ関数のカバーする ユースケースを増やして便利にするために使う
最近オーバーロードが 役に立った話
作りたかったもの routes 定義のヘルパ。 パスパターンを literal で渡すだけで、必要なパラメータを受け取る path() 関数を返してほしい (こういうものを自前で作ってる経緯は割愛)
実現方法 ざっくりこんな感じで実現できる。 ポイントを分解すると、 ① Template Literal Types ② infer による
literal からの型の抽出 ③ 関数のオーバーロード キモは、パスパラメータを含まないパター ンの route では、引数を渡さなくてもエ ラーにならないこと
よくある使い方 ...は省略
一般化すると
① 引数型を分岐したい場合 → Union がハマらなければ使う! ② 返り値型などを分岐したい場合 → 以下の場合を除いてまず使ってみる! 関数のオーバーロードの使いどき
➢ 同じ関数でカバーできるメリットがないかも ➢ Template Literal Types などでパターン量が爆発するかも
引数にパターンがあるだけであれば、理論上ただの Union でほぼ表現できる。 が、Positional Argument の構造が分岐できない! ⚠ 使いどき ① 引数型を分岐したい場合
公式のサンプルコードでは Positional Argument の構造が分岐していて、 makeDate(1749198911) とも呼べるし、 makeDate(6, 6, 2025) とも呼べる
これは Union の場合、以下のようにオブジェクト形式にする、あるいは第二引数を optional にするなどでしか実現できない。 使いどき ① 引数型を分岐したい場合
最初の例で言うと、 PathParameter が `{}` であるような場合に第一引数を required にしたり optional にしたりできているのはオーバーロードのおかげ。 使いどき
① 引数型を分岐したい場合
使いどき ② 返り値型などを分岐したい場合 基本的には使える が、なんでもありのオーバーロードは正直全く関係のない関数もまとめられるもので、 (理論上は)アプリケーションの全ての関数を 1つでカバーできたりする 秩序を保つために、以下は考える - 同じ関数であるメリットがあるか?
- Template Literal Types などでパターン数が爆発しないか? - 推論の度に動的にパターンマッチが実行される - 極端にパターンの多い計算を含んでいると、通常の関数定義より負荷がかかる
おわり