Active Model Basics

1 What is Active Model?

To understand Active Model, you need to know a little about Active Record. Active Record is an ORM (Object Relational Mapper) that connects objects whose data requires persistent storage to a relational database. However, it has functionality that is useful outside of the ORM, some of these include validations, callbacks, translations, the ability to create custom attributes, etc.

Some of this functionality was abstracted from Active Record to form Active Model. Active Model is a library containing various modules that can be used on plain Ruby objects that require model-like features but are not tied to any table in a database.

In summary, while Active Record provides an interface for defining models that correspond to database tables, Active Model provides functionality for building model-like Ruby classes that don't necessarily need to be backed by a database. Active Model can be used independently of Active Record.

Some of these modules are explained below.

1.1 API

ActiveModel::API adds the ability for a class to work with Action Pack and Action View right out of the box.

When including ActiveModel::API, other modules are included by default which enables you to get features like:

• Attribute Assignment
• Conversion
• Naming
• Translation
• Validations

Here is an example of a class that includes ActiveModel::API and how it can be used:

class EmailContact
  include ActiveModel::API

  attr_accessor :name, :email, :message
  validates :name, :email, :message, presence: true

  def deliver
    if valid?
      # Deliver email
    end
  end
end

irb> email_contact = EmailContact.new(name: "David", email: "david@example.com", message: "Hello World")

irb> email_contact.name # Attribute Assignment
=> "David"

irb> email_contact.to_model == email_contact # Conversion
=> true

irb> email_contact.model_name.name # Naming
=> "EmailContact"

irb> EmailContact.human_attribute_name("name") # Translation if the locale is set
=> "Name"

irb> email_contact.valid? # Validations
=> true

irb> empty_contact = EmailContact.new
irb> empty_contact.valid?
=> false

Any class that includes ActiveModel::API can be used with form_with, render and any other Action View helper methods, just like Active Record objects.

For example, form_with can be used to create a form for an EmailContact object as follows:

<%= form_with model: EmailContact.new do |form| %>
  <%= form.text_field :name %>
<% end %>

which results in the following HTML:

<form action="/email_contacts" method="post">
  <input type="text" name="email_contact[name]" id="email_contact_name">
</form>

render can be used to render a partial with the object:

<%= render @email_contact %>

1.2 Model

ActiveModel::Model includes ActiveModel::API to interact with Action Pack and Action View by default, and is the recommended approach to implement model-like Ruby classes. It will be extended in the future to add more functionality.

class Person
  include ActiveModel::Model

  attr_accessor :name, :age
end

irb> person = Person.new(name: 'bob', age: '18')
irb> person.name # => "bob"
irb> person.age  # => "18"

1.3 Attributes

ActiveModel::Attributes allows you to define data types, set default values, and handle casting and serialization on plain Ruby objects. This can be useful for form data which will produce Active Record-like conversion for things like dates and booleans on regular objects.

To use Attributes, include the module in your model class and define your attributes using the attribute macro. It accepts a name, a cast type, a default value, and any other options supported by the attribute type.

class Person
  include ActiveModel::Attributes

  attribute :name, :string
  attribute :date_of_birth, :date
  attribute :active, :boolean, default: true
end

irb> person = Person.new

irb> person.name = "Jane"
irb> person.name
=> "Jane"

# Casts the string to a date set by the attribute
irb> person.date_of_birth = "2020-01-01"
irb> person.date_of_birth
=> Wed, 01 Jan 2020
irb> person.date_of_birth.class
=> Date

# Uses the default value set by the attribute
irb> person.active
=> true

# Casts the integer to a boolean set by the attribute
irb> person.active = 0
irb> person.active
=> false

Some additional methods described below are available when using ActiveModel::Attributes.

1.3.1 Method: attribute_names

The attribute_names method returns an array of attribute names.

irb> Person.attribute_names
=> ["name", "date_of_birth", "active"]

1.3.2 Method: attributes

The attributes method returns a hash of all the attributes with their names as keys and the values of the attributes as values.

irb> person.attributes
=> {"name" => "Jane", "date_of_birth" => Wed, 01 Jan 2020, "active" => false}

1.4 Attribute Assignment

ActiveModel::AttributeAssignment allows you to set an object's attributes by passing in a hash of attributes with keys matching the attribute names. This is useful when you want to set multiple attributes at once.

Consider the following class:

class Person
  include ActiveModel::AttributeAssignment

  attr_accessor :name, :date_of_birth, :active
end

irb> person = Person.new

# Set multiple attributes at once
irb> person.assign_attributes(name: "John", date_of_birth: "1998-01-01", active: false)

irb> person.name
=> "John"
irb> person.date_of_birth
=> Thu, 01 Jan 1998
irb> person.active
=> false

If the passed hash responds to the permitted? method and the return value of this method is false, an ActiveModel::ForbiddenAttributesError exception is raised.

irb> person = Person.new

# Using strong parameters checks, build a hash of attributes similar to params from a request
irb> params = ActionController::Parameters.new(name: "John")
=> #<ActionController::Parameters {"name" => "John"} permitted: false>

irb> person.assign_attributes(params)
=> # Raises ActiveModel::ForbiddenAttributesError
irb> person.name
=> nil

# Permit the attributes we want to allow assignment
irb> permitted_params = params.permit(:name)
=> #<ActionController::Parameters {"name" => "John"} permitted: true>

irb> person.assign_attributes(permitted_params)
irb> person.name
=> "John"

1.4.1 Method alias: attributes=

The assign_attributes method has an alias attributes=.

The following example demonstrates the use of the attributes= method to set multiple attributes at once:

irb> person = Person.new

irb> person.attributes = { name: "John", date_of_birth: "1998-01-01", active: false }

irb> person.name
=> "John"
irb> person.date_of_birth
=> "1998-01-01"

1.5 Attribute Methods

ActiveModel::AttributeMethods provides a way to define methods dynamically for attributes of a model. This module is particularly useful to simplify attribute access and manipulation, and it can add custom prefixes and suffixes to the methods of a class. You can define the prefixes and suffixes and which methods on the object will use them as follows:

1. Include ActiveModel::AttributeMethods in your class.
2. Call each of the methods you want to add, such as attribute_method_suffix, attribute_method_prefix, attribute_method_affix.
3. Call define_attribute_methods after the other methods to declare the attribute(s) that should be prefixed and suffixed.
4. Define the various generic _attribute methods that you have declared. The parameter attribute in these methods will be replaced by the argument passed in define_attribute_methods. In the example below it's name.

class Person
  include ActiveModel::AttributeMethods

  attribute_method_affix prefix: "reset_", suffix: "_to_default!"
  attribute_method_prefix "first_", "last_"
  attribute_method_suffix "_short?"

  define_attribute_methods "name"

  attr_accessor :name

  private
    # Attribute method call for 'first_name'
    def first_attribute(attribute)
      public_send(attribute).split.first
    end

    # Attribute method call for 'last_name'
    def last_attribute(attribute)
      public_send(attribute).split.last
    end

    # Attribute method call for 'name_short?'
    def attribute_short?(attribute)
      public_send(attribute).length < 5
    end

    # Attribute method call 'reset_name_to_default!'
    def reset_attribute_to_default!(attribute)
      public_send("#{attribute}=", "Default Name")
    end
end

irb> person = Person.new
irb> person.name = "Jane Doe"

irb> person.first_name
=> "Jane"
irb> person.last_name
=> "Doe"

irb> person.name_short?
=> false

irb> person.reset_name_to_default!
=> "Default Name"

If you call a method that is not defined, it will raise a NoMethodError error.

1.5.1 Method: alias_attribute

ActiveModel::AttributeMethods provides aliasing of attribute methods using alias_attribute.

The example below creates an alias attribute for name called full_name. They return the same value, but the alias full_name better reflects that the attribute includes a first name and last name.

class Person
  include ActiveModel::AttributeMethods

  attribute_method_suffix "_short?"
  define_attribute_methods :name

  attr_accessor :name

  alias_attribute :full_name, :name

  private
    def attribute_short?(attribute)
      public_send(attribute).length < 5
    end
end

irb> person = Person.new
irb> person.name = "Joe Doe"
irb> person.name
=> "Joe Doe"

# `full_name` is the alias for `name`, and returns the same value
irb> person.full_name
=> "Joe Doe"
irb> person.name_short?
=> false

# `full_name_short?` is the alias for `name_short?`, and returns the same value
irb> person.full_name_short?
=> false

1.6 Callbacks

ActiveModel::Callbacks gives plain Ruby objects Active Record style callbacks. The callbacks allow you to hook into model lifecycle events, such as before_update and after_create, as well as to define custom logic to be executed at specific points in the model's lifecycle.

You can implement ActiveModel::Callbacks by following the steps below:

1. Extend ActiveModel::Callbacks within your class.
2. Employ define_model_callbacks to establish a list of methods that should have callbacks associated with them. When you designate a method such as :update, it will automatically include all three default callbacks (before, around, and after) for the :update event.
3. Inside the defined method, utilize run_callbacks, which will execute the callback chain when the specific event is triggered.
4. In your class, you can then utilize the before_update, after_update, and around_update methods like how you would use them in an Active Record model.

class Person
  extend ActiveModel::Callbacks

  define_model_callbacks :update

  before_update :reset_me
  after_update :finalize_me
  around_update :log_me

  # `define_model_callbacks` method containing `run_callbacks` which runs the callback(s) for the given event
  def update
    run_callbacks(:update) do
      puts "update method called"
    end
  end

  private
    # When update is called on an object, then this method is called by `before_update` callback
    def reset_me
      puts "reset_me method: called before the update method"
    end

    # When update is called on an object, then this method is called by `after_update` callback
    def finalize_me
      puts "finalize_me method: called after the update method"
    end

    # When update is called on an object, then this method is called by `around_update` callback
    def log_me
      puts "log_me method: called around the update method"
      yield
      puts "log_me method: block successfully called"
    end
end

The above class will yield the following which indicates the order in which the callbacks are being called:

irb> person = Person.new
irb> person.update
reset_me method: called before the update method
log_me method: called around the update method
update method called
log_me method: block successfully called
finalize_me method: called after the update method
=> nil

As per the above example, when defining an 'around' callback remember to yield to the block, otherwise, it won't be executed.

1.6.1 Defining Specific Callbacks

You can choose to create specific callbacks by passing the only option to the define_model_callbacks method:

define_model_callbacks :update, :create, only: [:after, :before]

This will create only the before_create / after_create and before_update / after_update callbacks, but skip the around_* ones. The option will apply to all callbacks defined on that method call. It's possible to call define_model_callbacks multiple times, to specify different lifecycle events:

define_model_callbacks :create, only: :after
define_model_callbacks :update, only: :before
define_model_callbacks :destroy, only: :around

This will create after_create, before_update, and around_destroy methods only.

1.6.2 Defining Callbacks with a Class

You can pass a class to before_<type>, after_<type> and around_<type> for more control over when and in what context your callbacks are triggered. The callback will trigger that class's <action>_<type> method, passing an instance of the class as an argument.

class Person
  extend ActiveModel::Callbacks

  define_model_callbacks :create
  before_create PersonCallbacks
end

class PersonCallbacks
  def self.before_create(obj)
    # `obj` is the Person instance that the callback is being called on
  end
end

1.6.3 Aborting Callbacks

The callback chain can be aborted at any point in time by throwing :abort. This is similar to how Active Record callbacks work.

In the example below, since we throw :abort before an update in the reset_me method, the remaining callback chain including before_update will be aborted, and the body of the update method won't be executed.

class Person
  extend ActiveModel::Callbacks

  define_model_callbacks :update

  before_update :reset_me
  after_update :finalize_me
  around_update :log_me

  def update
    run_callbacks(:update) do
      puts "update method called"
    end
  end

  private
    def reset_me
      puts "reset_me method: called before the update method"
      throw :abort
      puts "reset_me method: some code after abort"
    end

    def finalize_me
      puts "finalize_me method: called after the update method"
    end

    def log_me
      puts "log_me method: called around the update method"
      yield
      puts "log_me method: block successfully called"
    end
end

irb> person = Person.new

irb> person.update
reset_me method: called before the update method
=> false

1.7 Conversion

ActiveModel::Conversion is a collection of methods that allow you to convert your object to different forms for different purposes. A common use case is to convert your object to a string or an integer to build URLs, form fields, and more.

The ActiveModel::Conversion module adds the following methods: to_model, to_key, to_param, and to_partial_path to classes.

The return values of the methods depend on whether persisted? is defined and if an id is provided. The persisted? method should return true if the object has been saved to the database or store, otherwise, it should return false. The id should reference the id of the object or nil if the object is not saved.

class Person
  include ActiveModel::Conversion
  attr_accessor :id

  def initialize(id)
    @id = id
  end

  def persisted?
    id.present?
  end
end

1.7.1 to_model

The to_model method returns the object itself.

irb> person = Person.new(1)
irb> person.to_model == person
=> true

If your model does not act like an Active Model object, then you should define :to_model yourself returning a proxy object that wraps your object with Active Model compliant methods.

class Person
  def to_model
    # A proxy object that wraps your object with Active Model compliant methods.
    PersonModel.new(self)
  end
end

1.7.2 to_key

The to_key method returns an array of the object's key attributes if any of the attributes are set, whether or not the object is persisted. Returns nil if there are no key attributes.

irb> person.to_key
=> [1]

1.7.3 to_param

The to_param method returns a string representation of the object's key suitable for use in URLs, or nil in the case where persisted? is false.

irb> person.to_param
=> "1"

1.7.4 to_partial_path

The to_partial_path method returns a string representing the path associated with the object. Action Pack uses this to find a suitable partial to represent the object.

irb> person.to_partial_path
=> "people/person"

1.8 Dirty

ActiveModel::Dirty is useful for tracking changes made to model attributes before they are saved. This functionality allows you to determine which attributes have been modified, what their previous and current values are, and perform actions based on those changes. It's particularly handy for auditing, validation, and conditional logic within your application. It provides a way to track changes in your object in the same way as Active Record.

An object becomes dirty when it has gone through one or more changes to its attributes and has not been saved. It has attribute-based accessor methods.

To use ActiveModel::Dirty, you need to:

1. Include the module in your class.
2. Define the attribute methods that you want to track changes for, using define_attribute_methods.
3. Call [attr_name]_will_change! before each change to the tracked attribute.
4. Call changes_applied after the changes are persisted.
5. Call clear_changes_information when you want to reset the changes information.
6. Call restore_attributes when you want to restore previous data.

You can then use the methods provided by ActiveModel::Dirty to query the object for its list of all changed attributes, the original values of the changed attributes, and the changes made to the attributes.

Let's consider a Person class with attributes first_name and last_name and determine how we can use ActiveModel::Dirty to track changes to these attributes.

class Person
  include ActiveModel::Dirty

  attr_reader :first_name, :last_name
  define_attribute_methods :first_name, :last_name

  def initialize
    @first_name = nil
    @last_name = nil
  end

  def first_name=(value)
    first_name_will_change! unless value == @first_name
    @first_name = value
  end

  def last_name=(value)
    last_name_will_change! unless value == @last_name
    @last_name = value
  end

  def save
    # Persist data - clears dirty data and moves `changes` to `previous_changes`.
    changes_applied
  end

  def reload!
    # Clears all dirty data: current changes and previous changes.
    clear_changes_information
  end

  def rollback!
    # Restores all previous data of the provided attributes.
    restore_attributes
  end
end

1.8.1 Querying an Object Directly for its List of All Changed Attributes

irb> person = Person.new

# A newly instantiated `Person` object is unchanged:
irb> person.changed?
=> false

irb> person.first_name = "Jane Doe"
irb> person.first_name
=> "Jane Doe"

changed? returns true if any of the attributes have unsaved changes, false otherwise.

irb> person.changed?
=> true

changed returns an array with the name of the attributes containing unsaved changes.

irb> person.changed
=> ["first_name"]

changed_attributes returns a hash of the attributes with unsaved changes indicating their original values like attr => original value.

irb> person.changed_attributes
=> {"first_name" => nil}

changes returns a hash of changes, with the attribute names as the keys, and the values as an array of the original and new values like attr => [original value, new value].

irb> person.changes
=> {"first_name" => [nil, "Jane Doe"]}

previous_changes returns a hash of attributes that were changed before the model was saved (i.e. before changes_applied is called).

irb> person.previous_changes
=> {}

irb> person.save
irb> person.previous_changes
=> {"first_name" => [nil, "Jane Doe"]}

1.8.2 Attribute-based Accessor Methods

irb> person = Person.new

irb> person.changed?
=> false

irb> person.first_name = "John Doe"
irb> person.first_name
=> "John Doe"

[attr_name]_changed? checks whether the particular attribute has been changed or not.

irb> person.first_name_changed?
=> true

[attr_name]_was tracks the previous value of the attribute.

irb> person.first_name_was
=> nil

[attr_name]_change tracks both the previous and current values of the changed attribute. Returns an array with [original value, new value] if changed, otherwise returns nil.

irb> person.first_name_change
=> [nil, "John Doe"]
irb> person.last_name_change
=> nil

[attr_name]_previously_changed? checks whether the particular attribute has been changed before the model was saved (i.e. before changes_applied is called).

irb> person.first_name_previously_changed?
=> false
irb> person.save
irb> person.first_name_previously_changed?
=> true

[attr_name]_previous_change tracks both previous and current values of the changed attribute before the model was saved (i.e. before changes_applied is called). Returns an array with [original value, new value] if changed, otherwise returns nil.

irb> person.first_name_previous_change
=> [nil, "John Doe"]

1.9 Naming

ActiveModel::Naming adds a class method and helper methods to make naming and routing easier to manage. The module defines the model_name class method which will define several accessors using some ActiveSupport::Inflector methods.

class Person
  extend ActiveModel::Naming
end

name returns the name of the model.

irb> Person.model_name.name
=> "Person"

singular returns the singular class name of a record or class.

irb> Person.model_name.singular
=> "person"

plural returns the plural class name of a record or class.

irb> Person.model_name.plural
=> "people"

element removes the namespace and returns the singular snake_cased name. It is generally used by Action Pack and/or Action View helpers to aid in rendering the name of partials/forms.

irb> Person.model_name.element
=> "person"

human transforms the model name into a more human format, using I18n. By default, it will underscore and then humanize the class name.

irb> Person.model_name.human
=> "Person"

collection removes the namespace and returns the plural snake_cased name. It is generally used by Action Pack and/or Action View helpers to aid in rendering the name of partials/forms.

irb> Person.model_name.collection
=> "people"

param_key returns a string to use for params names.

irb> Person.model_name.param_key
=> "person"

i18n_key returns the name of the i18n key. It underscores the model name and then returns it as a symbol.

irb> Person.model_name.i18n_key
=> :person

route_key returns a string to use while generating route names.

irb> Person.model_name.route_key
=> "people"

singular_route_key returns a string to use while generating route names.

irb> Person.model_name.singular_route_key
=> "person"

uncountable? identifies whether the class name of a record or class is uncountable.

irb> Person.model_name.uncountable?
=> false

1.9.1 Customize the Name of the Model

Sometimes you may want to customize the name of the model that is used in form helpers and URL generation. This can be useful in situations where you want to use a more user-friendly name for the model, while still being able to reference it using its full namespace.

For example, let's say you have a Person namespace in your Rails application, and you want to create a form for a new Person::Profile.

By default, Rails would generate the form with the URL /person/profiles, which includes the namespace person. However, if you want the URL to simply point to profiles without the namespace, you can customize the model_name method like this:

module Person
  class Profile
    include ActiveModel::Model

    def self.model_name
      ActiveModel::Name.new(self, nil, "Profile")
    end
  end
end

With this setup, when you use the form_with helper to create a form for creating a new Person::Profile, Rails will generate the form with the URL /profiles instead of /person/profiles, because the model_name method has been overridden to return Profile.

In addition, the path helpers will be generated without the namespace, so you can use profiles_path instead of person_profiles_path to generate the URL for the profiles resource. To use the profiles_path helper, you need to define the routes for the Person::Profile model in your config/routes.rb file like this:

Rails.application.routes.draw do
  resources :profiles
end

Consequently, you can expect the model to return the following values for methods that were described in the previous section:

irb> name = ActiveModel::Name.new(Person::Profile, nil, "Profile")
=> #<ActiveModel::Name:0x000000014c5dbae0

irb> name.singular
=> "profile"
irb> name.singular_route_key
=> "profile"
irb> name.route_key
=> "profiles"

1.10 SecurePassword

ActiveModel::SecurePassword provides a way to securely store any password in an encrypted form. When you include this module, a has_secure_password class method is provided which defines a password accessor with certain validations on it by default.

ActiveModel::SecurePassword depends on bcrypt, so include this gem in your Gemfile to use it.

gem "bcrypt"

ActiveModel::SecurePassword requires you to have a password_digest attribute.

The following validations are added automatically:

1. Password must be present on creation.
2. Confirmation of password (using a password_confirmation attribute).
3. The maximum length of a password is 72 bytes (required as bcrypt truncates the string to this size before encrypting it).

For further customization, it is possible to suppress the default validations by passing validations: false as an argument.

class Person
  include ActiveModel::SecurePassword

  has_secure_password
  has_secure_password :recovery_password, validations: false

  attr_accessor :password_digest, :recovery_password_digest
end

irb> person = Person.new

# When password is blank.
irb> person.valid?
=> false

# When the confirmation doesn't match the password.
irb> person.password = "aditya"
irb> person.password_confirmation = "nomatch"
irb> person.valid?
=> false

# When the length of password exceeds 72.
irb> person.password = person.password_confirmation = "a" * 100
irb> person.valid?
=> false

# When only password is supplied with no password_confirmation.
irb> person.password = "aditya"
irb> person.valid?
=> true

# When all validations are passed.
irb> person.password = person.password_confirmation = "aditya"
irb> person.valid?
=> true

irb> person.recovery_password = "42password"

# `authenticate` is an alias for `authenticate_password`
irb> person.authenticate("aditya")
=> #<Person> # == person
irb> person.authenticate("notright")
=> false
irb> person.authenticate_password("aditya")
=> #<Person> # == person
irb> person.authenticate_password("notright")
=> false

irb> person.authenticate_recovery_password("aditya")
=> false
irb> person.authenticate_recovery_password("42password")
=> #<Person> # == person
irb> person.authenticate_recovery_password("notright")
=> false

irb> person.password_digest
=> "$2a$04$gF8RfZdoXHvyTjHhiU4ZsO.kQqV9oonYZu31PRE4hLQn3xM2qkpIy"
irb> person.recovery_password_digest
=> "$2a$04$iOfhwahFymCs5weB3BNH/uXkTG65HR.qpW.bNhEjFP3ftli3o5DQC"

1.11 Serialization

ActiveModel::Serialization provides basic serialization for your object. You need to declare an attributes hash that contains the attributes you want to serialize. Attributes must be strings, not symbols.

class Person
  include ActiveModel::Serialization

  attr_accessor :name, :age

  def attributes
    # Declaration of attributes that will be serialized
    { "name" => nil, "age" => nil }
  end

  def capitalized_name
    # Declared methods can be later included in the serialized hash
    name&.capitalize
  end
end

Now you can access a serialized hash of your object using the serializable_hash method. Valid options for serializable_hash include :only, :except, :methods and :include.

irb> person = Person.new

irb> person.serializable_hash
=> {"name" => nil, "age" => nil}

# Set the name and age attributes and serialize the object
irb> person.name = "bob"
irb> person.age = 22
irb> person.serializable_hash
=> {"name" => "bob", "age" => 22}

# Use the methods option to include the capitalized_name method
irb>  person.serializable_hash(methods: :capitalized_name)
=> {"name" => "bob", "age" => 22, "capitalized_name" => "Bob"}

# Use the only method to include only the name attribute
irb> person.serializable_hash(only: :name)
=> {"name" => "bob"}

# Use the except method to exclude the name attribute
irb> person.serializable_hash(except: :name)
=> {"age" => 22}

The example to utilize the includes option requires a slightly more complex scenario as defined below:

  class Person
    include ActiveModel::Serialization
    attr_accessor :name, :notes # Emulate has_many :notes

    def attributes
      { "name" => nil }
    end
  end

  class Note
    include ActiveModel::Serialization
    attr_accessor :title, :text

    def attributes
      { "title" => nil, "text" => nil }
    end
  end

irb> note = Note.new
irb> note.title = "Weekend Plans"
irb> note.text = "Some text here"

irb> person = Person.new
irb> person.name = "Napoleon"
irb> person.notes = [note]

irb> person.serializable_hash
=> {"name" => "Napoleon"}

irb> person.serializable_hash(include: { notes: { only: "title" }})
=> {"name" => "Napoleon", "notes" => [{"title" => "Weekend Plans"}]}

1.11.1 ActiveModel::Serializers::JSON

Active Model also provides the ActiveModel::Serializers::JSON module for JSON serializing / deserializing.

To use the JSON serialization, change the module you are including from ActiveModel::Serialization to ActiveModel::Serializers::JSON. It already includes the former, so there is no need to explicitly include it.

class Person
  include ActiveModel::Serializers::JSON

  attr_accessor :name

  def attributes
    { "name" => nil }
  end
end

The as_json method, similar to serializable_hash, provides a hash representing the model with its keys as a string. The to_json method returns a JSON string representing the model.

irb> person = Person.new

# A hash representing the model with its keys as a string
irb> person.as_json
=> {"name" => nil}

# A JSON string representing the model
irb> person.to_json
=> "{\"name\":null}"

irb> person.name = "Bob"
irb> person.as_json
=> {"name" => "Bob"}

irb> person.to_json
=> "{\"name\":\"Bob\"}"

You can also define the attributes for a model from a JSON string. To do that, first define the attributes= method in your class:

class Person
  include ActiveModel::Serializers::JSON

  attr_accessor :name

  def attributes=(hash)
    hash.each do |key, value|
      public_send("#{key}=", value)
    end
  end

  def attributes
    { "name" => nil }
  end
end

Now it is possible to create an instance of Person and set attributes using from_json.

irb> json = { name: "Bob" }.to_json
=> "{\"name\":\"Bob\"}"

irb> person = Person.new

irb> person.from_json(json)
=> #<Person:0x00000100c773f0 @name="Bob">

irb> person.name
=> "Bob"

1.12 Translation

ActiveModel::Translation provides integration between your object and the Rails internationalization (i18n) framework.

class Person
  extend ActiveModel::Translation
end

With the human_attribute_name method, you can transform attribute names into a more human-readable format. The human-readable format is defined in your locale file(s).

# config/locales/app.pt-BR.yml
pt-BR:
  activemodel:
    attributes:
      person:
        name: "Nome"

irb> Person.human_attribute_name("name")
=> "Name"

irb> I18n.locale = :"pt-BR"
=> :"pt-BR"
irb> Person.human_attribute_name("name")
=> "Nome"

1.13 Validations

ActiveModel::Validations adds the ability to validate objects and it is important for ensuring data integrity and consistency within your application. By incorporating validations into your models, you can define rules that govern the correctness of attribute values, and prevent invalid data.

class Person
  include ActiveModel::Validations

  attr_accessor :name, :email, :token

  validates :name, presence: true
  validates :email, format: { with: URI::MailTo::EMAIL_REGEXP }
  validates! :token, presence: true
end

irb> person = Person.new
irb> person.token = "2b1f325"
irb> person.valid?
=> false

irb> person.name = "Jane Doe"
irb> person.email = "me"
irb> person.valid?
=> false

irb> person.email = "jane.doe@gmail.com"
irb> person.valid?
=> true

# `token` uses validate! and will raise an exception when not set.
irb> person.token = nil
irb> person.valid?
=> "Token can't be blank (ActiveModel::StrictValidationFailed)"

1.13.1 Validation Methods and Options

You can add validations using some of the following methods:

• validate: Adds validation through a method or a block to the class.

• validates: An attribute can be passed to the validates method and it provides a shortcut to all default validators.

• validates! or setting strict: true: Used to define validations that cannot be corrected by end users and are considered exceptional. Each validator defined with a bang or :strict option set to true will always raise ActiveModel::StrictValidationFailed instead of adding to the errors when validation fails.

• validates_with: Passes the record off to the class or classes specified and allows them to add errors based on more complex conditions.

• validates_each: Validates each attribute against a block.

Some of the options below can be used with certain validators. To determine if the option you're using can be used with a specific validator, read through the validation documentation.

• :on: Specifies the context in which to add the validation. You can pass a symbol or an array of symbols. (e.g. on: :create or on: :custom_validation_context or on: [:create, :custom_validation_context]). Validations without an :on option will run no matter the context. Validations with some :on option will only run in the specified context. You can pass the context when validating via valid?(:context).

• :if: Specifies a method, proc or string to call to determine if the validation should occur (e.g. if: :allow_validation, or if: -> { signup_step > 2 }). The method, proc or string should return or evaluate to a true or false value.

• :unless: Specifies a method, proc or string to call to determine if the validation should not occur (e.g. unless: :skip_validation, or unless: Proc.new { |user| user.signup_step <= 2 }). The method, proc or string should return or evaluate to a true or false value.

• :allow_nil: Skip the validation if the attribute is nil.

• :allow_blank: Skip the validation if the attribute is blank.

• :strict: If the :strict option is set to true, it will raise ActiveModel::StrictValidationFailed instead of adding the error. :strict option can also be set to any other exception.

1.13.2 Errors

ActiveModel::Validations automatically adds an errors method to your instances initialized with a new ActiveModel::Errors object, so there is no need for you to do this manually.

Run valid? on the object to check if the object is valid or not. If the object is not valid, it will return false and the errors will be added to the errors object.

irb> person = Person.new

irb> person.email = "me"
irb> person.valid?
=> # Raises Token can't be blank (ActiveModel::StrictValidationFailed)

irb> person.errors.to_hash
=> {:name => ["can't be blank"], :email => ["is invalid"]}

irb> person.errors.full_messages
=> ["Name can't be blank", "Email is invalid"]

1.14 Lint Tests

ActiveModel::Lint::Tests allows you to test whether an object is compliant with the Active Model API. By including ActiveModel::Lint::Tests in your TestCase, it will include tests that tell you whether your object is fully compliant, or if not, which aspects of the API are not implemented.

These tests do not attempt to determine the semantic correctness of the returned values. For instance, you could implement valid? to always return true, and the tests would pass. It is up to you to ensure that the values are semantically meaningful.

Objects you pass in are expected to return a compliant object from a call to to_model. It is perfectly fine for to_model to return self.

• app/models/person.rb

  class Person
    include ActiveModel::API
  end
  

  Copy

• test/models/person_test.rb

  require "test_helper"
  
  class PersonTest < ActiveSupport::TestCase
    include ActiveModel::Lint::Tests
  
    setup do
      @model = Person.new
    end
  end
  

  Copy

See the test methods documentation for more details.

To run the tests you can use the following command:

$ bin/rails test

Run options: --seed 14596

# Running:

......

Finished in 0.024899s, 240.9735 runs/s, 1204.8677 assertions/s.

6 runs, 30 assertions, 0 failures, 0 errors, 0 skips