DEV Community: Deepak Singh

Rails Action Pack Variants

Deepak Singh — Mon, 06 Aug 2018 16:43:56 +0000

Recently on one of the projects at Eloquent Studio, I needed to render two very different view templates for desktop and mobile, even Bootstrap responsive design did not fit the requirement.

A little hesitant to roll out a custom solution for such a common requirement, I did some google searches and struck up the RailsGuides. ActionPack Variants is just what I was looking for. ActionPack Variants is a specialisation of request format. Released with Rails 4.1, the api was later improved to its current state in Rails 5 as per this PR

Within the controller action's respond to block

# app/controllers/patterns_controller.rb
before_action :set_variant, only: :show

def show
  format.html do |html|
    html.phone
    html.tablet
  end
end

private

def set_variant
  case request.user_agent
    when /iPad/i
      request.variant = :tablet
    when /iPhone/i
      request.variant = :phone
    when /Android/i && /mobile/i
      request.variant = :phone
    when /Android/i
      request.variant = :tablet
    when /Windows Phone/i
      request.variant = :phone
  end
end

And setup view templates as

# app/views/patterns/show.html.erb

# Show page for desktop view

# app/views/patterns/show.html+tablet.erb

# Show page for tablet view

# app/views/patterns/show.html+phone.erb

# Show page for phone view

Not just devices, variants can be used for more varied use cases, like rendering different view templates based on user roles.

CoverImage Credits: https://unsplash.com/@bugsster

Clean Validations with Custom Contexts

Deepak Singh — Wed, 01 Aug 2018 10:29:50 +0000

Active Record validations are a well-known and widely used in Rails.

class User < ApplicationRecord
  validates :name, presence: { message: "must be given please" }
end

This runs the validation on save, both when creating a new record or when updating an existing record.

on option allows control over when to run the validation, commonly used with value of create or update

class User < ApplicationRecord
  belongs_to :club, optional: true 
  validates :name, presence: { message: "must be given please" }, on: :create
  validates :club, presence: { message: "must be given please" }, on: :update  
end

This allows creating users without associating them with a Club, but enforces presence of Club on subsequent updates. This pattern is commonly used to allow users to signup with bare minimum form fields and then forcing them to update their profiles with more information on subsequent visits.

Value for the on option is not limited to create and update, we can have our own custom contexts. Like in a multistep form, we can have validations for each of the steps. on options makes this really easy to do

class User < ApplicationRecord
  validate :basic_info, on: :basic_info
  validate :education_details, on: :education_details
  validate :professional_info, on: :professional_info

  private
  def basic_info
    # Validation for basic info, first_name, last_name, email
  end

  def education_details
    # Validation for education_details
  end

  def professional_info
    # Validation for professional_info
  end
end

In the controller

class UsersController < ApplicationController
  ...

  def update_basic_info
    @user.assign_attributes(basic_info_params)
    @user.save(:basic_info)
  end

  def update_education_details
    @user.assign_attributes(education_details_params)
    @user.save(:education_details)
  end

  def update_professional_info
    @user.assign_attributes(professional_info_params)
    @user.save(:professional_info)
  end

  private
  def basic_info_params
    # strong params
  end

  def education_details_params
    # strong params
  end

  def professional_info_params
    # strong params
  end
end

With Rails 5 adding support for multiple contexts, we can use multiple context together

@user.save(:basic_info, :professional_info)

This seems pretty neat, let's go a step further and do this with update_attributes. In current implementation of Rails,
update_attributes does not support validation contexts. We can get around this by defining our own custom method

class ApplicationRecord < ActiveRecord::Base
  self.abstract_class = true

  def update_attibutes_with_context(attributes, *contexts)
    with_transaction_returning_status do
      assign_attributes(attributes)
      save(context: contexts)
    end
  end
end

In the controller

@user.update_attibutes_with_context({first_name: 'fname'}, :basic_info)

Lastly, we can use with_options to group multiple validation within a context

  with_options on: :member do |member_user|
    member_user.validates :club_name, presence: true
    member_user.validates :membership_id, presence: true
  end

This makes really easy to write readable and maintainable code, with a good separation of concerns.

Read my last post on ActiveRecord Validations here https://dev.to/spidergears/rails-active-record-validation-messages-4dcf

Better Rails Active Record Validation Messages

Deepak Singh — Tue, 17 Jul 2018 22:07:06 +0000

Validations are used to ensure that only valid data is saved to database and no business rules are violated. For example, it may be important for business to ensure that users provides a valid email address and phone number. Model-level validations are the most common way (db-level constraints is another option) to achieve this. Model-level validations are database agnostic, simple to test and maintain. Rails makes this more fun with built-in helpers and support for custom validations.

All that being done, the next crucial step is to provide users with immediate feedback as they use your site. Rails allows to do just that with the :message option. It specifies the customised error message that will be added to the errors collection when the validation fails.

The :message option accepts a string or a proc.

When using strings, rails provides placeholder/interpolation variables to help add context and reduce cognitive load.
- %{value}
- %{attribute}
- %{model} Use them in the message string as,

validates :age, numericality: { message: "%{attribute} must be a number" }

Age must be a number feels much better than must be a number.

Using procs adds more flexibility and logic to the message string. Proc has access to the object being validated and a data hash with keys model, attribute and value, same as the interpolation variable above.

validates :username,
    uniqueness: {
      message: ->(object, data) do
        "Hey #{object.name}!, #{data[:value]} is taken already!"
      end
    }

validates :score,
    presence: {
      message: ->(object, data) do
        if object.member?
          "something"
        else
          "Something else"
        end    
      end
    }

Magic does not end here, rails also allows overriding default validation messages via i18n-localization files.

en:
  activerecord:
    errors:
      models:
        user:
          attributes:
            firstname:
              blank: "custom message, can\'t be blank"

Active Record provides couple of namespaces where message translations can be placed in order to provide different messages and translation for certain models, attributes, and/or validations. It also transparently takes single table inheritance into account.

Also placeholder/interpolation variables are still available.

en:
  activerecord:
    errors:
      models:
        user:
          attributes:
            firstname:
              blank: "Please fill in your %{attribute}"

http://guides.rubyonrails.org

Further, ActiveModel::Errors#full_messages prepends the attribute name to the error message using a separator that is looked up from errors.format (and defaults to %{attribute} %{message}). This too can be customised as

en:
  errors:
    # format to use in full error messages.
    format: "%{message} %{attribute}"

Dev.pun

Deepak Singh — Thu, 28 Jun 2018 16:00:37 +0000

Code for Humans

Deepak Singh — Fri, 22 Jun 2018 13:10:09 +0000

white-spaces are code too...

It's great, your code works in production and is fast enough.
Congratulation, but...

Is it readable enough?
How easy is it for a new developer to pick it up and make all the sense?
Does reading through the code present a good mental model of the system built?

This not an exhaustive list, but if answer to any of the above question is NO, then you should consider revisiting and making a few cosmetic changes.

Here are a few pointers that I follow when writing/reading code

white-spaces

- white-spaces are code too


leave a blank line between method definitions
a blank line when there is a changes in context within method body

indentation

- indent code well
follow consistent indent length, 2 spaces or 4 spaces
be consistent with use of tabs or spaces, choose one and stick to it across the team(s)

variable and method naming

- use concise and meaningful names
variable names should reflect the value they refer
method names should reflect the process / business logic contained

documentation

- unless it is a framework, module, class, method, variable names should be self documenting without need of additional documentation
comments should not be a tool to justify messy code segments

design the code

- every code is a piece of art uniquely conceived by it's developer
visualise the interactions between objects before beginning to code
visualise message exchanges needed before beginning to code

right abstraction

- abstraction does not mean hiding the complexity detail
know the behavioural traits to model
have a api spec to refer to
know before hand methods, variables, constants to expose
do not make decisions based on speculations
requirements are the corner stone

language idioms

- make use of language idioms
Ruby Example: [1, 2, 3, 4].sum  v/s  [1, 2, 3, 4].each {|ele| sum = sum + ele}

Code for Humans

Cover Image Credit: Unsplash

Dev.to tech-stack

Deepak Singh — Fri, 22 Jun 2018 07:50:44 +0000

I was initially drawn to dev.to after reading a ~~medium~~ dev.to article about how fast the platform is. I would like to know more on the architecture and infrastructure involved, helping dev.to stay up everyday.