Tag: gem

Rails + Responders + Trailblazer – Flash messages with proper model names from Trailblazer operations

Responders gem is really awesome. It sets flash message based on the controller action and resource status allowing you to dry up your Rails controllers. Trailblazer is a thin layer on top of Rails. It gently enforces encapsulation, an intuitive code structure and gives you an object-oriented architecture. When combining both of them together, you can achieve really slim and functional controllers:

class ContractsController < BaseController
  def index
    respond_with(collection Contracts::Index)

  def show
    respond_with(present Contracts::Update)

  def new
    respond_with(form Contracts::Create)

  def create
    respond_with(run Contracts::Create)

  def edit
    respond_with(form Contracts::Update)

  def update
    respond_with(run Contracts::Update)

  def destroy
    respond_with(run Contracts::Destroy)

Unfortunately there's one downside: Since Responders #respond_with method expects a model as a first argument, it will think that your operation is a model (if you return it the way I did) and try to figure out it's human name. Probably it won't end up as you expect and you will see a message similar to this one:

Users/campaigns/update was successfully updated.

It happens because of this piece of code from Responders:

resource_name = if resource.class.respond_to?(:model_name)

Trailblazer operations don't respond to #model_name, that's why all the operations will be translated using the else statement. To make it work as expected, we just need to implement the #model_name class method:

class ApplicationOperation < Trailblazer::Operation
  def self.model_name

I follow the ApplicationController, ApplicationRecord, ApplicationHelper "pattern" also with operations. That way I don't need to add this code into Trailblazer::Operation or into each of the operations separately. #model_class method is a method that will return the model class that we've set using Trailblazer::Operation #method:

class Operation < ApplicationOperation
 include Model
 model Contract

Operation.model_class #=> Contract
Operation.model_name #=> ActiveModel::Name:0x0000000575b778 @name="Contract"...

From now on, all the Trailblazer operations will introduce themselves to Responders with the name of the model on which we operate.

Envlogic – Ruby gem to have a Rails.env like environment behaviour in your non Rails Ruby applications

Envlogic is a simple gem that will help you manage your Ruby application environment. You can use it instead of a really popular solution like this one:

class App
  def self.env
    ENV['APP_ENV'] || ENV['RACK_ENV'] || 'development'

How does it work?

Well it uses Rails String Inquirer and a bit of magic to resolve the environment key name. It will try to figure out the ENV key on its own, and if it fails it will fallback to development. To use it, just extend your class/module with Envlogic module:

Class MyApp
  extend Envlogic

MyApp.env #=> 'development'
MyApp.env.production? #=> false
MyApp.env.development? #=> true

ENV key name resolving

Envlogic will try to guess the key n few steps:

  • First it will try to guess the key based on the root directory name of your app. If it is called my_app - the key will be MY_APP_ENV (ENV['MY_APP_ENV'])
  • If this fails, it will try to resolve the class/module name in which it is - MyApp will be converted to MY_APP_ENV. It is worth pointing out, that this will also work for namespaced elements, so key for My::SuperApp will be equal to MY_SUPER_APP_ENV
  • It will try RACK_ENV as well
  • And finally will fallback to development

Where can I use it?

Anywhere outside of Rails app (it has a mechanism like this already built it). Just include this gem in your Gemfile and extend your class with it:

gem 'envlogic'

Can I safely replace my string solution with this one?

Yes. The env object (Envlogic::Env) behaves mostly like a typical string, so if you used to compare the env like this:

MyApp.env == 'production'

it will keep working as nothing would happen.

Few simple examples

Based on the app class name:

class MyApp
  extend Envlogic

ENV['MY_APP_ENV'] = 'production'

MyApp.env.production? #=> true
MyApp.env.development? #=> false
MyApp.env.test? #=> false

Based on the app dir name (/home/apps/super_app):

class App
  extend Envlogic

ENV['SUPER_APP_ENV'] = 'production'

App.env.production? #=> true
App.env.development? #=> false
App.env.test? #=> false

Based on the namespaced class name:

class Ux::App
  extend Envlogic

ENV['UX_APP_ENV'] = 'production'

Ux::App.env.production? #=> true
Ux::App::App.env.development? #=> false
Ux::App.env.test? #=> false

Copyright © 2024 Closer to Code

Theme by Anders NorenUp ↑