# 自分がフォームを構築する際にぼんやり考えている事をゆるく列挙します（フロントエンド編）

Tags: ポエム html css

「ゆるWeb勉強会@札幌 Advent Calendar 2019」の6日目の記事になります。

フォームを作る上でディレクターへ確認しておきたいポイントや私がぼんやり考えている事をゆるく雑に列挙していきます。

フロントエンド編と表題に書きましたが、バックエンド編は書けません…。

# プレースホルダー

• 構築前にWFを見てディレクターへ確認する
• セレクトボックスの場合、デフォルト値は何なのか

# 名前入力

• 名字と名前で入力分けるのか一緒なのか
  • レガシー感あるサイトでは見るけど最近は減ったかも
• ふりがな入力欄はデータとして使いたい場合ソートや検索で便利そう
  • そもそもDM送ったり電話するってなった場合、読み方わからないと困ると思われる

# セレクトボックス、ラジオボタン、チェックボックスなどの装飾

• ブラウザデフォルトでOKかスタイリングが必要か
• Bootstrapなどのフレームワークを使う想定だと気にする必要はないけど、デザイナーがデザインしたのを使いたい場合に考える
• CSSでフォーム装飾するの面倒くさい。工数かかるが最近はセレクトボックスが面倒くさいくらい…かも
• 外部のフォームサービスを使う場合、そもそも iframe で吐き出されるからスタイリングできない場合もある
  • iframe ではなく、DOMを吐き出してくれる場合もマークアップは自由にできない場合が多いのでレイアウトが制限されるのでデザインが再現できないですよと伝えておく
• iOSで appearance を none とかにしないと <button> タグとか、OS固有のが出て社内外から不具合だと言われる可能性があるので対応しておく
• button submit select タグあたりはブラウザ固有の装飾だったりするので留意しておく
  • 開発時はBrowserSyncで複数ブラウザ開いて確認する

参考：フォーム要素のスタイルをリセットする | cly7796.net

# Submitボタンを押せる条件

• 必須項目全てバリデーション通ったら
• 上記に加え利用規約を確認のチェックボックスにチェックをしたら
• たまに利用規約を全てスクロールしないとボタンが disabled のママだったりする

# 日付処理

• 2つの日付（開始日と終了日）を選択して期間を設定するような場合、終了日が開始日より過去の日付を選択できないようにしたり、選択された場合エラーを出す必要がある
  • 開始日と終了日の比較 （moment.js や Day.js を使うとラク）
• 手動入力なのかデイトピッカー的なライブラリを使うのか（その場合はユーザーによってテキストを入力させないようにする readonly属性 とか？）
• 年月日の入力フォーマットはどうするか
  • YYYY/MM/DD
  • YYYY-MM-DD
  • YYYY年MM月DD日

# 住所関連

• 郵便番号から自動で住所を入力させるやつを実装する処理
  • サービス使うかライブラリを使うか、自前でAPI用意するかJSON作るか
• 郵便番号はハイフンを許容するか
  • バリデーション ハイフン有り正規表現の例： /^\d{3}[-]\d{4}$/
  • バリデーション ハイフン無し正規表現の例： /^\d{7}$/
  • ハイフン有りでDBに登録しといたほうがRESTでfetchするとき楽かもしれない
• 住所のフリガナが必要か
  • 管理画面などでソートしたい場合はフリガナあったほうがいいのかもしれんがユーザーは入力が辛いので避けたい

# 電話番号

• ハイフンの許容はどうするか
• 国際電話の場合も想定するか
• バリデーションは数字ならOKなのか（全角数字は認めたくない）
  • 電話番号の最適なバリデーション方法は？市外局番をどうするのか、携帯とか
  • バリデーションの精度で見積もり変えたほうがいい（実装に時間かかるだろうし）

# 数字関連

• 価格を入力するとき自動で3桁毎にカンマつけるのかどうか
• 税込みなのか税抜きなのか
• 最大何桁まで入力できるのか
• 空白の場合は自動で null にするのか 0 にするのか

# ファイルを添付する場合

• formタグの属性に enctype="multipart/form-data” を追加する
  • 送信時に FormData属性に変換しても良いが、手間がかかる
• 画像をアップロードするような仕様の場合、対応する拡張子を確認する
  • 最大容量（何MBまでOK？）を確認する
  • サムネイルを表示するのか
  • 最終的にはバックエンド側で条件を満たしていない画像は弾くはず…

# 内容クリアボタン

• 存在の有無を確認
  • 商品一覧の検索フォームなどで、複数の選択肢がある場合は、合ったほうが良いが、ワイヤーフレームに無い場合は追加しなくてよいのか確認する

# 送信する値

• セレクトボックス、ラジオボタン、チェックボックスの値
  • ID的なやつで送信するのかラベル（テキスト）で送るのか

# textareaのバリデーション

• XSS攻撃対策、他にはメルアド、URLが記載されていた場合はエラーを出すのか
• Chromeとかだと自分で幅や高さが広げられるのでそのあたりも対策しておく
  • ただしユーザーがいじりたい場合もあるのでそのあたりはどうするか確認する

# 確認画面

• そもそも確認画面が存在しない、ポップアップで情報を送信させるか確認をする場合の挙動
  • 送信OKの場合の処理
    • サンキューページへ移動
      • サンキューページを用意
    • ポップアップのテキストが「送信完了しました」に変わって終了（ポップアップはボタンで閉じさせる必要がある）
      • 閉じたあとは画面そのままなのか、上部へ移動するのかリロードするのか

# 入力途中にリロードされたときの挙動

• 入力した内容がクリアされるのか
• トップページへ戻されるのか

# エラー文の表示

• バリデーションエラー
  • 入力の下に出す
  • フォーム上部にまとめて出す
• ajaxでPOSTする場合はAPIから返ってきたエラーを出す
  • エラーをページ上のどこに出すのか
• ファーストビューで収まらないようなフォームの場合、エラー箇所までスクロールさせるのか
• ポップアップ（モーダルウィンドウ）で表示させるのか

# バリデーションタイミング

• リアルタイム
  • Vue.jsなどのFWを使うと比較的ラクに実装できる（VeeValidateなど）
  • 文字数でバリデーションするときはリアルタイムだと必要な文字数に達するまでエラー出続けるのでフォーカス外した時にバリデしたほうがユーザーにやさしい
• input からフォーカス外したとき
• submit ボタンを押したとき

# さいごに

バックエンド編も書けるようなエンジニアになりたいんだなぁ

みつを