One of the beautiful things about the Rails framework is the way that it codifies a number of best practices into an easy to get started, customizable, and highly documented tool. Why reinvent the wheel building up a boilerplate app when you can rely on some of the great minds who already did so, and focus your time on your own innovations? Rails generators are just one of the many things that allows Rails to power up great apps in a relatively short timeframe. We'll touch on some basics below.
The basic format of a Rails generator is
<rails generate generator-name details...>. This can also be shortened with the alias for
<rails g generator-name details....>. In these examples, I'll use the alias
g, but they can be written either way. For this example, we'll imagine that we are building an application with Book, Author, and Publisher models.
<rails g model Modelname>
rails g model Book
This will create an empty migration for the books table, a Book model, plus the test files for the Book model.
<rails g migration camel_case_description_of_migration column_name:data_type>
rails g migration add_name_column_to_books name:string
This will create a fully populated migration file that looks like:
<rails g controller Pluralname [action action] [options]>
rails g controller Books new create show update
This is a great generator to use in tandem with the Model and Migration generators. This example of the Controller generator will create a BooksController, complete with the boilerplate for actions listed in the generator (new, create, show, update) as well as view files for each of those actions. In addition, this will create routes for the listed actions, plus an associated scss file, and additional tests for the created items
<rails g resource Modelname column_name:data_type>
rails g resource Author name:string
The resource generator builds on the above three controllers while offering some slight variation. It will generate a migration file to create the authors table, complete with any options we passed in, here a name column with a string datatype. This will also generate the Author model, AuthorsController, a view folder for the author related view pages, a helper file, the full authors resource for routes, associated tests, and a scss file.
<rails g scaffold Modelname column_name:data_type>
rails g scaffold Publisher name:string
The Scaffold generator is the most robust generator. This builds a complete app according to boilerplate Rails standards. If you are quickly bootstrapping an app and want to follow all the conventions, this can be a great option to get something off the ground very quickly. I won't list all the files this generates, but the Rails documentation shows a full list. One note, in most cases you won't be building an app that completely follows conventions so this generator is used less often than other ones.
One of the great things about using Rails generators is that you can populate most of the details of your
belongs_to relationships via the command line. Rails will also work behind the scenes during database lookups to enforce requirements of these relationships when they are generated in this way. Using our examples above, we can imagine that a book belongs to an author. If we re-create our Book, we can add this relationship in:
rails g resource Book name:string author:references
<rails g task task_name>
rails g task track_books
This will create a task file located in the
tasks folder (
lib/tasks/track_books.rake) where you can define tasks that you need in your app.
This will do the reverse action of the associated generator and completely roll back whatever is included in the description. This full name of this command is
destroy, but it can be aliased as
<rails d model Name>
rails d model Book
This example rolls back everything that was created with the command
rails g model Book, destroying the associated test files, the Model, and the boilerplate migration.
I'll leave you with a final benefit to using generators when you can. As much as typing less to create more allows you to save time, generators also offer built in protection against typos and some anti-patterns. The human brain can only remember or see so much. Even while I was typing up this blog post, I was positive I had spelled "codefies" correctly and there was some other reason it had the squiggly line below it. (Turns out it really is "codifies", not "codefies" and an "e" is not an "i"...) So developers are prone to making mistakes. Sometimes those mistakes result in massive debugging efforts, but if you can avoid that, you may as well.
Top comments (0)