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
Result 型、自前で書くか、ライブラリ使うか
Search
majimaccho
May 23, 2025
4
670
Result 型、自前で書くか、ライブラリ使うか
TSKaigi 2025でのLT資料です
majimaccho
May 23, 2025
Tweet
Share
More Decks by majimaccho
See All by majimaccho
TypeScript サーバーサイドエンジニアが関数型から学 ぶべき 3 つのアイディア
majimaccho
4
570
graphql-rdb-mismatch
majimaccho
0
36
tblsはいいぞ(第44回 PostgreSQLアンカンファレンス@オンライン)
majimaccho
0
240
Featured
See All Featured
For a Future-Friendly Web
brad_frost
179
9.8k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.6k
Typedesign – Prime Four
hannesfritz
42
2.7k
Intergalactic Javascript Robots from Outer Space
tanoku
271
27k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.6k
Code Review Best Practice
trishagee
69
19k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
22k
What's in a price? How to price your products and services
michaelherold
246
12k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
Into the Great Unknown - MozCon
thekraken
40
1.9k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
Transcript
Result 型、自前で書くか、ライブラリ使うか @TSKaigi2025 1
自己紹介 名前:majimaccho お仕事: @caddi 職種: Web App Engineer X: @majimaccho_
2
TypeScriptのResult型のこと、気になりませんか? 3
今回と前回のTSKaigiでは… 4
5
どうしてResult型が必要なの? 6
こんなお困りありませんか? 1. TypeScript で try-catchしたらunknown型になって辛い 2. TSKaigiでResult型がいいらしいけどどのライブラリを使えばいいの? 3. 自前でも実装できそうだけど何がダメかわからない 7
結論: ライブラリを使わなくても大丈夫 (使うなとは言ってない) 8
Result 型 基本の形 type Result<T, E> = | { isOk:
true; value: T } | { isOk: error: E, message: string }; type CreateHoge = (x: string) => Result<Hoge, HogeError>; try-catchとは違って unknownではないのでエラーの型が厳格になる エラーを発生させる可能性のある関数を明示的にできる エラー処理の抜け漏れを防ぎやすい 9
ヨシ! 10
あれ? じゃあなんでライブラリがあるの? 11
関数型ができない(当たり前) Result型は関数型言語での恩恵が大きい TypeScriptは関数型言語ではない Result型のメソッドチェーンはできない エラー合成もできない 関数型ドメインモデリングで紹介されているROPは できない 12
Result 型を実装したライブラリ これらはメソッドチェーンもエラー合成もできる fp-ts neverthrow Effect 他にもたくさん(迷ったら初手 neverthrow でいいと思う。詳しくはチャッピーに) //
neverthrow の例 return parse(input) .andThen(updateDb) .andThen(sendEmail) .match(handleSuccess, handleError) 13
ライブラリを使うデメリット オンボーディングコストが高い 普通のライブラリの学習コストより高い Adapterコードが増える メソッドチェーンができるようにするために高階関数にする必要が出てくる なれていない人には苦痛を感じさせるかも AIが期待通りにコードを書いてくれない(らしい) 必要な依存が増える(みなさんZod v4大丈夫ですか) ドメイン層にライブラリは極力入れたくないがResult型が一番欲しいのはドメ
イン層 14
自前での実装 メリット 学習コストが少ない 依存が増えない メソッドチェーンのためのAdapterはない AI が期待通りにコードを書いてくれやすい デメリット メソッドチェーン・エラー合成ができないため ライブラリを使う場合と比べて、呼び出し側のコードがごちゃっとする
15
結論・どちらを使うか: チームのライブラリ・関数型プログラミングの習熟度によって異なる プロジェクト全体でRailway Oriented Programming をするならライブラリを使うの が良い 手続型的に書いている中に Result 型を組み込むのであれば必要な箇所だけ自前で
実装するのが良い 現環境のAIエージェントでは期待通りにコードを書いてくれないかも 16
ご清聴ありがとうございました こちらでもう少し詳しい話をするので、 内容が気になる方はこちらもチェックしてみてください 17