要約
これを参考にして自分で考えてください。分かってるでしょ?
本編
解決したい問題
最近トレンドとかにも入ってる素振りのために Rust と Elm でRSSビューア作ったのElm部分のコードを見にいきましょう
Modelはこれ
type alias Model =
{ inputUrl : String
, submittedUrl : Maybe String
, items : List Item
, previewing : Maybe Item
, message : Maybe String
, flags : Flags
}
itemsがAPIから取ってきた値で、messageがAPIたたいて何か問題が起きたときにエラー内容を格納するところ
何が問題か
このRSSアプリでは叩くAPIは一個でエラーもグローバルで一個の関係なので問題ないかもしれません。では叩くAPIが増えてしまったら、どうしましょうか?
実のところ大した問題ではありません。問題がないと思えば今のままでもいいですし、どこ由来のエラーか区別したいならカスタム型を作るなりなんなりして何とかすればいい話です
よくある解決策
多分一般的な解決策はあります(多分は一般的にかかってます)
ここの一番下の見出しの部分を見てください。あ、型だけでいいですよ
type Profile
= Failure
| Loading
| Success { name : String, description : String }
上のModelもそうですが大体型だけ見てればいいですよ。
このカスタム型にはとってきたいProfileが、失敗、ロード中、成功に分けて表現されています
あなたが推測できる通り、もちろんこれはAPI経由で取ってくる値です
なんだか型を書いたらあとはわかるっしょて気分になってきました
見たらわかる通り、この型はAPIで値を取ってくるという状況をデータとして表現しています。このように型を設計できたら、あとあなたがやることはviewでいい感じに表示することだけです
あなたのviewでLoadingがきたらスピナーをくるくるまわして、Failureなら赤色でエラーメッセージだして、Successなら望むようにデータを表示してください
エラーの情報がなくなってるって?好きに足せよ
type Profile
= Failure String
| Loading
| Success { name : String, description : String }
はい、これで文字列でエラーの原因を表現できるようになりましたね
カスタム型でもっと厳密に詳細にエラー情報をトラッキングしたいならがんばってくれ
ざねりさんのコードでもHttp.ErrorをStringに潰してるところがありますね。そこらへんでどれだけ詳細にトラッキングするかって話です
Result Http.Error a
をうまいこと変換してください
RemoteData
上記カスタム型は自分がいいように都度作ったほうがいいとは思いますがpackageはもちろんあります
RemoteDataと呼ばれてます
type RemoteData e a
= NotAsked
| Loading
| Failure e
| Success a
Resultの拡張みたいな型ですね!
エラーハンドリングのページに書いてあるんですが、あくまでResultやMaybeは汎用的な型なんですよね
Evan(Elm作者)としては自分の表現したいシチュエーションに合わせてカスタム型を作るほうがいいといってます。同意見です(ただこの意見は書き捨てのコードをささっと書くとか抽象化の力を借りてスタイリッシュに書こうというのには合いません。ボイラープレートコード上等です。書け。他人の抽象化に乗ってる暇はない)
終わり
書かなきゃいけないことは書いたと思うので終わります。大体型見たら終わりますからね、しょうがないね
elm-jpってコミュニティがあります。まだどんな質問にも答えてくれるし、質問に答える前にお前それどういうことってわざわざ聞いてくれる感じなので何かあったらどうぞ