Rails%203%20In%20Action

Page and action caching
The next time you reload this page in your browser, you’ll see this line in your server’s
output:
Write fragment views/localhost:3000/projects/1 (3.0ms)
Look familiar? It’s exactly the same output generated by caches_action. The cache
method that you just used assumes that it’s only being used once per page and so will
save it with the same path (more commonly referred to as the cache key). You had a
problem with this initially, didn’t you?
Yes, you did. It was saving the page name just fine, but it didn’t care if you were on
your first page of pagination or the last, it was always showing the first cached page. If
you click the Next link on your pagination, you’ll find that you’ve regressed this
behavior accidentally. Not to worry, this is easy to fix. You need to tell your cache
method that there’s more than one type of this page. You can do that by passing a
string containing the page number to the method to give it a unique name, or key. By
making this key unique for each page, Rails will cache a list of tickets for each page
rather than one for all.
To fix this, change the cache call in your app/views/projects/show.html.erb file to
this:
When you refresh this page and switch back into the terminal where your server is
running, you’ll see this line of output:
Write fragment views/projects/1/1 (3.3ms)
You’ve specified the key that the cache now uses to store the fragment, and so you’ll
see that it’s saved it as views/projects/1/1 now, with the first 1 being the ID of your
project and the second one being the page number. If you create, update, or delete a
ticket, you’ll see that this fragment gets cleared away.
Expire fragment (?-mix:projects\/1\/.*?) (1.9ms)
The next time you revisit the project’s page, you’ll see that it rewrites the fragment
again:
Write fragment views/projects/1/1 (1.5ms)
In this section, you’ve seen that fragment caching is useful not only for caching
dynamic actions with caches_action, but also for caching small chunks of pages by
using the cache method. The latter allowed you to cache a small fragment of the page
rather than the entire page, which is great if you have a small chunk of the page that
takes a long time to render. You didn’t, but it’s always good to know what tools are
available if you come up against this particular beast.
With the cache method in the view, you don’t have to set the cache_path for the
user because you’re only caching the part of the page that is user-agnostic. Everything
else in either the layout or elsewhere in this view would be processed each time the
page is requested, but the part you have cached will be retrieved from that cache and
461