Musicboxd the Sequel: 2 Music 2 Boxd
As the months have progressed while learning full time at the Flatiron School, it’s been pretty easy to look back and reflect on how far we’ve come since starting in October. Personally, the most obvious leap has been in Phase 3, learning how to use Ruby on Rails. Learning how to make a basic application with Sinatra seemed like a big step forward in it’s own right, but after a single week of wading through everything that Rails has to offer it was pretty obvious to me that Sinatra was a small fry compared to this framework! Since my project that I built out for the Phase 2 project was something that I was pretty passionate about, I decided to go even further with it for Phase 3, adding more functionality and making the application a little more complex.
My Phase 3 project, like Phase 2, is what I call Musicboxd (not-so-subtly lifted from the social media website that I got inspiration from, Letterboxd). Musicboxd is an app designed for users to rate albums, share their favorite albums with their friends, write out reviews of any length, and see what music strangers are discovering as well.
Some great features that Rails integrates are the addition of different folders to help organize your helper methods that are used in your program’s views and the addition of form partials, both of which help keep logic out of your views, which helps keep your code DRY and easy to read for whoever might be looking through.
Partials are a feature that can be added to the list of reasons why Rails seems like magic sometimes. The best way to explain how they work is to show you how:
Here’s my New Album view before adding in my partial. It’s not impossible to understand; there’s some logic to display any errors that occur before saving, and the form to create a new album with a nested form for a new artist. It’s not the worst thing in the world, but we can make it easier to read! Because our form will be the same for both our new and edit actions, we can take that form out of the corresponding views and throw it into a new erb file in the albums folder!
Likewise with the errors, but since that part of the view can be used across different folders, we’ll throw it in the layouts folder.
now all we need to put in our new.html.erb file are two lines of code to replace all of that! for the form, we just need to render the form. The errors is where it gets a little more tricky. Because we had to abstract away everything that hinted that it’ll be used for an album, we need to tell the program to add those album instances back in. Here’s what the final file looks like:
Much easier to read! Because the errors partial lives in a different folder, the layouts folder, we need to tell Rails to search outside of the albums folder, hence ‘layouts/errors’. Since every occurance of @album has been abstracted away (being changed to object) in the partial, we need to add those back in. By telling our .erb file to locally replace each occurance of object with @album, we finish rendering our errors partial in our view!
There were parts of Phase 3 that felt more challenging than parts of other phases, but getting through everything and understanding what makes Rails tick has been a great journey! Going through each phase in this course and learning more and more complex concepts in software engineering makes me all the more excited for the final two phases in the course!