【Rails】Railsチュートリアル 第５章 復習用

前回の第４章ではRubyのコードに関して学習し、基礎的なオブジェクト指向が理解出来た（はず）

第５章ではおそらくviewの部分をメインに扱っている
さらに今回はBootstrapも用いる

classとid

・HTMLではclassに似たようなidというものがある
・idは重複してはならない（一度しかつかえない）
・クラスとidはcssを当てる時に便利
・また今回のclass名にはbootstrapにおいて特別な意味を持つため、適当につけてはいけない。

.nav{ /*ここはidの場合は.ではなく#を用いる*/
    font-size:20px
    }

link_to（重要）

・様々なRailsのコードを見る限り恐らくめちゃくちゃ頻出するコード
・link_toはページ内にリンクを作成するコード(HTMLでいう<a href=""　と同じである)
・書き方は、link_to　”リンクテキスト名", "URL"(idは必ず必要でない)
・URLの部分の具体的な書き方は以降解説する(現在#を仮においている)

<%= link_to "sample app", '#', id: "logo" %>

image_tag

・image_tagは画像を表示させるためのもの
・第一引数は画像のファイルパス。絶対必要
・第二、第三引数のaltとwidthはなくても良い。(altは画像が表示できない時に代わりのテキストを表示させる。)
・link_toの引数としてimage_tagを設定し、画像にリンクを貼ることができる。書き方は以下のとおり

<%= link_to image_tag("rails.svg", alt: "Rails logo", width: "200"),
                      "https://rubyonrails.org/" %>

Bootstrap

・先ほども書いたように、html.erbで指定したクラス名はすべてbootstrapに関係してあるため、意味がある。
・例えば、navbar-inverseクラスはデフォルトのnavbarの色をダークな色調に変更する
・bootstrapを設定するには、bootstrap-sass gemを使ってRailsアプリケーションに導入する
・gemを追加したらbundle installを忘れずに
・もしくはターミナルで次のコマンドを打つ

gem install bootstrap -v 5.3.0

・まだ理解する必要はないらしいが、cssの拡張子をscssにしている理由はbootstrap-sass gemが動作するためのおまじないとして必要
・scssファイルに以下の記述を加えることでbootstrapを読み込むことができる

@import "bootstrap-sprockets";
@import "bootstrap";

パーシャル

・ヘッダーのhtmlの部分を別ファイルに保存して、部分ごとにhtmlファイルを分割する
・それぞれのまとまりをファイルごとに分けることで、作業しやすくする(=パーシャル)
・パーシャルのファイルの頭文字は必ず_からつける（じゃないと認識しない）
・以下の記述を加えることで、このコードが書かれた部分は layouts/_header.html.erbに書き換わる(yieldと同じ感じ)

<%= render 'layouts/header' %>

アセットパイプライン

・「CSSや画像などの静的コンテンツの作成と管理を大幅に強化する」らしい
・つまりディレクトリ内のcssや画像などをひとまとまりにすること
・静的ファイルを目的別に分類する、標準的な3つのディレクトリが使われている
・app/assets: 現在のアプリケーション固有のアセット
・lib/assets: あなたの開発チームによって作成されたライブラリ用のアセット
・vendor/assets: サードパーティのアセット（デフォルトでは存在しません）
・これらをマニフェストファイルを使ってどのように１つにまとめるか指定する
・実際に処理を行うのはSprocketsというgem

どうしてこんなめんどくさいことをするのか？

・機能ごとや場所ごとにcssファイルを分割して整理しやすくすることもできる（パーシャルのように）
・しかし、cssファイルを多用すると本番環境では著しく動作が遅くなってしまう
・だからといって最初から１つにファイルをまとめたら、開発段階では開発者は見づらくなってしまう
・なので開発段階では分割し見やすくし、本番環境では動作を早めるためにまとめる
・そのまとめる作業で使うのがアセットパイプライン！
・デプロイの際にコマンドを実行してこのアセットをコンパイルする

Sass

・Sassは強化版css
・変数、ネスト、ミックスインという機能がとくに重要(ミックスインは第７章で解説)
・Sassは先程作ったように.scssというフォーマットに対応している
・cssファイルと記述は同じなので、cssファイルをsassにコピペしても使うことができる

ネスト

・ネストは、共通なパターンがファイル内にある時まとめることができる

.center {
  text-align: center;
}

.center h1 {
  margin-bottom: 10px;
}

cssではこのように記述するが

.center {
  text-align: center;
  h1 {
    margin-bottom: 10px;
  }
}

sassではこのように書き換えることができる
idをネストするときは、#id:hover だったら、&:hoverとなる（&を代わりに置く）

変数

その名のとおり、sassでは色など繰り返し使うものに変数を指定できる

$light-gray: #777;
.
.
h2 {
  color: $light-gray;
}

・このように$変数名:#;で変数を指定することができる
・Bootstrapではデフォルトで色に変数が指定されている

レイアウトのリンク

・先ほどlink_toで#とおいたところを実際のリンクに変更する
・aboutページへのURLは/static_pages/aboutよりも/aboutのほうがよい
・さらに/aboutではなくabout_pathとして名前付きルーティングにできる
・_path以外にも_urlというものもある
・root_pathはルートURL以下の文字列を、root_urlは完全なURLの文字列を返します。

root_path -> '/'
root_url  -> 'https://www.example.com/'

名前付きルーティングの使い方

・about_path等はこれまでのルートの記述方法では使えない。
・そのため名前付きルーティングが使えるようなルーティングに変更していく

get "static_pages/help"

この記述を

get  "/help", to: "static_pages#help"

このように変更する
・GETリクエストが/helpに送信されたときにStaticPagesコントローラーのhelpアクションを呼び出してくれるようになります
・また名前付きルーティングが使えるようになる

Integration test(統合テスト)

・このテストは、アプリ内のリンクがちゃんと正常に動作するか確かめるテスト
・アプリケーションのHTML構造を調べて、レイアウトの各リンクが正しく動くかどうかチェックする

1.ルートURL（Homeページ）にGETリクエストを送る。
2.正しいページテンプレートが描画されているかどうか確かめる。
3.Home、Help、About、Contactの各ページへのリンクが正しく動くか確かめる。

require "test_helper"

class SiteLayoutTest < ActionDispatch::IntegrationTest

  test "layout links" do
    get root_path
    assert_template 'static_pages/home'
    assert_select "a[href=?]", root_path, count: 2
    assert_select "a[href=?]", help_path
    assert_select "a[href=?]", about_path
    assert_select "a[href=?]", contact_path
  end
end

・まずassert_templateメソッドを使ってHomeページが正しいビューをレンダリングしているかどうか確かめます

assert_select "a[href=?]", about_path

・assert_selectメソッドを使って、特定のリンクが存在するかどうかを、aタグとhref属性をオプションで指定して調べています。
・assert_selectメソッドは、特定のHTMLタグが存在するかどうかをテストするもの
・Railsは自動的にはてなマーク "?" をabout_pathに置換しています
・ルートurlは２個存在するため、count:2を使ってurlが２個あるかどうか調べている(ロゴの部分とヘッダーにある)
・assert_selectメソッドには様々なオプションが有るため、いろいろなテストができる
・しかしあまりassert_selectで複雑なテストはしないほうがいい

User登録

・Usersコントローラーを作成する
・RESTアーキテクチャに従い、新規ユーザーへのアクションはnewとする（後日RESTについての記事を書く予定）
・ここで私は、「どんな基準でコントローラーを分けているのか？」と疑問に思った
・そのためこちらのサイトを参照しようと思うhttps://qiita.com/starhacks/items/0e156c815a69564e90ec
・この後はルーティングを名前付きルーティングに変更し、テストやhomeアクションも変更した

感想

４章は意外と理解が難しくなかったが、５章は理解するまでがとても難しかった印象
特にアセットパイプラインは理解に苦しんだ
Bootstrapの有用性がまだ私にはわからない。そもそもどのクラス名がどのような効果になるのか、全くわからない
ただ４章のお陰でテストコードの意味がだんだんとわかるようになってきた
またUsersコントローラーを新たに作成したが、どうしてわざわざ新たなコントローラーを作成したのか、疑問に残るため調べたいと思う