ticketdive.com
メールアドレス入力フォームの
バリデーション仕様

ticketdive.com (Next.js / SPA) の「メールアドレス入力フォーム」が submit 時にどんなバリデーションを行っているかを、 production の JS chunk を静的解析し、ブラウザ上で実機検証して確定させる。

対象

手法

• Bundle 取得該当ページを読み込んだ際に <script src> から各 page chunk を列挙し、curl で取得。
• 整形prettier --parser babel で minified を可読化。
• 静的解析zod schema・register()・onBlur・refine の引数を読み取り。
• 実機検証本番フォームに既知の typo / 大文字 / + 入りメールを入力し、表示されるエラー文言と DOM 状態を確認。

zod スキーマ (再整形)

email: z.string()
  .min(1,   t("form.required"))      // 必須
  .email(   t("form.emailValid"))    // RFC 風の形式チェック
  .refine(e => !e.includes("+"),     // ★ "+" を 1 文字でも含むと NG
          { message: t("form.emailValid") }),

password: z.string().min(1, t("form.required")),
verificationCode: z.string()
  .length(6, t("form.verificationCodeLength"))
  .regex(/^\d{6}$/, t("form.verificationCodeFormat")),

HTML 属性と検証タイミング

• type"text" (type="email" ではない)。inputMode="email" と autoComplete="email" はソフトキーボード等のヒントのみ。
• HTML5 pattern[a-z0-9._%+\-]+@[a-z0-9.\-]+\.[a-z]{2,}$ が付与されるが、送信は onClick: handleSubmit() 経由で native form submit ではない。よって pattern 制約検証は走らない (実機で VALID.User@Example.COM も通過することを確認)。
• 検証タイミングreact-hook-form のデフォルト mode: onSubmit。入力中・blur 時は何も走らない。
• 典型エラー文言必須 → 「必須項目です」 / 形式・+ → 「有効なメールアドレスを入力してください」。

実機検証 (個人情報マスク済み)

signup ページにはメール検証が 2 系統ある。①は submit 時の zod refine、②は blur 時の純粋な UX (typo 検出ではない再確認プロンプト)。

① submit 時 — typo ブラックリスト

固定リスト z をモジュール初期化時に Object.values({...}).flat() でフラット化し、refine で ローカル部以降を完全一致 比較する。

const z = Object.values({
  icloud:   [/* @icluod.com, @icloud.cmo, ... 30件 */],
  gmail:    [/* @gamil.com,  @gmial.com,  ... 31件 */],
  docomo:   [/* @docmo.ne.jp, @docom.ne.jp, ... 29件 */],
  ezweb:    [/* @ezwbe.ne.jp, @ezweb.ne.jo, ... 29件 */],
  softbank: [/* @i.softabnk.jp, @i.softbakn.jp, ... 27件 */],
  yahoo:    [/* @yhoo.co.jp, @yaho.co.jp, ... 30件 */],
}).flat();

email: z.string()
  .min(1, "form.required")
  .email("form.validEmail")
  .refine(e => {
    const idx    = e.lastIndexOf("@");
    const domain = idx === -1 ? "" : e.slice(idx).toLowerCase();
    return !z.includes(domain) && !e.includes("+");
  }, { message: "form.validEmail" });

• 照合方式完全一致のみ。Levenshtein 距離やキーボード近傍などの fuzzy match は無し。リストに無い typo (例: @gaamail.com) は通過する。
• 正規化toLowerCase() のみ。前後空白の trim はしない。
• エラー文言typo ヒット時も「有効なメールアドレスを入力してください」(form.validEmail)。ユーザーには typo として識別できる文言ではない。

② blur 時 — 入力値エコー UX

ここがユーザー体感での 「メールアドレスに誤りがないか確認してください。」 の出所。バリデーションではなく、入力した値をそのまま赤色で再描画する確認プロンプトである。

const [R, setR] = useState("");

<Input
  {...register("email", {
    onBlur: e => setR(e.currentTarget.value),
  })}
  type="email"
  ...
/>

{R.trim().length > 0 && (
  <Stack>
    <Text fontWeight={600}>
      {t("form.emailConfirmationNote")}      {/* ← 「メールアドレスに誤りがないか確認してください。」 */}
    </Text>
    <Text color="red1" fontWeight={600}>
      {R}                                     {/* ← 入力値を赤で再表示 */}
    </Text>
  </Stack>
)}

• 発火条件email 入力欄を blur した時。中身が空白以外なら必ず表示。
• typo 検出ではない正しい foo@gmail.com でも、ブラックリスト外の typo foo@gaamail.com でも、同じプロンプトが出る。
• 表示位置入力欄の下、error 表示とは別の領域。

signup chunk に含まれる固定リスト。先頭の @ は省略表記。合計 176 件。

signup だけが ① 既存ユーザーの大半を占めるであろう 6 大ドメインを守るために typo リストを持ち、② 入力値エコーで目視確認も促す。 account/email 変更時はすでに本人確認 (パスワード + 認証コード) があるため、typo の救済より 「本人の意図した変更を尊重する」 方針と読み取れる。

• signup の typo 対策は固定リスト依存キーボード隣接エラー (@gmaul.com 等) や .com のミス (.cmo, .con 等) はカバーされているが、リストに無い typo (例: @gaamail.com) は素通りする。
• UX とロジックの分離が浅いblur 時の「メールアドレスに誤りがないか確認してください。」は 常に 出るプロンプトであり、ユーザーは typo 検出と誤解しやすい。
• エラー文言の使い回し形式エラー / + 拒否 / typo ヒットがすべて form.validEmail = 「有効なメールアドレスを入力してください」。原因切り分けが難しく、サポート問い合わせの粒度を上げにくい。
• + 拒否は両ページ共通foo+tag@gmail.com 系のエイリアスはサインアップ・変更ともに不可。RFC 上は valid。意図的な制約と推測 (重複登録抑止 / 配信都合)。
• HTML pattern は装飾的送信は JS でハンドルしているため pattern 制約検証は事実上効かない。大文字や + を含む入力でも HTML5 レベルではエラーにならない。