The Amazing Power of Rails Generators

I was in my second month of learning computer coding when the curriculum took me into Rails Application Basics. I wasn’t sure what all this meant and it was confusing at first what each generator did and when I should use them. After getting to know how these powerful tools functioned, they became my favorite tools in basic Rails app development.

One of the hardest things to get right when developing Rails apps, or any coding for that matter, is syntax. Words within each model, controller, and migration vary on when to be plural and when to be singular. Sometimes we use camel case to write things while other times snake case is appropriate. This was the most frustrating thing for me because my errors would throw my entire app off. Enter Rails Generators!!

I will first start by saying that these generators are tools. That means that each one has a purpose and should be used to handle the right job. I am going to discuss (as much as I can, being 2 months into coding) what the basic tasks of each generator are and when to use each tool.

To start, all Rails generators follow the same basic set up when typing them into the terminal. rails generator <type of generator> <options>. There are four main types of generators:

• Migrations
• Models
• Controllers
• Resources

Note: generator can be abbreviated to just g in the terminal command. Also, a good idea is to add --no-test-framework to the <option> part of the code because rails will automatically create test files with any generator. This could cause issues and/or a lot of unnecessary test code.

Migration Generator

This creates a simple migration that will assist with creating or editing tables in the app. One example of a migration generator:

rails g migration CreateSongs name:string genre:string artist:string release_date:date --no-test-framework

This generator will create the following song table migration in the app. We can then edit this table in the created file if we want, as long as we haven’t run our migrations ( db:migrate ).

class CreateSongs < ActiveRecord::Migration[6.0]
  def change
    create_table :songs do |t|
      t.string :name
      t.string :artist
      t.date :release_date
      t.timestamps
    end
  end
end

A migration generator can also be used to add to or edit a table. This is usually used if a migration to create the new table has already been run. Let’s say we want to add genre to the songs table above. Enter the following in the terminal: rails g migration add_genre_to_songs genre:string --no-test-framework.
Notice we use snake case here and Rails is smart enough to generate the right file. This migration generator would give us the following migration within our app:

class AddGenreToSongs < ActiveRecord::Migration[6.0]
  def change
    add_column :songs, :genre, :string
  end
end

One major disadvantage of using the migration generator is that it still leaves room for errors in filenames being misspelled as well as not being properly pluralized, throwing off our entire app from the start. It also leaves room for human error when it comes to not setting up tables properly or forgetting to add all the table attributes. There is nothing worse than getting a good way into developing your app, realizing a table wasn’t migrated properly, and having to start over or write a bunch more migrations to correct early issues.

Model Generator

This is perhaps the most used generator when developing Rails apps. The model generator can set up the tables as well, while it also sets up the corresponding model files and properly spells each model and filename. A sample model generator would look like this:

rails g model Song name:string artist:string genre:string release_date:date --no-test-framework.

That would create the same table migration as above, as well as song.rb in our app/models folder of the app. The terminal output, which describes what was executed, would look like this:

invoke  active_record
create  db/migrate/20200711025914_create_songs.rb
create  app/models/song.rb

Model generators eliminate a lot of human error in connecting the model and its tables to each other, however, it still leaves us with work to do. We must set up our models and associate them with each other. Then we must also still create the proper controllers for each model, make sure they are all spelled correctly, and placed in the right positions for the app to work.

Controller Generator

This generator will create a controller, a views folder for the controller, helper file for the controller (not always needed), routes for our controllers to call views, and some stylesheet files for CSS. The invoke coffee command that the controller generator outputs creates coffee files, which is a type of Javascript file.

The controller generator is primarily used after table migrations have been run and models have been created and properly associated with one another. After all that is done, we are left with creating the views we need for our app and any associated CSS (if we so choose). The following is an example of what files would be created with
rails g controller song index show new --no-test-framework :

create app/controllers/song_controller.rb
route get ‘song/index’
route get ‘song/show’
route get ‘song/new’
invoke erb
create app/views/song
create app/views/song/index.html.erb
create app/views/song/show.html.erb
create app/views/song/new.html.erb
invoke helper
create app/helpers/song_helper.rb
invoke assets
invoke coffee
create app/assets/javascripts/song.js.coffee
invoke scss
create app/assets/stylesheets/song.css.scss

Resource Generator

The most inclusive generator of these four main types is the resource generator. This generator adds routes, controllers, models, and tables. All the file names are properly spelled and pluralized. We run the following code:

rails g resource Song name:string artist_id:integer genre_id:integer --no-test-framework

And this is all the things the generator does in the app:

invoke  active_record
create  db/migrate/20200711041330_create_songs.rb
create  app/models/song.rb
invoke  controller
create  app/controllers/songs_controller.rb
invoke  erb
create  app/views/songs
invoke  helper
create  app/helpers/songs_helper.rb
invoke  assets
invoke  scss
create  app/assets/stylesheets/songs.scss
invoke  resource_route
route   resources :songs

All we are left to do is put any associations in the models ( belongs_to, has_many, etc. ), any actions in the controllers to display views, and set up the views in the appropriate folders that have already been named. The cool thing is that this generator can set up a basic app with very few, if any, unnecessary files or code in our app.

Each generator tool has its pros and cons, so chose wisely. To recap;

• Use a migration generator when creating or editing a table migration
• Use a model generator to create a model AND a corresponding table
• Use a controller generator to create routes, CSS for views, and controller AFTER models and tables are set up
• Use a resource generator to create ALL associated files of the model, table, controller, and routes

I personally like the resource generator the best because I can put my primary focus on just making sure the views are displaying correctly. Each persons’ preference will vary based on abilities and what needs to happen within the app. I hope this will help you decide which generator tool is best when building your app.

This post is written by a Power Code Academy Student Developer.