Perils and Pitfalls of Ruby on Rails

Coming out of learning Sinatra, I felt on top of the world as my Flatiron cohort and I advanced onto our next module, Ruby on Rails. It was only a matter of time that the emotional roller coaster of coding would catch up on me after the experiencing Sinatra bliss. In my minds eye, Rails seemed like an extension of Sinatra with more moving parts. But when I started brainstorming my project, the concept of Ruby on Rails became more complicated than I had previously thought.

When thinking about what to cover here, I thought it would be helpful to go over things I wish I knew before diving into project mode.

Project concept:

What I did:

I based my project concept off of my Sinatra app with changed features. My ruby on rails app is called GallerySpace. GallerySpace allows users to look through a list of works of art from around the world and throughout history. Users are able to read more about a specific piece to find out specs like the artist, medium, and year it was created. If a piece interests a user, they are able to leave a comment pertaining to that specific piece. A user isn’t limited to how many comments they can make. Users also have access to an index of comments to see all their comments tagged to the appropriate pieces.

What I should’ve done:

As much as I had fun revamping this concept, I do wish I had chosen a different concept. It would’ve challenged me creatively and it would’ve added more variety if I were to add this project to my portfolio.

What I learned:

Despite my decision, evolving my concept of GallerySpace made me become more flexible with the feature I would create for my app. In my Sinatra app, a user is able to create their own art pieces and commit them to the database. In my Ruby on Rails app version, Users don’t have access to create a new piece of art. Instead, pieces of art are provided for them which gives me less routes and views to worry about configuring.

My models also changed when reconfiguring GallerySpace. Instead of a piece of art work being the joins table, comments became the joins table. In the Ruby on Rails version, comments is not only a new model but also offers features for users to create, edit, and delete comments associated with the work_id of a work. Comments is a nested route that can be accessed through the parent route of Works.

config/routes.rb
Rails.application.routes.draw do
...
resources :works do
resources :comments
end

Routes:

A hard adjustment I had to make when transitioning from Sinatra to Ruby was going from hardcoded paths url helpers. Hardcoded paths offer exact coordinated for a path but leave room for syntax errors. Url helpers are more dynamic and follows DRY (Don’t Repeat Yourself protocol). Url Helpers offers cleaner readability within the views and translate automatically into HTML. Url Helpers also make it more accessible to pass in arguments rather than utilize string interpolation.

Another adjustment was being able to access and utilize routing methods by inputting ‘rails routes’ in the terminal. Learning to read and understand each column is a huge asset to knowing how to connect controllers to views.

what I learned:

(column 1)     (column 2)            (column 3)
works    GET  /works(.:format)       works#index
work    GET  /works/:id(.:format)   works#show

Column 1: shows you the prefix for the route helper methods. Prefixes are used with methods (_path, _url) that enables you to render a path to a specific page.

So instead of redirecting via ERB in Sinatra erb:‘ works/index’

You redirect in Ruby on Rails with ‘ redirect_to works_path’

what I learned: The difference between _path and _url is that _path gives you the relative path and _url renders the whole URL. Use these mindfully. A safe tip is to use _path so nothing breaks if the server domain changes.

Column 2: the HTTP verb

Column 3: shows the path for the route and the needed parameters that will need to be passed to the route. The work#index page is a static route, meaning it will show the same view and will not change. The work#show is a dynamic route, meaning it has a variable that is passed to the route. In this route, that variable will be the id of the work being shown in the view (work_id). When :id parameters are needed in the URL, a route helper method must pass an ID.

Column 4: shows the syntax of ‘controller#action’

Deceifering routes allows you to acheive the rails concept of “convention over configuration”. Once you understand the protocol of rails is that resources are accessible through their pluralized name with _path ('works_path'). The easier of a time you will have connecting your routes.

Hopefully these tips and advice will help you get through some of the pitfalls as a novice Rails developer.