
Rails
[Active Support](https://guides.rubyonrails.org/active_support_core_extensions.html)
provides various extensions, utilities, and helpers. It provides a collection of
utility classes and standard library extensions that are very useful.

Rails 5.1 introduced `assert_no_changes` and `assert_changes` making it easier
to observe changes. Using
[ActiveSupport::TestCase#assert_no_changes](https://api.rubyonrails.org/classes/ActiveSupport/Testing/Assertions.html#method-i-assert_no_changes)
we can easily assert that the result of evaluating an expression has not changed
before and after calling the passed block.

To assert the expected change in the value of an object we can use
`assert_changes`.

```ruby
assert_changes -> { user.address } do
  user.update address: 'Miami'
end
```

`assert_changes` also supports `from` and `to` options.

```ruby
assert_changes -> { user.address }, from: 'San Francisco', to: 'Miami' do
  user.update address: 'Miami'
end
```

Similarly, `assert_no_changes` allows us to assert a value that is expected to
not change.

```ruby
assert_no_changes -> { user.address } do
  user.update address: 'Miami'
end
```

We can also specify an error message with `assert_no_changes`.

```ruby
assert_no_changes -> { user.address }, 'Expect the address to not change' do
  user.update address: 'Miami'
end
```

### Before

`assert_no_changes` did not support the `from` option similar to
`assert_changes`.

```ruby
assert_no_changes -> { user.address } do
  user.update address: 'Miami'
end
```

However,
[Rails 7 has added from: option to ActiveSupport::TestCase#assert_no_changes](https://github.com/rails/rails/pull/42277),
allowing us to assert on the initial value that is expected to not change.

### Rails 7 onwards

Provides the optional `from` argument to specify the expected initial value.

```ruby
assert_no_changes -> { user.address }, from: 'San Francisco' do
  user.update address: 'Miami'
end
```

Check out this [pull request](https://github.com/rails/rails/pull/42277) for
more details.

This article was originally published on this [website](https://www.bigbinary.com/blog/rails-7-adds-from-option-to-assert_no_changes).

Rails 7 Adds from option to ActiveSupport::TestCase#assert_no_changes


[Active Record](https://api.rubyonrails.org/v6.1.4/classes/ActiveRecord/Persistence.html)
in Rails provides various methods like `exists?`, `persisted?`, `destroyed?` and
many more. Using these methods we can easily determine if an object exists in
the database or if an object is an existing record in the database and not a new
record.

Using these methods we can quickly determine the state of an object and easily
write complex conditional statements that depend on the state of an object.
Previously we did not have a method that lets us determine if an object was a
part of the database in past but now does not exist.

However,
[Rails 7 has added previously_persisted? method to ActiveRecord](https://github.com/rails/rails/pull/42389),
which returns `true` if an object has been previously a part of the database
records but now has been destroyed.

Let’s assume we have a `User` model with the name column value `John Doe`. If
this record has been deleted from the database, we can still check if `John Doe`
was a user of our app or not in the past.

### Before

Let's say we delete the user with the name `John Doe`.

```ruby
# app/controllers/user_controller.rb
previous_user = User.find_by_name('John Doe')
previous_user.destroy!
```

Now we can check if the user exists in our database.

```ruby
# app/controllers/user_controller.rb
# check if previous_user is destroyed and is not a new user
if previous_user.destroyed? && !previous_user.new_record?
  # returns true
end
```

### Rails 7 onwards

We can use the `previously_persisted?` method on an object.

Let's delete the user with the name `John Doe`.

```ruby
# app/controllers/user_controller.rb
previous_user = User.find_by_name('John Doe')
previous_user.destroy!
```

Now we can check if the user exists in our database using the
`previously_persisted?` method.

```ruby
# app/controllers/user_controller.rb
previous_user.previously_persisted? # returns true
```

Check out this [pull request](https://github.com/rails/rails/pull/42389) for
more details.

This article was originally published on this [website](https://www.bigbinary.com/blog/rails-7-adds-activerecord-previously_persisted).


Rails 7 adds ActiveRecord::Base#previously_persisted?

In web applications, forms are one of the most essential interfaces for user
input and it can be tedious to write and maintain form markups with many
attributes. Rails provide
[Action View Form Helpers](https://guides.rubyonrails.org/form_helpers.html) for
generating form markup.

Using
[select](https://guides.rubyonrails.org/form_helpers.html#making-select-boxes-with-ease)
helper we can easily create select boxes in HTML with one `<option>` element for
each option to choose from.

For example, let's say we have a list of cities for the user to choose from.

```ruby
# app/views/address/new.html.erb
<%= form.select :city, ["Pune", "Mumbai", "Delhi"] %>
```

Rails will generate the following markup.

```html
<select name="city" id="city">
  <option value="Pune">Pune</option>
  <option value="Mumbai">Mumbai</option>
  <option value="Delhi">Delhi</option>
</select>
```

Previously for generating a select box for weekday select, we needed to write a
custom helper. Rails did not have anything out of the box for the weekday
selection.

However,
[Rails 7 has added weekday_options_for_select and weekday_select](https://github.com/rails/rails/pull/42979)
using which we can easily generate a dropdown field of selecting a weekday.

### Before

In Rails 6.1 we can create a dropdown field for weekday as shown here.

```ruby
# app/views/users/new.html.erb
<%= form_with(model: user) do |form| %>
  <div class="field">
    <%= form.label :weekly_off %>
    <%= form.select :weekly_off, I18n.t('date.day_names') %>
  </div>
<% end %>
```

Or we can do something like this.

```ruby
# app/views/users/new.html.erb
<%= form_with(model: user) do |form| %>
  <div class="field">
    <%= form.label :weekly_off %>
    <%= form.select :weekly_off, I18n.t('date.day_names').map.with_index.to_h %>
  </div>
<% end %>
```

Then The generated markup looks like this.

```html
<select name="user[weekly_off]" id="user_weekly_off">
  <option value="Sunday">Sunday</option>
  <option value="Monday">Monday</option>
  <option value="Tuesday">Tuesday</option>
  <option value="Wednesday">Wednesday</option>
  <option value="Thursday">Thursday</option>
  <option value="Friday">Friday</option>
  <option value="Saturday">Saturday</option>
</select>
```

Here is how it would look if we go with the second option.

```html
<select name="user[weekly_off]" id="user_weekly_off">
  <option value="0">Sunday</option>
  <option value="1">Monday</option>
  <option value="2">Tuesday</option>
  <option value="3">Wednesday</option>
  <option value="4">Thursday</option>
  <option value="5">Friday</option>
  <option value="6">Saturday</option>
</select>
```

### Rails 7 onwards

We can use the `weekday_options_for_select` or `weekday_select` helper for
generating a dropdown field for selecting a weekday.

```ruby
# app/views/users/new.html.erb
<%= form_with(model: user) do |form| %>
  <div class="field">
    <%= form.label :weekly_off %>
    <%= form.select :weekly_off, weekday_options_for_select("Monday", day_format: :abbr_day_names) %>
  </div>
<% end %>
```

Or we can do something like this.

```ruby
# app/views/users/new.html.erb
<%= form_with(model: user) do |form| %>
  <div class="field">
    <%= form.label :weekly_off %>
    <%= form.weekday_select :weekly_off, { selected: "Monday", day_format: :abbr_day_names } %>
  </div>
<% end %>
```

Then The generated markup looks like this.

```html
<select name="user[weekly_off]" id="user_weekly_off">
  <option value="Sunday">Sunday</option>
  <option selected="selected" value="Monday">Monday</option>
  <option value="Tuesday">Tuesday</option>
  <option value="Wednesday">Wednesday</option>
  <option value="Thursday">Thursday</option>
  <option value="Friday">Friday</option>
  <option value="Saturday">Saturday</option>
</select>
```

`weekday_options_for_select` accepts a few options and all of them have a
default value.

`selected` defaults to nil and if we provide this argument the value passed will
be used as the selected option.

```html
 
<option value=\"Sunday\">Sunday</option>\n
<option value=\"Monday\">Monday</option>\n
<option value=\"Tuesday\">Tuesday</option>\n
<option value=\"Wednesday\">Wednesday</option>\n
<option value=\"Thursday\">Thursday</option>\n
<option selected=\"selected\" value=\"Friday\">Friday</option>\n
<option value=\"Saturday\">Saturday</option>"
```

`index_as_value` defaults to false and if true it will set the value of each
option to the index of that day.

```html

<option value=\"0\">Sunday</option>\n
<option value=\"1\">Monday</option>\n
<option value=\"2\">Tuesday</option>\n
<option value=\"3\">Wednesday</option>\n
<option value=\"4\">Thursday</option>\n
<option value=\"5\">Friday</option>\n
<option value=\"6\">Saturday</option>"
```

`day_format` defaults to :day_names and passing this a different `I18n` key will
use different formats for the option display names and their values.

```html

<option value=\"Sun\">Sun</option>\n
<option value=\"Mon\">Mon</option>\n
<option value=\"Tue\">Tue</option>\n
<option value=\"We\">Wedn</option>\n
<option value=\"Thu\">Thu</option>\n
<option value=\"Fri\">Fri</option>\n
<option value=\"Sat\">Sat</option>"
```

Note that `:abbr_day_names` options are built into Rails but we can define your
array.

Check out this [pull request](https://github.com/rails/rails/pull/42979) for
more details.

This article was originally published on this [website](https://www.bigbinary.com/blog/rails-7-adds-weekday_options_for_select-and-weekday_select).

Rails 7 adds weekday_options_for_select and weekday_select


Rails 5 introduced [byebug](https://github.com/deivid-rodriguez/byebug) which is
an easy-to-use, feature-rich ruby debugger. It offers features like `Stepping`,
`Breaking`, `Evaluating`, `Tracking`.

Using [byebug](https://github.com/deivid-rodriguez/byebug) we can easily control
the execution of a program and the debug inspector for call stack navigation.
This allows us to handle and track the execution flow.

Here is
[byebug documentation](https://guides.rubyonrails.org/debugging_rails_applications.html#debugging-with-the-byebug-gem)
and here is the [pull request](https://github.com/rails/rails/pull/14646) where
it was added.

[Rails 7 is replacing byebug with ruby/debug](https://github.com/rails/rails/pull/43187).
`debug` is Ruby’s new debugger which will be included in Ruby 3.1. To align
Rails with Ruby `debug` has been added to Rails 7.

Let's see an example of debugging with both Byebug and Debug.

### Before

Let's assume we have a `NameController`. Inside any Rails application, you can
call the debugger by calling the `byebug` method.

```ruby
# app/controllers/name_controller.rb
class NameController < ApplicationController
  def index
    name = "John Doe"
    byebug # Call to debugger
    city = "San Francisco"
  end
end
```

Then The invoked debugger results in the following.

```ruby
    [1, 7] in app/controllers/test_controller.rb
    1: class NameController < ApplicationController
    2:   def index
    3:     name = "John Doe"
    4:     byebug # Call to debugger
=>  5:    city = "San Francisco"
    6:   end
    7: end

  (byebug) name # variable call
  "John Doe"
```

### Rails 7 onwards

We can use the `binding.break` method for calling Ruby Debug.

```ruby
# app/controllers/name_controller.rb
class NameController < ApplicationController
  def index
    name = "John Doe"
    binding.break # Call to debugger
    city = "San Francisco"
  end
end
```

The invoked debugger results in the following.

```ruby
  [1, 7] in app/controllers/test_controller.rb
  1| class NameController < ApplicationController
  2|   def index
  3|     name = "John Doe"
  4|     binding.break # Call to debugger
> 5|    city = "San Francisco"
  6|   end
  7| end
>#0 NameController#index at ~/demo_app/app/controllers/name_controller.rb:5
  #1  ActionController::BasicImplicitRender#send_action(method="index", args=[])
(rdbg) name # variable call
"John Doe"
```

Check out this [pull request](https://github.com/rails/rails/pull/43187) for more details and for commands or features of Ruby Debug, please visit [Ruby-Debug](https://github.com/ruby/debug).

This article was originally published on this [website](https://www.bigbinary.com/blog/rails-7-replaced-byebug-with-ruby-debug).


Rails 7 replaced byebug with ruby/debug


Rails 5.2 introduced
[ActiveStorage](https://guides.rubyonrails.org/active_storage_overview.html)
which made it possible to easily upload files to a cloud storage service like
Amazon S3, Google Cloud Storage, or Microsoft Azure Storage. It also helped in
attaching the files to active record objects.

Using `ActiveStorage` and [ImageMagick](https://www.imagemagick.org) we can
transform image uploads and extract metadata from files. For transforming image
uploads we can use [image_processing](https://www.imagemagick.org) gem with
`ActiveStorage` and create variants of an image.

Previously for creating image variants, we needed to use
[image_processing](https://www.imagemagick.org) gem with `ActiveStorage`
processor. The default processor for `ActiveStorage` is `MiniMagick`, but we can
also use [Vips](https://www.rubydoc.info/gems/ruby-vips/Vips/Image).

However,
[Rails 7 has added the ability to use pre-defined variants](https://github.com/rails/rails/pull/39135)
which provides a way to easily create variants for images.

Let's assume we have a model `Blog`. Using `has_one_attched` every record can
have one file attached to it.

```ruby
# app/models/blog.rb
class Blog < ApplicationRecord
  has_one_attached :display_picture # Setup mapping between record and file
end
```

To create a `blog` with an attachment on `display_picture`.

```ruby
# app/views/blogs/new.html.erb
<%= form.file_field :avatar %>
```

```ruby
# app/controllers/blogs_controller.rb
class BlogsController < ApplicationController
  def create
    blog = Blog.create!(blog_params)
    session[:user_id] = blog.id
    redirect_to root_path
  end

  private
    def blog_params
      params.require(:blog).permit(:title, :display_picture)
    end
end
```

### Before

If we want to create variants of `display_picture`, we needed add the
[image_processing](https://www.imagemagick.org) gem to the `Gemfile`.

```ruby
# project_folder/Gemfile
gem 'image_processing'
```

Then to create variants of the image, we can call the `variant` method on the
attachment record.

```ruby
# app/views/blogs/show.html.erb
<%= image_tag blog.display_picture.variant(resize_to_limit: [100, 100]) %>
```

### Rails 7 onwards

We can use the `variants` option on `has_one_attached`.

```ruby
class Blog < ActiveRecord::Base
  has_one_attached :display_picture, variants: {
    thumb: { resize: "100x100" },
    medium: { resize: "300x300" }
  }
end
```

To display we can use the `variant` method.

```ruby
# app/views/blogs/show.html.erb
<%= image_tag blog.display_picture.variant(:thumb) %>
```

`variants` can also be used on `has_many_attached`. Check out this
[pull request](https://github.com/rails/rails/pull/39135) for more details.

This article was originally published on this [website](https://www.bigbinary.com/blog/rails-7-adds-ability-to-use-predefined-variants).

Rails 7 adds the ability to use pre-defined variants


Rails
[Active Record Validation](https://guides.rubyonrails.org/active_record_validations.html)
provides a convenient way to validate the state of an object before it is stored
in the database. There are various built-in
[Active Record validations](https://guides.rubyonrails.org/active_record_validations.html)
like `presence`, `length`, `numericality` and `uniqueness`.

By using
[numericality validator](https://guides.rubyonrails.org/active_record_validations.html#numericality),
we can validate an attribute to only have numeric values.

```ruby
# app/models/blog.rb
class Blog < ApplicationRecord
  validates :likes, numericality: true
end
```

We can also use helpers like `greater_than`, `greater_than_or_equal_to`,
`equal_to`, `less_than`, `less_than_or_equal_to`, `other_than`, `odd`, `even`
with
[numericality validator](https://guides.rubyonrails.org/active_record_validations.html#numericality)
but these work only on numbers.

```ruby
# app/models/blog.rb
class Blog < ApplicationRecord
  validates :likes, numericality: { greater_than: 1 }
end
```

Previously for validating comparisons of dates we needed to write
[custom validators](https://guides.rubyonrails.org/active_record_validations.html#performing-custom-validations)
or use a gem like [date_validator](https://github.com/codegram/date_validator).

However,
[Rails 7 has added ComparisonValidator](https://github.com/rails/rails/pull/40095)
which provides a way to easily validate comparisons with another value, proc, or
attribute. Let's assume we have a model `Blog` with an `end_date` attribute.

### Before

If we want to validate the `end_date` attribute for the provided value or then
we would need to write a
[custom validator](https://guides.rubyonrails.org/active_record_validations.html#performing-custom-validations)
or use a gem like [date_validator](https://github.com/codegram/date_validator).

```ruby
# Using date_validator gem
class Blog < ApplicationRecord
  # validate against provided value
  validates :end_date, date: { after: Proc.new { Date.today } }
  # validate against another attribute
  validates :end_date, date: { after: :start_date }
end
```

### Rails 7 onwards

We can use [ComparisonValidator](https://github.com/rails/rails/pull/40095) to
validate the comparison of the `end_date` attribute for a provided value.

```ruby
class Blog < ApplicationRecord
  # validate against provided value
  validates_comparison_of :end_date, greater_than: -> { Date.today }
  # validate against another attribute
  validates :end_date, greater_than: :start_date
end
```

[ComparisonValidator](https://github.com/rails/rails/pull/40095) also provides
helpers like `greater_than`, `greater_than_or_equal_to`, `equal_to`,
`less_than`, `less_than_or_equal_to` and `other_than`.

Check out this [pull request](https://github.com/rails/rails/pull/40095) for
more details.

This article was originally published on this [website](https://www.bigbinary.com/blog/rails-7-adds-comparison-validator-to-active-record).

Rails 7 adds ComparisonValidator to ActiveRecord


[ActiveRecord](https://guides.rubyonrails.org/active_record_querying.html) is
one of the most powerful features in Rails. With `ActiveRecord` we can easily
query and handle database objects without writing any SQL.

By using `ActiveRecord Query Interface`, we can perform various query operations
like `Joins`, `Group`, `Find`, `Order`. We can also chain relations with
`where`, `and`, `or`, `not` but for `and` or `or` the two chaining relations
must be structurally compatible.

For any two relations to be
[Structurally Compatible](https://github.com/rails/rails/blob/c577657f6de64b743b12a21108dc9cc5cfc35098/activerecord/lib/active_record/relation/query_methods.rb#L650)
they must be scoping the same model, and they must differ only by the `where`
clause when no `group` clause has been defined. If a `group` clause is present
then the relations must differ by the `having` clause. Also, Neither relation
may use a `limit`, `offset`, or `distinct` method.

Previously for `and` or `or` query methods, we needed to make sure that the two
relations are structurally compatible otherwise `ActiveRecord` would raise an
error.

However,
[Rails 7 has added ActiveRecord::Relation#structurally_compatible?](https://github.com/rails/rails/pull/41841)
which provides a method to easily tell if two relations are structurally
compatible. We can use this method before we run `and` or `or` query methods on
any two relations.

Let's assume we have two models `Blog` and `Post` with the following relations
```ruby
# app/models/blog.rb
class Blog < ApplicationRecord
  has_many :posts
end
```

```ruby
# app/models/post.rb
class Post < ApplicationRecord
  belongs_to :blog
end
```

### Before

If we run `or` query between incompatible relations we would get an
ArgumentError.

```ruby
relation_1 = Blog.where(name: 'bigbinary blog')
relation_2 = Blog.joins(:posts).where(posts: { user_id: current_user.id})

begin
  relation_1.or(relation_2)
rescue ArgumentError
  # Rescue ArgumentError
end
```

### Rails 7 onwards

We can check the structural compatibility of the two relations.

```ruby
relation_1 = Blog.where(name: 'bigbinary blog')
relation_2 = Blog.where(user_id: current_user.id)

if relation_1.structurally_compatible?(relation_2) # returns true
  relation_1.or(relation_2)
end
```

Check out this [pull request](https://github.com/rails/rails/pull/41841/files)
for more details.

This article was originally published on this [website](https://www.bigbinary.com/blog/rails-7-adds-active-record-relation-structurally-compatible).
