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
660
Result 型、自前で書くか、ライブラリ使うか
TSKaigi 2025でのLT資料です
majimaccho
May 23, 2025
Tweet
Share
More Decks by majimaccho
See All by majimaccho
TypeScript サーバーサイドエンジニアが関数型から学 ぶべき 3 つのアイディア
majimaccho
4
560
graphql-rdb-mismatch
majimaccho
0
36
tblsはいいぞ(第44回 PostgreSQLアンカンファレンス@オンライン)
majimaccho
0
230
Featured
See All Featured
[RailsConf 2023] Rails as a piece of cake
palkan
55
5.6k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.4k
Code Reviewing Like a Champion
maltzj
524
40k
Making Projects Easy
brettharned
116
6.3k
Code Review Best Practice
trishagee
69
18k
Designing Experiences People Love
moore
142
24k
What's in a price? How to price your products and services
michaelherold
246
12k
Adopting Sorbet at Scale
ufuk
77
9.4k
YesSQL, Process and Tooling at Scale
rocio
173
14k
The Language of Interfaces
destraynor
158
25k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
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