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
330
プロダクト開発でも使おう 関数のオーバーロード
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
テスト駆動Kaggle
isax1015
1
880
顧客の画像データをテラバイト単位で配信する 画像サーバを WebP にした際に起こった課題と その対応策 ~継続的な取り組みを添えて~
takutakahashi
4
1.4k
新メンバーも今日から大活躍!SREが支えるスケールし続ける組織のオンボーディング
honmarkhunt
5
9.3k
Hack Claude Code with Claude Code
choplin
8
2.8k
20250704_教育事業におけるアジャイルなデータ基盤構築
hanon52_
5
1.2k
型で語るカタ
irof
0
800
マッチングアプリにおけるフリックUIで苦労したこと
yuheiito
0
240
MDN Web Docs に日本語翻訳でコントリビュートしたくなる
ohmori_yusuke
1
130
MySQL9でベクトルカラム登場!PHP×AWSでのAI/類似検索はこう変わる
suguruooki
1
220
Claude Code派?Gemini CLI派? みんなで比較LT会!_20250716
junholee
1
690
可変性を制する設計: 構造と振る舞いから考える概念モデリングとその実装
a_suenami
2
340
レトロゲームから学ぶ通信技術の歴史
kimkim0106
0
130
Featured
See All Featured
Code Reviewing Like a Champion
maltzj
524
40k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
282
13k
GraphQLとの向き合い方2022年版
quramy
49
14k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
18
1k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
126
53k
StorybookのUI Testing Handbookを読んだ
zakiyama
30
5.9k
Bash Introduction
62gerente
613
210k
Music & Morning Musume
bryan
46
6.7k
Making Projects Easy
brettharned
116
6.3k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
Fireside Chat
paigeccino
37
3.5k
Why You Should Never Use an ORM
jnunemaker
PRO
58
9.5k
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 などでパターン数が爆発しないか? - 推論の度に動的にパターンマッチが実行される - 極端にパターンの多い計算を含んでいると、通常の関数定義より負荷がかかる
おわり