Last week I finished my second project at Flatiron School. The task at hand was to create an application using Ruby on Rails and to deploy via Heroku. Throughout the process of designing our application, my team and I were constantly utilizing the ‘rails routes’ command through our terminal to check the paths to each file within our application. Prior to this project, I had used the command sparingly, but I had no idea exactly how useful this tool is until I created an application myself. The objective of this post is to help other developers learn when to call this command, how to interpret the message, and to portray the value of this built-in tool.
The routes in your application will act as a bridge between the URI and controller files. When a user types in an address the route will examine the request and look for the corresponding controller. When writing your application you always have the option to hard code your paths, but calling ‘rails routes’ will provide you with route helpers. I recommend using these helpers because they are dynamic, can improve readability of your code, and is a more natural way of writing urls instead of string interpolation.
I used the command ‘rails routes’ most frequently when trying to complete the following tasks:
- Throughout the application there were links from one page to another, and I was never exactly sure off the top of my head what the path to these pages were. By calling rails routes I was able to get a quick summary of the available paths, where they lead to, and the correct syntax for them within my program.
- Because we we were using the Heroku free plan, we weren’t going to have our own domain so we decided to nest all of our routes behind “/brain” (the name of our application). It was important that we maintain clean and clear URI paths to preserve our users' experience. This was my first time nesting routes and while it was challenging, I couldn’t have done it without consistently calling ‘rails routes’. Below is a screenshot of the nested routes for this project - it was not intuitive for me at first look. By calling rails routes I was able to immediately view in the terminal what our routes looked like, verify if they were correct, and could also make changes in real time and see the updates to routes in the terminal.
The output will show you all the available routes within your program. As mentioned above, these are listed as route helper methods so that you don’t have to hard code paths into your project. Route helpers also offer the benefit of providing intuitive path names so when you or someone else is reading the code, they can make an educated guess on where the link will lead them.
Column 1 - Prefix:
These are the prefixes for the helper method - you’ll want to add _path at the end of the method when using in your code. See how intuitive these are!
Column 2 - Verb:
Lists the HTTP verb - what the program is doing and corresponds to a CRUD action.
Column 3 - URI Pattern:
This column lists the path for route. Tells you what the URI will look like from a users’ perspective and will also note what type of parameters are needed (ex: user_id, post_id).
Column 4 - Controller#Action:
Lists the designated controller and the corresponding action. The controller will be listed on the left side of the hashtag, and the action (where it is going within the controller) is listed on the right side of the hashtag.
Overall, 'rails routes' has proved to be an invaluable tool and helped to demonstrate how the code I was writing would be translated in the URI. I could easily visualize how my program was navigating through the MVC architecture. It also cut back on my errors because I was able to quickly reference the correct paths, rather than guess them. My tip for beginners is to remember the power of running ‘rails routes’ - utilize it frequently to ensure proper application structure and to check out your URIs from the users' perspective.