Before and after filters in Ruby on Rails - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to define a before filter in a Rails controller.

Ruby on Rails

class PostsController < ApplicationController
  [1] :authenticate_user

  def index
    # list posts
  end
end

Drag options to blanks, or click blank then click option'

Abefore_action

Bafter_action

Caround_action

Dskip_action

Attempts:

3 left

💡 Hint

Common Mistakes

Using after_action instead of before_action

Using skip_action which disables filters

Using around_action which wraps actions

The before_action method sets a filter to run before controller actions.

2fill in blank

medium

Complete the code to define an after filter that runs only on the show action.

Ruby on Rails

class UsersController < ApplicationController
  after_action :log_view, only: [1]

  def show
    # show user
  end
end

Drag options to blanks, or click blank then click option'

A[:index]

B[:edit]

C[:show]

D[:destroy]

Attempts:

3 left

💡 Hint

Common Mistakes

Using the wrong action name in the only option

Forgetting to wrap the action name in an array

Using except instead of only

The only: option limits the filter to specified actions. Here, it runs only on show.

3fill in blank

hard

Fix the error in the filter definition to run a method after every action.

Ruby on Rails

class CommentsController < ApplicationController
  [1] :clear_cache

  def create
    # create comment
  end
end

Drag options to blanks, or click blank then click option'

Aafter_filter

Bafter_action

Cbefore_filter

Dbefore_action

Attempts:

3 left

💡 Hint

Common Mistakes

Using deprecated filter methods like before_filter or after_filter

Using before_action instead of after_action

In modern Rails, after_action replaces the deprecated after_filter.

4fill in blank

hard

Fill both blanks to run a method before all actions except edit and update.

Ruby on Rails

class ProfilesController < ApplicationController
  [1] :check_permissions, except: [2]

  def edit
    # edit profile
  end

  def update
    # update profile
  end
end

Drag options to blanks, or click blank then click option'

Abefore_action

Bafter_action

C[:edit, :update]

D[:show, :index]

Attempts:

3 left

💡 Hint

Common Mistakes

Using after_action instead of before_action

Using except with wrong action names

Not wrapping actions in an array

before_action runs the method before actions, and except: [:edit, :update] excludes those actions.

5fill in blank

hard

Fill all three blanks to define a before filter that runs only on create and update, and an after filter that runs on destroy.

Ruby on Rails

class ArticlesController < ApplicationController
  [1] :verify_user, only: [2]
  [3] :log_deletion, only: [:destroy]

  def create
    # create article
  end

  def update
    # update article
  end

  def destroy
    # destroy article
  end
end

Drag options to blanks, or click blank then click option'

Abefore_action

B[:create, :update]

Cafter_action

Dbefore_filter

Attempts:

3 left

💡 Hint

Common Mistakes

Using deprecated before_filter

Mixing up before and after actions

Not specifying the correct actions in only

before_action runs verify_user only on create and update. after_action runs log_deletion only on destroy.

Practice

1. What is the main purpose of a before_action filter in a Rails controller?

easy

A. To run code before a controller action executes

B. To run code after a controller action executes

C. To skip a controller action entirely

D. To define a new controller action

Solution

1. Step 1: Understand the role of filters

   Filters in Rails run code around controller actions to modify behavior.

2. Step 2: Identify the timing of before_action

   before_action runs code before the main action method executes.

3. Final Answer:

   To run code before a controller action executes -> Option A

4. Quick Check:

   before_action = runs before action [OK]

Hint: Before filters run code before actions start [OK]

Common Mistakes:

• Confusing before_action with after_action
• Thinking before_action skips actions
• Assuming before_action defines new actions

2. Which of the following is the correct syntax to define an after filter named log_action in a Rails controller?

easy

A. after_filter :log_action

B. after :log_action

C. before_action :log_action

D. after_action :log_action

Solution

1. Step 1: Recall the modern syntax for after filters

   Rails uses after_action to define code that runs after controller actions.

2. Step 2: Check each option

   after_filter :log_action uses deprecated after_filter. after_action :log_action uses correct after_action. before_action :log_action is for before filters. after :log_action is invalid syntax.

3. Final Answer:

   after_action :log_action -> Option D

4. Quick Check:

   Use after_action for after filters [OK]

Hint: Use after_action, not after_filter, for after filters [OK]

Common Mistakes:

• Using deprecated after_filter instead of after_action
• Mixing before_action with after filters
• Incorrect syntax like 'after :method'

3. Given this controller code:

class PostsController < ApplicationController
  before_action :set_post
  after_action :log_post

  def show
    render plain: @post.title
  end

  private
  def set_post
    @post = Post.find(params[:id])
  end

  def log_post
    Rails.logger.info "Post viewed: #{@post.id}"
  end
end

What will be the output when GET /posts/5 is called, assuming the post with ID 5 has title "Hello"?

medium

A. The page shows "Hello" and logs "Post viewed: 5" after rendering

B. The page shows "Hello" but does not log anything

C. The page shows nothing and logs "Post viewed: 5"

D. An error occurs because @post is not set

Solution

1. Step 1: Understand filter order and effects

   before_action :set_post runs before show, setting @post. after_action :log_post runs after show completes.

2. Step 2: Trace the request flow

   When show runs, @post is set, so render plain: @post.title outputs "Hello". After rendering, log_post logs "Post viewed: 5".

3. Final Answer:

   The page shows "Hello" and logs "Post viewed: 5" after rendering -> Option A

4. Quick Check:

   before_action sets data, after_action logs after render [OK]

Hint: before_action sets data, after_action runs after response [OK]

Common Mistakes:

• Thinking after_action runs before rendering
• Assuming @post is nil in show
• Confusing logging output with page content

4. Identify the error in this controller code:

class UsersController < ApplicationController
  before_action :authenticate_user
  after_action :clear_session

  def index
    # list users
  end

  private
  def authenticate_user
    redirect_to login_path unless current_user
  end

  def clear_session
    session[:temp] = nil
  end
end

medium

A. The methods authenticate_user and clear_session must be public

B. The before_action should be after_action for authentication

C. The after_action runs even if redirect happens, causing errors

D. There is no error; the code works as expected

Solution

1. Step 1: Analyze filter behavior with redirects

   If authenticate_user redirects, the action does not run, but after_action still runs.

2. Step 2: Understand consequences of after_action after redirect

   Running clear_session after redirect can cause unexpected side effects or errors.

3. Final Answer:

   The after_action runs even if redirect happens, causing errors -> Option C

4. Quick Check:

   after_action runs even after redirect [OK]

Hint: after_action runs even if before_action redirects [OK]

Common Mistakes:

• Assuming after_action skips on redirect
• Thinking authentication should be after_action
• Believing private methods must be public

5. You want to run a before_action filter named check_admin only before the edit and update actions in a Rails controller. Which is the correct way to write this?

hard

A. before_action :check_admin, except: [:edit, :update]

B. before_action :check_admin, only: [:edit, :update]

C. after_action :check_admin, only: [:edit, :update]

D. before_filter :check_admin, only: [:edit, :update]

Solution

1. Step 1: Identify correct filter type and options

   Use before_action to run code before actions. Use only: to limit to specific actions.

2. Step 2: Evaluate each option

   before_action :check_admin, only: [:edit, :update] correctly uses before_action with only: [:edit, :update]. before_action :check_admin, except: [:edit, :update] uses except, which excludes those actions. after_action :check_admin, only: [:edit, :update] uses after_action, wrong timing. before_filter :check_admin, only: [:edit, :update] uses deprecated before_filter.

3. Final Answer:

   before_action :check_admin, only: [:edit, :update] -> Option B

4. Quick Check:

   Use before_action with only: for specific actions [OK]

Hint: Use before_action with only: to target specific actions [OK]

Common Mistakes:

• Using except instead of only
• Using after_action instead of before_action
• Using deprecated before_filter