Caching In Cells: API Change In 3.10.

The caching layer in “Cells”: just got an update. By using the new “uber”: 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|

…you have to change to the following.

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

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

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"]

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|

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


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”: – 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.



2 thoughts on “Caching In Cells: API Change In 3.10.

  1. I don’t quite understand block vs tags
    Can you explain more?
    (I read the PR but still don’t understand 😦


  2. PikachuEXE: the tags: option is just an example, it could be any arbitrary option, they’re simply passed to the cache store – in this case I was assuming that the store understands a tags: option.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s