Ruby Archives - Page 40 of 117

It's not really often that you don't know what will be in a block. Especially when you plan to nest blocks multiple times. However things like this happen...

Typical nested blocks

Here's a "typical" example of nested blocks:

class TimeBenchmarkWrapper
  def monitor
    time = Time.now
    yield
    ms = (Time.now - time) * 1000
    print "#{TimeBenchmarkWrapper}: Time taken: #{ms}ms\n"
  end
end

class LoggerWrapper
  def monitor
    print "#{LoggerWrapper}: logging something\n"
    yield
  end
end

class AroundFilterWrapper
  def monitor
    return unless before_action
    yield
    after_action
  end

  def before_action
    print "#{AroundFilterWrapper} before logic\n"
  end

  def after_action
    print "#{AroundFilterWrapper} after logic\n"
  end
end

class ExampleClass
  def execute
    # Here should the code go
    print "#{ExampleClass} executing...\n"
  end
end

time = TimeBenchmarkWrapper.new
logger = LoggerWrapper.new
around = AroundFilterWrapper.new

logic = ExampleClass.new

around.monitor do
  logger.monitor do
    time.monitor do
      logic.execute
    end
  end
end

The code above is really simple. It just wraps around a business logic with some monitors (logger, benchmark, around filter). But...

Reordering, rearranging, dynamic number of nested blocks

Everything is awesome until we decide to to have a dynamic order and amount of nested blocks that perform some sort of logic around our business logic.

Let's say that I would like to do something like this:

wrappers = [ClosestWrapper, MiddleWrapper, OuterWrapper]

wrapped_block = wrap_with(wrappers) do
  # The "proper" business logic
  logic.execute
end

In the wrappers array we would like to have all the wrappers that we want to use in a given order. And then the magical method wrap_with should somehow nest all the blocks. So how can we achieve such a behaviour?

Multiple blocks injecting

The solution to this problem is quite simple: defining blocks that accept block parameter and them injecting one into another. If you don't understand the code, please read to comments in the code - they explain all the details:

def wrap_with(wrappers, &block)
  # We define the most bottom block - that should evaluate the real code
  # All the blocks are in array because we will use inject to inject one into another
  # and since we will be injecting first into second, second into third, etc
  # our "base" proc needs to be first (it will be the most inner block)
  blocks = [-> { block.call } ]

  # Each wrapper needs to be wrapped with a proc that accepts a inner block containing
  # stuff that should be inside - this inside stuff is a proc as well and
  # will be executed. That's why when we execute the most outer block if will execute
  # the inner one (and it will happen as a cascade)
  blocks += wrappers.map do |wrapper|
    proc do |inner_block = nil|
      wrapper.new.monitor do
        inner_block.call
      end
    end
  end

  # In general it is equal to a code like this (but generated dynamically):
  # We assume that we have following monitors: [Monitor1, Monitor2, Monitor3]
  # Monitor3.new.monitor do
  #   Monitor2.new.monitor do
  #     Monitor1.new.monitor do
  #       proxy.call(*args, &block)
  #     end
  #   end
  # end
  blocks.inject do |inner, resource|
    proc { resource.call(inner) }
  end.call
end

# Example usage - now we can change order and amount of wrappers
# and everything will still work
wrappers = [TimeBenchmarkWrapper, LoggerWrapper, AroundFilterWrapper]

wrap_with(wrappers) do
  ExampleClass.new.execute
end

If you still don't get it, here's an illustration of how the blocks are injected:

Performance impact

Below you can see, that from 1 to 100 nested blocks, "automated" nested blocks perform around 2.5-3 times slower than a standard Ruby code. The more nestings you have the slower it gets. The generated nestings are slower mostly because they use more resources for managing (storing, handling) more blocks.

Conclusion

If the performance is not your primary goal and you prefer visibility and flexibility over it, then the auto-generated block approach is definitely better. However it is still worth keeping in mind, that even with normal blocks, the more of them we have the slower it gets.

Benchmark sources: github.com/mensfeld/benchmarks/tree/master/Ruby-dynamic-nested-blocks

For some reason not many RoR developers know that they can extend ActiveRecord associations. This feature can be a great way to cleanup any relational code that is dependent on a parent resource (or to just add a simple functionalities to scopes). Here's a really simple example how you can use it:

class User < ActiveRecord::Base
  module GroupActions
    # Here you work on a scope
    def reactivate!
      # I know we could use update_all - this is not the case ;)
      map(&:reactivate!)
    end
  end

  belongs_to :group

  def reactivate!
    update!(active: true)
  end
end

class Group < ActiveRecord::Base
  has_many :users, extend: User::GroupActions
end

That way you can perform actions like this one:

# Looks much better than any method like current_group.reactivate_users!
current_group.users.reactivate!

Dynamic pagination (changeable per page on a parent resource)

You can also use a small trick to access parent model and it's data. It can be useful for example when implementing a dynamic pagination model (based on a parent key value) or any other functionality that somehow depends on a relation owning model. Instead of doing something like this in your controllers:

def index
  @pictures = current_gallery.pictures.per(current_gallery.per_page).page(current_page)
end

you can leave the implementation details out of it (which in general is a good idea):

def index
  @pictures = current_gallery.pictures.paginated(current_page)
end

And this is how you can achieve such a behavior:

class Gallery < ActiveRecord::Base
  has_many :pictures,
    extend: Picture::RelationExtensions

  validates :per_page,
    numericality: { only_integer: true },
    inclusion: { in: (1..100).to_a }
end

class Picture < ActiveRecord::Base
  module RelationExtensions
    def paginated(current_page)
      # We create a picture instance that has a gallery reference already
      # because in the controller - gallery is a current scope starting point
      page(current_page).per(self.new.gallery.per_page)
    end
  end

  belongs_to :gallery, inverse_of:  :pictures
end

It's a really great idea to use approach like this also because you can use it with any standard scope:

current_gallery.active.paginated(current_page)
# or if you return an active record association you can chain methods
current_gallery.active.paginated(current_page).reactivate!

Conclusion

If you want to hide implementation details of any association related action (especially when it uses owning model fields data), using ActiveRecord association can be a really good idea.

Category: Ruby

Ruby: Auto-generated dynamic nested blocks wrappings for Ruby and its performance

Typical nested blocks

Reordering, rearranging, dynamic number of nested blocks

Multiple blocks injecting

Performance impact

Conclusion

Extending ActiveRecord association to cleanup your associations code

Dynamic pagination (changeable per page on a parent resource)

Conclusion