Active Rails

Ruby on Rails allows for rapid development of applications by using a concept known as convention over configuration. A new Ruby on Rails application is created by running the application generator, which creates a standard directory structure and the files that act as a base for every Ruby on Rails application. These files and directories provide categorization for pieces of your code, such as the app/models directory for containing files that interact with the database and the app/assets directory for assets such as stylesheets, JavaScript files, and images. Because all this is already there, you won’t be spending your time configuring the way your application is laid out. It’s done for you.

One great example of rapid development of a Rails application is the 35-minute Rails tour video recorded by David Heinemeier Hansson.^[4] This screencast takes you from having nothing at all to having a basic blogging and commenting system, in a little over half an hour.

Once learned, Ruby on Rails affords you a level of productivity unheard of in other web frameworks, because every Ruby on Rails application starts out the same way - with exactly the same layout. The similarity between the applications is so close that the paradigm shift between different Rails applications isn’t tremendous. If and when you jump between Rails applications, you don’t have to relearn how it all connects together - it’s mostly the same.

The Rails ecosystem may seem daunting at first, but Rails conventions allow even new things to seem familiar very quickly, smoothing the learning curve substantially.

One of the best-known sites that runs Ruby on Rails is GitHub, a hosting service for Git repositories. The site was launched in February 2008, and is now the leading Git web-hosting site. GitHub’s massive growth was in part due to the Ruby on Rails community quickly adopting it as their de facto repository hosting site. Now GitHub is home to over 200 million repositories^[6] for just about every programming language on the planet. It’s not exclusive to programming languages, either; if it can go in a Git repository, it can go on GitHub. As a matter of fact, this book and its source code are kept on GitHub!

Other companies you might’ve heard of, like Airbnb, Stripe, Square and Twitter all use Rails too. It’s used by some pretty big players!

But you don’t have to build huge applications with Rails. There’s a Rails application that was built for the specific purpose of allowing people to review the previous edition of this book, and it’s just over 2,000 lines of code. This application allowed reviewers during the writing of the book to view the book’s chapters and leave notes on each element, leading overall to a better book.

Now that you know what other people have accomplished with Ruby on Rails, let’s dive into creating your own application.

To get started, you must have these three things installed:

If you’re on a UNIX-based system (Linux or Mac), we recommend that you use ruby-install ^[7] to install Ruby and RubyGems. For Windows, we recommend the RubyInstaller application^[8]. There’s a complete installation guide for Ruby and Rails, on Mac OS X, Linux, and Windows, in Appendix A of this book.

Before proceeding, let’s check to be sure you have everything. Type these commands, and check out the responses:

If you see something that looks close to this, you’re good to go! You might see [x86_64-linux] instead of [x86_64-darwin19], or a slightly different patch (p) number, but that’s okay. These particular values are the ones we’re using right now and we’ve tested everything in the book against them; as long as you have Ruby 3.1, Rails 7.0, and RubyGems 3.0, everything should be fine.

Remember before how we said that every Rails application starts out with the same layout? Well, we’re about to see that for ourselves!

With Rails installed, to generate an application, you run the rails command and pass it the new argument and the name of the application you want to generate: things_i_bought. When you run this command, it creates a new directory called "things_i_bought", which is where all your application’s code will go.

The application you’re going to generate will be able to record purchases you’ve made. You can generate it using this command:

The output from this command may seem a bit overwhelming at first, but rest assured, it’s for your own good. All the directories and files generated provide the building blocks for your application, and you’ll get to know each of them as we progress. For now, let’s get rolling and learn by doing, which is the best way.

To get the server running, you must first change into the newly created application’s directory, and then start the application server:

rails server (or rails s, for short) starts a web server on your local address on port 3000, using a Ruby web server called Puma. It will output this:app-name:

This indicates that the server will be available on port 3000 on your local machine, and that you can stop the server by pressing Ctrl+C.

To connect to this server, go to http://localhost:3000 in your favorite browser.

You’ll see the Rails welcome page:

At the bottom of this page, you’ll see two things: the version of Rails, and the version of Ruby that you’re using. These should match the earlier version numbers that we mentioned earlier. That is, the Rails version should be 6.1.0 and the Ruby version should start with "Ruby 3.1.1".

The rest of this chapter is going to be a walk through for the different pieces of a Rails application. We’re going to use a utility called the scaffold generator that will generate a lot of our code for us. After we’ve done that, we’ll walk through all the individual pieces that this generator provides.

This should give you a fairly good overview of the parts that a Rails application is comprised of.

To get started with this Rails application, you can generate a scaffold. Scaffolds in Rails provide a lot of basic functionality and are generally used as temporary structures to get started, rather than for full-scale development. In this case, it’s a really good way to get started with exploring what Rails is capable of straight away.

Let’s generate a scaffold by running this command:

This generator will generate quite a lot:

When you used the rails command earlier, it generated an entire Rails application. You can use this command inside an application to generate a specific part of the application by passing the generate argument to the rails command, followed by what it is you want to generate.

The scaffold command generates everything that we will need for creating, viewing, updating or deleting purchases within our application. We’ll walk through the individual pieces shortly, but first let’s talk about this command that was just used.

Everything after the name of the scaffold defines the fields for the database table, and the attributes for the objects of this scaffold. Here you tell Rails that the table for your purchase scaffold will contain name and cost fields, which are a string and a decimal, respectively. To create this table, the scaffold generator generates what’s known as a migration. Let’s look at what migrations are.

When we’re working within a Rails application, our data has to come from somewhere, and that somewhere is usually a database. In order to use this scaffold of ours properly, we’re going to need some data. And that data is going to need to come from a database table. But that table doesn’t exist yet! To create a database table to store our data in, we use what’s known as a migration.

Migrations provide a way to implement incremental changes to the database’s structure — the data within that structure comes later. Each migration is timestamped right down to the second, which provides you (and anybody else developing the application with you) an accurate timeline of your database’s evolution. Let’s open the only file in db/migrate now and see what it does. Its contents are shown in the following listing.

Migrations are Ruby classes that inherit from ActiveRecord::Migration. Inside the class, one method is defined: the change method.

Inside the change method, you use database-agnostic commands to create a table. When we execute the code in this migration, it will create a table called purchases with a name column that’s a string, a cost column that’s a decimal, and two timestamp fields. These timestamp fields are called created_at and updated_at and are automatically set to the current time when a record is created or updated, respectively. This feature is built into a part of Rails called Active Record. If there are fields present with these names (or created_on and updated_on), they will be automatically updated when necessary.

Ensure that your Rails server is still running, or start a new one by running rails s or rails server again. Start your browser now, and go to http://localhost:3000/purchases. You’ll see the scaffolded screen for purchases:

Let’s take a look at how this page came to be. How is it that we’re able to go to http://localhost:3000/purchases and see something already? The answer to that lies in a file called config/routes.rb. The scaffold generator has added a line there:

This resources :purchases line is very simple, but it does quite a lot. This line generates routes for purchases actions that can be taken within this application. To see what those routes are, we can run this command:

Here’s the output for all the purchases routes from that command in a tabular form (we’ll ignore all those other routes for now!):

This one line in the config/routes.rb file has provided us with eight different routes. The one that we care about for the page we’re looking at right now is the top route:

When we make a request to http://localhost:3000/purchases in our browser, this will be a GET request. The route that matches this request in our Rails application is this top route, and it says that any GET request to /purchases will be routed to purchases#index.

This purchases#index syntax is a combination of two things, and it indicates the name of a controller and a name of an action.

A controller in a Rails application is a class that handles incoming requests and outgoing responses for the same kind of thing. In our application, the controller that serves this GET /purchases route is called PurchasesController, and it lives at app/controllers/purchases_controller.rb. That controller will handle all the actions that users can take with purchases within this application.

The action for this particular route is defined as a method inside this controller. When you hear "action" in a Rails application, you can think of it as being synonymous with "method defined inside a controller". Let’s look at the method for the index action now:

This index method calls out to a class called Purchase. This is a class that was generated when we ran our scaffold generator, and it’s defined in app/models/purchase.rb:

This class inherits from another class called ApplicationRecord, which was generated when we created our application:

This class inherits from ActiveRecord::Base, and it’s ActiveRecord::Base that defines the all method we’re using in the index action of the PurchasesController.

This Purchase.all call will run a query on our database to find all purchases that currently exist. There aren’t any right now, which is why we’re seeing a nearly blank page!

When the controller calls Purchase.all, it assigns the result of that call to @purchases, an instance variable.

The next thing that is used is called a view. A view is a template that is used to show information collected from our controllers. By default, actions within controllers will always render views that match the action’s name. The view that will be used to show the information collected by this index action is a file located at app/views/purchases/index.html.erb:

This view is written mostly in HTML, but you’ll notice a few extra things about it too. There’s two special kinds of tags here, called ERB tags. There’s <% %> and <%= %>. This kind of view is often referred to as an HTML+ERB view, as it is using another templating language called ERB along with HTML.

Inside <%= %> ERB tags, we evaluate Ruby code. This code runs, and whatever the Ruby code outputs will be displayed on the page. When we use an <% tag, the Ruby code is only evaluated, and the return value of that code is not put onto the page.

This view will be processed by Rails when it serves the request for GET /purchases, the Ruby code will be executed and the result will be pure HTML. Here is what the view is currently outputting:

There’s an empty div there where our purchases should go, but we don’t have any yet. We’ll see these appear soon.

So we have now seen how this page is built by Rails:

The way that this content gets on the page is:

Here’s a flowchart to help you understand what’s happening:

We’ve now seen our first example of the big five main components of a Rails application:

We’ll see these five things feature prominently in this book, as they really are the five pillars that Rails is built upon.

Three of these, the models, views and controllers are critical parts of the Model-View-Controller pattern we mentioned earlier in this chapter. This pattern is commonly used by applications (not just Rails ones!) in the programming world, as it is a nice way of organizing and separating different responsibilities within an application.

Now that we have seen how to list purchases, let’s look at another feature of our application that scaffolding has given us automatically: the ability to create a new purchase.

Let’s add a new purchase by going to http://localhost:3000/purchases and then clicking "New Purchase".

On this form, you will see two inputs for the fields you generated when you ran the scaffold generator:

You’ll notice in the URL bar in your browser that the route for this request is localhost:3000/purchases/new.

If we look at the rails routes output again, the route that matches this path is this one:

This route sends requests for GET /purchases/new to the new action within the PurchasesController. Let’s look at this action now.

This action initializes a new instance of the Purchase model, just so we can use it in the view. What you see on the page comes from the view located at app/views/purchases/new.html.erb, and it looks like the following listing.

This is an ERB file just like index.html.erb, the two ERB <%= tags here will evaluate some Ruby and output values. Let’s first talk about the render method.

The render method, when passed a string as in this example, tells Rails to use a partial. A partial is a separate template file that you can include into other templates to repeat similar code. Let’s go through this file now.

After creating a purchase, we arrive at a page that displays the information of the purchase we have just created:

The URL for this page is http://localhost:3000/purchases/2. The number at the end of the URL is the unique numerical ID for this purchase. The route that matches this path is this one:

This path goes to the show action in PurchasesController. Let’s look at that action now:

This action is blank, but Rails will still render the related view. Let’s look at that view for the show action:

On the first line is the notice method, which displays the notice set on the redirect_to from the create action.

After that, we see a call to <%= render @purchase %>. This is some Rails "magic" that takes the class of the passed-in object, and tries to render a partial matching that name. In this case, that partial will be called purchases/_purchase.html.erb.

You might expect the @purchase object to be defined in the show action of PurchasesController:

But it is not! Instead, this @purchase object is defined by a before_action in this controller, at the very top of the class:

A before_action method will be executed before every action specified in the only option: hence the name before_action. The find method of the Purchase class is used to find the record with the ID of params[:id] and instantiate a new Purchase object from it (params[:id] being the number on the end of the URL). We can know that the parameter will be called :id if we look at the URL in our routes again:

Where we have :id in the routes, whatever value is there in the path will be made available as params[:id] in a controller.

Going back to the view for this show action — app/views/purchases/show.html.erb — we now know where @purchase is coming from. The partial at app/views/purchases/_purchase.html.erb is then used to display information about this purchase:

This partial will display the name and cost of any purchase in this application.

Let’s go back to the show view now, and we’ll look at the links and buttons at the bottom:

At the end of this file is link_to, which generates a link using the first argument as the text value, and the second argument as the href for that URL. The second argument for link_to is a method: edit_purchase_path. This edit_purchase_path method is provided by the resources :purchases line in config/routes.rb, and we would call it a routing helper method.

Let’s look at our routing table one more time. Particularly, let’s look at the line that shows us the edit route:

The "Prefix" column shows the prefix that we can use for this route, and to get the path to that route we use edit_purchase_path. This will take us to the edit action within PurchasesController. Let’s take a look at that flow now.

Let’s change the cost of the "foo" purchase now. Perhaps it only cost 10. To change it, go back to http://localhost:3000/purchases, click the "Show this purchase" link under the "foo" purchase to go to the show page, then click "Edit this purchase". This will go to the route provided by edit_purchase_path route, which will be /purchases/2/edit. In our browser, we’ll see the route being http://localhost:3000/purchases/2/edit.

On this page, you should see a page that looks similar to the "New Purchase" page:

This page looks similar because it reuses the app/views/purchases/_form.html.erb partial that was also used in the template for the new action. Such is the power of partials in Rails: you can use the same code for two different requests to your application. The template for the edit action this action is shown in the following listing.

For this action, you’re working with a pre-existing object rather than a new object, which you used in the new action. This preexisting object is found by the edit action in PurchasesController, as shown here.

Oops: it’s not here! The code to find the @purchase object is identical to what you saw earlier in the show action: it’s set in before_action which runs before the show, edit, update and destroy actions.

Back in the view for a moment, at the bottom of it you can see two uses of link_to. The first creates a "Show" link, linking to the @purchase object, which is set up in the edit action of your controller. Clicking this link would take you to purchase_path(@purchase) or /purchases/:id. Rails will figure out where the link needs to go according to the class of the object given. Using this syntax, it will attempt to call the purchase_path method because the object has a class of Purchase, and it will pass the object along to that call, generating the URL.^[12]

The second use of link_to in this view generates a "Back" link, which uses the routing helper purchases_path. It can’t use an object here because it doesn’t make sense to; calling purchases_path is the easy way to go back to the index action.

Let’s try filling in this form—for example, by changing the cost from 100 to 10 and clicking "Update Purchase". You now see the show page but with a different message:

Clicking "Update Purchase" brought you back to the show page. How did that happen? Click the back button on your browser, and view the source of this page, specifically the form tag and the tags directly underneath, shown in the following listing.

The action of this form points at /purchases/2, which is the route to the show action in PurchasesController. You should also note two other things. The method attribute of this form is a post, but there’s also the input tag underneath.

The input tag passes through the _method parameter with the value set to patch. Rails catches this parameter and turns the request from a POST into a PATCH.^[13] This is the second (of three) ways /purchases/:id responds according to the method. The relevant line from rails routes is this line:

By making a PATCH /purchases/:id request, the request is routed to the update action in PurchasesController.

Let’s look at this next.

Just as in the show and edit actions, the @purchase object is first fetched by the call to before_action :set_purchase.

The parameters from the form are sent through in the same fashion as they were in the create action, coming through as purchase_params. Rather than instantiating a new object by using the new class method, you use update on the existing @purchase object. This does what it says: updates the attributes. What it doesn’t say, though, is that it validates the attributes and, if the attributes are valid, saves the record and returns true. If they aren’t valid, it returns false.

When update returns true, you’re redirected back to the show action for this particular purchase by using redirect_to. If the update call returns false, you’re shown the edit action’s template again, just as back in the create action where you were shown the new template again. This works in the same fashion and displays errors if you enter something wrong. Let’s try editing a purchase, clearing the name field’s value, and then clicking "Update Purchase". It should error exactly like the create method did:

As you can see by this example, the validations you defined in your Purchase model take effect automatically for both the creation and updating of records.

What would happen if, rather than updating a purchase, you wanted to delete it? That’s built in to the scaffold, too!

In Rails, delete is given a much more forceful name: destroy. This is another sensible name, because to destroy a record is to 'put an end to the existence of'.^[14] Once this purchase’s gone, it’s gone for good.

You can destroy a purchase by going to http://localhost:3000/purchases/2 and clicking the "Destroy" button:

When that purchase is destroyed, you’re taken back to the purchases index action. You’ll see that the record no longer exists. You should now have only one record:

How does all this work? Let’s look at the app/views/purchases/show.html.erb view, and its Delete button:

A button_to in Rails works similarly to a link_to. However, it generates more than just a button. If we were to look at the HTML generated by this one line, we would see all of this:

This button_to generates a whole form! When that button is pressed, it will submit this form. The _method field will route this request to the destroy action:

Let’s look at this action now:

This action destroys the record loaded by before_action :set_purchase by calling destroy on it, which permanently deletes the record. Then it uses redirect_to to take you to purchases_url, which is the route helper defined to take you to http://localhost:3000/purchases. Note that this action uses the purchases_url method rather than purchases_path, which generate a full URL back to the purchases listing.

That wraps up our application run-through!

Rails follows strict conventions, such as MVC (Model View Controller). With these conventions, every Rails application is built in much the same way, which allows developers to be able to work on any Rails application with ease.

This also means that we’re not going to have to make decisions about the architecture of our Rails application. Rails has made those decisions for us already, and so we can get started on building our application right away.

The five main pillars of a Rails application are:

Routes tell our application what controller and what action should serve our request. Actions that work on the same resource (a purchase in our application) are grouped within a single controller. To put it simply: routes are a way to match a request’s path to a controller and an action within the application.

Controller actions use a model to interact with the database. This can be anything from creating new purchases, to finding all purchases, to updating purchases, to deleting purchases. Any actions that we take on our purchase data goes through our model first.

Finally, the views are used to combine HTML and Ruby to produce dynamic HTML content which is then served to our browser. Without these, we wouldn’t be able to see the data that the controller was fetching in the first place!

The scaffold generator provides us with a total of seven different actions we can do on a particular resource:

The scaffold generator gave us these actions, and their relevant templates. It’s a great example of how to quickly build something with Rails.