Bird
Raised Fist0
Ruby on Railsframework~5 mins

Before and after filters in Ruby on Rails - Cheat Sheet & Quick Revision

Choose your learning style10 modes available
Recall & Review
beginner
What is a before filter in Rails controllers?
A before filter is a method that runs before a controller action. It can prepare data or check conditions before the main action runs.
Click to reveal answer
beginner
What does an after filter do in Rails?
An after filter runs after a controller action finishes. It can be used to clean up, log information, or modify the response.
Click to reveal answer
beginner
How do you declare a before filter in Rails 5 and later?
Use before_action :method_name inside the controller to run method_name before actions.
Click to reveal answer
intermediate
Can you skip a before filter for some actions in Rails? How?
Yes, use skip_before_action :method_name, only: [:action1, :action2] to skip the filter for specific actions.
Click to reveal answer
intermediate
Why use before and after filters instead of putting code directly in actions?
Filters help keep controller actions clean and focused. They let you reuse code like authentication or logging across many actions easily.
Click to reveal answer
Which method runs before a Rails controller action?
Aaround_action
Bafter_action
Cbefore_action
Dskip_action
How do you skip a before filter for only the 'show' action?
Askip_filter :filter_name, only: [:show]
Bskip_after_action :filter_name, only: [:show]
Cbefore_action :filter_name, except: [:show]
Dskip_before_action :filter_name, only: [:show]
What is a common use for after filters?
ALogging or cleanup after an action
BChecking user permissions before an action
CRendering views before an action
DSkipping actions
Which Rails filter runs both before and after an action?
Aaround_action
Bbefore_action
Cafter_action
Dskip_action
Why are filters useful in Rails controllers?
AThey replace views
BThey help reuse code and keep actions clean
CThey speed up database queries
DThey automatically generate routes
Explain what before and after filters do in Rails controllers and give an example use case for each.
Think about what you want to do before or after a page loads.
You got /4 concepts.
    How do you apply and skip a before filter for certain actions in a Rails controller?
    Look at how to control which actions run the filter.
    You got /3 concepts.

      Practice

      (1/5)
      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
      Recommended

      Ready to prove it?

      Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

      10 questions~5 mineasy hard