The Rails ActionView date helper
time_ago_in_words takes an argument, for example,
Time.now and outputs elapsed time since the input in prose. How fun is that?!
Some examples from the documentation:
An alias for the
time_ago_in_words method is
The Rails helper
to_sentence takes an array and converts it to a comma separated sentence, where the last element is joined by a connector word, for example:
Joyous! Here’s the documentation.
div_for works very similarly to
form_for but is specifically for divs.
Div_for creates a
div element with an id and class parameters that reference the specified Active Record object. Particularly useful if you want to iterate through a collection of divs.
Here’s a quick example:
Note: With Rails 5,
div_for was removed from core Rails and moved to the record_tag_helper gem.
Did you know that you can include
belongs_to in your table migrations?
belongs_to in your migration, the Rails generator knows to add the corresponding
belongs_to in the object model.
In the following example…
t.belongs_to :category produces the corresponding model:
belongs_to in your table migrations is also an alias for
t.references. Read more about Rails associations here.
You may have noticed in the example above that Ryan Bates is using
def up and
def down vs.
In most cases, Rails can guess the reverse of your migration, for example,
remove_column. There, writing your migrations with
def change makes sense and Rails will know the reverse and execute it on
rails db:rollback. See the Rails guide on using the change method for a list of all supported migration definitions.
However, in cases where Rails can’t automatically match the reverse action, be specific and write separate up and down migration definitions.
For example, if you wanted to change the precision of a decimal point in your database, Rails couldn’t automatically guess the original precision on rollback, and separate up/down migration definitions are required. Here’s the code:
Lastly, you may have seen routes defined with
resources, but there’s also an option called
resource. The difference is subtle but an important semantic one that signals to other developers your intent and what they can expect from the application.
You would use the singular
resource to indicate that only a single resource will ever exist, for example a user dashboard. Two differences in behavior to note with the singular
resourcedoes not define routes with an
id, since a singular resource does not need serialized ids
resources still map to plural controllers
Below is an example of routes with a singular
resource adapted from the Rails guide on singular resources:
|HTTP Verb||Path||Controller#Action||Used for|
|GET||/dashboard/new||dashboards#new||return an HTML form for creating the dashboard|
|POST||/dashboard||dashboards#create||create the new dashboard|
|GET||/dashboard||dashboards#show||display the one and only dashboard resource|
|GET||/dashboard/edit||dashboards#edit||return an HTML form for editing the dashboard|
|PATCH/PUT||/dashboard||dashboards#update||update the one and only dashboard resource|
|DELETE||/dashboard||dashboards#destroy||delete the dashboard resource|