This post was written by Flatiron student Rachel Nackman and originally appeared on her blog. Check it out to learn more about Ruby and Rachel’s journey to becoming a developer at the Flatiron School. Want to join Rachel and hundreds of other students who have changed their career through code? Check out the Flatiron School’s upcoming courses near you.
We’ve been using the built-in generators in Rails quite a bit as our labs progress in complexity, and we’ve all marveled at the amount of work that happens behind the scenes when we run these simple commands. This magic can be unnerving, but as we know, the tricks are based on pattern and strong convention. Pattern and convention notwithstanding, I’ve found that it can be difficult to keep track of which components each generator will create. We need to remember how each generator performs so that we can decide which combination of generators meets our specific needs. Below is a (non-exhaustive) quick reference sheet, living in a public Google spreadsheet that I’ll try to keep updated as we learn. For now, the generators covered here represent those we’ve used most frequently in our labs.
Rails Generator Quick Reference
Note that this quick reference is not nearly as robust as the help option available to you from the command line. This is meant to be used simply as an at-a-glance memory jogger. There are a number of other default generators not yet included on the list. You can even generate your own generator using the generator generator, which I hope to do one day. Get full information about all generator options by running
rails generate --help
or to learn about a specific generator, try
rails generate scaffold --help
You can substitute scaffold for any other default generator. In the quick reference, I’ve included abbreviated versions of the file names created by the generator if you name the component you’re generating the singular example.
rails generate scaffold example
Say you generate a component that you then decide you’d like to remove from your application. You can destroy the set of files you’ve generated by running, for example:
rails destroy scaffold example
This will step through each of the files created by the referenced generator and delete them. Most of the generators in the quick reference will add stub files to the test unit for each of the components you’ve added to the application. In many of our labs, these test units have already been created, and we don’t want to overwrite them by generating blank new files. One way to skip over the creation of test units as we generate components is to append the --no-test-framework option to our generator commands:
rails generate scaffold example --no-test-framework
But I tend to forget to do this, and I often find that I want to undo my generator commands. One very important problem with this strategy: destroying a series of generated files will also destroy and remove any files that the generator has overwritten. The destroy command does not simply roll back your last generator. So in the case of the test framework, if you leave off the --no-test-framework option by accident, destroying the generated files will completely remove a bunch of tests. I learned this the hard way: I showed up at school one morning thinking I’d breezed through a lab and gotten all the tests passing. And I had – but only because I’d deleted a significant portion of the specs. You can circumvent faulty (human) memory issues here by adding a line to your config/application.rb file:
module Testing
class Application < Rails::Application
# ...
config.generators.test_framework false
end
end
This should allow you to generate without including the --no-test-framework option – and without overwriting your tests.Want to become a Ruby expert like Rachel? Learn more about Flatiron’s web development courses near you.
