Rails Routing: Static and Dynamic Routes

Rails applies a standardized MVC structure that implements a full set of CRUD features:

index, new, create, show, edit, update, destroy

Rails runs its routes as either dynamic or static pages. A static route is one whose view does not change. Typical examples are about or contact pages. A dynamic route will change depending on the parameters that are input, such as accessing a specific article on a blog’s post page.

Static Routes

To configure a static route, we must go into config.routes.rb and add a route code for our static page.

In this instance we have added a hello_world route into the draw block.

This route is comprised of three components: the HTTP verb “get”, the path “‘hello_world’” which describes the path that will be used in the URL, and the controller action “‘static#hello_world’”, which tells the Rails router to pass through the static controller’s about action.

Next, we need to create a controller under app/controllers/static_controller.rb, which is a class called StaticController with the parent ApplicationController, containing a method for the route:

class StaticController < ApplicationController
 def hello_world
 end
end

Protip: changes made to controller files can be seen in the browser without restarting the Rails server because they are in the app directory.

We can now map the view in one of two ways: Explicit rendering (in which you choose the view file you want the user to be routed to) or Implicit rendering, which automatically looks for the view file with a name that matches the controller.

To explicitly render a Hello World! view, we create a views directory called static which contains the file hello_world.html.erb, which contains the single header line:

<h1>Hello World!</h1>

Thus we have created a static route to an explicitly rendered view that shows:

Dynamic Routes

A dynamic route functions differently in that it essentially takes the post id and instantiates it by parsing the object’s id as a parameter and passing it through the appropriate controller. It then passes it through the associated model to create the individual instance. The instance is then passed into the associated view, providing a unique rendering of that specific content. Dynamic routes are associated with the route actions in the controller that include /:id, so in the instance that we are working in a BooksController for a CRUD interactive reading list, our action would look like:

/books/:id

If our dynamic instance has the id of, say, 25, it will show as:

/books/25

To implement a dynamic route code, we follow a similar first step as the static route — we check the config/routes.rb to make sure we have a map to the show action in the BooksController:

get 'books/:id', to: 'books#show'

The difference here is that we are routing it to an action ‘books/:id’ which contains the unique id signature for each individual instance.

We then return to our BooksController (which inherits from the ApplicationController) as before and create an internal method that shows information based on unique or specific params:

def show
 @book = Book.find(params[:id])
end

This tells us that we will be instantiating a specific book that is based on a specific set of user input params. But because of the obligatory unique nature of a dynamic route, the view will have to be written to express that unique information. The instance variable is now available in show.html.erb view file, so we can show the key of title by calling on the instance:

<h1><%= @book.title %></h1>

Now we have a header that is the title of the specific book instance, and can access the rest of the book’s params as well, using that same instance variable:

<h1><%= @book.title %></h1>
<p><%= @book.description %></p>

Our description spec can be implemented to look like this:

it 'shows the description on the show page in a p tag' do
 visit "/books/#{@book.id}"
 expect(page).to have_css("p", text: "My book desc")
end

Refactoring and Resource Routing

Because we only care about the show action in this example, we can refactor the get route in the routes.rb file using RESTful defaults and the resources method to specific which route we care about:

get 'books/:id', to: 'books#show'

becomes

resources :books, only: :show