Rails Essentials: Action View Helper Methods & Strong Params
First and foremost, what is Action View and what is its role in Rails? Action View templates allow us to write embedded Ruby within HTML files. To better DRY our code, we implement the use of partials. The following two examples will show how to use and render partials in html.erb files.
Partial forms will allow us to reuse our code repeatedly throughout various sections of our application, but without repeating ourselves. As you can see depicted above is an example of a partial form. I am using the form_for method so the user can create and update specific attributes from the model. Within this method, we are iterating over an instance of the Form Builder class. This specific application allows the user to write Broadway Show reviews, but they also have the ability to edit these reviews as well. What if they changed their mind and decide they love/hate the show? Or what if they made a spelling error? Form_for gives us the ability to make all of these changes plus many more features. Keep in mind that this helper takes in an argument of the instance of the model. Another important feature to mention is that form_for knows exactly which route is needed for the data instead of having to declare each route manually. What can I say? It’s the magic of rails.
Did you notice that I used fields_for in addition to form_for? If you’re wondering why, the short answer is: nested attributes. This is an additional helper method that will make our code more dynamic. For my project, reviews belong to a show and a show has many reviews. Therefore, a user will have the ability to create an update specific attributes about the reviews.
For future reference, do not get form_tag and form_for confused. Although seemingly similar, they serve very different purposes. Form_tag is best used for when you only need to generate HTML.
This form will repeatedly be used, so instead of writing it several times, why not just write it once and render it in each file where it will be needed? As always, the goal is to not repeat yourself. Partial forms give us that ability. Just remember, partial forms always start with an underscore, but when we render it, the underscore disappears. For example, the partial I showcased above was named “_form” but when rendered, it’s render(‘form’). It’s even possible to render forms from different folders, just remember to call the name of the folder before the name of the partial.
Strong Params
How can we ensure our Rails application is only accepting parameters that we specifically want? Strong parameters!
Imagine you are trying to gain access to the world’s most exclusive restaurant. Only a select few can get in. You arrive to the front door and are greeted by a security guard to confirm that you are on the list to enter this hypothetically fancy restaurant. The guard sees your name, and you’re in! This is how strong params work. They are set in place with the purpose of securing your Rails application and only allowing the fields we want to permit to get accepted. Take a look at an example of how we would invoke strong params in the very first method defined under private:
There are two specific elements that are described in the method: permit and require. So what’s the difference? Require absolutely mandates that anything submitted must include what is required. If not, a 400 Bad Request error will occur. Permit is not as binding, and allows any of the keys that are passed into the hash, but if they are not included, it’s not a problem.
Coming from Sinatra, I can see why Ruby on Rails is the preferred web framework. I recall reading online that while Sinatra is like a bicycle, Rails would be considered a car- and after this project, I can see why! Rails is filled to the brim with code, resources, and helper methods that make our applications limitless. This project wasn’t easy, but I learned plenty!
