Discovering Ruby on Rails
As I progressed through my time in Flatiron, I was beginning to feel like I had a grasp on the work! I understand a lot of how Ruby works, the syntax, and other elements, so I thought that using a heavyweight framework like Rails would be easier than our previous project with Sinatra. Well, it certainly wasn’t easy but it was really fun to discover all the ways that Rails is there to help, even if that means a lot of trouble before you get it figured out!
Rails felt quite similar to Sinatra in that in still follows the MVC, or Model, View, Controller pattern. This means that the models interact with the database, the back-end of your application, to save and retrieve data from your tables, the views represent everything that will be shown to the client, while the controller handles the interaction between the front-end and back-end, like a server in a restaurant going between the guests and the kitchen. Really, it should be called MCV or VCM based on the actual flow, because views and models never interact in your application!
In Rails, our controllers use methods, called controller actions, to handle the interaction between our routes and our views. So, if there is a set of routes defined as “resources :items”, then Rails looks for a controller called “Items Controller”, and within this controller, the controller actions would normally be index, new, create, edit, update, and destroy. In the views folder, the controller actions (specifically only ‘get’ requests) would have corresponding views. So the “new” action has a “new.erb” view folder under the “items” folder. When you use a post, patch, put, or delete request, the corresponding controller action communicates with the models to let them know about the changes. So Rails is all very orderly and organized. But the sheer number of files and folders in even my small Rails application was enough to give me a splitting headache several times!
One of the scarier parts of this project before starting was the creation of a scope method. I hadn’t handled much SQL but I understood that using SQL to pull information from the database tables was much faster than when using Ruby, so it is very useful to have scope methods. Basically you write your scope method inside the model that you want to write it for, then you need to create a route for the scope method’s information to be displayed, and a corresponding controller action and view file. I wrote my scope method in the Product model, so my route went through the products controller, and the view file went under the products directory. After playing around with some failed attempts I came up with a method for my skincare application that would allow me to list products by their type, be it “moisturizer” or “cleanser”, or any others, and I was so happy when it worked! In addition to being a wickedly helpful method, it gave my application the feel of a real website! My scope method ended up like this:
scope :product_category, ->(product_type) {where(“category = ?”, product_type)}
So what started off as a scary part of my application ended up being one of the most enjoyable parts! I’d really love and plan to play around with more of these methods and add new routes and views to my application soon!
