フロントエンドでのWorkHourの作成と編集

編集中のWorkHourオブジェクトは、一部の値が設定されてないかもしれない。 reactでは、この状態のオブジェクトを、useStateで、どっかに持っとかないといけない。 このuseStateの型パラメータに、WorkHourを指定すると型エラーになる。 なぜなら、編集中は、一部の値がまだ設定されてないこともあるから。 なので、元のWorkHourで必須になっているもの全てをoptionalにした型を別途作った。 ただ、当初は、dealsページからの追加しか想定してなく、その場合はdealIdは自動で決まるのでdealIdだけはrequiredのままだった。 で、これが以下の2点で設計ミスだったなと思う。

  1. dealsページ以外から追加する場合に使いまわせない: 今回、weekページを作ったんだけど、そっからもworkhourを追加したくなった。この時、weekページではdeal idは自動では決まらないので、dealsページ用に作った編集用の型は使えなかった
  2. 別の型を手で定義するのは効率的でない: TypeScriptには、型を変換する便利な奴らがいる(link)。これを使って、編集用には全フィールドをoptionalにした型を利用する。型のレベルでの担保は、そのレベルにしておいて、それ以上のバリデーションは実行時に値に基づいて行なった方が良さそう

バリデーション

オブジェクトを永続化するために保存する時に、どこで値のバリデーションをするか。サーバー側では、保存の直前に実行すれば良さそう。 クライアント側では、やっぱり保存のAPIコールの直前に実行すれば良いんだろうか？という気もするんだけど、実は、そこだけではないかもしれないと思う。 のは、クライアント側では、保存しようとしたオブジェクトが不正だった場合は、不正の内容を把握して、それをユーザーに通知したいから。 この時、保存用APIが投げる例外だと一般的すぎて、オブジェクト編集の各画面ごとにカスタマイズされた例外が欲しくならないだろうか。 しかし、画面ごとにバリデーションのロジックを作って、さらに保存前に、だとコードが増えすぎるきらいもある。 ただ、コードの各箇所では、その個所で興味のあるロジックを書いとくのが正道な気がする。 という考え方に従えば、エラーの内容によって適切にユーザーへのフィードバックを調整したい時にはUIに近い場所でバリデーションとエラーハンドリングを行うべき。 一方で、自分用ツールで、例外オブジェクトが見れれば十分という場合には、保存用APIでバリデーションして、エラーをそのままconsoleに出すとかでも良いとも思える。