What are we building?
Let's learn Rails by building a simple web application. Let's name it
after a type of rock.
The application will be a simple todos for the whole company of small size. The application will have the following features.
- Users will be able to prioritize the tasks by starring them. These starred tasks will be shown first in the list.
- Users can toggle the task as pending or done.
- Task creators can delete/edit the task.
- Users can add comments to the tasks. These comments cannot be edited/deleted.
Our goal is to learn the process of writing a Ruby on Rails application with React.js.
Here's the working demo of the application. Here is the info needed to login.
1email: firstname.lastname@example.org 2password: welcome
Setting up a new Rails application
Let's build a brand new Rails application. Rails offers us a command-line utility to build a brand new Rails application.
Run this command to generate a new Rails application with a specific Rails version:
1rails _6.1.4_ new granite --skip-turbolinks
It will produce a long output and might take some time to complete. It is downloading and setting up required files from the internet.
Setting a specific Webpacker version
Run the following command from the root of the project, in the terminal:
1yarn add @email@example.com
If you're curious about why we use a specific version of
webpacker module, you
can give the
a read and come back.
Update to stylesheet pack tag
The default Rails application erb template file,
In that file, we need to replace
Thus update it like so:
We will discuss in depth about why we need to do this replacement towards the end of the book.
If you're very curious and don't mind the verbosity/complexity at this early stage itself, then you can give this section a read to understand about Webpacker's CSS compilation in depth.
Configuring default Ruby and Node.js versions
We can lock our application with a specific Ruby and Node.js version. This will help us to isolate the dependencies of Ruby and Node.js modules used in the application.
In our application we will use Node.js version
16.4.2 and Ruby version
Run the following commands from the terminal:
1echo "16.4.2" > .nvmrc > .node-version 2echo "3.0.1" > .ruby-version
These files will be read by
nvm to auto-set the versions.
Now run the following commands from the terminal to ensure that our project is currently using these specified versions:
1rbenv install 2nvm install
The above commands should ideally point out that the specified versions are already installed and you can safely exit. If that's not the case, then please go ahead with the installation of the required versions, using the same commands.
Fixing rexml gem issue
We are not going to use some of the auto-generated gems for testing. Thus let's
remove those unwanted gems, among which there are
selenium based gems that may
rexml dependency issue.
Run the following command from the terminal:
1bundle remove capybara selenium-webdriver webdrivers
The above command should've removed those unwanted gems from the
Updating .gitignore file
We don't need all of the generated files to be version-controlled. To ignore
these unwanted files, we specify them in the
.gitignore file. BigBinary has
specified a standard set of folders and files to be ignored by git in the
Run the following command from the terminal, in the root of the project, to use that config:
1curl -o ".gitignore" "https://raw.githubusercontent.com/bigbinary/wheel/master/.gitignore"
.gitignore file should be visible in your project's root.
In a future chapter we will see why we are removing fixtures. For now let's just go ahead and disable the fixtures.
To disable using fixtures open
test/test_helper.rb and comment out the line
1# fixtures :all
Execute the following lines on the terminal to delete the fixtures folder completely:
1rm -rf test/fixtures
Ensure fixtures wont get generated
Rails provide several generator commands that helps in generating boilerplate code for models, controllers, migration scripts, etc. We will be using them throughout the book.
But, with some of those generators, fixture files also get generated by default. We won't need those fixture files.
Fortunately, we can customize Rails generators to disable auto-generation of fixtures for all the commands.
To do that, add the following lines in
1require_relative 'boot' 2require 'rails/all' 3 4Bundler.require(*Rails.groups) 5 6module Granite2 7 class Application < Rails::Application 8 # previous code if any 9 13 end 14end
For simple applications, we can always rely on using
Active Record queries to
create seed data for tests instead of fixtures. We will learn about them in the
SQlite3 database is the default database for a newly created Rails application.
Run this command to create databases for our application:
1bundle exec rails db:create
The output will look like this:
1Created database 'db/development.sqlite3' 2Created database 'db/test.sqlite3'
Starting the server
Now let's start the server. Run this command:
1bundle exec rails server
The output would look like this:
1=> Booting Puma 2=> Rails 6.1.4 application starting in development 3=> Run `rails server --help` for more startup options 4Puma starting in single mode... 5* Version 4.3.6 (ruby 3.0.1-p64), codename: Mysterious Traveller 6* Min threads: 5, max threads: 5 7* Environment: development 8* Listening on tcp://127.0.0.1:3000 9* Listening on tcp://[::1]:3000 10Use Ctrl-C to stop
Open browser and visit http://localhost:3000. We will see a page that would look like this:
Before committing the files, let's verify whether our Ruby and Node.js versions are the required versions or not, by running the following commands from terminal:
1rbenv version # should be 3.0.1 2nvm version # should be 16.4.2
Once verified, add this new application to git:
1git rm -r --cached . # to reapply gitignore 2git add -A 3git commit -m "Initial commit"