But as your application grows, these “invisible” side effects become a maintenance nightmare. Today, we’ll explore why callbacks are often technical debt in disguise and how to move toward a more explicit, modern architecture.
The biggest issue with callbacks is that they are implicit. When you call user.save, you expect a database write. You don’t necessarily expect a 3rd-party API call to Stripe, a background job enqueued to Intercom, and a cache purge for the entire dashboard.
create(:user) triggers a chain reaction of logic that isn’t relevant to the test at hand.The modern Rails way is to favor Explicit over Implicit. Instead of hiding logic inside the Model, move it to a dedicated Service Object. This makes the flow of data obvious and easy to test in isolation.
1
2
3
4
5
6
7
8
9
class User < ApplicationRecord
after_create :send_welcome_email
private
def send_welcome_email
UserMailer.welcome(self).deliver_later
end
end
1
2
3
4
5
6
7
8
9
10
11
12
class UserRegistrationService
def self.call(params)
user = User.new(params)
if user.save
UserMailer.welcome(user).deliver_later
Analytics.track("User Signed Up", user_id: user.id)
end
user
end
end
Now, when you look at the service, you know exactly what happens when a user registers. No surprises.
If you truly need a “decoupled” way to handle side effects without bloating your service objects, the modern “Observer” pattern in Rails is ActiveSupport::Notifications.
This follows the Pub/Sub (Publish/Subscribe) pattern. The Model (or Service) simply broadcasts that something happened, and “Subscribers” listen and react.
1
2
3
4
5
6
7
class User < ApplicationRecord
def register
if save
ActiveSupport::Notifications.instrument("user.registered", user: self)
end
end
end
1
2
3
4
5
6
7
# config/initializers/events.rb
ActiveSupport::Notifications.subscribe("user.registered") do |*args|
event = ActiveSupport::Notifications::Event.new(*args)
user = event.payload[:user]
UserMailer.welcome(user).deliver_later
end
Are callbacks always evil? No.
By moving side effects out of your models, your test suite will get faster, and your code will become much easier to reason about.
]]>In this post, we’ll explore the main version managers in the ecosystem and a significant shift introduced in Rails 8 regarding environment consistency.
Ruby is an evolving language. Different projects often require different versions of Ruby and Rails. If you install Ruby directly through your operating system’s package manager (like apt or brew), you are stuck with one version, and you risk breaking system tools that rely on that specific version.
Version managers solve this by:
Formerly known as rtx, mise is the new community favorite. It is a drop-in replacement for asdf but written in Rust, making it significantly faster.
asdf plugins and .tool-versions; manages Ruby, Node, and env vars; extremely fast.Until recently the gold standard for polyglot developers. asdf uses a plugin system to manage almost any runtime (Ruby, Node.js, PostgreSQL).
.tool-versions file.mise due to speed and ease of use.Lightweight and focused solely on Ruby. It works by using “shims” to intercept Ruby commands.
ruby-build plugin to actually install new versions.The oldest and most feature-rich. It manages Ruby versions and “gemsets” (isolated silos for gems).
Most version managers respect a file called .ruby-version placed in your project’s root directory. When you cd into the folder, the manager reads this file and switches the Ruby version for you automatically.
1
2
# .ruby-version
3.3.0
With the release of Rails 8, the conversation about version managers has shifted slightly. While you still need a way to install Ruby locally, Rails 8 doubles down on containerization as the primary way to manage environment consistency through Kamal and an improved Docker integration.
Rails 8 makes it easier than ever to use Dev Containers. Instead of worrying if every developer on your team has the right version of mise or rbenv, Rails 8 provides a pre-configured .devcontainer folder.
Rails 8 uses Kamal by default for deployment. Kamal packages your app into a Docker image. This means that the version of Ruby you used in development is exactly the same one that goes to production, reducing the “it works on my machine” syndrome to zero.
If you are a modern developer working on multiple languages and want the best performance, mise is the current winner. If you prefer the classic, stable approach, rbenv remains a solid choice.
However, keep an eye on the Rails 8 philosophy: while version managers are great for your local shell, Docker and Dev Containers are becoming the standard for professional, reproducible development environments.
]]>Both approaches are valid, but they favor different mental models and workflows. Here is a breakdown of the pros and cons of each to help you decide which fits your project best.
ERB is a template-based system. It feels like writing an HTML document that has “holes” where Ruby code can be injected.
.html.erb files, global helpers, and partials.Phlex is a component-based system. It feels like writing a Ruby class that happens to output HTML.
initialize method, you define exactly what data a component needs. If you miss an argument, Ruby tells you exactly why and where.div { ... } instead of <div>...</div>. This requires a mental shift and can occasionally lead to syntax confusion.To see the difference in “feeling,” consider this comparison:
1
2
3
4
5
6
7
<div class="user-card">
<%= image_tag @user.avatar %>
<h2><%= @user.name %></h2>
<% if @user.admin? %>
<span class="badge">Admin</span>
<% end %>
</div>
1
2
3
4
5
6
7
def view_template
div(class: "user-card") do
image_tag(@user.avatar)
h2 { @user.name }
span(class: "badge") { "Admin" } if @user.admin?
end
end
reload! command is a lifeline. Whether you’re testing a new method or debugging a complex query, the ability to refresh the application code without restarting the console session is a massive productivity boost.
However, as the framework has evolved to become more robust, a subtle discrepancy appeared: while your code was reloading, the execution state (such as the Query Cache) sometimes stayed stuck in the past. A recent update to Rails, implemented in Pull Request #56639, fixes this by making the console experience more consistent with how the framework handles actual web requests.
In modern Rails versions, code execution is wrapped in what is known as the Rails Executor. This component manages the “lifecycle” of a task, handling essential housekeeping such as:
Recently, the Rails console began using the Executor for every command to mirror a real web request environment. But this introduced a catch: the Executor’s state could persist longer than intended during a long-running console session.
Before this update, calling reload! refreshed your classes and constants, but it didn’t necessarily “reset” the current Executor.
This led to a frustrating edge case. Since the Executor enables the Query Cache by default, you could run a query, call reload!, and run the same query again, only to see the old results because the cache hadn’t been cleared. The code was new, but the data was stale.
The implementation ensures that reload! now triggers a full reset of the Rails Executor.
Now, when you run the command:
1
2
3
4
5
6
7
8
9
10
11
12
13
# Start your console
user = User.first
# (SQL: SELECT * FROM users LIMIT 1)
# Imagine a background job or another process updates that user in the DB
# ...
reload!
# Now triggers a full Executor reset via PR #56639
User.first
# (SQL: SELECT * FROM users LIMIT 1)
# Guaranteed to fetch fresh data from the database
This change is all about reducing surprises. By making reload! reset the Executor, the console now perfectly mirrors the “clean slate” that a user gets on a fresh browser request. It eliminates those “ghost bugs” where you think your code isn’t working, only to realize later that you were looking at cached database results from earlier in the session.
<=> operator, popularly known as the Spaceship Operator. It is the fundamental building block that allows the language to determine the order of magnitude between objects, serving as the engine behind ubiquitous methods like sort and min.
The <=> operator is a trivalent comparison method. Unlike traditional operators (< or >) that return a boolean value, the spaceship returns an Integer (or nil if the objects are not comparable):
When applied to Arrays, Ruby utilizes an element-by-element comparison logic known as lexicographical order (following the same strategy as a dictionary).
The interpreter traverses each index comparing the values:
1
2
3
[1, 2, 3] <=> [1, 2, 4] # => -1 (comparison stops at index 2: 3 < 4)
[1, 5, 0] <=> [1, 2, 9] # => 1 (comparison stops at index 1: 5 > 2)
[1, 2] <=> [1, 2, 3] # => -1 (the left array ends first)
The true power of <=> lies in its integration with the Ruby core. The Enumerable#sort method, essential in any Rails application, uses the spaceship operator internally to determine the position of each element in the collection.
By implementing the <=> method in a custom class and including the Comparable module, the object automatically gains support for all logical operators: <, >, <=, >=, ==, and the between? method.
1
2
3
4
5
6
7
8
9
10
11
12
13
class Product
include Comparable
attr_reader :price
def initialize(price)
@price = price
end
def <=>(other)
return nil unless other.is_a?(Product)
price <=> other.price
end
end
Understanding the mechanics of the spaceship operator is crucial for Rails developers when dealing with:
ActiveRecord collections after complex Ruby-side manipulations.image/svg+xml MIME type or create separate .erb templates just to wrap a string.
The introduction of a dedicated SVG renderer eliminates this friction. By recognizing :svg as a first-class format, Rails treats vector graphics with the same level of priority and automation as a standard JSON response.
The core of this update is the reliance on duck typing. If an object responds to to_svg, Rails knows exactly how to handle the delivery. This shifts the responsibility of the graphical representation to the object itself, ensuring it knows how to visualize its own data.
The logic for generating the XML stays encapsulated. This makes it easy to test and reuse across different parts of the application.
1
2
3
4
5
6
7
8
class Page
def to_svg
# This method returns the raw XML string
# generated by a library or custom logic
qr_code
end
end
In the controller, the implementation is reduced to a single line within the respond_to block. The framework handles the header assignment and method invocation automatically.
1
2
3
4
5
6
7
8
9
10
11
class PagesController < ActionController::Base
def show
@page = Page.find(params[:id])
respond_to do |format|
format.html
format.svg { render svg: @page }
end
end
end
This approach reinforces the “Skinny Controller” philosophy. By delegating the XML generation to the model layer, the controller focuses solely on request handling and format negotiation.
Because the renderer is built directly into the Rails core, it ensures that the Content-Type header is always strictly compliant with browser standards for vector images. This prevents common bugs where SVGs are treated as plain text or downloaded instead of rendered inline.
The native SVG renderer is a classic example of Rails identifying a recurring pattern and baking it into the framework. It streamlines the delivery of visual data and ensures that the codebase remains expressive and aligned with established conventions. By reducing boilerplate and promoting encapsulation, it helps maintain high standards of code quality.
]]>When you call a method on a Ruby object, the interpreter doesn’t look everywhere at once. It follows a strictly linear, vertical path. It starts at the most specific point (the object’s instance) and moves up until it finds the first implementation of the method.
The search order follows this hierarchy:
def user.admin?).prepend sit “in front” of the class.include. If multiple modules are included, they are searched in reverse order of declaration (the last one included is searched first).You can inspect this path in any Rails console or Ruby script using the ancestors method. It returns an array representing the exact lookup order.
1
2
3
4
5
6
7
8
9
10
module Authenticatable
def login; "Logged in!"; end
end
class User < ActiveRecord::Base
include Authenticatable
end
puts User.ancestors
# => [User, Authenticatable, ActiveRecord::Base, ..., Object, Kernel, BasicObject]
The choice between include and prepend is often misunderstood. It is entirely about where the module is placed in the lookup path:
include: The module is placed immediately after the class. If both define the same method, the class’s version wins.prepend: The module is placed before the class. This allows the module to override the class method and optionally call super to trigger the class’s original logic.This makes prepend the ideal tool for the “Decorator” or “Wrapper” pattern, common in performance monitoring or logging gems.
What happens if Ruby reaches BasicObject and still hasn’t found the method? It doesn’t give up immediately. It starts a second search from the beginning of the chain, this time looking for a method called method_missing.
This is where the “magic” of Rails happens. Features like dynamic finders (e.g., User.find_by_email) or OpenStruct attributes rely on catching a failed lookup and handling it dynamically. If method_missing is also not found (or if it calls super), Ruby finally raises the NoMethodError.
.ancestors list will silently “hide” the other.super will trigger. It isn’t always the parent class; it could be an included module.The only_columns method allows for an “allowlist” approach to model attributes, giving you precise control over what data your application interacts with.
There are two main scenarios where listing ignored columns becomes tedious:
With only_columns, you define a strict contract. Instead of listing what you don’t want, you list exactly what the model is authorized to see. Anything not on this list is automatically ignored by ActiveRecord.
1
2
3
4
5
class User < ApplicationRecord
# The model will only recognize these 3 columns,
# ignoring everything else in the table.
self.only_columns = %w[id email created_at]
end
If a new secret_token column is added to the users table, this specific service won’t even realize it exists, ensuring data isolation and security.
This feature is a major win for maintenance. If your service only uses 5 columns out of a 100-column table, you never have to update an “ignore list” again when other teams modify the schema. It provides security by omission, keeps objects in memory lighter, and makes your data contract explicit.
]]>In the past, when a business pivot or architectural change required a schema name update (e.g., from v1_internal to legacy_data), you had to rely on strings and manual execution:
1
2
3
4
def up
execute "ALTER SCHEMA v1_internal RENAME TO legacy_data"
end
The problem with this approach is that it’s not naturally reversible, forcing you to write a separate down method to handle rollbacks.
With rename_schema, the operation becomes declarative. Rails handles the PostgreSQL heavy lifting, and more importantly, it makes the migration automatically reversible.
1
2
3
4
5
6
class RenameInternalSchema < ActiveRecord::Migration[7.0]
def change
rename_schema :v1_internal, :private_data
end
end
Using a native helper instead of raw SQL strings keeps your migrations consistent with the rest of your codebase. It’s particularly useful for enterprise applications where schemas are used to isolate client data or version different parts of the database. By staying within the DSL, you ensure that your schema history remains clean and that rollbacks are as simple as running bin/rails db:rollback.
updated_at timestamp.
PR #51455, merged in July 2025, solves this dilemma by allowing you to update specific columns and the timestamp in one go. Even though this was introduced a few months ago, it’s a game-changer worth remembering for any performance-tuned Rails app.
Whenever we used #update_columns to gain performance (avoiding expensive callbacks), we lost the information of when the record was actually modified—unless we manually updated the updated_at field:
1
2
3
4
5
6
7
# Before: You had to update the timestamp manually
user.update_columns(last_login_at: Time.current, updated_at: Time.current)
# Or run two separate database commands
user.update_column(:last_login_at, Time.current)
user.touch
This led to repetitive code and was prone to bugs, especially for ETL processes or cache keys that rely heavily on the updated_at field.
Now, you can simply pass touch: true to ensure that Rails’ audit timestamps are updated within the same SQL query.
1
2
3
4
5
6
# Updates the column and updated_at in a single, efficient query
user.update_columns(active: true, touch: true)
# It also works for a single column update
user.update_column(:active, true, touch: true)
You can even pass a specific time if needed:
user.update_columns(active: true, touch: { time: 1.day.ago })
touch command.updated_at: Time.current in every direct update call.Rails.env.development?). However, ActiveSupport also extends this functionality to Arrays, transforming a simple list into an object capable of answering questions semantically.
Array#inquiry is perfect for when you have a list of options and want to check for the presence of an item without using the traditional .include?.
Imagine you have an array of roles for a user. The standard way to check a permission would be:
1
2
3
4
5
roles = ["admin", "editor"]
if roles.include?("admin")
# do something
end
It works, but it’s not very “Rails Way.” The code gets cluttered with parentheses and strings, losing that fluid readability that Ruby is known for.
By calling .inquiry on an array, Rails wraps that list in an ActiveSupport::ArrayInquirer object. This allows you to ask questions using methods ending in ?.
1
2
3
4
5
roles = ["admin", "editor"].inquiry
roles.admin? # => true
roles.editor? # => true
roles.guest? # => false
You can also check for multiple items at once by passing arguments:
1
roles.any?(:admin, :moderator) # => true
roles.admin? is much more natural for a human to read than roles.include?("admin").Rails.env or ActiveRecord Enums.rails db:seed, the command used to populate the database with initial data. But what happens when you modify your seeds.rb file and want to start fresh without deleting the entire database? That’s where rails db:seed:replant comes in.
This command is a productive shortcut for anyone who needs to “clean up and start over” with the application’s core data.
If you run the rails db:seed command multiple times, Rails simply executes the script again. If your script isn’t smart enough to check if a record already exists (using find_or_create_by, for example), you’ll end up with duplicate data.
The old-school solution was to run rails db:migrate:reset db:seed, but this is slow because it drops the database, recreates the tables, and runs all migrations from scratch.
The rails db:seed:replant command performs two actions atomically:
db/seeds.rb script.It is significantly faster than a full reset because it doesn’t touch the schema; it only affects the content.
1
rails db:seed:replant
extend self right at the top. But what does it actually do, and why not just use def self.method?
extend self is an idiomatic way to make a module’s methods available both as instance methods and as module methods.
When creating a utility module, you usually want to call its methods directly:
1
2
3
4
5
6
7
module Calculator
def self.add(a, b)
a + b
end
end
Calculator.add(1, 2) # Works
The issue is that if you have 10 methods, you have to write self. for every single one. Furthermore, if you want to include this module in a class to use those methods internally, def self.add won’t be available as an instance method for that class.
By using extend self, you are telling Ruby: “Take all the instance methods defined here and add them to the module itself as well.”
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
module Formatter
extend self
def capitalize_name(name)
name.capitalize
end
end
# Usage 1: Direct module call
Formatter.capitalize_name("gemini") # => "Gemini"
# Usage 2: Including in a class
class User
include Formatter
def display_name
capitalize_name("alex") # Works here too!
end
end
self. prefix.PR #55405 introduces the relative_time_in_words helper, bringing much more natural language to our Views by handling dates as “today,” “yesterday,” or “tomorrow.”
The time_ago_in_words helper focuses purely on time distance (minutes, hours, days). If a user has a trip scheduled for tomorrow, Rails might say “in about 20 hours.”
While technically correct, it’s not how humans speak. For a great user experience (UX), terms relative to the current day are much easier to process than performing mental calculations with hours.
relative_time_in_words examines the date and decides the best way to describe it in relation to “now,” prioritizing terms like yesterday, today, and tomorrow when appropriate.
1
2
3
4
5
6
7
8
9
10
11
12
13
# Assuming today is January 7, 2026
relative_time_in_words(Date.today)
# => "today"
relative_time_in_words(Date.yesterday)
# => "yesterday"
relative_time_in_words(Date.tomorrow)
# => "tomorrow"
relative_time_in_words(2.days.ago)
# => "2 days ago"
current_user is a daily companion in Controllers and Views. However, the moment you need that information inside a Model to validate a business rule, things get tricky. Many developers end up passing the user as a parameter everywhere. But did you know Rails has a native solution for this?
CurrentAttributes is the official bridge to carry context from the Controller to the Model cleanly and safely.
Imagine a method in your model that checks if a user can edit a record. Currently, it likely needs to receive the user as an argument:
1
2
3
def editable_by?(user)
self.author == user || user.admin?
end
While this works, if you have a call chain (Controller -> Service -> Model), you are forced to “carry” that user all the way down. This pollutes your method signatures and makes the code more rigid and harder to read.
CurrentAttributes allows you to create a central repository for the request. Instead of passing the user manually, your Model simply asks Rails: “Who is the user right now?”.
1
2
3
class Current < ActiveSupport::CurrentAttributes
attribute :user
end
1
Current.user = current_user # The user coming from your authentication system
1
2
3
def can_be_edited?
self.author == Current.user || Current.user.admin?
end
The most common concern is: “Is this safe? Won’t one user see another’s data?”. The answer is no.
Rails uses what is called Thread Isolation. Every request on your server runs in its own “bubble” (thread). Rails ensures that Current.user in Thread A never leaks into Thread B. Furthermore, at the end of every request, Rails automatically wipes (resets) this object, ensuring the next visitor starts with a clean slate.
With the introduction of PR #54231, Rails has unified how these methods validate queries before execution, putting an end to this long-standing inconsistency.
Even though both methods operate on Relations, Rails used to impose different restrictions on each.
For instance, if you tried to use update_all on a query containing a limit or an offset, Rails would often throw an error (especially on databases that don’t natively support those clauses in an UPDATE statement). Meanwhile, delete_all might allow the operation or fail in a different way depending on how the query was constructed.
This discrepancy led to confusing bugs when refactoring logic—such as switching from a hard delete to a soft delete—expecting the API to handle the scopes identically.
The new PR ensures that if an operation is invalid for the database (such as an UPDATE or DELETE combined with DISTINCT, LIMIT, or GROUP BY in certain contexts), both methods will now respond consistently.
Previously, you might encounter divergent behavior. Now, the validation is standardized:
1
2
3
4
5
6
7
8
9
# Attempting to update or delete within a complex scope
scoped_query = User.where(active: true).limit(10)
# Both now follow the same validation rules
scoped_query.update_all(status: 'archived')
# => Raises ActiveRecordError if the query is incompatible
scoped_query.delete_all
# => Follows the exact same error logic as update_all
This change is fundamental for three main reasons:
delete_all versus update_all. If the Relation is invalid for bulk modification, it is invalid for both.The focus here isn’t just about fixing a bug; it’s about reinforcing the ActiveRecord interface. By unifying these behaviors, the framework reduces the developer’s cognitive load, allowing you to trust that sibling methods will behave like siblings.
]]>Starting with modern versions of Rails, in_order_of provides a clean and expressive way to define custom ordering directly in SQL—without resorting to database-specific functions or complex CASE statements.
Enums in ActiveRecord allow you to define a set of named values backed by integers in the database.
Example:
1
2
3
4
5
6
7
8
class Order < ApplicationRecord
enum status: {
pending: 0,
paid: 1,
shipped: 2,
cancelled: 3
}
end
This gives you a friendly API while keeping storage efficient:
1
2
3
Order.paid
order.shipped?
order.status # => "pending"
When you call:
1
Order.order(:status)
Rails sorts by the underlying integer values. This works only if the enum definition matches the order you want to present in the UI or apply in business logic.
Often, that’s not the case. For example, you may want to prioritize shipped orders first, followed by paid ones, regardless of how the enum is defined.
Rails provides in_order_of as a high-level way to express custom ordering while keeping the sorting logic in SQL.
Example:
1
2
3
4
Order.in_order_of(
:status,
[:shipped, :paid, :pending, :cancelled]
)
This reads almost like plain English and clearly communicates intent.
Under the hood, Rails converts the enum values to their integer equivalents and generates the appropriate SQL to preserve the specified order.
in_order_of integrates seamlessly with enums because:
This makes it safer and more maintainable than hand-written SQL expressions.
Sometimes, you only care about ordering a subset of enum values.
1
Order.in_order_of(:status, [:shipped, :paid])
Records with other statuses will still be returned, but they’ll appear after the specified values, following the database’s default order.
This is particularly useful when highlighting “important” states without excluding the rest.
Sorting in Ruby using sort_by or similar methods may seem convenient, but it has downsides:
in_order_of avoids these problems by keeping ordering inside the database, where it belongs.
resource and resources — and although they look similar, they serve different purposes. Understanding the distinction between them is essential for designing clean, intention-revealing routes in a Rails application.
Both helpers are used in config/routes.rb to generate RESTful routes. The key difference lies in whether the resource is singular or plural, and that directly affects the URLs and controller actions Rails creates for you.
resources is the most commonly used helper. It represents a collection of objects, where each item has its own identifier (usually an id).
Example:
1
resources :articles
This generates the full set of RESTful routes:
| HTTP Verb | Path | Controller#Action |
|---|---|---|
| GET | /articles | articles#index |
| GET | /articles/new | articles#new |
| POST | /articles | articles#create |
| GET | /articles/:id | articles#show |
| GET | /articles/:id/edit | articles#edit |
| PATCH | /articles/:id | articles#update |
| DELETE | /articles/:id | articles#destroy |
You use resources when:
indexTypical examples include posts, comments, products, and users.
resource (singular) represents a single object that does not need an ID in the URL. Rails assumes there is only one instance of that resource per context (often per user).
Example:
1
resource :profile
This generates a smaller set of routes:
| HTTP Verb | Path | Controller#Action |
|---|---|---|
| GET | /profile/new | profiles#new |
| POST | /profile | profiles#create |
| GET | /profile | profiles#show |
| GET | /profile/edit | profiles#edit |
| PATCH | /profile | profiles#update |
| DELETE | /profile | profiles#destroy |
Notice what’s missing:
index route:id segment in the URLYou use resource when:
id would be redundantCommon examples include user profiles, dashboards, shopping carts, or account settings.
Even when using resource, Rails still expects a plural controller name:
1
2
resource :profile
# maps to ProfilesController
This keeps controller naming consistent across the framework.
A good rule of thumb:
resources when you can say:
“There are many of these.”resource when you can say:
“There is only one of these per scope.”For example:
resources :postsresource :profileChoosing between resource and resources is more than syntax — it communicates intent. Singular routes make your URLs cleaner, your controllers simpler, and your application easier to reason about.
deliver_all_later enqueues many emails at once. When each job is executed, it sends the email using deliver_now. This improves performance by reducing the number of round-trips to the queue datastore, especially when dealing with a large number of emails.
To use deliver_all_later, you can pass an array of email deliveries:
1
2
user_emails = User.all.map { |user| Notifier.welcome(user) }
ActionMailer.deliver_all_later(user_emails)
You can even specify a custom queue if needed:
1
ActionMailer.deliver_all_later(user_emails, queue: :my_queue)
This new feature is particularly useful for large-scale email delivery, such as when you’re sending out notifications to thousands of users. By batching email deliveries, you reduce the load on your application and improve overall efficiency.
]]>current_page? helper only works with GET and HEAD requests. This can be problematic when dealing with forms or actions that use other HTTP methods like POST, PUT, or PATCH. This feature was introduced in this PR
For example, if you have a page for viewing posts and another for creating posts, both share the same URL (/posts). The only difference is the HTTP method used (GET for viewing and POST for creating). With the default current_page? helper, it’s difficult to highlight the correct navigation link when a user submits a form to create a post.
Rails now allows you to pass a method argument to current_page?, enabling you to match specific HTTP methods when checking the current page. This means you can distinguish between actions that share the same URL but differ by HTTP method.
Here’s how to use it:
1
2
3
4
5
6
7
8
<ul class="nav nav-tabs">
<li class="nav-item">
<%= link_to "All posts", posts_path, class: ["nav-link", { active: current_page?(posts_path) }] %>
</li>
<li class="nav-item">
<%= link_to "Create post", new_post_path, class: ["nav-link", { active: current_page?(new_post_path) || current_page?(posts_path, method: :post) }] %>
</li>
</ul>
This simple addition makes it easier to highlight the right link, whether you’re viewing posts (GET /posts) or creating a new post (POST /posts). It improves your app’s navigation and helps you avoid unnecessary workarounds.
By adding support for HTTP methods in current_page?, Rails makes it simpler to handle navigation for actions that share the same URL. If you’re working with forms or actions that use multiple HTTP methods, this feature will save you time and help create cleaner, more intuitive navigation.