DEV Community: LUIS CUEVAS

Rails Routes - Mastering Routing in Ruby on Rails: A Concise Guide with Code Examples

LUIS CUEVAS — Thu, 07 Sep 2023 01:31:27 +0000

1. Single Route Resources

Single route resources are a straightforward way to define routes for a resource with only one route. Let's create a route for a "book" resource using Rails resources method:

# config/routes.rb
resources :books, only: [:show]

In this example, we've defined a single "show" route for the "books" resource, which maps to the "BooksController#show" action.
But if we want all the whole REST routes for books, we use this.

resources :books

2. Nested Routes

Nested routes in Ruby on Rails involve physically nesting one resource inside a block supplied to another resource in the routes file. This allows for URLs like '/books/2/chapters/10', where chapters are nested under books.

Nested routes allow you to express hierarchical relationships between resources. For instance, if you have a 'Chapter' resource that belongs to a 'Book,' you can set up nested routes like this:

resources :books do
  resources :chapters
end

of course we have defined associations between models

# app/models/book.rb
class Book < ApplicationRecord
  has_many :chapters
end

and

# app/models/chapter.rb
class Chapter < ApplicationRecord
  belongs_to :book
end

3. Member and Collection Routes

In Ruby on Rails, when defining routes for a resource, you have the flexibility to add custom actions using member and collection routes. These two types of routes serve different purposes and are suitable for distinct scenarios.

Suppose you have a "books" resource and want to add a custom "highlight" action for a specific book. You can define a member route like this:

resources :books do
  member do
    get 'highlight'
  end
end

Now, you can access the "highlight" action for a specific book using a URL like "/books/1/highlight," where "1" represents the book's ID.

Suppose you want to add a custom "search" action that searches for books across the entire collection. You can define a collection route like this:

resources :books do
  collection do
    get 'search'
  end
end

Now, you can perform a search action that applies to all books using a URL like "/books/search."

Note that Member routes typically map to actions that perform operations on a single member or instance of a resource.
Collection routes map to actions that involve the entire collection of a resource.

4. Adding Non-RESTful Routes

Sometimes, you may need routes that don't follow RESTful conventions. For example, let's create a custom route for marking a book as a favorite:

# config/routes.rb
resources :books do
  post 'favorite', on: :member
end

Below are other different approaches to implement a non-RESTful route for this scenario:

Using the match Method

This approach allows you to specify the HTTP method (e.g., POST) and the controller action to be invoked. The :as option allows you to create a named route helper method, such as favorite_book_path, for generating URLs to this route.

match '/books/:id/favorite', to: 'books#favorite', via: :post, as: :favorite_book

Using post Method with on: Option

By specifying the on: option within the post method in your routes file. This approach explicitly states that the "favorite" route is a member route, and it maps to the favorite action in the BooksController

resources :books do
  post 'favorite', on: :member, to: 'books#favorite'
end

Using Custom Named Routes

With this approach, you have flexibility in naming the route and can use the generated named route helper (e.g., mark_favorite_path or custom_favorite_route_path) to generate URLs for this non-RESTful action.

post '/books/:id/favorite', to: 'books#favorite', as: :mark_favorite

# OR, using a custom helper method name
post '/books/:id/favorite', to: 'books#favorite', as: :custom_favorite_route

Now, you can mark a book as a favorite by making a POST request to "/books/1/favorite."

5. Redirects

In Rails, you can define redirects easily in your routes file. Suppose you want to redirect "/old_path" to "/new_path":

# config/routes.rb
get '/old_path', to: redirect('/new_path')

This code will redirect any request to "/old_path" to "/new_path."

6. Wildcard Routes

Wildcard routes are a powerful tool for handling dynamic URLs. Suppose you want to capture all requests to "/books/*" and route them to a specific controller action:

get '/books/*path', to: 'books#show'

With this wildcard route, you can capture various book-related paths and route them to the "BooksController#show" action.

7. Some Anti-Patterns, or Please Dont

Overuse of Custom Routes

Anti-Pattern: Defining excessive custom routes for every controller action

resources :books do
  get 'custom_action_1', on: :member
  post 'custom_action_2', on: :collection
  put 'custom_action_3', on: :member
  # ... more custom actions ...
end

Instead, it's recommended to use RESTful routes whenever possible and resort to custom routes only when necessary.

Verbosity in Named Routes:

Anti-Pattern: Using overly verbose names for named routes.

# BAD
get '/books/:id/edit_book', to: 'books#edit', as: :edit_book_action

# GOOD
get '/books/:id/edit', to: 'books#edit', as: :edit_book

Unused or Dead Routes

Anti-Pattern: Defining routes that are no longer used in the application.

get '/unused_route', to: 'unused#action'

Such routes should be removed to maintain a clean and maintainable route configuration

Complex Route Constraints

Anti-Pattern: Overcomplicating routes with complex constraints.

get '/books/:id', to: 'books#show', constraints: { id: /\d{3}/ }

Keep route constraints simple and understandable, and use them sparingly.

Lack of RESTful Structure with RESTful actions

Anti-Pattern: Creating routes that don't adhere to RESTful principles when these are for RESTful action in the first place.

# BAD because show is a RESTful action
get '/books/show_book/:id', to: 'books#show'
# Better
resources :books, only: [:show]

Inconsistent Route Naming

Anti-Pattern: Using inconsistent naming conventions for routes.

# Wrong
get '/books/show_book/:id', to: 'books#show', as: :display_single_book
# Best
resources :books, only: [:show]

Consistency in naming conventions makes the codebase more understandable

By avoiding these anti-patterns and following Rails' conventions for routing definitions, you can maintain a clean and maintainable routing configuration in your Ruby on Rails application, making it easier for developers to understand and work with the code.

Conclusion:

Mastering routing in Ruby on Rails is essential for building robust web applications. In this concise guide, we've covered single route resources, nested routes, member and collection routes, non-RESTful routes, redirects, and wildcard routes, and anti-patterns, each of these illustrated with code examples. By understanding these routing concepts, you'll be better equipped to handle complex routing scenarios in your Rails applications.

Using GIVEN-WHEN-THEN on RSpec test classes

LUIS CUEVAS — Sun, 11 Jun 2023 02:24:02 +0000

Using Given-When-Then in RSpec
RSpec provides a way to use Given-When-Then in test classes by using aliases. Aliases are a way to define new names for existing RSpec methods. By using aliases, developers can write tests that use Given-When-Then syntax.

RSpec is a testing tool for Ruby, created for behavior-driven development (BDD / TDD). It is the most frequently used testing library for Ruby in production applications. RSpec provides a powerful DSL (domain-specific language) that allows developers to write expressive and readable tests. Also there are a number of other popular testing libraries for Ruby, such as Test::Unit and Minitest.

but always the lazy one in me wants something easier to read and remember when coding tests

require 'spec_helper'

RSpec.testing 'Calculator' do
  Given 'a calculator' do
    let(:calculator) { Calculator.new }
    When 'the calculator adds two numbers' do
      before_that do
        @result = calculator.add(2, 3)
      end

      Then 'the result should be the sum of the two numbers' do
        expect(@result).to eq(5)
      end
    end
  end
end

was it easy to read?

In the code example above, we define aliases for example_group and example elements using the keywords Given, When, and Then. We also define a helper method before_that that is used as wrapper of the before(:each) method. Also we use 'testing' as an alias for 'describe'

We have capitalized the words Given When Then so that they are not confused with Ruby reserved words that are the same but lowercase.

We then define a test class for a Calculator object. We use the Given alias to define a context for the test, and the When alias to define the behavior being tested. We use the before_that helper method to set up the preconditions for the test. Finally, we use the Then alias to define the expected outcome of the test.

What is Given-When-Then?

Given-When-Then is a test description technique that helps developers to write tests that are easy to read and understand. The technique is based on three parts:

Given: This part describes the preconditions of the test. It sets up the context for the test.
When: This part describes the action that is being tested. It specifies the behavior that is being tested.
Then: This part describes the expected outcome of the test. It specifies the result that is expected from the behavior being tested.

How to do use aliases on RSpec tests

To enable this aliases just add these sentences on the spec_helper.rb:

RSpec.configure do |config|
  ....
  config.alias_example_group_to :testing
  config.alias_example_group_to :Given
  config.alias_example_group_to :When
  config.alias_example_to :Then

  def before_that(&block)
    before(:each, &block)
  end
end

class Calculator
  def add(int_a, int_b)
    int_a + int_b
  end
end

IMHO Given-When-Then is a powerful test description technique that helps developers to write tests that are easy to read and understand. RSpec provides aliases that allow developers to use Given-When-Then syntax in their tests. By using aliases on RSpec, developers can write tests that are expressive and readable, making it easier to maintain and debug their code.

By following these dev tricks, you can write Given-When-Then tests that are easy to read and understand. This will make it easier to maintain, document and debug your code.