Rails – 掲示板 – モデルとデータベースの準備

概要

第2段階の仕様のうちプロフィールに続いて記事投稿の機能を実装していく。

まず、記事投稿に必要なモデルとデータベースのテーブルを準備する。

  • Post:投稿記事のモデル
  • PostImage:投稿記事に付加可能な画像ファイルのモデル

手順の詳細は「モデル生成とマイグレーション」、「アソシエーション~基本」を参照

モデルの生成

Postモデル

以下のRailsコマンドでPostモデルを生成する。Userモデルを参照するため、user:referencesを指定。

生成されたモデルの内容を確認。references指定に基づいて、Railsによりbelongs_toが記述されている。

app/models/post.rb

モデルと同時に生成されるマイグレーションファイルを確認。ここでもusersテーブルを参照する外部キーが設定されている。

20210331121751_create_posts

PostImageモデル

以下のRailsコマンドでPostモデルを生成する。Postモデルを参照するため、post:referencesを指定。

生成されたモデルの内容を確認。references指定に基づいて、Railsによりbelongs_toが記述されている。

models/post_image.rb

モデルと同時に生成されるマイグレーションファイルを確認。ここでもpostsテーブルを参照する外部キーが設定されている。

20210331122545_create_post_images.rb

アソシエーションの設定

Userは複数の記事(Post)を投稿するため、Userモデルにhas_manyを追加する。

models/User.rb

 

1つの記事(Post)が複数の画像(PostImage)を持つことができるので、Postモデルにhas_manyを設定する。post_imagesと複数形になっている点に注意。

さらに、記事投稿時に画像ファイルも削除するよう、dependentも設定。

models/post.rb

post_image.rbPostに従属するが、Railsによってbelongs_toが設定済みなので編集不要。

マイグレート

以上の設定に基づいてマイグレーションを実行。その結果、postsテーブルとpost_imagesテーブルが生成される。

postsテーブル、post_imagesテーブルの構造を確認。

rails consoleでの確認

rails consoleでアソシエーションが機能しているか確認。

まず、Userに属するPostデータとPostに属するPostImageデータを作成。

テーブルに登録されたデータを確認。

このあとpost.destroyにより、postデータとPostImageデータが連動して削除される。

 

Rails – アソシエーション – 基本

概要

Railsにおけるデータベースのテーブル間のアソシエーションについて、基本を整理する。

以下のようなテーブルを例にする。Railsが生成するcreated_atupdated_atは省略している。

  • userspostsimagesのレコードはそれぞれUserPostImageモデルのインスタンス
  • PostUserに、ImagePostに属する
  • Userは0以上複数のPostを持つ
  • Postは0以上複数のImageを持つ

アソシエーションの意義

単純にテーブル操作する場合

普通に3つのテーブルだけがある場合に、特定idのユーザーの投稿記事を作成し、その記事が2つの画像を持たせるには以下の様になるだろう。

このときに生成されるデータは以下の様になる。

ここで投稿記事Post(id=1)をそれらに付随する2つの画像データとともに削除する。それには2つのImageを削除してから元のPostを削除する。

このように個別のテーブルを操作する場合、データの生成・登録や削除の際に、

  • 関連するテーブルのデータのidを常に意識し
  • データ間の関連を念頭に置きながら個々のデータを操作する

必要がある。

アソシエーション導入後

テーブル間のアソシエーションを導入した場合、関連付けられたデータの操作が直感的に、またシンプルになる。

データの生成

データの生成は以下のとおりで、親となるデータのidを意識しなくても、具体の親オブジェクトを指定して生成すれば関連付けられたデータが生成される。

上の例では、まずpostscreateした後に、そのインスタンスに従属するようにimagescreateしている。

このようなデータベースへの書き込みを、さらにまとめることができる。

 

最後にsaveするまではデータベースには保存されずidもnilのままだが、オブジェクト間の関係は保たれている。最後に保存するときに、postと2つのImagesのインスタンスが同時に保存される。

データの取得

データの取得は、親モデル.子モデルのコレクションで取得し、親モデルは単数形、子モデルは複数形。

データの削除

そして投稿記事を画像ごと削除する場合には、以下の様にたった1行で済む

さらに、外部キー制約をかけているので、以下のように親のデータだけを削除しようとするとエラーとなる。

アソシエーション設定の流れ

仕様

冒頭の3つのテーブルのうち、PostImageの2つを取り出して考える。以下の様に若干変更。

  • Postcomment要素を持つ
  • ImagePostImageに変更
  • Userとの関係は考えない

2つのモデルの関係は以下のとおりとする。

  • PostImagePostに属する
  • Postは0以上複数のPostImageを持つ
  • Postの削除に伴って、これに属するPostImageのデータも削除される

モデルの生成~外部キー指定

以下のコマンドで2つのモデルを生成する。

PostImagePostに従属するよう、post:referencesを指定している。生成するモデルが属するモデル(親のモデル)をAとするとA:referencesと指定する。

Postモデルについては枠組みのみ生成されている。

app/models/post.rb

PostImageモデルについては、references指定に伴って、Railsによりbelongs_toの1行が追加されている。

app/models/post_image.rb

モデルのアソシエーションの定義

has_many

Postが複数のPostImageを持つことをRailsに伝えるため、Postモデルにhas_manyメソッドを追記する。

dependent

親のデータを削除するときにこのデータも一括して削除するためには、dependent: :destroyを指定。

注意点

  • belongs_to :parentはメソッドの引数が単数形
  • has_many :childrenはメソッドの引数が複数形
  • dependent: :destroyは引数のハッシュで値がシンボル

マイグレーションファイル

Postsモデル

コマンドでの指定に従って、comment要素が設定されている。

PostImageモデル

コマンドで指定したfile_nameのほか、Railsによって以下の外部キーの指定が生成されている。

t.references :user, foreign_key: true

マイグレーション実行~テーブル

マイグレーション実行の結果、postsimagesの3つのテーブルが生成される。

postsテーブル

デフォルトのidcreated_atupdated_atのほか、不通に指定したcomment要素が含まれる。

post_imagesテーブル

デフォルトの要素のほか、Railsコマンドで指定した2つの要素が含まれる。

  • post: referencesの指定に対して、postsテーブルのidを参照する外部キーpost_id
  • 普通に指定したfile_name

アソシエーション設定の確認

rails consoleによる確認

rails consoleでデータベース操作の効果を確認する。

データの生成と保存

2つのPostImageオブジェクトを持つPostオブジェクトを1つ生成し、まとめて保存する。表示は見やすくするために再構成している。

saveより前では3つのオブジェクトともidnilとなっているが、オブジェクト間の関連は保持されている。

postsテーブルとPostImagesテーブルへの登録内容を確認。

データの取得

postsに従属する複数のPostImageデータをループで取り出す例。

この操作はデータベース登録(save)の前でも可能。

deleteに対する制約エラー

PostImageデータを持っている状態でpost.deleteしようとすると外部キー制約エラー

destroyによる一括削除

post.destroyだと従属する2つのImageも削除される

1つの実行文で、当該Postデータとそれに関連付けられたPostImageデータも削除される。

 

Rails – 掲示板 – プロフィール画像アップロード機能

概要

ユーザー設定の枠組みコメント編集機能を実装した。

ファイルアップロードの実装の詳細は「画像アップロード」にまとめており、ここでは以下の仕様のコードと説明のみまとめる。

  • ユーザー設定画面に以下を表示
    • 現在のプロフィール画像
    • ファイル選択要素
    • コメント入力要素(現在のコメント内容を入れておく)
  • 送信時に画像が選択されていれば画像ファイルを保存してファイル名をデータベースに登録
    • 画像保存前に 今の画像ファイルを削除
    • 画像ファイル名はランダム文字列で与える
  • コメント入力は入力されているテキストで更新
  • 更新に成功すればプロフィール画面に遷移
  • 更新に失敗すれば再度ユーザー設定画面に遷移

掲示板の第2段階へ

画像ファイル保存場所

publicディレクトリー下にuser_imagesディレクトリーを作成。ここにプロフィール画像を保存。

users#editアクション

プロフィールコメント編集と同じ。

ルーティング

プロフィールコメント編集と同じ。

edit.html.erbビュー

画像アップロードに関する表示要素は以下のとおり。

  • 現在のプロフィール画像(L6~12)
  • プロフィール画像選択フィールド(L13)

app/views/users/edit.html.erb

イメージファイルをdivで囲んでいる(L6~12)。スタイル設定でdiv要素のサイズに合わせて画像をフィッティング・センタリング

file_fieldのパラメーターキー:upload_fileはモデルのパラメーターには含まれない(L13)。コントローラーでファイルオブジェクトを取り出すためだけに使われる。

ボタンが押されると、update_user_pathupdateコントローラーに制御が移る(L4)。

user_image_urlヘルパー

editビューでプロフィール画像を表示するのにuser_image_urlヘルパーを使っている。このヘルパーはUserに関して使うので、UsersHelperモジュールに書いている。

画像ファイルのパスについては画像ファイルの配置とパス指定を参照

users#updateアクション

次の機能を追加している。

  • フォームからのアップロードファイルの取得
  • ファイルの保存
  • データベースへのファイル名の登録

app/controllers/users_controller.rb

パラメーターからアップロードファイルのオブジェクトを取得(L6)。

user_paramsで得られたパラメーターをnew_user_paramsに保存しているが、ファイルが存在する場合はこれに:image_file_nameがマージが追加される。

ファイルタイプはJPEGかPINGのみで、それ以外はエラーをフラッシュして再度設定画面を表示(L11~20)。

ファイル名の衝突を避けるため、ファイル名をランダム文字列としている(L22)。

現在存在しているファイルを削除する(L27~33)。

ランダム文字列の生成

ランダム文字列の生成は記事投稿にも使うため、application_helper.rbに書く。

app/helpers/application_helper.rb

これを有効にするにはインクルードしておく必要がある。

app/controllers/application_controller.rb

user_paramsヘルパー

プロフィールコメント編集と同じ。

params[:user][:update_file]は直接保存しないため、ストロングパラメーターとする必要がない。

スタイル

プロフィール画像のフィッティングとセンタリング(L20~33)。

L34ではファイル入力要素のスタイルを設定。

app/assets/stylesheets/users.scss

フラッシュの追加

application.html.erbフラッシュの表示を追加(application_signed_out.html.erbと同じ内容)。

  • jQueryの読み込み
  • フラッシュ表示部
  • 一定時間後のスライドアップ

app/views/layouts/application.html.erb

プロフィール画面の変更

プロフィール画像ファイルのアップロードができたので、プロフィール画面にこれを表示させるよう変更する。

  • プロフィール画面が未登録の場合はダミー画像を表示する
  • 画像が存在する場合はuser_image_urlヘルパーで画像のフルパスを取得する

app/views/users/show.html.erb

 

Rails – 共通ヘルパーの置き場所

概要

複数のコントローラーやビューで共通に利用したいヘルパーの置き場所について。単純なヘルパーの場合、以下の場所が候補になる。

  • app/helpers下のビューに対応した***_helper.rbに記述
  • app/helpers/application_helper.rb内に記述
  • app/controllers/concerns下のモジュールファイルに記述(コントローラー

依存関係を持つような場合はconcernsに置くのがよいようだが、単純なヘルパーの場合はビューとの関連によってapplication_helper.rbに統一するのが簡明かもしれない。

コントローラーに対応したhelper

ヘルパーファイルにヘルパーを記述してapplication_controllerでインクルードすると、コントローラーやビューでこれを使うことができる。

以下はPagesコントローラーの例で、コントローラーとビューの両方でfoo_helperの実行が確認できる。

定義・設定

helpersディレクトリー内にあるコントローラー_helper.rbの中でヘルパーを定義する。

app/helpers/pages_helper.rb

application_controllerでモジュールをインクルード。

app/controllers/application_controller.rb

利用

コントローラーで利用可能。

app/controllers/pages_controller.rb

ビューでも利用可能。

app/views/pages/helper_test.html.erb

application_helper

application_helperもヘルパーファイルの1つで、Railsにより準備される。これを上と同じくapplication_controllerでインクルードして、アプリケーション共通のヘルパーとして使える。

定義・設定

helpersディレクトリー内にあるapplication_helper.rbの中でヘルパーを定義する。

app/helpers/application_helper.rb

application_controllerでモジュールをインクルード。

app/controllers/application_controller.rb

利用

コントローラーで利用可能。

app/controllers/pages_controller.rb

ビューでも利用可能。

app/views/pages/helper_test.html.erb

concerns

app/controllers/concernsにはコントローラー間で共通のモジュール、app/models/concernsはモデル間で共通のモジュールのファイルを配置する。

コントローラーなどでインクルードしてもビューではこれらのモジュールは使えない。

定義・設定

concernsディレクトリー下にモジュールファイルを作成して、その中にヘルパーを書く。

app/controller/concerns/common_module.rb

application_controllerでモジュールをインクルード。

app/controllers/application_controller.rb

利用

コントローラーで利用可能。

app/controllers/pages_controller.rb

しかしビューでは使えない。

 

 

 

Rails – 画像アップロード

概要

  • Railsで画像ファイルをアップロードする処理を整理する
  • ユーザーのプロフィール画面のアップロードと更新を例にする
  • 更新時、前の画像は削除する
  • 画像ファイル名の衝突をさけるため、ランダム文字列を生成してファイル名にする

フォームからのアップロード情報を受け取る

ビュー

以下のビューが表示されるとファイル選択要素が表示される。

file_fieldに対するキーは:upload_fileと設定しているが、これはモデルに存在しないキーでもよい。

ここでは登録済みユーザーのプロフィール画像を編集する想定で、PATCHメソッドでupdateコントローラーに送信される。

コントローラー

フォームから送られたアップロードファイルに関するデータはparamsに格納されていて、以下で取得できる。

params[:モデル][:file_fieldで設定したキー]

ここではアップロードファイルが指定されているときにupload_fileにアップロードファイルの内容を保存し、その中のoriginal_filenameの値をupload_file_nameに保存している。

UploadedFileクラス

file_fieldからparamsに保存されるのはUploadedFileクラスのインスタンス。

たとえば上のupload_fileの内容は以下の様になっていて、original_filenamecontent_typeがインスタンス変数として参照できる。

また、画像ファイルの実体はreadメソッドで読みだすことができて、これをファイルの保存時に使う(readメソッドは1回しか呼び出せないらしい)。

permitの設定は不要

フォームから得られるUploadedFileオブジェクトをparamsで取得しているが、これに対してrequire.permitに含める必要はない。

Railsのモデルの仕組みによって自動的に入力・保存するものではないため。

ファイルの書き込み

基本手順

  1. アプリケーションの中のファイル保存ディレクトリーを取得
  2. 上記とファイル名を組み合わせたフルパスを取得
  3. 画像ファイルの書き込み

コントローラー

コントローラーのupdateアクションのみ示す。

流れは以下のとおり。

まず事前にプロジェクトディレクトリー下のpublicに必要に応じてサブディレクトリーをつくっておく

/home/.../ex_bbs/public/user_images

Rails.rootはプロジェクトディレクトリーのフルパスを保持したPathオブジェクト

Rails.root.join()でパスにディレクトリーをつなげていく

upload_dir = Rails.root.join("public", "user_images")

upload_dirにファイル名をつなげてファイルのフルパスにする

upload_file_path = upload_dir + upload_file_name

ファイルのフルパスとファイルの実体を指定して、画像ファイルを書き込む。

File.binwrite(upload_file_path, upload_file.read)

データベースへの登録

基本手順

  1. フォームから得られたparamsにヘルパーでパーミッションを適用
  2. その結果にアップロードファイルのファイル名をマージして登録用のパラメーターとする
  3. 登録用パラメーターでデータベースに登録

コントローラー

パラメーターヘルパー

コントローラーで多用されるヘルパーは以下のような形。

フォームから得られたパラメーター(user_paramsの戻り値)は以下のような内容。画像選択以外の要素がないのでパラメーターは空になっている。

パラメーターの調整

フォームで得られた:upload_fileからデータベースに登録するファイル名を取り出し、パラメーターにマージする。

new_user_params = user_params.merge({image_file_name: upload_file_name})

マージ後のnew_user_paramsの内容は以下のとおりで、空だった内容に:image_file_nameが追加されている。

データベースの更新

ユーザーモデルのupdateに調整したパラメーターを与えてデータベースを更新する。

@user.update(new_user_params)

ファイルの削除

データ更新の際に、現在登録されているファイルを削除する場合。

ファイル名の重複防止~ランダム文字列

アップロードファイル名にoriginal_filenameを使うと、ユーザー側で指定したファイル名が衝突する可能性がある。その場合、あとから登録した画像で上書きされてしまう。

そこで、ファイル名にランダム文字列を使って、実質上衝突が起こらないようにする。

同じ機能は投稿記事のコントローラーでも利用し、アプリケーションに共通なので、application_helper.rbに記述する。

app/helpers/application_helper.rb

app/controllers/application_controller.rb

そして、アップロード画像のファイル名をランダム文字列とする。このファイル名はデータベースの更新と画像ファイルの保存に共通して使われる。

こうすることで、複数のユーザーが同じファイル名で画像をアップロードしても、ユーザーごとに異なる名前となるため、ファイル名の衝突がおきない。

まとめ

画像ファイルのアップロードのためのファイル群をまとめておく。ユーザーのプロフィール画像をアップロードするケースを例にする。

editアクション

  • ユーザー操作などでルーティングされ、画像アップロードを含むページを表示する
  • ビューで使うセッション中のユーザーのインスタンスをインスタンス変数に保存する

app/controllers/users_controller.rb

ビュー

  • 画像アップロードを含むページ
  • ボタンを押すとPATCHメソッドでupdateアクションにデータが送られるようルーティングしている

app/views/users/edit.html.erb

updateアクション

フォームからのデータを受け取り、以下の処理を行う。

  • 画像の保存(古い画像の削除)
  • データベースのファイル名の更新

app/controllers/users_controller.rb

ランダム文字列ヘルパー

ファイル名の衝突を防ぐランダム文字列生成のヘルパー。

app/helpers/application_helper.rb

 

HTML/CSS – img画像のフィッティングとセンタリング

概要

  • img要素で表示させる画像をdiv要素で囲む
  • div要素でサイズを指定して画像を収める
  • 画像を縦横にセンタリングする
  • 画像のサイズがdiv要素のサイズより大きい場合を想定している(画像の方が小さい場合に伸長はされない)

HTML

画像をdiv要素で囲み、CSSでサイズを設定する。画像ファイルは、CDNによるダミー画像を使っている。

CSS

画像を収めるための設定。画像ファイルより小さい枠のサイズを設定している。ただしこのままでは画像が左寄せか上寄せになる。

上の設定に画像の縦横センタリングを含めた設定。

Rails – 掲示板 – プロフィールコメント編集

概要

ユーザー設定の枠組みに、プロフィールコメントの編集機能を実装する。

掲示板の第2段階へ

ルーティングの確認

ユーザー設定でルーティングは設定済みだが確認しておく。フォームからのデータはPATCHで送られてくる。

ビューの編集

edit.html.erbにコメント入力欄を追加し、スタイル設定のためのdiv要素を加える。

フォームのボタンが押されると、PATCHメソッドでupdate_user_pathにルーティングされる。その際、セッション中のユーザーのIDがparamsに渡される。

app/views/users/edit.html.erb

また、プロフィール画面でコメント表示するようshow.html.erbを変更する。

app/views/users/show.html.erb

コントローラーの編集

editアクション(再掲)

UsersControllereditでセッションユーザーを取得し、ビューで共用できるようインスタンス変数に格納する(ユーザー設定機能で実装済みだが再掲)。

updateアクション

updateでもセッション中のユーザー取得してインスタンス変数に保存する。

そして、フォームで入力されたパラメーターの内容で@user(セッション中のユーザー)の内容を更新する。

現在のフォームから送られてくるのは:comment(と:id)だけなので、この内容で:idで取得済みのユーザーのコメントが更新される。

  • 更新に成功した場合はプロフィールページへ
  • 更新に失敗した場合は再度ユーザー設定画面へ

user_paramsヘルパーの変更

今の設定では、user_paramsの中で取得が許可されている属性にコメントが含まれていない。

そこでフォームから送られてくるコメントのデータを受信可能とするために、user_params:commentpermitに追加する。

スタイルファイル

ユーザー設定ページのスタイルをusers.scssに追記する。

apps/assets/stylesheets/users.scss

実行結果

ボタンを押して内容がセットされると、プロフィールページに遷移して変更が反映される。

 

Rails – 掲示板 – ユーザー設定の枠組み

概要

プロフィールの編集機能は、ユーザー設定機能として追加する。

プロフィールの画像ファイル名とコメントはユーザー属性として追加した。そこでプロフィール編集に限定しない「ユーザー設定」の機能にこれを含め、今後様々なユーザーの属性設定が可能なようにする。

掲示板の第2段階へ

ユーザー設定の枠組み

editとupdate

ユーザー設定の枠組みにはeditupdateを使う。

編集画面 編集処理
URL /user/:id/edit /user/:id/update
Prefix edit_user update_user
action users#edit users#update
method GET PATCH
画面 edit.html.erb edit.html.erb

ルーティング

枠組みに従ってルーティングを設定。Prefixを使ったユーザーごとのリンクはedit_user_path(:id)のようになる。

updateアクションへのルーティングのメソッドはpatchとしている。Railsによって、form_withで扱うモデルがデータベースに未保存の場合はPOST、保存済みの場合はPATCHが送信されるようにHTMLが生成される。

config/routes.rb

コントローラー

枠組みに従ってusersコントローラーにeditアクションとupdateアクションを準備する。

editアクションでは、ビューで表示させるためセッション中のユーザーのオブジェクトをインスタンス変数に格納する。

app/controllers/users_controller.rb

ビュー

users#editでレンダリングされるビューを準備する。

  • @user.nameを表示させて、受け渡しを確認
  • form_withbuttonを配置して、フォームのボタンが押されたときのメソッドを確認

app/views/users/edit.html.erb

メニューの追加

ヘッダーメニューにユーザー設定の項目を追加する。

app/views/layouts/application.html.erb

動作確認

ここでヘッダーメニューのユーザー設定をクリックすると、以下の画面が表示され、@userが渡されているのがわかる。

ここでボタンを押したときの、Railsサーバーのコンソールの表示は以下のとおり。

PATCHメソッドであることや、URLのパターン、params:idが1にセットされていることがわかる。

留意点

editのルーティングの書き方について

ここではeditへのルーティングを以下の様に書いた。

この場合、たとえばユーザーIDが1の設定ページのブラウザでのURLは以下の様になる。

http://localhost:3000/users/1/edit

一方、このルーティングを単に以下の様に書いても通る。

このときのURLは次のように形が違うが、ページは適正にレンダリングされる。

http://localhost:3000/users/edit.1

どちらのルーティングの書き方でも、Prefixによるヘルパーは、IDに対応して問題なくルーティングしてくれる。

edit_user_path(:id)

edit/updateのアクションについて

前述のように、モデルのインスタンスがデータベースに登録済みであれば、フォーム実行時のメソッドはRailsによってPATCHとされる。

これをPOSTなどに変更したい場合は、以下の様にform_withでメソッドを指定し、ルーティングのメソッドもそれに合わせる。

コントローラーでのIDの指定について

UsersController中、showアクションでユーザープロフィールを表示、editアクションとupdateアクションではプロフィールの変更を行っている。

showアクションでは、データベースからparamsに格納された:idのユーザーを取得している。

一方プロフィールを編集する場合、セッション中のユーザーのID(user_in_session.id)を使っている。

params[:id]を使うと、他のユーザーのプロフィールにも反応してその内容を見られる。

プロフィールページはサインインしているユーザーのみ見られ、かつ他のユーザーのプロフィールを見られることを想定しているのでこの方法をとる。

一方プロフィールを編集する場合は、サインインしている(セッション中の)ユーザーのデータのみ扱う必要があるので、user_in_session.idを使う。

 

 

Rails – 掲示板 – アイコンの導入

概要

これまでメニューには「投稿」や「サインアウト」といった文字列を表示していたが、ここでこれらをアイコンに変更する。

アイコンはCDNで提供されるものもあり、ここではFont Awesomeを利用する。

読み込みスクリプトの記述

ヘッダーメニューの共通レイアウト、application.html.erbのheadセクションに、Font Awesomeのアイコンを使うためのJavaScriptを読み込むタグを記述する。

app/views/layouts/application.html.erb

アイコンタグの記述

Font Awesomeのアイコンは、iタグのクラスでアイコンの種類を指定して表示させる。アイコンごとのクラス表現を含むタグは、サイトでアイコンを選択するとコピーできる。

また、Railsのlink_toヘルパーでアイコンをクリックしたときのリンク先を指定する場合、以下の様にdoブロックで囲む。

また、ここでは以下の2つを追加している。

  • アイコンのスタイルを設定するクラスを追加
  • マウスオーバー時に表示されるtitleを追加

こうしてヘッダーメニューを変更したのが以下の内容。

スタイルの設定

アイコンタグのクラスにスタイルを適用するため、SCSSファイルを編集する。

アイコンの間に線を引くための&+liブロックを削除し、.iconブロックを追加してサイズ色を設定している。

app/assets/stylesheets/header.css

Rails – 掲示板 – ユーザー属性の追加

概要

ユーザーモデルにプロフィールに使う画像ファイル名とコメントの2つの属性を追加する。

そのために、既にデータが登録されているデータベースのテーブルに、カラムを追加する。

マイグレーションによるカラム追加

データベースにデータが登録されている状態で、データを損なわずにテーブルのカラムを追加する。大まかな流れは以下のとおり。

  1. カラム追加用のマイグレーションファイルを生成する
  2. 追加用マイグレーションファイルの内容を確認する/記述する
  3. マイグレーションを実行する

現在のテーブルをマイグレートした際のマイグレーションファイルの内容は以下のとおり。

db/migrate/20210320060906_create_users.rb

カラム追加用マイグレーションファイルの生成

カラム追加のためのマイグレーションファイルを生成するコマンドは以下のとおり。

rails generate migration AddAnyToTable col:type ...

  • Anyは一般に追加するカラム名を書くが、任意の文字列でよい
  • Tableはカラムを追加するテーブル名
  • col:typeは追加するカラム名と型で複数指定可
    • 指定しなければ空のマイグレーションファイルが生成され、後から追加内容を記述

マイグレーションファイルの記述

コマンド実行の結果、以下のようなマイグレーションファイルが生成される。

20210326083051_add_coumuns_to_users.rb

このファイルのchangeメソッドにカラム追加の命令を記述。

add_column :table, :col, :type

テーブル名、カラム名、型をシンボルで記述する。

マイグレーションの実行

マイグレーションを実行。

マイグレーションの結果、新たにカラムが追加されている。

データが残っていることを確認。追加されたカラムはupdated_atよりも後ろにある。