「RailsガイドのActionViewフォームヘルパーをひたすら読み解いていく」の投稿 - Crieit

【第2回】基本的なフォームを作成する

2020-12-13T18:23:19+09:00

概要

Railsガイドの「１基本的なフォームを作成する」を取り上げる
- Action View フォームヘルパー - Railsガイド
ちなみに、9章まである。12回ぐらいの連載で終わるかな

フォームヘルパーのヘルパーって？

この勉強をしたいと思ったのは、フォームについて勉強したいと思ったから
とはいえ、Railsガイドのタイトルは「Action View フォームヘルパー」
- ということで、まずヘルパーについて簡単に触れる

Viewフォームヘルパーとは、ControllerやModelではなく、Viewで使うことを想定して、フォームを簡単かつ便利に作るためのヘルパー（道具）のこと。

例えば、content_tagヘルパーというものがあるのだけれど、これはまさにその典型例。

content_tag(:div, "header", class: ["one", "two"])
#=> "< div class="one two" >header< /div >"

Rails tips: ビューの`content_tag`のあまり知られていないオプション（翻訳）｜TechRacho（テックラッチョ）〜エンジニアの「？」を「！」に〜｜BPS株式会社

という観点からすれば、フォームヘルパーとは、

フォームを簡単かつ便利に作るためのヘルパー（道具）のこと。

ということは、ヘルパー全般に言えるけれども、簡単かつ便利になる前の
HTMLタグたちを理解しなければ、フォームヘルパーの意味は理解できないとうこと。

基本的なフォームを作成する

Railsガイドでは、まずform_tagの説明から始まる。
ここで、form_tag, form_for, form_withの概要を確認する。

form_tagはモデルに紐づけない場合、form_forはモデルに紐付ける場合に使う
昔（Rails5.1より前）は、form_forとform_tagがあった
form_forとform_tagの2つは、form_withに統合された
この記事でも説明している
- 【Rails 5】(新) form_with と (旧) form_tag, form_for の違い - Qiita

ということで、まずはform_forというモデルに紐づけないシンプルなケースを確認しよう。今では、form_withで書くことが一般的なので、その場合も確認する。

# form_tag
<%= form_tag do %>
  Form contents
<% end %>

# form_with
<%= form_with do %>
  Form contents
<% end %>



  
    
    
  
  Form contents




  
  Form contents

前回の記事で触れたとおりだが、以下を確認しよう。

action: フォームで送信するURL
method: HTTPのリクエストのメソッド（get, post, put, patch, deleteなど）
authenticity_token: CSRF対策のためのトークン。

なお、前回記事では触れなかったが、下記のとおりである。
そんなに重要ではないと思うけど一応確認する。

accept-charset: 文字コードを指定するオプション
name="utf8"のinput: 文字コードを指定するオプション
- IEはフォームのaccpet_charsetを無視して、ブラウザの文字コードと同じエンコードだと認識してたらしい
- それを乗り越えるため、隠しパラメータで文字コードを指定する方法を採用していたらしい

デフォルトでは、現在のURLに対してPOSTメソッドでHTTPリクエストが送られる。 なので、送信先のURLやメソッドに関する記述がなくとも、先ほどのようなHTMLタグが生成される。

1.1 一般的な検索フォーム

モデルに紐づかないフォームとしてありがちなのが、検索フォームだ。
この場合、actionやmethodがデフォルトのままだと困るので、設定する必要がある。

また、検索フォームの場合、何のフォームであるか示すため、
左横なんかにラベルがついていることが一般的だと思う。

そして、当然検索ワードを入力するtextなどの入力フォームや送信ボタンが必要となる。

ということで、このような記述になる。
せっかくなので、form_withバージョンで書いてみる。

<%= form_with(url: "/search", method: "get") do %>
  <%= label_tag(:q, "Search for:") %>
  <%= text_field_tag(:q) %>
  <%= submit_tag("Search") %>
<% end %>


  
    
  
  Search for:

GETメソッドの場合、parameterはURLにくっつけるような形で送信される。
例えば、googleでmiketaと検索すると、以下のようなURLにリダイレクトされる。

[https://www.google.com/search?q=miketa&rlz=1C5CHFA_enJP891JP891&oq=miketa&aqs=chrome..69i57j69i59l2j69i60l4j69i65.551j0j15&sourceid=chrome&ie=UTF-8](https://www.google.com/search?q=miketa&rlz=1C5CHFA_enJP891JP891&oq=miketa&aqs=chrome..69i57j69i59l2j69i60l4j69i65.551j0j15&sourceid=chrome&ie=UTF-8)

不勉強なので詳しいことは分からないが、以下のようなパラメータが送られている。本筋から外れるのでこれ以上は踏み入らないが、各メソッドの違いを意識するとよい。

q: miketa  
rlz: 1C5CHFA-en....  
aqs: chrome..69i...  
sourceid: chrome
ie: UTF-8

1.2 フォームヘルパーの呼び出しで複数のハッシュを使う

Railsガイドには、以下のように書いてある。

form_tagヘルパーは2つの引数を取ります。
1つはアクションへのパスで、もう1つはオプションのハッシュです。

このハッシュには、フォーム送信のHTTPメソッドやHTMLオプション(フォーム要素のクラスなど)が含まれます。

引数とは、メソッドのカッコ内のやつです。

form_tag(引数はここだよ)

引数は、アクションへのパスとオプションのハッシュの２つなので、こうなる。

form_tag(
  第１引数 - アクションへのパス（paramsの送り先のURL）, 
  第２引数 - オプションのハッシュ（GETなどのHTTPメソッドやhtmlタグ内のclassの指定など
)

第１引数についてはURLを直書きすることもできるが、users_pathのように書くこともできるし、controller: "people", action: "search"のように書くこともできる。

ただ、controller: "people", action: "search"を何気なく書くと、エラーになってしまう。例えば、以下のように書くとactionが第２引数と認識されるのでエラーになる。

form_tag(controller: "people", action: "search", method: "get", class: "nifty_form")

よって、ハッシュを使うとよい。

form_tag({controller: "people", action: "search"}, method: "get", class: "nifty_form")

余談：form_withの場合

ぶっちゃけあまりform_tagなんて使わないと思うので、
form_withについても理解しておきたい。

ということで、form_withメソッドについても調べてみた。

form_with(model: nil, scope: nil, url: nil, format: nil, **options, &block)

ここでRuby自体の理解が大事になるのだが、こういった引数の書き方はキーワード引数という。キーワード引数を指定をしないとき、デフォルトの設定が採用される。

例えば、root_pathへのフォームを作成する場合、このようなコードとなる。

<%= form_with url: root_path do |form| %>
  フォーム内容
<% end %>

この場合、例えばmodelについての引数は指定されていない。その場合、デフォルトのmodel:nilが採用される。他のオプションについても、同様である。

その他のオプション等が何を意味するかについては、長くなりそうなので、後ほどの機会で。

1.3 フォーム要素生成に使うヘルパー

分かりやすいので、そのまま掲載する笑

Railsには、〜フォーム要素を生成するためのヘルパーが多数用意されています。
これらの基本的なヘルパーは名前が_tagで終わっており (text_field_tagやcheck_box_tagなど)
それぞれただ1つの要素を生成します。

ただ、どちらかというと、tagよりfieldの方が目にすることが多いかもしれない。
fieldについては、後ほど触れる。

続ける。

これらのヘルパーの1番目のパラメータは、inputの名前と決まっています。
・・・たとえば、フォームに<%= text_field_tag(:query) %>というコードが含まれていたとすると、
コントローラでparams[:query]と指定すればこのフィールドの値にアクセスできます。

少し具体的にみてみる。

<%= form_with url:root_path do %>
  <%= check_box_tag(:pet_dog) %>
  <%= label_tag(:pet_dog, "I own a dog") %>
  <%= check_box_tag(:pet_cat) %>
  <%= label_tag(:pet_cat, "I own a cat") %>
  <%= submit_tag("Search") %>
<% end %>

これで、こんなHTMLタグが生成される。


  
  
  I own a dog
  
  I own a cat

そして、このフォームから送信されたparamsを取得するには、
〜tagの第１引数を使って、こんな感じで書いてあげれば大丈夫。

# pet_dogにチェックを入れて、pet_catにチェックをしていない場合
params[:pet_dog] #=> 1という値が取得できる
params[:pet_cat] #=> nilになる（paramsが送られていないため）

1.4 その他のヘルパー

HTMLのinputタグは、山ほど種類がある。
20種類以上ある。

ということは、その数だけ、Railsのヘルパーもある。
Railsガイドでは、これだけ紹介されているが、あくまで一例。

<%= text_area_tag(:message, "Hi, nice site", size: "24x6") %>
<%= password_field_tag(:password) %>
<%= hidden_field_tag(:parent_id, "5") %>
<%= search_field(:user, :name) %>
<%= telephone_field(:user, :phone) %>
<%= date_field(:user, :born_on) %>
<%= datetime_local_field(:user, :graduation_day) %>
<%= month_field(:user, :birthday_month) %>
<%= week_field(:user, :birthday_week) %>
<%= url_field(:user, :homepage) %>
<%= email_field(:user, :address) %>
<%= color_field(:user, :favorite_color) %>
<%= time_field(:task, :started_at) %>
<%= number_field(:product, :price, in: 1.0..20.0, step: 0.5) %>
<%= range_field(:product, :discount, in: 1..100) %>

フォーム作成前に、どのようなinputタグがあるか、そしてそれに対応するrailsのヘルパーはどのようなものになるか、確認してみるといいかも。

最後にテスト

フォームヘルパーは、HTMLの何を簡単に作るものでしょう？
getメソッドの場合、パラメータはどこに付与されるでしょう？
- ここではざっくりとしか説明してないですが、postメソッドの場合などについても調べてみるとよい
以下の場合、どうすればいいでしょう？
- emailフィールドのフォームを設ける
- コントローラでparams[:person]として値を取得したい
- モデルに紐づけず、検索フォームとしたい
- 検索フォームは、emails_controller.rbのsearchアクションで処理する
- 適当な設定なので、おかしいところがあるかもしれないが、ご容赦ください
- その場合、ツッコミどころを考えるのも勉強になります笑
fieldの数を10個ぐらいあげてみよう！

補足

やばい、この調子だと日がくれる...

【第１回】 Formの概要

2020-12-13T18:20:56+09:00

概要

初回なので、Railsガイドの解説に突入する前に、フォーム自体についてまとめる

フォームとは

フォームとは、Webアプリを使う人がサーバーに何かを送るときに使う
例えば、ユーザー登録のときにメールアドレスやパスワード登録をするときなど
ここなんかが分かりやすそうだった
- formタグとは｜コーディングのプロが作るHTMLタグ辞典

初学者でも、何かを送るものって意識はあるだろうけど、以下の意識は薄いのではないか。
フォームでは、何を・どこに・どのように・どんなinputで送るかが定義されている。

どこのURLに
どのようなメソッドで
どのようなパラメータを送るか
- keyとvalueは何か
フォームの種類は何か
- HTMLのinputで指定する
- text_fieldなどがある
- 実は20種類以上もある。。

What, Where, How,（ + Type of input)と覚えるとよいかも。（自己流です）
2W1HT・・・なんかいい語呂でもないかな。。。

まず、フォームの概要について押さえておく。
ここはRailsガイドに掲載されていないが、把握すべき基礎的な内容だ。

formタグの概要について


  [email protected]" />

action: アクセス先のURL
method: HTTPメソッド
type: フォームの入力値の種類（text, email, radio, checkboxなど）
name: フォームの名前を示している
value: 値

アクションは、あくまでアクセス先のURLである。
間違いやすいので注意すること。

paramsハッシュの中身は、以下のとおりとなる。

{'user' => {'email' => '[email protected]'}, {'name' => 'alice'}, {'age' => 20} }

このような形で書くことで、params[:user]と書くことで、Userモデルに紐づく全てのハッシュを取得できる。また、以下のように取得するハッシュを制限することができる。

params.require(:user).permit(:email)

Labelタグについて

フォームでは、よくラベルタグを使う。
フォームを使うメリットは、２つある。

ラベルをクリックすると、そのチェックボックスをクリックしたことになる。
音声読み上げソフトが、いい感じに対応してくれる。

ラベルタグは、インプットタグと紐付ける。
紐付けにあたっては、labelのforとinputのidを同一にする。

以下の事例においては、cheeseで紐付けされている。
繰り返しになるが、nameはパラメータのkeyなので、勘違いしないように。
（keyというのは用語が適切でないかも。Hashのkey-valueのkey）


    Do you like cheese?

Form_withでは使われないが、labelタグにinputタグをネストすることでも紐付け可能。

Do you like peas?

- HTML: HyperText Markup Language | MDN

Formの隠し要素

Railsでフォームを作ると、文字エンコードとauthenticity_tokenが自動で含まれる。
authenticity_tokenはCSRF対策のため。GETメソッドの場合、このトークンは作成されない。

Railsサーバーに対して、このトークン抜きでリクエストを送っても拒否される。要注意。（ただし、Railsの設定次第ではトークン抜きでも受け付けることができたはず）

<%= form_tag do %>
  Form contents
<% end %>


  
    
    
  
  Form contents

CSRFとは

CSRFとは、クロスサイトリクエストフォージェリーの略。
まず、リクエストフォージェリーに着目するとよさそう。

リクエストとは、サーバーに送るリクエストのこと。
例えば、ユーザー登録をするのは、クライアントからサーバーへのリクエスト。

フォージェリとは、偽物のこと。

で、リクエストフォージェリー。
これは、悪意のある人がJavaScriptなんかでこっそりコードを仕込んでおくことで、
その人の意志とは関係なく、サーバー側にリクエストを送ってしまうこと。

え、そんなことできるのかって。できる。
JavaScriptを使うと、例えば何かの要素をクリックした際に、
特定のURLに対してリクエストを送るよう指示を出すことができる。

この機能を使って、例えばtwitterにログインしているユーザーを対象にして、
クリックしたと同時に、そのユーザーに知らず知らずの内に、サーバー側にリクエストを投げることができる。

例えば、殺害予告ツイートの投稿リクエストを投げることができる。
ログインした状態で、まさにそのユーザーからリクエストが送られてしまうので、
このリクエストは受け入れられてしまい、意図していないのに殺害予告ツイートをしてしまうハメになる。

たぶん、概念的にはこんな感じの理解で大枠あっていると思う。

authenticity_tokenでCSRFがなぜ対策できるのか

試してみると分かるが、このtokenはサーバー側から毎回ランダムに生成される。
同じページであっても、リロードすると変わるはずだ。

このトークンは、投稿時にサーバー側に併せて送られる。
そして、このトークンがサーバー側で事前に送ったものと一致するか検証がなされる。

つまり、イメージとしては、こんなかんじ。
まず、OKパターン。

サーバー「ユーザー登録するときは、開けゴマって言うこと」
クライアント「開けゴマ！ユーザー登録します。」
サーバー「OK！登録する！」

NGパターン。

クライアントがCSRFにひかかってしまった
意図していないのに「〇〇を17時に爆破する」というツイート登録がサーバーに飛ぶ
サーバー「開けゴマ！がないから受け付けません」

この開けゴマがtoken。

これがリロードする度に変わるので、サイトをまたいで、つまりクロスサイトで
フォージェリーなリクエストを送ることを防げる。

最後にテスト

まず、これが自分の言葉で説明できるか考えてみよう。


  [email protected]" />

次に、ラベルって何か自分の言葉説明できるか考えてみよう。
そして、空欄に何が入るか振り返ってみよう。


    Do you like cheese?

最後にauthenticity_tokenって何だったか自分の言葉で説明できるか考えてみよう。

補足

自分で書いておきながら説明できないかも。。。
あと、これは書きダメベースなので、次回から尻すぼみます。