Rails Tricks Issue 2: Console Tricks
Hi, this is Greg with the second issue of Rails Tricks!
Thanks to everyone for subscribing!
This week, I want to share a few Rails console tricks I use regularly. The first one is the _ command, which always holds the return value of the last evaluated command in IRB, which is the default for Rails` console. For instance, if you run an Active Record query to find a record, then you realize that you want to keep the result around, you can easily assign it to a variable:
Another thing I regularly do is, to look up the definition of methods or the location of their definition. This comes in handy when you are debugging an issue and can be helpful to see what a method actually does or where it is defined.
Because maybe a gem overrides it, and that causes unexpected behavior. In a Rails console, to see the definition, you can use Object.method(:name).source:
And if you want to verify that all is defined in Active Record and nothing overrides it in your application, you can check the location of the definition:
The source method is actually added by a gem called methodsource, which was part of Rails between 7.1, but it will be removed with that release, so if you still want to be able to see the definition of methods in your console, you will need to add that gem to your Gemfile.
The next thing I want to share is the --sandbox option. If you pass this option when you start your console, every database modification will be rolled back on exit.
This can be useful when you are debugging something in production, and you want to make sure you are not messing up something accidentally.
And the final thing is to have some fun! Type IRB.send(:easter_egg, :dancing) or IRB.send(:easter_egg, :logo) in your IRB session and enjoy the result!
You can exit by pressing CTRL+C.
P.S.: I just came across this blog post recently from Jemma about the measure command in IRB: https://jemma.dev/blog/irb-measure.
This week I have a special guest trick:
Hello there, I'm Adrian, the author of Avo, and I'm excited to share a neat trick with you today. In this tutorial, I'll be demonstrating how to attach hooks and business logic to Avo's controllers using a Current model.
You may already be familiar with Rails' Current model, which is used to set the current user, multi-tenancy accounts, or other pieces of information. Typically, before_action is used in your ApplicationController to demonstrate how Current works. However, if you attempt to apply the same changes to your app the action will not work in Avo's context. This is because Avo has its own AplicationController.
So how do we apply this behavior inside Avo? Let me walk you through it.
Firstly, we configure the Current model and create the concern that holds the business logic.
Next, we add this concern to Avo's ApplicationController using Rails' to_prepare hook:
With this setup, our Authentication concern will be applied to the Avo::ApplicationController, and it will be executed within Avo's context.
This technique can also be applied to other classes, such as including all helpers inside Avo's field declarations:
By following these steps, you can now use your own extensions in your Avo resources. I hope this short tutorial helps you write better Avo resources and ship code faster.
Adrian ✌
That’s it for this week, see you next time!
Greg