Callbacks overview in Ruby on Rails - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to define a callback that runs before saving a record.

Ruby on Rails

class User < ApplicationRecord
  [1] :normalize_name

  def normalize_name
    self.name = name.downcase.titleize
  end
end

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

Aaround_update

Bafter_create

Cbefore_save

Dafter_destroy

Attempts:

3 left

💡 Hint

Common Mistakes

Using after_create runs too late, after the record is created.

around_update is for wrapping update actions, not saving.

after_destroy runs after deletion, not saving.

The before_save callback runs just before the record is saved, allowing you to modify attributes.

2fill in blank

medium

Complete the code to run a callback after a record is created.

Ruby on Rails

class Order < ApplicationRecord
  [1] :send_confirmation_email

  def send_confirmation_email
    # email sending logic
  end
end

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

Aafter_create

Bbefore_save

Cbefore_destroy

Daround_save

Attempts:

3 left

💡 Hint

Common Mistakes

before_save runs too early, before creation.

before_destroy is for deletion, not creation.

around_save wraps save, not specifically creation.

The after_create callback runs after a new record is successfully created.

3fill in blank

hard

Fix the error in the callback declaration to run a method before updating a record.

Ruby on Rails

class Product < ApplicationRecord
  [1] :check_stock

  def check_stock
    # stock checking logic
  end
end

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

Abefore_update

Bafter_update

Cafter_save

Dbefore_create

Attempts:

3 left

💡 Hint

Common Mistakes

after_update runs too late, after the update.

after_save runs after any save, not just update.

before_create runs before creating, not updating.

The before_update callback runs just before an existing record is updated.

4fill in blank

hard

Fill both blanks to define callbacks that run before creating and after destroying a record.

Ruby on Rails

class Comment < ApplicationRecord
  [1] :sanitize_content
  [2] :log_deletion

  def sanitize_content
    # clean content
  end

  def log_deletion
    # log deletion
  end
end

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

Abefore_create

Bafter_create

Cafter_destroy

Dbefore_update

Attempts:

3 left

💡 Hint

Common Mistakes

Using after_create instead of before_create for sanitizing.

Using before_update instead of after_destroy for logging deletion.

before_create runs before a new record is created, and after_destroy runs after a record is deleted.

5fill in blank

hard

Fill all three blanks to define callbacks that run before validation, after save, and around update.

Ruby on Rails

class Article < ApplicationRecord
  [1] :prepare_data
  [2] :clear_cache
  [3] :track_changes

  def prepare_data
    # prepare data before validation
  end

  def clear_cache
    # clear cache after save
  end

  def track_changes
    # track changes around update
  end
end

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

Abefore_validation

Bafter_save

Caround_update

Dbefore_save

Attempts:

3 left

💡 Hint

Common Mistakes

Using before_save instead of before_validation for preparing data.

Using before_save instead of after_save for clearing cache.

Confusing around_update with before_update or after_update.

before_validation runs before validations, after_save runs after saving, and around_update wraps the update process.

Practice

1. What is the main purpose of callbacks in Rails models?

easy

A. To run code automatically at specific points in a model's life

B. To manually call methods from controllers

C. To style the HTML output of views

D. To handle database migrations

Solution

1. Step 1: Understand what callbacks do

   Callbacks are hooks that run code automatically during certain model events like saving or deleting.

2. Step 2: Identify the correct purpose

   Callbacks help automate tasks at specific points in a model's lifecycle, not manual calls or styling.

3. Final Answer:

   To run code automatically at specific points in a model's life -> Option A

4. Quick Check:

   Callbacks = automatic code run [OK]

Hint: Callbacks run code automatically at model events [OK]

Common Mistakes:

• Confusing callbacks with controller methods
• Thinking callbacks style views
• Mixing callbacks with database migrations

2. Which of the following is the correct syntax to define a callback that runs before saving a record?

easy

A. on_save :method_name

B. after_save :method_name

C. before_save do method_name end

D. before_save :method_name

Solution

1. Step 1: Recall callback syntax

   Rails uses before_save :method_name to run a method before saving a record.

2. Step 2: Check other options

   after_save runs after saving, on_save is invalid, and the block syntax is incorrect here.

3. Final Answer:

   before_save :method_name -> Option D

4. Quick Check:

   before_save syntax = before_save :method_name [OK]

Hint: Use before_save :method_name to run code before saving [OK]

Common Mistakes:

• Using after_save instead of before_save
• Trying to use on_save which doesn't exist
• Incorrect block syntax for callbacks

3. Given this model code:

class User < ApplicationRecord
  before_create :set_default_role

  def set_default_role
    self.role ||= 'guest'
  end
end

What will be the role of a new User if none is set before saving?

medium

A. 'guest'

B. 'admin'

C. nil

D. Raises an error

Solution

1. Step 1: Understand before_create callback

   The before_create callback runs the method set_default_role before the record is created in the database.

2. Step 2: Analyze set_default_role method

   The method sets self.role to 'guest' only if it is currently nil or falsey (using ||=).

3. Final Answer:

   'guest' -> Option A

4. Quick Check:

   before_create sets role to 'guest' if none set [OK]

Hint: before_create sets default values if none exist [OK]

Common Mistakes:

• Assuming role stays nil if not set
• Confusing before_create with after_create
• Thinking it raises an error without role

4. Identify the error in this callback definition:

class Post < ApplicationRecord
  before_save :check_title

  def check_title
    if title.blank?
      errors.add(:title, "can't be blank")
      throw :abort
    end
  end
end

medium

A. Using throw :abort is incorrect to stop save

B. No error, this is correct usage

C. Callback method should be private

D. errors.add should be errors.add_error

Solution

1. Step 1: Review callback usage

   The before_save callback runs check_title before saving.

2. Step 2: Check error handling

   Adding errors and using throw :abort is the correct way to stop saving if validation fails.

3. Final Answer:

   No error, this is correct usage -> Option B

4. Quick Check:

   throw :abort stops save correctly [OK]

Hint: Use throw :abort to halt save in callbacks [OK]

Common Mistakes:

• Thinking throw :abort is invalid
• Believing errors.add needs a different method
• Assuming callback methods must be private

5. You want to run a method log_update only after a record is updated but not created. Which callback should you use?

hard

A. before_save

B. after_save

C. after_update

D. before_update

Solution

1. Step 1: Understand callback timing

   after_save runs after both create and update, but after_update runs only after updates.

2. Step 2: Choose callback for updates only

   Since you want to run log_update only after updates, after_update is the correct choice.

3. Final Answer:

   after_update -> Option C

4. Quick Check:

   after_update runs only after updates [OK]

Hint: Use after_update for actions only after updates [OK]

Common Mistakes:

• Using after_save which runs on create too
• Choosing before_update which runs before update
• Confusing before_save with after_update