Forem: Main Street

Using Ruby Procs to improve readability

Manuel Ortega — Sat, 24 Apr 2021 12:12:52 +0000

We always try to avoid adding comments to our code. There may be some exceptions but ideally the code itself should clearly express what it is doing.

In this pursuit of code readability and expressiveness Procs are helpful in many scenarios. For example when we are dealing with a complex logic within a block we want to pass to a method (map, select, etc) from the Enumerable module.

Before

def self.error_messages(errors)      
  errors.map { |e| e.message.split(":")[3].strip rescue "" }.uniq.join(", ")
end

Let's focus on the block { |e| e.message.split(":")[3].strip rescue "" } we are passing to the map method. It is not extremely complex but still getting your head around it could take a while especially if it is the first time to face this code or functionally within an application.

After

def self.error_messages(errors)
  extract_readable_message = proc { |e| e.message.split(":")[3].strip rescue "" }
  errors.map(&extract_readable_message).uniq.join(", ")
end

This second version adding a Proc didn't change what the code does, but now anyone coming to these lines of code will easily understand not only what the code does but also why it does it.

What you think? Do you find this is worth it? Have you ever add a Proc as a way to improve readability?

The "What" and "Why" or How We are hiding those ugly IF's in our Service Objects

Manuel Ortega — Tue, 20 Apr 2021 10:32:24 +0000

We use Service Objects to encapsulate and organize business domain logic in our Rails applications. But how do we organize the "What" and "Why" within a single Service Object?

The "What" and "Why"? What do I mean? I hope the following code bites makes clear my point here.

Before

class Customers::CreateService < ApplicationService
  def initialize(customer_params)
    @customer_params = customer_params
  end

  def perform
    @customer = Customer.new(@assignment_params)
    if @customer.save
      sync_customer if TestApp.config[:sync_enabled]     
      create_qualified_notification if @customer.status_qualified?
      create_twilio_proxy_session if TestApp.config[:proxy_enabled]
      Result.new(@customer, true)
    else
      Result.new(@customer, false)
    end
  end

  private

  def sync_customer
    ...
  end

  def create_qualified_notification
    ...
  end

  def create_twilio_proxy_session
    ...
  end
end

As you can see in this before version of our Service Object we are mixing the "What" and "Why" within the perform public method. We are putting what the perform method does when a customer is created, for example, it creates a qualified notification, but we are also putting the "Why" here, it is, we are creating the qualified notification because the customer is being created with qualified status.

The "What" is what the Service Object does and the "Why" is the control-flow logic.

After

class Customers::CreateService < ApplicationService
  def initialize(customer_params)
    @customer_params = customer_params
  end

  def perform
    @customer = Customer.new(@assignment_params)
    if @customer.save
      sync_customer     
      create_qualified_notification
      create_twilio_proxy_session
      Result.new(@customer, true)
    else
      Result.new(@customer, false)
    end
  end

  private

  def sync_customer
    if TestApp.config[:sync_enabled]
      ...
    end
  end

  def create_qualified_notification
    if @customer.status_qualified?
      ...
    end
  end

  def create_twilio_proxy_session
    if TestApp.config[:proxy_enabled]
      ...
    end
  end
end

As you can see in the after version we are moving the control-flow logic, the "Why", to the private methods and keeping only the "What" in the perform public method:

 sync_customer     
 create_qualified_notification
 create_twilio_proxy_session

The argument for this is that anyone from our team or future me can read the perform method and reason about what it is trying to accomplish faster because it's just the "What".

Much of the credit goes to JP for recommending this "What" and "Why" separation in a code review

How to name Rails Concerns?

Manuel Ortega — Thu, 15 Apr 2021 18:28:57 +0000

Rails concerns are a handy technique to organize code / logic within your classes. But how do we name these Rails Concerns?

We usually follow these two conventions:

able suffix

We suffix Concerns with able when the object we are including the concern to is able to act or behave as the concern describes.

module Avatarable
  extend ActiveSupport::Concern
  ...

  included do
    ...
  end
  ...

end

The Concern above tells us that the class we include this concern to is able to act / behave as we would expect from an avatar.

We also follow this convention when we can execute the action that the concern describes to the object we are including the concern to.

module Subscribable
  extend ActiveSupport::Concern
  ...
end

In this case we are making clear we are able to subscribe to objects from the class we include this Subscribable Concern to.

has prefix

We prefix our Concerns with has when the logic we are trying to group within our Concern is not describing a behavior but a has relation between the class where we will include the Concern to and a second entity. In the following scenario we may have a User entity that has mentions within a blogging platform. At some point we may come up with a Concern that groups all the logic tied to a user having mentions.

module HasMentions
  extend ActiveSupport::Concern

  included do
    ...
  end
end

In case none of the conventions described above makes sense within a specific scenario we don't follow them and goes with whatever better describes what the concern groups together.

How do you name your Rails Concerns? What conventions do you follow?

Great Ruby Gems Most People Haven’t Heard About

Ronak Bhatt — Fri, 01 Jan 2021 06:39:34 +0000

What are the best Ruby gems that you can use in your Rails projects?

That’s what you’ll discover in this article!

I’m going to give you 7 gems, but not the same old gems that you’ve seen a million times, I’m going to be sharing with you some gems that are very helpful, but little-known.

But before we do that…

A warning.

I’ve seen developers that pull in a gem for just about everything.

If it remotely sounds like it could be helpful.

Without taking a moment to think if that gem solves the problem they have if it’s the best option, well-maintained & documented, etc.

That’s a mistake.

1. Find Dead Routes To Keep Your Code Clean

As your Rails application grows, you’ll accumulate more & more routes.

You’ll change code & some of these routes become stale.

No longer needed…

But they’ll stay there, in your config/routes.rb, making it harder to manage.

How do you find which routes to delete?

There is a gem called traceroute.

It loads your routes & compares them to the controller actions you’ve defined.

But right now it has two limitations:

It doesn’t work with Rails 6
It doesn’t detect implicit controller actions

You can find it here.

2. Make Your Migrations Safer So You Can Avoid Problems Rails migrations can cause a lot of problems if done wrong.

For example:

Removing a column can cause problems because Rails has a cache of columns, and running a migration doesn’t reset this cache.

Another example:

If you add an index & you’re running PostgreSQL the whole table gets locked until the operation is complete.

Not good for your users.

Your application won’t be able to respond to requests that need to work with a locked table.

The good news?

You don’t have to remember all of these things.

With the help of the strong_migrations gem, you’ll know when you have one of these unsafe migrations before it makes it into production.

You can find it here.

3. Find Your Slow Tests & Make Them Faster

Slow tests are no fun.

But there are tools to help you find why your tests are slow so you can fix them!

One of these tools is the combination of test-prof + ruby-prof.

Here’s how to use it:

TEST_RUBY_PROF=1 rake

Outputs:

%self       total       self         wait        child       calls   name
 43.21      2.001     2.001     0.000     0.000        1     Kernel#sleep
   2.97      0.184     0.138     0.000     0.046     1640   Array#permutation
   1.39      0.064     0.064     0.000     0.000      144   PG::Connection#async_exec

Here I can clearly see my call to sleep, but this could easily be an API call, reading a big file, a slow SQL query, etc.

Another thing you can do is to use the event profiler.

Btw, Rails 6 added parallel testing, you’ve to enable this in test/test_helpers.rb if you’re upgrading your current project.

4. Find Out Which Code Is Used In Production & Which Isn’t

Let’s finish with another tool to help you improve your code.

It’s called coverband.

If you run this gem in production (low overhead), you’ll get a coverage report of what code is being run.

You can even track unused views!

This can help you make decisions when deleting code & cleaning your project.

Don’t let unused code build up!

You can find it here.

Thanks for reading!
I hope that helps someone. Thanks :).

I’d love to hear thoughts or comments around this. Feel free to email me at ronakabhattrz@gmail.com or hit me up on Twitter, @ronakabhattrz .

What is the Difference between Ruby Blocks, Procs and Lambdas

Ronak Bhatt — Fri, 13 Nov 2020 09:20:36 +0000

Having a problem understanding the difference between ruby blocks, procs and lamdas. What are the blocks? What is the difference between procs and lambdas? Let's break this down.

BLOCKS:

A block is a collection of code enclosed in a do/end statement or between braces { }. They are chunks of code that you can pick up and drop into another method as input or chunk of code that you associate with a method call. If you have used each before to loop through an Enumerable then you have used blocks.

Defining a block

def block_method
  puts "we are in the method"
end

block_method { puts "The block is called"}

PROCS

So what if you want to pass two blocks to your function. How can you save your block into a variable?
Ruby introduces procs so that we are able to pass blocks around. Proc objects are blocks of code that have been bound to a set of local variables.Once bound, the code may be called in different contexts and still access those variables.

Defining procs

You can call new on the Proc class to create a proc . You can use the kernel object proc. Proc method is simply an alias for Proc.new. This can be assigned into a variable.

factor = Proc.new {|n| print n*2 }

or 

factor = proc {|n| print n*2}

//using the proc value

[3,2,1].each(&factor)

>642

LAMBDAS

Can be defined using the method lambda or can be defined as stuby lambda

lamb = lambda {|n| puts 'I am a lambda' }
lamb = -> (n) { puts 'I am a stuby lambda' }

Difference between Procs and Lambdas

Procs don’t care about the correct number of arguments, while lambdas will raise an exception.

Return and break behaves differently in procs and lambdas
Next behaves same way in both procs and lambdas

References

rubyguides.com : Click Here!!!!

I hope that helps someone. Thanks :).

Thanks for reading. 🙂

I’d love to hear thoughts or comments around this. Feel free to email me at ronakabhattrz@gmail.com or hit me up on twitter, @ronakabhattrz .

Rails 6, Stimulus events

Ronak Bhatt — Tue, 27 Oct 2020 12:54:57 +0000

An action is a connection between:

a controller method
the controller’s element
a DOM event listener

gallery_controller.js

// controllers/gallery_controller.js
import { Controller } from "stimulus"

export default class extends Controller {
  next(event) {
    alert("Justclick !!! :")
  }
}

View File Setup

<div data-controller="gallery">
  <button data-action="click->gallery#next">…</button>
</div>

Descriptors

The data-action value click->gallery#next is called an action descriptor. In this descriptor:

click is the name of the DOM event to listen for
gallery is the controller identifier
next is the name of the method to invoke

The full set of these shorthand pairs is as follows:

I hope that helps someone. Thanks :).

Thanks for reading. 🙂

I’d love to hear thoughts or comments around this. Feel free to email me at ronakabhattrz@gmail.com or hit me up on twitter, @ronakabhattrz.

How to Use Scopes in Ruby on Rails

Ronak Bhatt — Thu, 15 Oct 2020 07:24:53 +0000

Scopes are custom queries that you define inside your Rails models with the scope method.

Every scope takes two arguments:

A name, which you use to call this scope in your code
A lambda, which implements the query

It looks like this:

class User < ApplicationRecord
  scope :active, -> { where("status: 0") }
end

As a result of calling a scope, you’ll get an ActiveRecord::Relation object.

Which means you can chain & combine scopes!

Example:

User.active

When To Use Scopes?

Let’s see an example.

def index
  @books = Book.where("LENGTH(title) > 20")
end

This is an index controller action that wants to display books with titles longer than 20 characters.

It’s fine.

But if you want to use this query in other places, you’re going to have duplicated code.

Duplicated code makes your project harder to maintain.

Let’s move this query into a scope.

Like this:

class Book
  scope :with_long_title, -> { where("LENGTH(title) > 20") }
end

Now our controller action looks like this:

def index
  @books = Book.with_long_title
end

Summary
Good job! As a result of reading this article, you’ve learned how to use Rails scopes in the most effective way.

Don’t forget to put this new knowledge into practice so you can remember how it works.

Thanks for reading. 🙂

I’d love to hear thoughts or comments around this. Feel free to email me at ronakabhattrz@gmail.com or hit me up on twitter, @ronakabhattrz.

Rails 6, Stimulus and Select2

Ronak Bhatt — Wed, 02 Sep 2020 09:01:24 +0000

This is just a quicky, to help out anyone using Rails 6, or any Stimulus-enabled Rails project and Select2, the amazing jQuery plugin for better select boxes.

add select2 & select2-bootstrap-theme package in web-pack

yarn add select2
yarn add select2-bootstrap-theme

Simple Select2 + Stimulus Controller

select2_controller.js

import { Controller } from "stimulus"
import $ from 'jquery';

require("select2/dist/css/select2")
require("select2-bootstrap-theme/dist/select2-bootstrap")

import Select2 from "select2"

export default class extends Controller {
  connect() {
    $('.content-search').select2();
  }
}

Replace f.select dropdown according to select2 specifications

<div class="form-group" data-controller='select2'>
  <%= f.select :user_id, User.all.map { |user| user.name }, {include_blank: false, required: true, include_hidden: false}, class: 'form-control content-search' %>
</div>

I hope that helps someone. Thanks :).

I’d love to hear thoughts or comments around this. Feel free to email me at ronakabhattrz@gmail.com or hit me up on Twitter, @ronakabhattrz.

Tables and other Advanced Formatting in Action Text (Kind of)

John Jacob — Fri, 07 Aug 2020 22:12:06 +0000

I work on an in house Learning Management system built in Rails. This Learning Management system allows our content team to create articles, videos and quizzes. This content is delivered through lessons for new business owners. Through these tracks they learn all they need to learn to start and run new service businesses.

Since were on rails and we needed rich text editing we reached for Action Text. Action Text gives you the solid Trix editor plug and play in your app.

Rails Action Text in Practice in our Content Library Back-end

However: Action Text / Trix doesn't support tables.

Our content team had lots of tables of information they wanted to be able to communicate. Sometimes it's hard to get across nuanced information for estimating and process without a table. We realized we needed table support in Action Text / Trix.

First Direction — Action Text Attachments

My first path was to extend the Action Text attachment model. This is what the team at Timelapse documented. Although they provided some good direction, there was nothing I could directly leverage. Also, this seems like a lot of front end complexity for a v1 of a product. Was looking for something similar. In this research I found this great Rails Conf video from Chris Oliver of Go Rails, a strongly recommended resource on Action Text attachments in general. However, decided against doing something so front end heavy (for now).

The Crazy Idea that worked: Render Code-blocks as HTML

Since this project didn't ever need a "Code Block" these articles render to a non-technical audience, why not allow any valid HTML written in a code block to render as HTML.

Pros:

No extra front end work
Simple Extension of the Article Decorator
Very maintainable portable simple content (Just HTML)

Cons:

Your users have to be reasonably technical to update HTML code-blocks
You don't get a WYSIWYG interface when editing content

I put a rough prototype and did a screen recording to get my colleagues thoughts.

Execution

All credit goes to the great Manuel Ortega for actually making my crazy idea work, he was able to build a clean implementation that solved many of the pitfalls my prototype was riddled with.

It all essentially boils down to one plain ol' ruby object — this Richtext::CodeBlocks::HtmlService object:


class Richtext::CodeBlocks::HtmlService
  ALLOWED_HTML_TAGS = ["table", "tr", "td", "th", "col", "pre", "p", "h1", "h2", "h3", "summary", "details", "row", "code"]
  ALLOWED_HTML_ATTRIBUTES = []

  # To Validate HTML tags and protect from bad formatted input
  def self.validate(html)
    errors = []
    html = Nokogiri::HTML::DocumentFragment.parse(html)
    html.search("pre").each do |pre_tag|
      pre_tag_html, pre_tag_errors = self.ensure_well_formed_markup(pre_tag.text)
      errors.push(pre_tag_errors) unless pre_tag_errors.empty?
      inner_html = self.extract_inner_html_from_pre_tag(pre_tag_html)
      inner_html = self.remove_not_allowed_tags_and_attributes(inner_html)
      pre_tag.children.first.replace(Nokogiri::XML::Text.new(
        inner_html,
        pre_tag
      ))
    end
    html = ActionText::Fragment.new(html)
    [html.to_html, errors.flatten.uniq]
  end

  # To parse each code block tag and render it to HTML
  def self.render(rich_text)
    html = Nokogiri::HTML::DocumentFragment.parse(rich_text)
    html.search("pre").each do |pre_tag|
      inner_html = Nokogiri::HTML::DocumentFragment.parse(pre_tag.text)
      inner_html = add_styles_to_tables(inner_html)
      advanced_code_block = "<div class='advanced-code-block'>#{inner_html.to_html}</div>"
      pre_tag.replace(advanced_code_block)
    end
    html.to_html
  end

  private

  def self.ensure_well_formed_markup(html)
    parsed = Nokogiri::XML("<pre>#{html}</pre>")
    [parsed, parsed.errors]
  end

  # To add our bootstrap specific classes to table elements
  def self.add_styles_to_tables(html)
    html.search("table").each do |table|
      table["class"] = "table"
      table.wrap("<div class='table-responsive'></div>")
    end
    html
  end

  def self.extract_inner_html_from_pre_tag(html)
    Nokogiri::XML(html.at("pre").inner_html)
  end

  # To add error messages to mis-formatted HTML
  def self.error_messages(errors)
    readable_message = ->(e) { e.message.split(":")[3].strip rescue "" }
    errors.map {|e| readable_message.call(e) }.uniq.join(", ")
  end

end

Using the HtmlService

You can just add a method in the article model:

def formatted_body
  Richtext::CodeBlocks::HtmlService.render(self.body.to_s).html_safe
end

and then call it in the view

  <%= @article.formatted_body %>

Screenshots

Here's the example of the editor with code blocks:

Here's the example output of that article:

Here's example validation being thrown to prevent you from saving bad HTML.

In Production

Obviously this repo is a very limited example, but used well in production with an extended CSS framework this can be pretty powerful in practice:

Github Repo

This is just a basic demo rails app using this approach. Excited to get feedback from anyone else looking to explore a feature like this.