Rails 6: Resources All The Way Down
(What I learned from triple nesting resources.)
Two of the major skills that were highlighted during the Phase 3/Rails session at FlatIron were nested resources and understanding scope methods. I’d like to share my process— and it may serve as a learning tool or a creepy campfire tale of questionable methods. That is for you — Dear Reader — to decide.
My application project for this phase is called TutorHub. Tutors and Students (separate classes) can login, create an account, and describe their impressive knowledge (tutors) or where their COVID-gap is going to be (students).
Once logged in, Students and Tutors can find each other by subject or grade level, respectively, and then create a Lesson/Session (join table!) for both parties to meet, whether that’s in person or on Zoom.
Here comes the cautionary tale: I was thrown by the concept of aliasing. I didn’t like it. I ran. Ran so far away. The syntax confused me and I thought that my views would be easier to manipulate if I used…Triple Resources. Working on the make-your-own-AIRBNB activity introduced me to aliasing, but I still couldn’t wrap my head around how to have two Users, with different “names”. These Users will have some common attributes, but enough non-shared attributes to set them apart from each other. So, what logically made sense, based on the flow of the user experience, was this:
Now, I know this method is frowned upon, I did learn an enormous amount about nested resourcing, what arguments get passed in when you need a route like: localhost:3000/tutors/4/students/7/lesson/3/edit? , as well as the strong conditional rendering you need when both users need access to #show #edit pages, (but have completely different id’s and classes!).
As much as I learned from nesting, I also was able to pick up some formatting skills and tricks from all the conditional formatting I had to do. For example, my Student#show page had to be a) visible to that Student after they created their account, b) visible to any Tutor so they may learn more about their student and schedule the actual Lesson with them, c) invisible to all other students for privacy/accessibility sake. But only Students could see specific information, like their ability to edit their page, but only Tutors could initiate a Lesson — from the Student page. All in all, a solid hands-on learning experience, and the stress has given me the perfect salt and pepper blend.
Rendering partials becomes more work then creating the original code. We all know that DRY is a way of life as we walk this earth. But, as you can see below, there were too many nuances and differences to some major routes. Even if I altered the local variables in my partial views, the actual nested routes lead to different views. Exhibit A:
So, the biggest help I found when trying to create these routes was
a) look at the bottom left of your screen when hovering over the link-text to display the (hopefully) correct nested route. Often I saw :tutor_id or :student_id in my route path, and that was a quick and easy tell to change the argument being passed in. Some quick “pry-ing” revealed the proper argument to enter.
b) If you are using button_to, the link path won’t show in the bottom right of your screen. One method to reveal the path is “right-click” on browser page > select Inspect, and hover over the button_to to see the route necessary for that path.
I had to navigate many errors when creating these paths, but using the methods above, I was able to quickly navigate how to fix my errors, and along the way learned a lot about nested routing. In the future, I plan to acquaint myself further with aliasing, and the shallow method so that I can better adhere to the nesting unwritten rule of only nesting one level deep.
—
