Callbacks overview in Ruby on Rails - Step-by-Step Execution

Concept Flow - Callbacks overview

Object Created

↓

Before Validation Callback

↓

Validation

↓

After Validation Callback

↓

Before Save Callback

↓

Before Create or Update Callback

↓

Save to Database

↓

After Create or Update Callback

↓

After Save Callback

↓

After Commit Callback

↓

Object Ready

Rails callbacks run in a specific order around object lifecycle events like validation and saving, allowing code to run before or after these steps.

Execution Sample

Ruby on Rails

class User < ApplicationRecord
  before_save :normalize_name
  after_create :send_welcome_email

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

  def send_welcome_email
    EmailService.send_welcome(self)
  end
end

This code runs a method to clean the user's name before saving and sends a welcome email after creating the user.

Execution Table

Step	Callback/Event	Action	Effect on Object	Notes
1	Object Created	New User instance initialized	User object with raw name	Start of lifecycle
2	before_save	normalize_name called	Name trimmed and capitalized	Runs before saving to DB
3	Validation	Validates user data	Checks if user data is valid	If invalid, save stops
4	Save to Database	User record saved	User data stored in DB	Persisted user
5	after_create	send_welcome_email called	Welcome email sent	Runs only on new record creation
6	after_save	Callback chain ends	User object saved and callbacks done	Final step
7	after_commit	Transaction committed	Changes finalized	Ensures DB transaction success
8	End	Lifecycle complete	User ready for use	No more callbacks

💡 All callbacks run in order around save; process ends after after_commit

Variable Tracker

Variable	Start	After before_save	After Validation	After Save	After after_create	Final
user.name	" alice "	"Alice"	"Alice"	"Alice"	"Alice"	"Alice"
user.persisted?	false	false	false	true	true	true
email_sent	false	false	false	false	true	true

Key Moments - 3 Insights

Why does the name change after before_save but before validation?

The execution_table shows before_save runs before validation, so normalize_name cleans the name before validations check it.

When is the welcome email sent in the lifecycle?

The after_create callback runs only after the user is saved for the first time, as shown in step 5 of the execution_table.

What happens if validation fails?

Validation happens after before_save; if it fails, the save and subsequent callbacks like after_create do not run, stopping the process early.

Visual Quiz - 3 Questions

Look at the execution_table, what is the value of user.name after the before_save callback?

A "Alice"

B " alice "

C "ALICE"

D "alice"

💡 Hint

Check the 'After before_save' column for user.name in variable_tracker.

At which step does the user record get saved to the database?

A Step 3

B Step 4

C Step 5

D Step 6

💡 Hint

Look at the 'Save to Database' event in the execution_table.

If validation fails, which callback will NOT run?

A before_validation

B before_save

C after_create

D after_commit

💡 Hint

Refer to the key_moments about validation failure stopping save and after_create callbacks.

Concept Snapshot

Rails callbacks run around object lifecycle events.
Common callbacks: before_save, after_create, after_commit.
before_save runs before validation and saving.
after_create runs only after new record creation.
Use callbacks to run code automatically at these points.

Full Transcript

Rails callbacks are special methods that run automatically at certain points in an object's lifecycle, like before saving or after creating a record. For example, before_save runs a method to clean data before the object is saved to the database. After_create runs a method to send a welcome email only after the object is first saved. The callbacks run in a specific order: object creation, before_save, validation, saving, after_create, after_save, and after_commit. If validation fails, the save and later callbacks do not run. This lets you add automatic behaviors tied to saving and creating objects in Rails.

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