Rails の destroy アクションを理解しよう

学習の目標

本章では、以下の内容を学習します。

  • destroy アクションの役割と動作原理を理解する
  • データ削除の処理フローを学ぶ
  • 削除後のリダイレクト先の考え方を理解する
  • 削除確認ダイアログの仕組みを知る
  • ルーティングヘルパーの命名規則を把握する

はじめに

これまで、index（一覧表示）、show（詳細表示）、new/create（新規作成）、edit/update（編集更新）と学んできました。Railsにおける7つの基本アクションの締めくくりとして、今回は destroy アクションについて学んでいきます。

destroy アクションは、データベースからレコードを削除するという重要な役割を担っています。シンプルな処理ですが、データを完全に削除するため、慎重に扱う必要があります。

destroyアクション - レコードを削除する

destroyアクションの役割

destroy アクションは、特定のレコード（データ）をデータベースから削除するためのアクションです。コードは次のようになります。

def destroy
  @post = Post.find(params[:id])
  @post.destroy!
  redirect_to posts_path, notice: "Post was successfully destroyed."
end

このコードでは、まず params[:id] を使って削除対象の投稿を検索し、@post というインスタンス変数に格納します。次に、@post.destroy! メソッドを呼び出してデータベースからその投稿を削除します。

destroy! メソッドの末尾にある感嘆符（!）は、削除に失敗した場合に例外を発生させる意味があります。例外が発生すると、処理が中断されて後続のリダイレクト処理は実行されません。このように、重要な処理が確実に成功することを保証するためのコードの書き方です。

削除後のリダイレクト

削除が完了したら、一覧画面（index アクション）にリダイレクトして「Post was successfully destroyed.」というメッセージを表示します。

redirect_to posts_path, notice: "Post was successfully destroyed."

create や update アクションでは詳細ページ（show アクション）へリダイレクトさせていましたので、以下のように書いていました。

redirect_to post_path(@post)

しかし、destroy アクションの場合は対象の投稿が削除済みなので、その詳細ページは存在しなくなっています。そのため、一覧画面にリダイレクトさせるのが適切です。

ルーティングヘルパーの命名規則

リダイレクト先を指定する posts_path というヘルパーメソッドについて、もう少し詳しく見てみましょう。

show アクションへのリダイレクトとは、以下の点が異なることに注意してください。

  1. index アクション（一覧）ページは単体ではなく複数のデータを扱うページなので、「post」ではなく「posts」というヘルパーメソッド名になっています
  2. index アクションは特定の（一つ）の投稿データを開くページではないので、引数として @post などを渡しません

これらの違いは、Railsのルーティングヘルパーの命名規則に基づいています。

  • 単数形（post_path）：特定のリソース（1つの投稿）に対するアクション（show, edit, update, destroy）
  • 複数形（posts_path）：リソース全体に対するアクション（index, new, create）

ただし例外として、new_post_path のように new_ が付くヘルパーもあります。これは、「新しい投稿を作成するためのフォーム」という特別なページであることを示しています。

削除の確認ダイアログ

データの削除は取り消せない操作なので、誤操作を防ぐために確認ダイアログを表示することが一般的です。Railsでは、リンクに data: { confirm: "本当に削除しますか？" } を追加することで、クリック時に確認ダイアログを表示できます。

例えば、投稿を削除するリンクは以下のように書きます。

<%= link_to "Destroy this post", post_path(@post), method: :delete, data: { confirm: "Are you sure?" } %>

このコードでは、「Destroy this post」というリンクをクリックすると、「Are you sure?」という確認ダイアログが表示されます。「OK」をクリックすると削除処理が実行され、「キャンセル」をクリックすると何も起こりません。

これにより、ユーザーが誤ってデータを削除してしまうリスクを減らすことができます。

データ削除の流れを理解する

ここで、destroyアクションを使ったデータ削除の流れをおさらいしておきましょう。

  1. ユーザーが「Destroy this post」リンクをクリックする
  2. 確認ダイアログが表示される
  3. ユーザーが「OK」をクリックする
  4. destroyアクションが実行される
  5. @post = Post.find(params[:id]) で削除対象の投稿を取得
  6. @post.destroy! で投稿をデータベースから削除
  7. redirect_to posts_path, notice: "Post was successfully destroyed." で一覧ページにリダイレクト
  8. 一覧ページに「Post was successfully destroyed.」というメッセージが表示される

この流れを理解することで、Railsのデータ削除の基本的な仕組みが見えてきます。

削除に関する注意点

関連データの削除

複数のモデルが関連している場合（例：投稿とコメントの関係）、主となるデータを削除すると関連するデータも削除するかどうかを設定できます。例えば、ブログ投稿を削除したときに、その投稿に対するコメントも一緒に削除するような場合です。

これは「依存関係」と呼ばれ、モデルの中で has_many :comments, dependent: :destroy のように設定します。dependent: :destroy を指定すると、親（投稿）が削除されたときに子（コメント）も一緒に削除されます。

論理削除と物理削除

実際のアプリケーションでは、データを完全に削除する（物理削除）のではなく、削除フラグを立てて表示しないようにする（論理削除）こともあります。これは、誤って削除したデータを復元できるようにするためや、削除されたデータの履歴を残しておきたい場合に使われます。

Railsでは、gem（プラグイン）を使って論理削除を実現することができます。例えば、「paranoia」や「acts_as_paranoid」などのgemがあります。

まとめ

本章では、Railsにおけるdestroyアクションの役割と動作原理について学びました。

  • destroyアクションは、データベースからレコードを削除するためのアクション
  • @post.destroy! メソッドを使ってデータを削除する
  • 削除後は一覧画面にリダイレクトする（削除されたデータの詳細ページは存在しないため）
  • posts_path は複数形で、引数を取らないヘルパーメソッド
  • 削除前に確認ダイアログを表示して、誤操作を防ぐ

これで、Railsの7つの基本アクション（index, show, new, create, edit, update, destroy）について一通り学びました。これらのアクションは、Webアプリケーションにおけるデータの「作成・読み取り・更新・削除」（CRUD）を実現するための基本的な仕組みです。

Railsコースの完了状況を確認
Previous
Rails の edit, update アクションを理解しよう
Next
モデルにバリデーションを追加して入力データを制限しよう