m-match
$ npm i m-match
名前はminimal, とmodulerからmを取ってみた
要するにこういうやつ
https://gyazo.com/027e355618b0ca697e0c06b64d6a8e74
モチベーション
部分的にほしいが、メソッドチェーンスタイルだと欲しいところだけを取り出せないじゃん
あとメソッドチェーンはコードデカくなってくると読みづらい
読みづらいということはメンテナビリティが下がるということでも有る
pattern matchが欲しいのではなく、まずは型安全なif thenの式だけがほしい
code:ts
if(isHoge(s)) {
return valueForHoge
else {
// ここでsはisHoge以外になってる
}
TSではtype guradがあるので、if文を書くと良い感じに型が分岐できるが、これを式にしたい。 matchしてたら何かを返して、matchしてなかったら入力を絞りたい
メソッドチェーンで登場する個別のパーツを分解して定義すると良いんじゃないの？ということで作った アプリケーションの特定のモジュールが、遷移条件と条件を満たした際の処理の２つを有してる場合に、凝集を高められる
ほんとにちょっとの差だけどね
注意
実際のところ、業務では素朴にif then書けばよいと思う
無理にオレオレの変な仕組みを作っても、チームでの認識合わせとのコストを考えるとペイしにくい
ので、これはあくまで技術的に可能かどうかのデモ的なものでしかない
マッチャー部分も丁寧に作って、型安全に保てるならbetter ts-patternになれる可能性はある
https://gyazo.com/027e355618b0ca697e0c06b64d6a8e74
https://gyazo.com/3a8897eaea0bb8338bb14fa561cd774e
分かったこと
インターフェースは割といいんじゃないかと思う
Effect-TS使うほどじゃないけど、Result型に相当するものを、何かこう素朴に記述したい…みたいな立ち位置はありそう ライブラリ側の型パズルがやばすぎてメンテがきつそうだ、というのを理解できた Honoとかで型の部分が大変って声を見た
「ライブラリ側の型は複雑怪奇になりがち」という話は漠然と知っていたが、体感で理解できてよかった
変な型パズルやらずに提供できないものなのか？分からん
ここまでをv0.0として（実際0.0.2でデプロイしてる）
v0.1以降を考えて実装しても良いなmiyamonz.icon
また継続して調査と実装する気持ちも湧いてきた
---