「画面に出ない」を見たとき、実装を疑う前に操作が届いたかを確かめる

入力チェックのエラー表示のスクリーンショットを撮ろうとして、1時間ほど回り道をしました。
原因は実装ではなく、操作のほうでした。
しかもその日、数時間前に同じ症状で実装が原因だったので、そちらに引っぱられていました。

エラーが画面に出なかった

やろうとしていたのは、空のフォームで保存ボタンを押して、
「タイトルを入力してください」が出た画面を撮ることでした。

押しても、何も出ません。
無反応です。
開発者ツールで DOM を見ると、フォームの中にエラー表示の要素が0個でした。

実装を読んだ。正しかった

まず、エラーを表示する部分のコードを読みました。
入力ごとにエラーの有無を見て、あればメッセージを出す。
書けています。
条件の付け方も、表示先も、おかしいところが見つかりません。

読めば読むほど「合っている」としか思えなくて、そこで止まっていました。

直接 submit を起こしたら、正常に出た

見方を変えて、JavaScript からフォームの送信を直接起こしてみました。
ブラウザには、ボタンを押さなくても送信を発生させる手段があります。

その場でエラーが2件出ました。「タイトルを入力してください」「URLを入力してください」。
実装は最初から正しかったわけです。
1文字も直していません。

壊れていたのは、こちら側の操作でした。
自動化のクリックが、送信を起こしていなかっただけでした。
実装を何度読んでも出てこない情報です。

直前の経験が、判断を引っぱっていた

回り道の理由は、はっきりしています。
同じ日の数時間前に、まったく同じ症状で実装が原因だったからです。

症状が同じでも、原因の層が違いました。
上と下です。
そして直前の経験があるぶん、実装を読みに行く動きが速くなっていました。
経験が判断を助けるどころか、切り分けの順序を歪めていた形です。

「出ない」を見ると、出す側から読み始める

振り返って思うのは、順序の癖です。

「画面に出ない」を見ると、出す側から読み始めます。
出す側にはコードがあるので、読めます。読めば確かめた気にもなれます。
一方で、入る側 —— そもそも操作が届いたのか —— は、コードを読んでも分かりません。

だから順序を逆にする、というのが今回の持ち帰りでした。
「そもそも動かそうとしたものは動いたか」を先に見る。
今回は、送信を直接呼ぶだけ。
1分で切り分けられました。

読んでいた時間のほうがずっと長かった、というのが正直なところです。