View Classes implementation proposal

view_classes_proposal.md

View Classes

This is a working draft of proposal. Feel free to comment, express your opinions and suggest alternative solutions.

Problem

As a second part of my Google Summer of Code, I planned to introduce View Classes to Action View.

There was ongoing discussion about this and extracting AV from AP (which is done already: rails/rails#11396) here: https://groups.google.com/forum/#!topic/rubyonrails-gsoc/N7uDY_6513I

The "problem" is becoming more common and people are looking for solution to ERB view templates bloated with too much logic (http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/#view-objects)

Solution

Example

I'd like to propose as simple as possible solution which will introduce context argument to render method like following:

class PagesController < ApplicationController
  def index
    @post = Post.find(params[:post])

    render context: PostsShowViewContext.new(@post)
  end
end

It will also work for partials in the same way:

render partial: "page_content", context: PostsShowViewContext.new(@post)

The render will expect context class instance as an argument. It'll have reference to controller.

The ViewContext class will look like this:

# app/view_models/posts/show.rb
class PostsShowViewContext
  include ActionView::ViewContext # pseudo code, something like this will be including AV's stuff.

  attr_reader :post

  def initialize(post)
    @post = post
  end

  def title
    post.title
  end
end

ActionView::ViewContext module will deliver all boilerplate: view helpers, assigns and route helpers

The whole thing would be implemented somewhere in place where ActionView makes rendering happen

# somewhere in ActionView depths
class ActionView::Rendering
  def render(options)
    if context = options[:context]
      context.controller = self
    end
  end
end

How it'll work

The intention of this change is to introduce "view classes", the object in which context's template would be evaluted. The way it works in tilt for example: https://github.com/rtomayko/tilt#basic-usage

Naming

As we all know, it's hard. For me, the best name for this "feature" would be ViewModel (view_model). However there are other candidates:

• View Context
• View Class
• Context

I've been interested in abstractions between the controller and view.
Some are:

• reform
• cells

Learning from Django: slides / video.

I greatly prefer the second solution. It is very obvious how it works. Passing data from controllers to views is something that can and should be explicit if possible. That's why I like the view model version. You pass it everything it needs and therefore reference everything via defined methods.

As either an app developer or someone looking to build a framework on this I'd prefer the decoupled explicitness of passing everything I need. If one wanted to do the first version it could be built on top of the second version as an abstraction.

I'm with @halorgium. There is definitely some inspiration to be drawn from some of the existing approaches out there already. Virtus is another great example, although a slightly detached abstraction.

Thanks guys for comments.

I've updated gist and left only second solution as a main one. Almost all people prefer it over first one. You can find int in previous rev if somebody would like to look it up - https://gist.github.com/strzalek/6267840/249c76563dfb3d2fcf97c76d7546614dbf84d214

Thanks Łukasz for those thoughts on the evil view layer!

I like the idea of having the context: option which makes it easy to use an alternative context. In current Rails, this is a bit clumsy.

Also, I like having all the helper context in a separate object. Love tilt's rendering simplicity #render(locals, context) but I believe this is similar in Rails now.

What will feel clumsy for many people is that they need to define the Context class. IMO, the context should be the controller instance. In cells, this is done really easily and as the cell instance doesn't contain all the HTTP/Streaming/Model/... dependencies as an ActionController instance does, it's pretty safe to use it as the context.

Your proposal would actually simplify our code in cells :-)

I don't understand where is the 2nd solution? Can you point me to it, please?

This gist i just a regular git repo. You can find both solutions under the link I've posted in my comment above: https://gist.github.com/strzalek/6267840/249c76563dfb3d2fcf97c76d7546614dbf84d214. You have "first" and "second" solution in there of which I've picked second one and only this one remained in the document.

I'm not a fan of adding this additional layer of chrome. It doesn't offer much if anything over using the existing mechanisms to achieve the same. If you want to use a context or presenter object, it couldn't be easier:

class PagesController < ApplicationController
  def index
    @context = PostsShowViewContext.new(Post.find(params[:post]))
  end
end

Now you can just do this in your views:

<%= @context.title %>