Building our Rails app Part 1: Intro to Rails

Img 1040
Steve Brewer
Over 1 year ago

I'm going to run through how I built this site using Ruby on Rails over a series of posts. For the first post, I'll start with my explanation of how Rails works.

How Rails works

I imagine Rails to be like a big robotic factory with three arms: Models, Views and Controllers. These arms do most of the heavy lifting for you and it makes a lot of assumptions so you spend less time typing the same lines of code over and over. For example, create a users resource in the routes.rb file:

resources :users

Then Rails will generate URLs for index, show, edit, update, new, and create for your users 'model', which will be all your data about your users.

Rails calls pages 'views'. If you create a file called "/views/users/show.html", Rails will take users to that show view and display the HTML content you add to that file. That's time saved typing out directions to Rails so you can achieve more, faster.

The show view is used to display an individual instance of a model, e.g. for a user it will show their profile. The index is the list of all the users, and would be called 'index.html' in the same 'views' folder.


The models take care of the data in the database - like the users table, all the attributes each user has such as email address and interests they've added to their profile. The model is where you tell Rails what the relationships between the databases are, such as how a user "has_many" posts and how posts "belong_to" users.


These are the pages Rails shows to the user. Generally, by Rails convention - a set of patterns Rails assumes to be the case for what you're building - each 'thing', such as the user, will likely have:

An index view - this usually displays a list of all users/posts/products

A show view - this is the view for displaying an individual user (in this case the profile page)

An edit view - this is the form for editing the user

A new view - we didn't create this as we use Omniauth to register users with GitHub, but it would be a sign up form that creates a new user, probably the same form as the edit form but it's submitted to the controller new action rather than edit, so the controller creates a new user rather than editing an existing one.


The controller decides what to present in the view and fetches it from the database, and what to do to the model when the view sends back requests, if anything. As I just touched on, if a user fills out the user form and is on the 'new' page, then our controller should contain:

def new
  @user = user_params

By convention, if you submit form data to the "users/new" url it will follow the action defined above, so the controller will tell the database to create a new user using the 'params' (data it receives from the HTML form). If the user entered their name into the name field, the controller will shove the value of that field into the name column on the database and save it. 

If it were the edit page however, we'd write this in our controller and based on the page name, Rails would action the following:

def edit
  @user = User.find(params[:id])

This will find the user with the ID that's in the URL (which probably came from the link clicked on the page before, maybe the index page). The page you'd be on is "users/1" for user 1. So Rails will take the data entered in the view's html form and send it to the update action, which we define as:

def update
  @user = User.find(params[:id])
  if @user.update(user_params)
    redirect_to user_path(user_params)
    render :edit
    flash[:alert] = 'Something went wrong updating your profile'

This finds the user again from the parameters in the URL, and if it can update them with the form data, it will do so and then carry out the code written inside the 'if' statement above and take the user to the user show page for that user (back to the profile). 

If the user couldn't be updated, maybe the form failed validation, it returns the user to the edit page. It's a good idea to enter a line after the render to flash a notice to the user letting them know what happened. 

Further down the user controller we'd define user_params so Rails knows what that is (just like creating a function in JavaScript):

def user_params
  params[:user].permit(:name, :bio, :job_title, :twitter, :instagram, :github, :facebook, :linkedin, :website_url, interests_attributes: [:id, :name, :_destroy], skills_attributes: [:id, :name, :_destroy])

We have to explicitly tell Rails what data to allow in from a form. This is called "strong params", but it just means if we don't mention :name, Rails will ignore the user's name when the form is submitted. 

In my next post, I'll run through the basics of setting up a Rails app. 




Sign in with GitHub to comment
Sign in