ユーザー登録フォームの`form_for`メソッドを`:user`で構成した場合に出力されるHTML

仮に、ユーザー登録フォーム(app/views/users/new.html.erb)を以下のような埋め込みRubyで構成したとします。第1引数が:userであることがポイントです。

<%= form_for(:user, url: yield(:path)) do |f| %>

出力されるHTMLは以下のようになります。

<form action="/signup" accept-charset="UTF-8" method="post">
  <!-- 略 -->
</form>

ユーザー登録フォームの`form_for`メソッドを`@user`で構成した場合に出力されるHTML

一方で、ユーザー登録フォーム(app/views/users/new.html.erb)を以下のような埋め込みRubyで構成した場合はどうなるでしょうか。第1引数が@userであることがポイントです。

<%= form_for(@user, url: yield(:path)) do |f| %>

出力されるHTMLは以下のようになります。

<form class="new_user" id="new_user" action="/signup" accept-charset="UTF-8" method="post">
  <!-- 略 -->
</form>

form要素に、:userの場合には定義されていなかったid="new_user"やclass="new_user"といった属性が定義されています。

ユーザー編集フォームの`form_for`メソッドを`@user`で構成した場合に出力されるHTML

今度は、@userで構成したform_forメソッドをユーザー情報編集フォーム(app/views/users/edit.html.erb)で使うとどうなるでしょうか。

<%= form_for(@user, url: yield(:path)) do |f| %>

出力されるHTMLは以下のようになります。

<form class="edit_user" id="edit_user_1" action="/users/1" accept-charset="UTF-8" method="post">
  <!-- 略 -->
</form>

form要素に、id="edit_user1"やclass="edit_user"といった属性が定義されています。

form_forメソッドの第1引数として@userを与えた場合、何のアクションに対してのフォームであるかに応じて、Railsがid属性やclass属性を自動で定義してくれます。一方で、:userの場合だと、そのような属性の自動定義は行われません。

`@password_reset`ではなく`:password_reset`を使っている理由

「何のアクションに対してのフォームであるかに応じて、Railsがid属性やclass属性を自動で定義する」というのが役に立つのは、「パーシャルを使って、newとeditでフォームの実装を使い回す」といった場合です。本文第10章の演習 - 編集フォームで実装したapp/views/users/_form.html.erbが典型的な例です。

PasswordResetsリソースにおいては、一度生成されたリソースの内容そのものを書き換えるようなユースケースは想定されていません。そのため、「何のアクションに対してのフォームであるかに応じて、Railsがid属性やclass属性を自動で定義する」という機能も使いません。このあたりが「@password_resetではなく:password_resetを使っている理由」となるでしょう。