ハコヅミを作る #46：料理の手順と食材を、1つずつ足す形に直す（ステップ3 完了）

前回（#45）までの相談のあいだに、GitHub Actions の障害は収まりました。止まっていたデプロイを流し直して、#43 の受入確認も済んでいます。

今回は、料理の仕上げです。

• レシピと食材の入力を、1つずつ足す形に直す（#194）
• 画面からはみ出す fieldset
• 料理を、本番に出す

---

どうにも、引っかかる

#42 の最後に書いた、気になる点です。

• 「新しい食材」は、大きな入力欄に、1行に1つずつ名前を書く
• レシピは、大きな入力欄に、自分で「1. 〜 2. 〜」と書く

作るのは簡単な形です。ただ、初めて見た人に、「改行で区切る」は伝わりにくい。レシピも、手順の順番を入れ替えたくなったら、番号を全部打ち直すことになります。

「＋」のボタンで、1つずつ足す形にしたい。レシピは、番号を自動で出して、順番を入れ替えられるようにしたい。

迷ったのは、時期です。#41 で、「料理のあとは、ベータ版まで機能を足さない」と決めたばかりでした。

---

今が、いちばん安い

相談すると、Claude Code は賛成でした。理由は、こうです。

• 料理は、まだ本番に出ていない。今なら、誰のデータも入っていない
• 新しい機能ではなく、料理の仕上げなので、約束には当たらない
• データの形に関わるのは、レシピのほう。「1. 〜 2. 〜」と自由に書かれた文を、あとから手順に分け直すのは、きれいにはできない

テスタがレシピを書き込んだあとでは、直すのが難しくなります。料理を本番に出すのは、これが入ってからにしました。

---

「×」は、何を消すのか

食材のほうで迷っていたのは、足したあとに消したいときです。「−」のボタンを置くと、この料理から外すのか、消耗品そのものを消すのかが、分からなくなりそうでした。

もらった答えは、「出す場所を分ければ、迷わなくなる」です。

もの	外し方	意味
＋で足した、まだ保存していない行	行の右の「×」	入力を取り消すだけ。まだ消耗品になっていない
もう消耗品になっている食材	チェックを外す	この料理から外すだけ。消耗品は残る
消耗品そのもの	料理の画面では、消せない	消耗品の画面で消す

「×」を置くのは、保存する前の行だけです。保存すると、その食材は上のチェックの一覧に入ります。そこからは、チェックで扱います。

1つのボタンに、2つの意味を持たせない。それだけで、迷いが消えました。

---

持ち方は、変えない

レシピを手順に分けるなら、手順用のテーブルを足す手があります。ただ、テーブルを足すと、エクスポートにも、退会にも、テストにも、足すものが増えます。

選んだのは、今の列のまま、1行＝1手順として持つ形です。番号は持ちません。画面に出すときに、行ごとに番号を振ります。

列も、マイグレーションも、変わりません。その代わり、決まりが1つ増えます。1つの手順の中では、改行できない。手順の欄で Enter を押しても、改行は入りません。貼り付けた文に改行があれば、保存のときに空白にします。

欄を通さずに、改行の入った文を直接送られても、同じ形に直します。入力欄の制限だけに頼らず、サーバーでも確かめています。

並べ替えは、「↑」「↓」のボタンにしました。指で引っぱって動かす方式は、スマホで安定して動かすのが難しく、パッケージも要ります。

---

画面イメージで、ボタンの場所を選ぶ

案A は、ボタン3つに幅を取られて、入力欄が1行7文字ほどになります。書いた手順が、読めません。

選んだのは、案B です。1つの手順が縦に長くなりますが、書いたものが読めるほうが大事です。「×」が、並べ替えのボタンから離れるので、押しまちがいも減ります。

キャンプの画面のレシピも、番号つきの手順で出すようにしました。

---

fieldset は、縮まない

バックグラウンドの作業が、実装の途中で、別の問題を見つけました。幅 320px で、料理の登録の画面が、横にはみ出します。

原因は、今回の変更ではなく、前からある「食材」のチェックの一覧でした。

• 一覧は、fieldset で囲んである
• fieldset は、中身の最小の幅より、狭くならない
• 切れ目のない長い英数字の名前の消耗品があると、名前が折り返さず、fieldset ごと画面の外へ広がる

100 文字の英数字の名前で試すと、幅 320px の画面で、ページの幅が 909px になりました。長い日本語の名前では、起きません。日本語は、どこででも折り返せるからです。

直しは、食材の fieldset に、どこででも折り返す指定を付けるだけでした。

ところが、折り返すようにすると、今度はチェックボックスが 13px につぶれました。名前が何行にもなって、横に並んだチェックボックスが押されたためです。共通の部品に、つぶれない指定を足しています。

長い英数字の名前の消耗品を、実際に登録する人は少ないと思います。ただ、型番をそのまま名前にする人は、いそうです。

報告の一文を、直す

PR の本文には、「直す前は、このテストが落ちた」と書いてありました。報告をよく読むと、足したテストを、直す前の状態で流してはいません。直す前のはみ出しは、別のやり方で確かめたものでした。

小さなことですが、事実と違う一文は、あとで「このテストは、問題を見つけられる」という思い込みになります。PR の本文を、事実に合わせて直しました。

バックグラウンドの作業は、自分の報告の中で「言いすぎの一文がある」と書いていました。隠さずに言ってくれるのは、助かります。

---

本番に出す

料理の3つ（登録、キャンプで選ぶ、画面の直し）と、#44 のフリーの上限の数を、まとめて本番に出しました。

本番のデータベースには、マイグレーションが3つ適用されます。どれも、今あるデータは消しません。

リリースのあとに、いちばん確かめたかったのは、1つです。今ある消耗品の項目に、「プランから来た項目」の印が、正しく付いているか。開発環境には、もとになる項目が1件もなく、確かめられなかったところでした。本番のデータベースで見る SQL を、リリースの PR に書いておき、マージのあとに確かめています。

お知らせ（#39）にも、1件足しました。日付は、本番に出す日に合わせます。

これで、ステップ3（料理）は完了です。

---

ステップ3 を、振り返る

回	中身
#42	料理の登録
#43	キャンプで作る料理
#44	フリーと有料の違い
#45	公開のあとの道のり
#46	料理の登録の画面の直し

料理の画像と、一覧のカード表示は、作っていません。ベータ版を始めたあとに回してあります。「最小の形で入れる」という条件は、守れました。

---

おわりに

• データの形に関わる直しは、誰かが書き込む前に済ませる。見た目だけの直しは、あとでもできる
• 1つのボタンに、2つの意味を持たせない。出す場所を分ける
• 持ち方を変えずに済む形を、先に探す。1行＝1手順なら、テーブルもマイグレーションも要らなかった
• fieldset は、中身の最小の幅より狭くならない。切れ目のない長い文字があると、画面からはみ出す
• 報告の中の「確かめた」は、何を、どう確かめたのかまで読む

次回からは、ステップ4（ベータ版の公開）です。まずは、別のモデルに、セカンドオピニオンのレビューを頼みます。