TSでResult型とかやりたいときのライブラリ調査
ResultとかEitherとかの代数的データ型をTSでやる
miyamonz.iconの場合は、割と手書きで単に分岐させてるような
候補
option-t
関数で独立してるのが良い
ドキュメントへのアクセスがしにくいのがちょっとつらい
と思ったが、逆引きの解説呼んだりしたらまあ分かるな
ドキュメントが少ないのは理由はある
option-tの作者のブログ
誤解ではないが弁護したい: option-tはドキュメントが少ない
これはかなり意図してそうなっている。
雑にまとめると
ライブラリに色を付けるのが妥当でない
データ構造の提供に留める
メンテできない
わざわざ書くほどじゃない
コードジャンプで見れば十分
import pathがやや気になるか？
このライブラリにはpipeは同梱されてないけど、pipe関数があれば良さげ？
neverthrow
メソッドチェーン
purify
結構前からあるっぽいけど知らなかったmiyamonz.icon
inspired byにfp-tsあるから、それより後発なのか？
MaybeとかにcaseOfとかisNothingとか、メソッドが生えてる
oxide.ts
rustから影響されてる
実装が少なく、ソースも読みやすい
ちょっとメソッドチェーンしてる
２年前で止まってるのは心配？
重め
これはいろいろと高度な関数プログラミングやるためにいろいろはいってる
ResultとかOptionだけのために入れるのは重たいような
内部的にfp-ts使ってるので、今回のスコープから外れる
観点
実装がまともか
plainなobjectか（serializableか）
語彙の好み
どの言語から影響されての名前がついてるか、というのがある
Haskell系か、Rust由来か、
まあこれはTSで頑張る時点で、母語がない状態で頑張るようなものなので、優先度は低いか
miyamonz.iconの好み順位
option-t
さらにこれがカリー化されてpipeも同梱されたら良いんじゃないか
neverthrow
oxide.ts
実装的にはneverthrowより好きだが、メンテ的に
とはいえ、
概念的にはどれもほとんど一緒で、
置換えも難しくないと思うし、
neverthrowが嫌いというわけではない
ライブラリの置き換えは難しくないと思う
変更範囲がでかいとしんどいかもしれないが
多分AIでなんとかなるっしょ
相互変換とかも書けそうなきがするので、段階的以降はできるんじゃないの、知らんけど
こういう系のライブラリの問題として、他人が読めるのか問題が有る
orElseとかmapOrとか語彙が、読めるか、脳内にちゃんと定着しているか
読み手という観点だと、
コードジャンプしたら何をしてるかが直ちに分かるようになってると良い
個別のオペレータが単なる関数として実装されてると良いのでは
書き手の場合、
「こうしたい」のときに直ちにオペレータが見つけられると良い
see also
option-tの作者
まず、そもそもとして冒頭でも述べたように、自分は実際には各プロジェクトのmotivationに依存して最終的なconvention（規約）が決定されるのであって、ライブラリそのものに強い色をつけるのが妥当と思えず、この種の一般的なデータ構造の実装を提供するライブラリそのものはデータ構造の提供に止めるべきであろう、ましてエラーハンドリングのようにコードの設計や運用指針まで影響するものであれば尚更、という設計意図が非常に強い。