“The magic of Rails and Active Record Associations.”
I have finished phase 3 of Flatiron School Software Engineering Course. Our project for phase 3 was to create a Rails CMS app. At first, I struggled trying to find out what I wanted to do for the project, but once I slowed down and really thought about what the flow of my project would look like, it all started to make sense. Here, I will break it down a little bit.
I wanted to make an app where users could view news articles from around the world, through many different news sources, and in the end also be able to interact and communicate with other users. The best approach here was to find a reliable API and implement it into the project. This was step one, and after a couple of hours I had a steady flow of news data coming in every time my articles database was seeded. Later, the database becomes automatically seeded with new data every time a user visits/refreshes the articles index home page.
Really cool! Now we have an endless amount of new articles being created for us to be able to view and play around with!
Next, I wanted the users to be able to interact and converse with each other about articles that interest them. Therefore, I knew I wanted some functionality where users could comment on articles, and reply to each others comments. I had to ask myself, “How can this be done? Users, articles, comments, and replies would all need to know about each other, but how?”
This is where the power of Active Record Associations comes into play. I have been learning and using Active Record for a couple months now, and I am still amazed at how seemingly “magical” it makes accessing and manipulating data. From here, ground up, its time to add some Active Record macros to all of our models to help establish their respective relationships.
Let’s break this down a little bit. In order to establish a cycle where I could access all information from anywhere, I started with comments and replies. These essentially ‘join’ everything together. A comment would belong to an article and a user, and also each comment would have many replies. A reply would belong to a comment and a user. This lets our comments and replies know which article and which user they are referring to. That being said, an article would have many comments, many users through comments, and many replies through comments. Therefore, the user would have many comments, replies, and articles through their comments. We can take a look at our database schema and see how this all plays out.
You can see here in our tables that because comments belong to users and articles, comments get ‘foreign key’ attributes of user_id and article_id in order to relate each comment with its article and the user that made the comment. The replies table works the same way. For a couple examples, this is what the forms would look like which the user has to submit a comment or reply:
In the form for comments, for example, the user would fill out the content. But when the post request is made to create a comment, we have a hidden field of ‘article_id’ which gets passed in upon submission to let our app know which article the user is commenting on. Similarly, users would fill out a reply form with content, and the hidden field of ‘comment_id’ would get passed in, letting our app know which comment is being replied to.
Back in our controllers, the ‘quarterbacks’, we can truly see where all the ‘magic’ happens behind the scenes. In the ‘create’ actions for comments and replies, all of our variables are set via associations in order to truly talk to our models and forms:
Super cool, right? Now all of our models are related! Unfortunately, this led to a pretty heated argument between Billy and I about what our company name would be after graduation, which Enoch tried to diffuse.
If you would like to see a brief walkthrough of what the project looks like, check it out here: