Cells 3.5 Release Party Summary

{{{
Yesterday we released “Cells 3.5.0”:http://github.com/apotonick/cells, which is another step towards real component-orientation in Rails. *The release party was a big hit.*

}}}

{{{
“Cells”:http://cells.rubyforge.org/ is the one and only *view components framework for Rails*. It has a vivid growing community and had almost 10,000 downloads in the last year. That’s cool.

h3. What’s new?

Basically *we threw out a lot of code* and deprecated some mechanics – we’re really happy to have abandoned the last ugly spots in Cells.

* First of all, I introduced a “CHANGES”:https://github.com/apotonick/cells/blob/master/CHANGES.textile file which keeps growing. Keep that in sight *if you wanna stay up-to-date about improvements and fixes.*
* The *generator* now uses the standard hooks for templates and tests.
* *States* now receive arguments (aka _state-args_) to use less instance variables.
* The *rspec-cells* gem finally runs and even has Capybara support.

h3. The Generator

Thanks to the great work of Jorge Calás the cells generator now works like all the other generators in Rails 3. *What has been the @cells:cell@ generator is now simply @cell@.*

It has hooks for templating and testing. Cells ships with *generators for ERB and Haml views* and *Test-Unit and Rspec test cases*.

$ rails g cell ShoppingCart display -e haml -t rspec
    create  app/cells/shopping_cart_cell.rb
    invoke  haml
    create    app/cells/shopping_cart/display.html.haml
    invoke  rspec
    create    spec/cells/shopping_cart_cell_spec.rb

Love it already.

h3. State-args are the new options

You usually *pass parameters into cells* to model encapsulation.

render_cell :shopping_cart, :display, 
  :user => current_user, 
  :items => current_user.items

This drastically reduces coupling. The outer world (e.g. the controller) knows about dependencies *whereas the cell should not care about retrieving its domain models.*

In former versions, you accessed those arguments by querying the @opts instance variable. *Ugh!* Don’t do this anymore. *The prefered way now is _state-args_.*

class ShoppingCartCell < Cell::Base
  def display(args)
    @items = args[:items]

The *options are passed as method arguments*, and that’s what arguments were made for!

If you don’t like that, *you can still use the @#options@ method in your states*.

  def display
    @items = options[:items]

This is for a soft transition, but be warned that Cells 4.0 will not store arguments in instance variables anymore. Don’t overuse instance variables – this *typically is a smell of improper method chaining design.*

h3. States are helpers

Complex *helpers typically invoke some code and then render a partial*. This is exactly what @render :state@ in cells does.

  - @items.each_with_index do |item, i|
    render({:state => :item_link}, item, i)

You typically do this in cell views. Notice how I *pass arguments into the state*.

class ShoppingCartCell  i.odd? ? :odd : :even

*The @#item_link@ state acts as a helper* method, but as opposed to a plain helper *you can use inheritance here* and all the other benefits real object instances bring.

h3. rspec-cells enhancements

If you like testing (you should _love_ it!) you can use either traditional unit tests or RSpec. *Include the rspec-cells gem into your @Gemfile@.*

gem "rspec-cells"

The packaged generator will stub out a useful spec template for you.

$ rails g cell ShoppingCart display -t rspec

You can use webrat’s matchers, or even *the new capybara string matchers*, if you have capybara installed.

context "rendering display" do
  subject { render_cell(:shopping_cart, :display) }

  it { should have_selector("h1", :text => "The Cart") }
end

h3. Get Cells!

We’re happy these improvements are on the road – tell us what you think about it! I’ll try to recover from the release party, now.
}}}

Advertisement