Progate +α メモず【Ruby on Rails ②③】

# はじめに
今回はデータベース周りが主軸……と思ったけど、結果的にいろいろと。
なんかいつの間にRails②を終えて③に入ってました。怖。
なのでまとめて投稿します。

今回も、気になる見出しがあれば見ていただけると嬉しいです！
# メモず
## `@変数`：Controllerとviewからアクセスできる
なんで`@`つけると参照できるの？別ファイルじゃないの？
→個人的には`html`と`script`の関係性に置き換えて納得しました。

RUNTEQだと `html`と`css`の関係がわかりやすいでしょうか。
- `html`の中に`css`がある（`stylesheet = css`）
- `html`で`class`や`id`をつけることで、`css`からもアクセスできる
  （`css`の場合はより広く、より深くアクセスできますが）
- `@`をつけてない変数とは、`css`でいうところの`class`も`id`もない`html要素`のイメージ
  （繰り返しになりますが、`css`だとタグでもアクセスできる。まあイメージということで）

## マイグレーションファイルの作成：`rails g model Post content:text name:string`
ここはProgateそのままになりますが
1. `rails`コマンドで、`g`つまり`generate`する。何を？
2. `model`。クラス名は`Post`。そして……
3. `Post`の集合体＝データベースの`posts`データベースと、`posts`マイグレーションファイルを作成。
4. `posts`の中身（構造）として、`content`という名前のカラムで、その中の型は`text`だよ。
### マイグレーションファイルって？
[前回記事](https://qiita.com/kohki_takatama/items/f6b52f97087765cc3fbc)にも書きましたが、
"Migration"：移行・遷移という意味。**データベースの設計図**のこと。  
データベースという建物の構造を遷移させるファイル、というイメージ。

### ファイルの場所
`post.rb`：`app/models/post.rb`
`xxx_create_posts.rb`：`db/migrate/xxx_create_posts.rb`
### 作成されたファイルの解説
Progateには「理解しなくていいよ！」って言われたけど・・・気になる・・・
```rb
class CreatePosts < ActiveRecord::Migration[5.0]
  def change
    create_table :posts do |t|
      t.text :content

      t.timestamps
    end
  end
end
```
- `class CreatePosts < ActiveRecord::Migration[5.0]` 
	  新しいクラス`CreatePosts`を定義。`ActiveRecord::Migration`を継承する。
	  `5.0`は、Rails 5.0のマイグレーションに準拠ということ。
- `def change`
    メソッド`change`を定義。マイグレーションファイルが実行された時と、ロールバックの時に呼び出される。
    `change`メソッドの利点は、単一のメソッドでマイグレーションの「進行」と「ロールバック」の両方の振る舞いを定義できること。
	>ただし、Railsが自動的に逆操作を推測できない複雑な変更を行う場合は、代わりに`up`メソッドと`down`メソッドを使用して、それぞれの操作を明示的に定義する必要があります。
- `create_table :posts do |t|`
	新しいテーブル`posts`を作成。`:`はシンボルであるということ。識別子として優れている。
	 シンボルについて詳しくは[前々回の記事](https://qiita.com/kohki_takatama/items/383ea364bbf41fdae95e#%E3%82%B7%E3%83%B3%E3%83%9C%E3%83%ABkey%E3%81%A8%E6%96%87%E5%AD%97%E5%88%97key%E3%81%AE%E9%81%95%E3%81%84%E3%81%A3%E3%81%A6)
- `t.text :content` 
	  `posts`テーブルに`content`という名前の`text`型のカラムを追加。
	>このカラムは、記事の本文など、長い文字列を格納するために使用されることが一般的です。
- `t.timestamps`
	>2つのカラム、`created_at`と`updated_at`をテーブルに追加します。これらはそれぞれ、レコードが作成された日時と最後に更新された日時を自動的に記録します。
## `rails db:migrate`マイグレーションファイルの実行
`change`メソッドの実行を行う。
この時、`create_table`メソッドで、自動的に`id`カラムも追加される。
無いと思うが、何らかの理由で`id`カラムを追加したくない場合は
```rb
class CreatePosts < ActiveRecord::Migration[5.0]
  def change
    create_table :posts, id: false do |t|
      t.text :content
      t.timestamps
    end
  end
end
```
と、`id: false`オプションで`id`カラムの追加をしないようにできる。
また、`create_table`メソッドで、すでに作成されたテーブル名を指定した場合、エラーが起こる。
同名のテーブルが存在しないときのみテーブルを作成する：`if_not_exists: true:オプション
```rb
class CreatePosts < ActiveRecord::Migration[5.0]
  def change
    create_table :posts, if_not_exists: true do |t|
      t.text :content
      t.timestamps
    end
  end
end
```
## 今更ながら…`Ctrl`+`Shift`+`V`で貼り付け
ターミナルの話。どうも慣れなくて、`Ctrl`+`C`で貼り付けしてProgateに怒られてます。
## Rails console の起動`rails console`
一般的なコンソール**ではない**。
- Rails環境へのアクセス。MVC、クラス、メソッドのすべてにアクセス可能
- Rubyコードを入力し、リアルタイムで実行可能。**テスト・データベース操作・アプリケーション動作確認**が簡単に行える。

なお、ここで定義した変数は、consoleを終了するまで有効。
`quit`コマンドでコンソールを終了。
### データベースへの追加
ここまでの例`post`を使うと、
```rb
変数(postが一般的)=Post.new(content:"勉強なう")
変数.save
```
をconsole内で行う。
## `<% %>`と`<%= %>`の違い
>1. **`<% %>`**:
    - この構文は、Rubyのコードを実行しますが、その結果をビューに出力しません。
    - コントロールフローのコード（例: `if`、`for`、`each`などのループや条件分岐）に使われることが一般的です。
    - 例: `<% if user_signed_in? %>`や`<% @users.each do |user| %>`
>2. **`<%= %>`**:
    - この構文は、Rubyのコードを実行し、その結果をビューに出力します。
    - 変数の値やメソッドの戻り値をHTMLテンプレートに表示したい場合に使います。
    - 例: `<%= @user.name %>`や`<%= link_to 'Home', root_path %>`
## `application.html.erb`：ビューの共通部分
ヘッダー・フッター・ナビゲーションバーなど、全ページに共通するHTML構造を記述する。
これは、デフォルトでレイアウトファイル（`app/viws/layouts`）を読み込むよう設定されているため。
### Railsでページがレンダリングされるプロセス
>1. **URLに基づいたアクションの実行**: まず、ユーザーがアクセスするURLに基づいて、適切なコントローラーとアクションが特定されます。このアクションは、ビューをレンダリングするために必要なデータを準備します。
    
>2. **ビューファイルの決定**: 次に、特定されたアクションに対応するビューファイル（例えば `show.html.erb` など）が決定されます。このファイルには、ページの具体的なHTMLコンテンツが含まれています。
    
>3. **レイアウトファイル（通常は `application.html.erb`）の適用**: ビューファイルの内容をレンダリングする前に、Railsはレイアウトファイル（デフォルトでは `application.html.erb`）を読み込みます。このレイアウトファイルは、サイト全体で共通のHTML構造（ヘッダー、フッターなど）を定義します。
    
>4. **ビューファイルの内容をレイアウトに挿入**: ビューファイルの内容は、レイアウトファイル内の `<%= yield %>` の位置に挿入されます。これにより、ビューの内容が共通のレイアウトの中に組み込まれた最終的なHTMLページが生成されます。
### もし、`<header>`が両方のファイルに存在していたら？
`application.html.erb`
```html
    <header>
      <div class="header-logo">
        <a href="/">TweetApp</a>
      </div>
      <ul class="header-menus">
        <li><a href="/about">TweetAppとは</a></li>
      </ul>
    </header>
```
`top.html.erb`
```html
<header>
  <div class="header-logo">
    <a href="/">Facebook</a>
  </div>
  <ul class="header-menus">
    <li>
      <a href="/about">TweetAppとは</a>
    </li>
  </ul>
</header>
```
結果は・・・
重なりました！！（画像撮り忘れ←）
両方表示されるってことですね。
## `link_to`メソッド：`a`タグ
`html.erb`において、以下の2つは等価
`<a href="/top">TopPage</a>` / `<%= link_to("TopPage", "/top)>`
さらに、`link_to`は
- 自動でセキュリティ機能を提供する
- ブロックを受け取り、複数のHTML要素を簡単に含めることができる
- Rialsヘルパー（いずれやるであろう概念）を使用できる。
といった利点がある。
### `post/:id`：`:id`によるルーティング
```rb
get "post/1" => "posts#show"
get "post/2" => "posts#show"
get "post/3" => "posts#show"
#...
```
と書くよりも、
```rb
get "post/:id" => "posts#show"
```
と書いた方がスマート！ただし、
```rb
get "post/:id" => "posts#show"
get "post/index" => "posts#show"
```
の順になってしまうと、`post/:id`が優先されてしまい、
`post/index`へのアクセスを`:id = index`だと処理してしまう。
よって、
```rb
get "post/index" => "posts#show"
get "post/:id" => "posts#show"
```
と、適切な順番で書こう。
### でも、どうやって`:id`をControllerに渡すの？
実は、`params`パラメータに入っている。よって、
```rb
def show
	@id = params[:id]
end
```
で取得できる。ほかにも、`http://example.com/posts?category=news`というリクエストでは、`params[:category]`は`"news"`となるなどの使い道がある。

## サーバー・データベースの変更：`Post`
### `Get`と`Post`の違い
>1. **GETメソッド**:
    - `GET`は主にデータの取得や表示のために使用されます。
    - これは**安全な操作**であるとされており、データベースやサーバーの状態を変更しないべきです。
    - `GET`リクエストはブックマークやリンクとして共有でき、キャッシュ可能です。
    - URLにパラメータが含まれるため、機密性の高い情報を送信するのには適していません。
>2. **POSTメソッド**:    
    - `POST`はデータをサーバーに送信する際に使用され、一般的にデータの作成や更新に使われます。
    - これは**非安全な操作**であり、データベースやサーバーの状態に変更を加えることが想定されています。
    - `POST`リクエストの内容はブラウザの履歴には保存されず、ブックマークやリンクとしても共有できません。
    - フォームからの送信やAPIリクエストによく使用され、URLにはパラメータが含まれません。

※`GET`がサーバーの状態を変更しないべき、というのは技術的な制約ではなく、HTTPプロトコルの設計原則やベストプラクティスに基づくもの
## `<%=form_tag(URL) do%>`
フォームに入力されたデータを送信するメソッド
### なんで、何かを表示するわけじゃないのに`<%= %>`なの？
確かに`form_tag`は送信のためのメソッドだけど、`form_tag`の中には`Html要素`があるでしょ？
それを表示するためには`<% form_tag %>`ではなく、`<%= form_tag %>`じゃないといけない。
```erb
<div class="main posts-new">
  <div class="container">
    <h1 class="form-heading">投稿する</h1>
    <%= form_tag("/posts/create") do %>
      <div class="form">
        <div class="form-body">
          <textarea></textarea>
          <input type="submit" value="投稿">
        </div>
      </div>
    <% end %>
  </div>
</div>
```
`<% form_tag %>`と書くとどうなるの？→テキストエリアとか、`submit`ボタンとか、`form_tag`の中にあるものがすべて表示されない。
### `textarea`には名前を付けようね！
でないと、`key`になるものがないから、`textarea`に入力したものが、サーバーにおくられなくなっちゃうぞ☆
## `redirect_to(URL)`
リダイレクト（別ページに飛ばす）メソッド。シンプルでいいね！
## クエリ：`.order(property: [:asc|:desc])`
`asc`と`desc`は`a`と`d`のどちらを上にしたいか、で覚えればよさげ。
`a`なら昇順、`d(de)`なら降順。

# 終わりに
新しい概念・構文・用語がさらっと出てくるので、調べる手が止まりません。
でも、Progateのいいところですよね。脱線しないで、まずモノづくり、そして**完成**の経験ができる。独学では難しかったところです。
あと、Rubyも良い言語ですね。今のところ参照元が散らばってること以外は、簡潔に書けてる。
明日も楽しみです。