Cells Integrates With The Asset Pipeline

{{{
Today’s a fantastic day.

Not only has it been nice and sunny so far, also did I release “Cells 3.11”:https://github.com/apotonick/cells! It is the last minor release before Cells 4.0, which will finally and forever get rid of the stinky @ActionController@ dependency that has sometimes made our life painful. In 4.0, the new view model will become the default “dialect” for cells.

Anyway, back to 3.11. It got two new features that I personally started loving. You can now *bundle assets into your cell’s directory* (JS, CSS, images, fonts, whatever) making a cell a completely self-contained MVC component for Rails.

The second addition is purely structural: @Cell::Concept@ introduces *a new file layout for cells* following the “Trailblazer architecture”:https://github.com/apotonick/trailblazer. This new layout feels more natural, is easier to understand and allows cleaner encapsulation.

h3. Packaging Assets.

It often makes sense to package JavaScript and CSS that belongs to a logical part of your page into the cell that implements it. We used to have those assets in global directories and it just felt wrong.

You may now push assets into the @assets/@ directory _within_ the cell.

app
├── cells
│   ├── comment_cell.rb
│   ├── comment
│   │   ├── show.haml
│   │   ├── assets
│   │   │   ├── comment.js
│   │   │   ├── comment.css

How cool is that? A cell can now ship with its own assets, making it a hundred times easier to find related code, views, and assets. Your designers are gonna love you.

h3. Hooking Into The Pipeline.

In order to use the assets in the global assets pipeline, two steps are necessary.

First, you need to configure the Rails app to find assets from the cell.

Gemgem::Application.configure do
  # ...
  config.cells.with_assets = %w(comment)
end

The @with_assets@ directive allows to register cells that contain assets.

Second, you need to include the files into the actual asset files. In @app/assets/application.js@, you have to add the cell assets manually.

//=# require comment

Same goes into @app/assets/application.css.sass@.

@import 'comment';

I know it feels a bit clumsy, but it actually works great and if you have a better idea please let us know!

When compiling the global asset, the assets from your cell are now included.

h3. Think In Concepts.

In the process of implementing the Trailblazer architectural style in Rails, the new Concept cell plays a major role. It allows a completely self-contained file layout. Here’s how that looks.

app
├── cells
│   ├── comment
│   │   ├── cell.rb
│   │   ├── views
│   │   │   ├── show.haml
│   │   │   ├── author.haml
│   │   ├── assets
│   │   │   ├── comment.js
│   │   │   ├── comment.css

See how *all relevant files* are under the @comment/@ directory? Views got their dedicated directory, and the actual cell code goes into @cell.rb@.

This slightly changes the way a cell looks.

# app/cells/comment/cell.rb

class Comment::Cell < Cell::Concept
  def show
    render
  end
end

A concept cell is _always_ a view model. I’ll blog about the latter in a separate post. Apart from the slightly different name (see discussion below) everything else remains the same.

h3. A New Helper.

Rendering (or just instantiating) a concept cell works with the new @concept@ helper.

= concept("comment/cell", comment).call

This is exactly the same syntax as found with “view models”:https://github.com/apotonick/cells#view-models-explained.

One cool new feature comes with that, too! You can also render collections of cells easily.

= concept("comment/cell", collection: Comments.all)

This helper is available in controllers, views and in the cell itself (for nested setups).

An in-depth discussion how to structure cells will be in the “Trailblazer book”:https://leanpub.com/trailblazer.

h3. Why The New Trailblazer Layout?

Trailblazer is all about structuring – an essential element of software development that Rails has failed to establish.

In Trailblazer, the Rails app is structured by _concepts_. A concept is usually a domain concern like comments, galleries, carts, and so on. A concept not only contains the cell, but also forms, domain objects (“twin”), operations and more. It has proven to be more intuitiv to structure code by concepts and not by controller, view and model.

The cell is still a fully self-contained component of the concept and can be moved, removed or changed without breaking the app.

h3. More To Come.

I’m lucky to have a great team of developers and we started to deploy several concept cells to production. It just feels so much better and natural. Give it a go!
}}}

Advertisement