ハコヅミを作る #33：削除の確認を、ブラウザの標準からアプリのダイアログに変える
前回（#32）は、期間のカレンダーでした。今回も、使い勝手の改善です。
- 削除などの確認を、アプリの見た目に合ったものに変える（#146）
ブラウザの標準の確認
ギアを削除するとき、「「ソロテント」を削除しますか？」と確認を出しています。これは、ブラウザの標準の確認（confirm()）でした。
1行で書けて、確実に動きます。ただ、見た目はブラウザが決めます。アプリの色や文字とは合いませんし、ブラウザによって、出る場所もボタンの並びも違います。
もとは、#31の「気づいた点をためる Issue」に足した項目でした。調べると、使っているのは4か所（削除、キャンプのプランの変更、凍結する、凍結を解く）で、確認の部品を新しく作ることになります。小さな直しではないので、別の Issue に分けました。
先に、見た目を選ぶ
3つの案（作る前の画面イメージ）。選んだのは、いちばん左の案A
選んだのは、案A です。まん中に出て、右下に「やめる」と実行のボタンが並びます。スマホでも広い幅でも、同じ見た目です。
バックグラウンドに任せる前に、決めておく
この Issue は、Claude Code に、バックグラウンドで実装してもらいました（#28）。その間に、別の Issue の相談を進めるためです。
「バックグラウンドで実行して」と頼むと、Claude Code は、すぐには始めませんでした。
先に見た目を決めてもらう必要があります。バックグラウンドの作業は、途中で質問できないためです。
言われてみれば、そのとおりです。画面イメージを見て、案と作り方を選んでから、始めてもらいました。人が決めることは、任せる前に済ませておく。任せたあとに決めることが残っていると、作業は止まるか、勝手に決めて進むか、のどちらかになります。
ブラウザの <dialog> で、自作する
ダイアログは、きちんと作ると、意外に手間がかかります。
- うしろの画面を、操作できなくする
- Esc で閉じる
- Tab を押しても、フォーカスがダイアログの外に出ない
- 閉じたら、もとのボタンにフォーカスを戻す
これを全部やってくれるのが、ブラウザの標準の <dialog> です。showModal() で開くだけで、上の4つが付いてきます。パッケージは足さずに、これで作りました。
できあがった確認。「やめる」・暗い背景・Esc で、何もせずに閉じる
最初のフォーカスは、「やめる」に置く
ダイアログが開いたとき、フォーカスは「やめる」にあります。勢いで Enter を押しても、消えないようにするためです。
仕組みは単純です。<dialog> は、開いたとき、中の最初のボタンにフォーカスを置きます。「やめる」を、先に並べているだけです。
赤いのは、取り返しのつかないものだけ
実行のボタンは、2通りあります。
| 確認 | 実行のボタン |
|---|---|
| 削除 | 赤い「削除する」 |
| 凍結する | 赤い「凍結する」 |
| キャンプのプランの変更 | 緑の「変更する」 |
| 凍結を解く | 緑の「凍結を解く」 |
全部を赤くすると、赤の意味が薄れます。
確認の文は、今までのものを、そのまま使っています。文言の見直しは、今回の対象外にしました。見た目を変える変更と、文を変える変更を混ぜると、何が変わったのかが分かりにくくなるためです。
テストで見つかった、細かな不具合
バックグラウンドの作業の報告には、作りながら見つけて直したことが、いくつか書かれていました。どれも、テストを流して初めて分かったものです。
閉じているダイアログに、テストが当たる
最初は、ダイアログを、閉じているあいだも画面に置いていました（見えないだけ）。すると、ほかのテストが落ちました。「プラン」という名前の入力欄を探すテストが、見出しに「プラン」を含む、閉じたままの確認に当たったのです。
閉じているあいだは、画面に置かないことにしました。管理画面では、ユーザーの数だけ確認が並ぶので、置かないほうが、画面の中身も少なくて済みます。
Esc で閉じて、すぐ開くと、また閉じる
Esc で閉じたあと、すぐにもう一度開くと、勝手に閉じることがありました。
ブラウザは、ダイアログを閉じたあと、少し遅れて「閉じました」と知らせてきます。その知らせが、開き直したあとに届いて、もう一度閉じていました。
「やめる」を押したときも、Esc のときも、背景を押したときも、同じ1つの処理で閉じるようにそろえて、遅れて届く知らせには頼らないようにしています。
今までのテストの書き換え
確認を出す操作は、E2E のあちこちにあります。14 ファイル、31 か所が、ブラウザの標準の確認を受ける書き方になっていました。前回のカレンダーと同じく、操作を関数にまとめて、書き換えています。
「アプリの中に、標準の確認が残っていない」ことも、テストにしました。ソースを読んで、confirm( が出てこないことを確かめます。あとで誰かが（自分が）、手軽さに負けて戻してしまわないための歯止めです。
任せた結果を、どう受け取るか
バックグラウンドの作業が終わると、報告が届きます。そのままうのみにはせず、3つを確かめています。
- CI が通っているかを、自分の目で（Claude Code に頼んで）見る
- 要のファイルを読む。今回は、確認の部品そのもの
- 実物の画面を撮って、見る。選んだ案のとおりか
報告には、「うまくいかなかったこと」も書いてもらっています。今回は、「Safari の実機では確かめていない」「途中で、手元のデータベースにテスト用のデータが残ったので、直接消した」とありました。できたことだけの報告より、こちらのほうが、信用できます。
Safari の件は、受入確認のときに、実機で見る項目に入れました。
おわりに
- 手軽な仕組み（
confirm()）は、最初はそれでよい。見た目が気になってから、置き換える - ダイアログは、ブラウザの
<dialog>に任せる。難しいところを、自分で書かない - 最初のフォーカスは、安全な側に置く
- 赤は、取り返しのつかないものだけに使う
- バックグラウンドに任せる前に、人が決めることを済ませておく
- 任せた結果は、CI・要のコード・実物の画面で確かめる。「できなかったこと」も報告してもらう
次回は、公開までの道のりを、もう一度引き直した話です。