Since I started working with , and after several years of using it passed by, I can’t stop wondering when I discover something new in world. Yes, this is how it works — you know, is for developer happiness (beyond this there are some other principles) and each year of using it and finding out new stuff supports this feeling inside. Ruby on Rails Ruby Ruby Ok, so this article shares a bunch of stuff I discovered recently. They are rarely used methods and not a must-have in your code, mostly “syntax sugar”, but anyway it will make your code much cleaner. Some stuff is just new changes appeared with new or versions. Ruby Rails Hash#dig I didn’t meet this in anyone’s code for 7 years of RoR development and discovered recently. And it’s obvious why :-) The first version I worked with was 1.8, but this method was introduced in 2.3. Ruby How many times did you do something like this: ... if params[:user] && params[:user][:address] && params[:user][:address][:somewhere_deep] Think of as kind of safe navigation operator but for objects. So now you could rewrite such things: dig &. Hash ... if params.dig(:user, :address, :somewhere_deep) Object#presence_in This one I found in the very good article about . It allows you to replace conditionals (often ternary) with single method call when you don’t actually need a boolean result of inclusion check, but a checked object itself. For example, your code looks like: Query Objects in Ruby on Rails sort_options = [:by_date, :by_title, :by_author]... sort = sort_options.include?(params[:sort])? params[:sort]: :by_date # Another optionsort = (sort_options.include?(params[:sort]) && params[:sort]) || :by_date Doesn’t this look better? params[:sort].presence_in(sort_options) || :by_date Module#alias_attribute Well, I found this very useful when I worked on a project with a legacy database. It had a table with weird column names like , and other. We mapped this table to an model and instead of writing queries and scopes on it like , we came up to using since it doesn’t just generate getter and setter (as well as a predicate method), but works in queries as well: SERNUM_0 ITMDES1_0 ActiveRecord WeirdTable.where(SERNUM_0: ‘123’) alias_attribute alias_attribute :name, :ITMDES1_0...scope :by_name, -> (name) { where(name: name) } Object#presence This one is more popular than others. There’s pretty good explanation on . So, is equivalent to: ApiDock object.presence object**.**present? object nil ? : Module#delegate Still rarely used by most of the developers for some reason. The main purpose of this method is loose coupling and following the . One of the good articles on this theme coming to mind is Avdi Grimm’s Also, check out short on utilizing in context of applying the . The snippet below describes this as well: Law of Demeter “Demeter: It’s not just a good idea. It’s the law.” Rails Best Practices article delegate Law of Demeter class Profile < ApplicationRecordbelongs_to :user delegate :email, to: :userend ...profile.email # equivalent to profile.user.email I hope you’ve just discovered some of these tips above and find them useful. Happy coding! ✋ If you liked this post, please click on to spread the word.

5 Ruby on Rails Tips You Probably Don’t Know

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Headless CMS Or Coupled CMS

106 Stories To Learn About Clean Code

10 Ways To Refactor Your Python Code

10 Ways to Prevent and Manage Technical Debt—Tips from Developers

110 Stories To Learn About Refactoring

The Early Velocity Trap

Headless CMS Or Coupled CMS

106 Stories To Learn About Clean Code

10 Ways To Refactor Your Python Code

10 Ways to Prevent and Manage Technical Debt—Tips from Developers

110 Stories To Learn About Refactoring

The Early Velocity Trap

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps