Caching In Cells: API Change In 3.10.

{{{
The caching layer in “Cells”:https://github.com/apotonick/cells just got an update. By using the new “uber”:https://github.com/apotonick/uber#dynamic-options gem we could generalize the processing of options resulting in a more streamlined experience for you.

h3. What Changed?

For those of you already using Cells’ caching, *please update your code when updating to 3.10!*

Blocks do not receive the cell instance as the first argument anymore – instead, they’re executed in the cell instance context.

And, the best: There’s no deprecation for this!

What used to be this…

class CartCell < Cell::Rails
  cache :show do |cell, options|
    cell.md5
  end

…you have to change to the following.

class CartCell < Cell::Rails
  cache :show do |options|
    md5
  end

Note how we simply got rid of the first block parameter.

h3. Caching In Cells.

Cells allow you to cache per state. It’s simple: the rendered result of a state method is cached and expired as you configure it.

To cache forever, don’t configure anything

class CartCell < Cell::Rails
  cache :show

  def show
    render
  end

This will run @#show@ only once, after that the rendered view comes from the cache.

h3. Static Cache Options.

Note that you can pass arbitrary options through to your cache store. Symbols are evaluated as instance methods, callable objects (e.g. lambdas) are evaluated in the cell instance context allowing you to call instance methods and access instance variables.

cache :show, :expires_in => 10.minutes

This is passed right to the underlying store.

h3. Dynamic Options.

If you need arbitrary dynamic options evaluated at render-time, use a lambda.

cache :show, :tags => lambda { |*args| tagged_as }

In case you don’t like blocks, use instance methods instead.

class CartCell  :cache_tags

  def cache_tags(*args)
    ["updated", "revisited"]
  end

Those evaluated options along with their key are simply passed to the cache store.

h3. Building Your Own Cache Key.

You can expand the state’s cache key by appending a versioner block to the @::cache@ call. This way you can expire state caches yourself.

cache :show do |options|
  options[:items].md5
end

The block’s return value is appended to the state key, resulting in the following key.

 "cells/cart/show/0ecb1360644ce665a4ef"

h3. Using Arguments.

Sometimes the context is needed when computing a cache key. Remember that all state-args are passed to the block/method.

Suppose we pass the current cart object into the @render_cell@ call.

render_cell(:cart, :show, Cart.current)

This cart instance will be available for your cache maths.

class CartCell < Cell::Rails

  cache :show, tags: lambda { |cart| cart.tags }

Cells simply passes all state-args to your code making it very flexible.

h3. A Note On Fragment Caching

Fragment caching is “not implemented in Cells per design”:http://nicksda.apotomo.de/2011/02/rails-misapprehensions-caching-views-is-not-the-views-job/ – Cells tries to move caching to the class layer enforcing an object-oriented design rather than cluttering your views with caching blocks.

If you need to cache a part of your view, implement that as another cell state.

}}}

Advertisement