You are developing your first Rails app, which is most likely a Blog - we all have been there :).
At some point, you end up with a controller created by scaffold, which looks more or less, like this:
class PostsController < ApplicationController
before_action :set_post, only: %i[ show edit update destroy ]
# GET /posts or /posts.json
def index
@posts = Post.all
end
# GET /posts/1 or /posts/1.json
def show
end
# GET /posts/new
def new
@post = Post.new
end
# GET /posts/1/edit
def edit
end
# (...) update create and destroy actions are hidden
# for the sake of readability
private
# Use callbacks to share common setup or constraints between actions.
def set_post
@post = Post.find(params[:id])
end
end
Rails generated set_post method, and even tells you to Use callbacks to share common setup or constraints between actions.
The code is DRY as it can be, you have a nice looking before_action, so it must be the famous Rails way of doing things - and it is.
However some developers (including me) are writing code in a different way.
Why?
Let's assume, that we stick to Filters (it is the official name of this feature despite the fact, that scaffold is calling it callback) - after implementing additional functionalities we can end up with something like this:
class PostsController < ApplicationController
before_action :set_post, only: %i[ show edit update destroy ]
before_action :set_user, only: %i[ edit update ]
before_action :check_admin, only: :destroy
after_action :send_email, only: %i[ update destroy ]
# GET /posts or /posts.json
def index
@posts = Post.all
end
# GET /posts/1 or /posts/1.json
def show
end
# GET /posts/new
def new
@post = Post.new
end
# GET /posts/1/edit
def edit
end
# (...)
end
Reading edit action has just become a bit harder, because you ended up with an empty action, which is in fact does quite a lot of things.
So in order to understand what is going on there you have to jump back and forth between the filters. And this is relatively simple action - you can image what happens, when the app grows.
What is the 'right' way?
Alternative approach is actually really simple - just call the method inside the action. That's it.
Then you end up with code like this:
class PostsController < ApplicationController
# GET /posts or /posts.json
def index
@posts = Post.all
end
# GET /posts/1 or /posts/1.json
def show
set_post
end
# GET /posts/new
def new
@post = Post.new
end
# GET /posts/1/edit
def edit
set_post
end
# (...) update create and destroy actions are hidden
# for the sake of readability
private
# Use callbacks to share common setup or constraints between actions.
def set_post
@post = Post.find(params[:id])
end
end
Now, at first glance at edit or show action you know which method is called.
Got it - let's forget about Action Filters
Actually, not really - they are used for authentication / authorization - you will more than once see code like this, especially when working with devise gem:
class PostsController < ApplicationController
before_action :authenticate_user!
end
Wrap up
If you are not dealing with authentication / autorization try avoiding using Action Filters (referred by some as ''callbacks'') - they make code harder to read.
Check my Twitter
Check my Linkedin
