#nested routes

If you’re a web developer working with React, you’ve probably heard of React Router, a popular library for handling client-side routing in React applications. React Router provides a simple and efficient way to create routes and navigate between different views in a single-page application (SPA). While static routing is commonly used in React Router, dynamic routing offers even more flexibility…

React is a JavaScript library that is widely used for building user interfaces. It allows developers to create reusable UI components and offers a declarative programming model that makes it easy to manage the state of an application. When it comes to routing in React, developers have two options: React Router and React Router DOM. Both of these libraries are designed to help with managing routes…

Today, we set about to build a clone of Y Combinator's Hacker News. My partner, Eric, and I started from the bottom, and spent a good deal of time setting up some complex associations on the models. It was not a very agile way of going about things, I guess, as our approach had pretty much set the architecture in stone. Most of the complexity came in trying to model the relationship between nested comments. We ended up going with an ancestors table that joined the comments table on itself. Our comment model was a beast. Here's what it looked like:

  attr_accessible :article_id, :author_id, :body, :parent_comment_id

  validates :body, :author_id, :presence => true

  belongs_to :article, :inverse_of => :comments

  belongs_to :user

  belongs_to :parent_comment, :class_name => "Comment"

  has_many :child_comments, :class_name => "Comment", :foreign_key => :parent_comment_id

  has_many :comment_ancestors, :class_name => "CommentAncestry", :foreign_key => :descendant_id

  has_many :comment_descendants, :class_name => "CommentAncestry", :foreign_key => :ancestor_id

  has_many :ancestors, :through => :comment_ancestors

  has_many :descendants, :through => :comment_descendants

Crazy, huh? After that travail we proceeded to build the controllers, bake in authentication, and finally work on the views, with our first-ever implementation of nested forms. I introduced Eric to Twitter Bootstrap towards the end of the day, and we immediately made the site much prettier. I stayed a good bit of time after class completing the views, adding in validations, and refining the look.

Man, time flew by this week. I've been really enjoying working with Rails as we step into more and more complex stuff. My partner Steven I and hit the ground running as soon as we pulled up the project. We popped out the models and migrations with all associations in about 30 minutes.

Then the requirements changed!

This is not unusual. Throughout the day, as we work, the lesson plan is being updated in real-time. Whether it's clearer requirements, or more interesting problems, or bonus assignments, there's aways a healthy chance that the project instructions page will look different when you refresh it.

In this case, we were making a music app, which was initially tracking artists, bands, singles, and recordings (one single may have many recordings). After being setting up the back-end entirely and being well satisfied with ourselves, we refreshed the instructions page. And, BAM, it was time to recycle our work. We considered, for the briefest moment, starting from scratch, but we didn't put much heart in that. The new requirements were close enough to try to hack and meld them into our existing framework.

Now we were set to be tracking artists, bands, albums, songs, and tracks. With some carefully checked migrations and some thoroughly nit-picked model associations, we did what had to be done and brought our back-end up to spec. I found the experience educational. Would not be surprised at all if the instructors intentionally did not announce that they had switched the requirements-- how else are we supposed to learn how to work with migrations to fix your database schema if we're not thrown for a loop then and again?

Over the course of the day, the project instructions grew at a rapid pace. The scope must have doubled or tripled by the end of it, with all the bonus stages. With the way my partner and I approached the project, we actually ended up crossing several of the plateaus before they were ensconced as official bonus assignments.

One of the really great things I used today for the first time were nested routes. These gave me the power to pass attributes from one page to another in a RESTful fashion with hardly any effort. These came in handy when when one of our views would be called upon to update the model of a different type of entity, say a Band page that allows you to create a new Album (and ensure that  the newly created album  is associated with the band).

Another interesting topic we handled was the mystery behind check boxes. Of all the form objects in Rails, check boxes are the least straightforward. To make Rails treat a set of checkboxes as part of a single entity, we need to pass an array on a hash in the checkbox name attribute. However, we also need to safeguard that that hash gets picked up in case all check boxes are unchecked. The mechanism for that is to set a hidden field with an empty array to act as the sentinel. Pretty hacky stuff, but it was the best Rails could come up with when reconciling the limitations of HTML.

Finishing up most of the bonus stages, I left class at a reasonable hour to play my customary Thursday basketball. Had a good round of gritty, hard-fought games. I played hard like I always do. In the last game, a 3 on 3, I took an overly ambitious shot when we were down by 6 with only 3 more points for the other team to win.

It was a no-look hook, which I make sometimes, but not often enough to justify in critical game-time situations. It felt right at the time. One of my teammates called me out for taking such a shitty shot, for not caring enough to take a good look at the basket, and, flustered, he lagged on his defense. Wham! The other team scored.

I didn't change my strategy, didn't get angry, and pushed my indignation for another time. My teammate didn't know me well enough to know that I care all the time. I kept doing what I do, grabbed every rebound, set solid picks, made outlet passes. On every play, I worked like a beast to get my teammates into good spots, to close in on help defense, to box out for every board. We scored every remaining point in that game, and I had a hand in creating each of those buckets.

I am using Devise for a small rails project and I want to create a new model, Setting. Setting belongs to the user and the user model has just one setting. Normally I would set up a simple nested route along the lines of:

resources :users do   resource :setting end

The challenge is that devise uses a helper method to define the user routes. So instead of:

resources :users

Devise uses the following to create the user routes.

devise_for :users

The problem is that since devise_for is a helper method, the following is not a valid solution to adding the nested routes since it's not a resource route even though it looks very similar.

devise_for :users do   resource :setting end

To create the nested routes, we need to go with: 

devise_for :user, :path => "accounts"

resources :users do   resource :setting end

Note that the devise_for was updated with the path "accounts". So now instead of routes for the authentication such as  /users/sign_in, you have /accounts/sign_in. This is important in case that you ever need to add a UserController, it could create conflicts if you hadn't changed the path to accounts or some name other than users.

Since it is a one to one relationship between user and settings, on my nav bar I have a settings link that takes me right to the show page. With this type of relationship, there isn't a need for an index page. You don't need the id for the setting, just the user id for the user that owns the settings.

link_to "Settings", user_setting_path(current_user)

Now in the SettingsController, I add the following:

def show   @setting = current_user.setting   if !@setting     redirect_to new_user_setting_path(current_user)   end end

So, I wanted to write a post that covers some new ideas (nested resources) and some good ol' rails fundamentals (model associations).  I will be using a very simple app to work through these ideas.  The purpose is to practice our skills and not get bogged down in the content.

The app will be for a pickup football league and will keep track of the different teams and the players that play for the those teams.  Our domain mapping looks like the following:

Model Name: Team

has_many :players

name:string

-----------------

Model Name: Players

belongs_to :team

name:string

team_id:integer

With our models planned out, let's jump into the code 

1) Rails new PickUpFootball

2) Generate the models with the data we planned above

rails g model team name:string

rails g model players name:string team_id:integer

3) Go into the models and make the association

Player: belongs_to :team

Team: has_many :players

4) Go into the Seed file and populate the app with some data

Team.destroy_all

Player.destroy_all

["Giants", "Ravens", "Eagles", "Patriots"].each do |mascot|

  Team.create( name: mascot)

end

team_one = Team.find_by_name("Giants")

team_one.players.create([{ name: 'Bill' }, { name: 'John' }, { name: 'Dave' }])

team_two = Team.find_by_name("Ravens")

team_two.players.create([{ name: 'Sam' }, { name: 'Chris' }, { name: 'Kyle' }])

team_three = Team.find_by_name("Eagles")

team_three.players.create([{ name: 'Neal' }, { name: 'Sean' }, { name: 'Kevin' }])

team_four = Team.find_by_name("Patriots")

team_four.players.create([{ name: 'Smith' }, { name: 'Spike' }, { name: 'Flannery' }])

***This code can totally be re-factored. I definitely didn't follow the DRY principle.

***Also, if you mistype and need to delete a model you'll first need to run rake db:rollback and then rails destroy model "name of model".

5) Seed the data

rake db:seed

6) We want to a listing of the Teams and Players so we will need to generate a controller for each as well as corresponding views.

rails g controller teams index show

rails g controller players show

7) Now, in order to see our views, we will need to create our routes.  This is where we can implement our first objective, nested routes.  Typically, we would just put in the code

resources :teams

resources :players

But, it would be nice if our urls were more descriptive and instead of passing ids it passed what our users would naturally type.  Enter nested resources.  Since we have the association of players belong to one specific team we would write our routes as followed:

resources :teams do

resources :players

end

8) Now we need to launch our server and open our homepage, which I set as teams/index, which I set with the following code

root to: "teams#index"

9) Now we need to show a listing of our teams

This is what I placed in my team's controller:

def index

@teams = Team.all

end

This is what I placed in my index view:

<% @teams.each do |team| %>

  <li><%= link_to team.name, team  %></li>

<% end %>

We should now have a listing of teams that are hyperlinked that take us to show page for a particular team.  

10) We now need to list the players for a particular team.  To do this we need to scope the particular team we are dealing with.   In our show method we need to define @team in such a way that it grabs the id from the url it is being passed.

def show

@team = Team.find(params[:id])

end

Then we need to cycle through our players and list them out for that team.  I placed this in my team's show page.

<% @team.players.each do |player| %>

  <li> <%= link_to player.name, team_player_url(@team, player)  %></li>

<% end %>

It is important to realize how nested routes change our routes.  Do a quick rake routes to see how they have changed.  Look at the above route.  For team_player_url we have to pass it first the team's id (we defined @team as being specifically that in our controller) and then the player's id.  Before nested routes we simply passed 1 id in our parameters, but now we need to pass 2 (team & player).  

11) This should link us to a player's individual page where we could potential put a bunch of information like stats, contact info etc.  For our purposes we will just list out that players name.  Since we have scoped team and players we can place this code in our views

<h1><%= @player.name %></h1>

If you refresh your browser now you will get a NoMethodError.  We need to go into our player's controller give our show method some much needed information.

def show

    @team = Team.find(params[:team_id])

    @player = @team.players.find_by_id(params[:id])

  end

To make this a bit more fancy and for practice we'll place a before_filter that way we do not have to keep repeating our @team code.  So, with some refactoring our new player's controller looks like this

  before_filter :require_team

  def require_team

  @team = Team.find(params[:team_id]) 

  end

  def show

  @player = @team.players.find_by_id(params[:id])

  end 

Yay, congrats.  We now have completed a small app that allowed us to practice nested resources, model associations, seeding data, and before filters.