2023/07/5

フロントエンドのバリデーションを設計するときに思うこと

はじめに

こんにちは、宇賀神です。

みなさんはバリデーション、書いてますでしょうか。

フレームワークとかライブラリの都合で仕様が固定されることも多く、設計とかあまり意識しない&意識したところで選択肢がない、的な状況もあると思うんですが、最近はフロントの自由度が上がっている影響で、考えられることが増えてきた感があります。

そんなバリデーションを設計するときに、UIUX的な観点も含めて自分なりに意識しているポイントを書いていこうと思います。

わりと設計思想の話なのでケースバイケースで正解は違うだろうし、あくまでいまの段階で自分が思うことなので、これが絶対だとも思ってないです。このあたりを前提として、生暖かく読んでください。

フロント側のバリデーションを実装するべきか、について

たまに聞くのが「バリデーションの処理はAPI側に書いて、フロントは422レスポンス受け取って結果を表示すれば良いじゃない」みたいなのがあります。処理の内容が同じになることが多いので結果として2重管理になったりする、みたいな観点ですね。

後述しますが、APIとフロントが行うバリデーションは厳密には役割が違う、というのが今のとこ自分の考えです。なので、基本的にはどちらにもバリデーションが実装されているのが理想かなと思います。

フロント側のバリデーション

フロント側のバリデーションの役割はざっくり「入力内容がinvalidかどうか、なぜinvalidなのかを伝えること」だと思っています。

極端な例だけど、全てのバリデーションエラーを「エラーが起きました」という表示しかしないフォームがあったとして。入力必須のフィールドが空でsubmitされてエラーになったとき、ユーザーはなぜエラーになったのかが分からず、手当たり次第に色んな方法を試すんだと思います。これがあんまり良くなさそうと。

サービス内で使う文言については色々な箇所で気をつけるべきですが、エラーメッセージの文言とかは特にシビアに考えるようにしています。さっきの例だと「xxxを入力してください」みたいなメッセージを表示できると、ユーザーが次に何をするかが分かりやすくなるんだと思います。

また、その手のフィードバックはなるべく早くユーザーに伝えるべきだし、もっと言うとエラーになることが分かっているのにわざわざサーバーと通信させることもないかなと。フロントでバリデーションをしているとそのあたりのstate管理ができるので、「invalidな入力がある場合submitボタンをdisabledにする」みたいなこともやれる。

まとめると、結果として以下のような触り心地になってると良さそうと思ってます。

• エラーメッセージは、ユーザーに「次に何をするべきか」を伝えられるような文言にする
• フロントバリデーションでinvalidな値があった場合、そもそもsubmitをしない（できない）ようにする

バリデーションの役割の違いについて

前述した「フロントとAPIのバリデーションは役割が違う」についてもう少し。

フロントのバリデーションの役割はさっき書いた通りですが、API側のバリデーションの役割はもうシンプルに「データ不整合を起こさせない」に尽きると思ってます。データ不整合って本当に厄介で、原因を見つけるのも大変だし、不整合を正すのもサービスが大きくなればなるほど大変になります。

ただ、API側だけでバリデーションをすると前述したような「ユーザーに適切にフィードバックを返す」がやれないケースが出てくるので、フロントでもバリデーションをした方が使いやすいサービスになるかなと思ってます。

まとめ

ざっとまとめると、こんなふうにフォームが出来ているといいよね、ということでした。

• APIとフロントのバリデーションは両方あった方が良い
• ユーザーに無駄な操作をさせない
• ユーザーが「次に何をするべきか」が分かるように文言を表示する
• データ不整合を防ぎたい

いざ書いてみると結構当たり前なことを書いてる気がするけども、こういうことをちゃんと意識するのって意外と難しくてかなり大事なことかなとも思うのです。

昨今は質の高いWebサービスが世に溢れていて、ユーザーの見る目もどんどん厳しくなる中なので、こうした細かいところに気をつけることは忘れずに開発していたいなーと思うのでした。

また書きます〜