Icons/logo Webcrunch
Andy from Webcrunch

Subscribe for email updates:

Portrait of Andy Leverenz
Andy Leverenz

December 2, 2017

•

Last updated November 5, 2023

A Twitter Clone - Let's Build: With Ruby on Rails

Welcome to our next Let's Build! This build introduces a well known social media giant Twitter into the mix as inspiration for the project. We will be creating a knock-off of sorts called Twittter.

This app will most notably demonstrate a user role system giving your web application and native application feel all within the browser. I'll be going a bit faster than the previous build as it was more of a foundational exercise where I explained common concepts revolving around the Ruby on Rails ecosystem. We'll make use of Rails generators to help scaffold some of the things I've already covered. If you haven't watched the first Let's Build, I invite you to do so in order to understand what we are doing.

Download the source code

Download the source code

What we are building

The app itself will feature a basic CRUD principle where we can create, read, update, and destroy Tweeets. In essence, this is the same as my previous build where we created posts for a blog. On top of the Tweeets, I introduce a new gem called Devise which makes creating an entire user role and authentication system easy. Combined with this gem we can authenticate users who want to author Tweets. A user's Tweeets are then also tied to their account. The end result is a public-facing site with a stream of tweets from different users. Users that have an account can log in to create their own Tweeets to add to the public stream.

What we won't be covering

Twitter is a pretty elaborate application. I won't be covering replies, retweets, likes, and quite a few other foundational features of the famous social media giant. Instead, I invite you to tinker with how to possibly add those features. Similar to the blog with comments build I did, see if you can figure out how to add replies to the application on your own. (Tip: It's the same as adding comments to the blog post as I did in the previous build ;) ). I may revisit this app to add more features to another exercise but I truthfully ran out of time! Let me know if you'd like to see me extend this further.

There are also a few gems in the wild for "liking" posts. Here's a favorite of mine

Note: One big error I noticed after calling it quits on this build was that any logged in the user could edit any other user's tweeets. This is a big security flaw as a user's abilities should only lie within their own account. See if you can find a way to only allow the current logged in user to edit their own tweets and not other users. I may revisit this series to extend and address these issues.

Watch Part 2

Watch Part 3

Ruby gems used in this build

  • Better Errors - For better errors

  • Bulma - for easy CSS. Feel free to roll your own styles and/or use a different framework.

  • Guard - Useful for live reloading our scss, js, css, and erb files, although it's capable of much more!

Guard is required for the Guard LiveReload gem to work

How I Extended Devise

As promised in the video I talk about extending the Devise gem to bypass the default registrations controller and apply our own. I referenced a blog post which helped me wrap my head around what's really going on. I definitely invite you to check it out to understand it a bit better yourself. To add any additional fields to the Devise model you use, this step is 100% required.

In my case, I added the name and username fields to the registration process. I needed to create a registrations controller which contains the following:

# app/controllers/registrations_controller.rb

class RegistrationsController < Devise::RegistrationsController 

    private

    def sign_up_params 
        params.require(:user).permit(:name, :username, :email, :password, :password_confirmation)
    end

    def acount_update_params 
        params.require(:user).permit(:name, :username, :email, :password, :password_confirmation, :current_password)
    end

end

The controller extends from the default Devise registrations controller. We append the name and username fields to the user model/table and make use of Rails strong parameters to make it all tie together.

Adding the fields to the database

We still require a couple of new columns in our users table inside our database to get this to work. To add these you need to run a migration. Run the following: 

$ rails g migration AddFieldsToUsers

Then head to db/migrate/XXXXXXXXXXXXXX_add_fields_to_users.rb to find the new migration. When it's all said and done I added the following:

class AddFieldsToUsers < ActiveRecord::Migration[5.1]
  def change
    add_column :users, :name, :string
    add_column :users, :username, :string
    add_index :users, :username, unique: true
  end
end

We are adding two columns to our users table which consist of the name and username field we want to add to our registration forms. I go one step further and make sure the username field is authored as unique which basically just means that no two users can use the same username.

With those fields and migration in place, you can go ahead and run rails db:migrate to make it all tie together.

Modifying the devise views

In app/views/devise/registrations/new.html.erb you can add the following updated code to reflect our most recent changes.

<!-- app/views/devise/registrations/new.html.erb -->
<div class="section">
    <div class="container">
    <div class="columns is-centered">

        <div class="column is-4">

        <h2 class="title is-2">Sign Up</h2>

        <%= simple_form_for(resource, as: resource_name, url: registration_path(resource_name)) do |f| %>
      <%= f.error_notification %>

      <div class="field">
        <div class="control">
        <%= f.input :name, required: true, autofocus: true, input_html: { class:"input" }, wrapper: false, label_html: { class:"label" } %>
        </div>
        </div>

        <div class="field">
        <div class="control">
        <%= f.input :username, required: true, input_html: { class:"input" }, wrapper: false, label_html: { class:"label" } %>
        </div>
        </div>

        <div class="field">
        <div class="control">
        <%= f.input :email, required: true, input_html: { class:"input" }, wrapper: false, label_html: { class:"label" } %>
        </div>
        </div>


        <div class="field">
            <div class="control">
                <%= f.input :password, required: true, input_html: { class:"input" }, wrapper: false, label_html: { class:"label" }, hint: ("#{@minimum_password_length} characters minimum" if @minimum_password_length) %>
            </div>
        </div>

        <div class="field">
            <div class="control">
                <%= f.input :password_confirmation, required: true, input_html: { class: "input" }, wrapper: false, label_html: { class: "label" } %>       
            </div>
        </div>

        <div class="field">
            <div class="control">
                <%= f.button :submit, "Sign up", class:"button is-info is-medium" %>
            </div>
        </div>

        <% end %>
            <br />
            <%= render "devise/shared/links" %>
        </div>
        </div>
    </div>
</div>

Here I make use of Bulma as well as add our name and username fields to the form. You will want to repeat this change on the edit.html.erb file in the same directory.

<!-- app/views/devise/registrations/edit.html.erb -->

<section class="section">
  <div class="container">
    <div class="columns is-centered">
      <div class="column is-4">

      <h2 class="title is-2">Edit <%= resource_name.to_s.humanize %></h2>
      <%= simple_form_for(resource, as: resource_name, url: registration_path(resource_name), html: { method: :put }) do |f| %>
        <%= f.error_notification %>

          <div class="field">
            <div class="control">
              <%= f.input :name, required: true, autofocus: true, input_html: { class: "input"}, wrapper: false, label_html: { class: "label" } %>
            </div>
          </div>

          <div class="field">
            <div class="control">
              <%= f.input :username, required: true,  input_html: { class: "input"}, wrapper: false, label_html: { class: "label" } %>
            </div>
          </div>

          <div class="field">
            <div class="control">
              <%= f.input :email, required: true, input_html: { class: "input"}, wrapper: false, label_html: { class: "label" } %>
            </div>
          </div>

          <div class="field">
          <% if devise_mapping.confirmable? &amp;&amp; resource.pending_reconfirmation? %>
            <p>Currently waiting confirmation for: <%= resource.unconfirmed_email %></p>
          <% end %>
          </div>

          <div class="field">
            <div class="control">
            <%= f.input :password, autocomplete: "off", hint: "leave it blank if you don't want to change it", required: false, input_html: { class: "input"}, wrapper: false, label_html: { class: "label" } %>
            </div>
          </div>

          <div class="field">
            <div class="control">
            <%= f.input :password_confirmation, required: false, input_html: { class: "input"}, wrapper: false, label_html: { class: "label" } %>
            </div>
          </div>

          <div class="field">
            <div class="control">
              <%= f.input :current_password, hint: "we need your current password to confirm your changes", required: true, input_html: { class: "input"}, wrapper: false, label_html: { class: "label" } %>
            </div>
        </div>

        <%= f.button :submit, "Update", class:"button is-info" %>

      <% end %>

        <hr />
        <h3 class="title is-5">Cancel my account</h3>
        <p>Unhappy? <%= link_to "Cancel my account", registration_path(resource_name), data: { confirm: "Are you sure?" }, method: :delete %></p>

      </div>
    </div>
  </div>
</section>

It's up to you what you want to "require" from a user. I noticed after the fact that the edit.html.erb the form doesn't necessarily need so many required fields. Feel free to extend/modify this to your liking.

Wrapping Up

The main purpose of this build was to reintroduce techniques and terminology used in the previous build. On top of the previous build, I went one step further and introduced authentication and user roles. We didn't build a fully functioning Twitter clone but we did take bits and pieces to create something similar.

You are welcome to extend this project further. I may even do so myself as time carries on just to resolve some bugs I spotted along the way as well as integrate new technologies and features into the mix. I hope you enjoyed the build as much as I did. As we press forward I plan to introduce more concepts and ideas for app builds of which you could make on your own. See you in the next build!

Credits

Music credit in part 2 - https://soundcloud.com/argofox

The Series So Far

Shameless plug time

Hello Rails Course

I have a new course called Hello Rails. Hello Rails is a modern course designed to help you start using and understanding Ruby on Rails fast. If you're a novice when it comes to Ruby or Ruby on Rails I invite you to check out the site. The course will be much like these builds but a super more in-depth version with more realistic goals and deliverables. View the course!

Follow @hello_rails and myself @justalever on Twitter.

Tags: clone rails ruby ruby on rails
Previous Let's Build: With Ruby on Rails - A B...
Next Let's Build A Dribbble Clone With Rub...
Read later
Link this article
Est. reading time: 9 minutes
Stats: 4,469 views
Source code: Icons/download Source code

Categories

Collection

Part of the Let's Build: With Ruby on Rails collection

Icons/chevron up