Using views and states

In the introducing chapter we got our twittering working. However, the #display view does two jobs at once.

It’s listing the tweets and managing the form for new posts.

Why not have a look at it.

 - widget_div do
   %ul
     - for tweet in @tweets
       %li
         = tweet.text
  
   %p
     What are you up to?
    
  - form_tag url_for_event(:submit), :remote => true do
    = text_field_tag 'text'
   
    = submit_tag "Tweet!"

In a component-oriented architecture things should be separated for good encapsulation so let’s learn two simple steps to do just that.

Extracting partials

Often it is good practice to move view fragment to partials. A partial is reusable and helps limiting the scope of variables used in the view.

Let’s extract the list to a separate view. Or partial. Whatever.

%ul
  - for tweet in tweets
    %li{'data-id' => tweet.id}
      = tweet.text

Notice how we refer to tweets as a local, and not as instance variable anymore (line 2). Overally, it is cleaner to work with locals. Instance variables are dangerous.

The new view must be rendered in the display view.

 - widget_div do
   = render :view => :list, :locals => {:tweets => @tweets}
  
   %p
     What are you up to?
    
   - form_tag url_for_event(:submit), :remote => true do
     = text_field_tag 'text'
    
    = submit_tag "Tweet!"

The render :view call looks and feels similar to partial rendering (line 2).

Rendering states vs. helpers

Partials are nice and a quick way to DRY up things. Rendering states gives you even more power. It allows rendering and executing an associated piece of code. Sounds like a helper, doesn’t it?

Rendering states in views is really comparable to using plain helpers. But – ha! – states are object-oriented, can be inherited and overwriten. How does that look like?

 - widget_div do
   = render({:state => :list}, @tweets)
  
   %p
     What are you up to?
    
   - form_tag url_for_event(:submit), :remote => true do
     = text_field_tag 'text'
    
    = submit_tag "Tweet!"

I replace the render :view with a render :state. The cool thing is, I can pass any options to the state method (line 2).

 class TwitterWidget < Apotomo::Widget
   responds_to_event :submit, :with => :process_tweet
 
   def display
     @tweets = Tweet.find(:all)
     render
   end
   
   def process_tweet(evt)
    Tweet.new(:text => evt[:text]).save

    @tweets = Tweet.find(:all) # this is wet!
    replace :view => :display
  end
  
  def list(tweets)
    render :locals => {:tweets => tweets}
  end
end

One thing changed: We got a new state #list (line 16-18)! It requires one argument tweets. So, when we render this state, we have to pass in a tweets list. It’s important to see how states urge you to define interfaces – and this is a good thing.

Summing up the rendering cycle

So, what’s going on here, step-by-step.

• The #display state called in #render_widget collects all tweets and renders its view.
• In the display view, we call render :state and thus invoke a second rendering cycle.
• The called #list state receives the tweets and renders its own view, list.haml (line 17).
• The list.haml view uses locals only.

%ul
  - for tweet in tweets
    %li{'data-id' => tweet.id}
      = tweet.text

Extracting the form to a separate state

Why not extract the form to another state and see how it looks? We will soon learn that this absolutely makes sense.

  def list(tweets)
    render :locals => {:tweets => tweets}
  end
  
  def form
    render
  end

First, I define a new state method that just renders (line 19-21). We then need an appropriate view.

.form
  What are you up to?
 
  - form_tag url_for_event(:submit), :remote => true do
    = text_field_tag 'text'
   
    = submit_tag "Tweet!"

Nothing new, just the form in a separate partial file.

The last step is to render the form state in our main view.

- widget_div do
  = render({:state => :list}, @tweets)
 
  = render :state => :form

Much simpler now, what was the actual form is now a delegation to the #form state (line 4).

DRYing up the widget class

After all this work, we can also clean-up our TwitterWidget and remove redundant queries to the Tweet model.

 class TwitterWidget < Apotomo::Widget
   responds_to_event :submit, :with => :process_tweet
 
   def display
     @tweets = Tweet.find(:all)
     render
   end
   
   def process_tweet(evt)
    Tweet.new(:text => evt[:text]).save

    replace :state => :display
  end
  
  def list(tweets)
    render :locals => {:tweets => tweets}
  end
  
  def form
    render
  end
  
end

Look what happens now in #process_state – after a tweet submission is consumed we simply re-run the #display state and let it manage the rendering of the widget (line 12).

That looks quite ok now. A quick discussion when to use states and then we’re done for today!

Views vs. States

Don’t confuse the :view and :state option. The first simply renders the view whereas the latter invokes a state method, which itself renders. Both are helpful and it’s a matter of design where to use which.

Another interesting concept is extracting logic and views to separate states, as we did with the form and the tweet list. As a rule of thumb, it is nothing wrong to move things to discrete states. Nevertheless, you could also create a separate widget class. We will learn more about that soon.

Apotomo is a Nick Sutterer product.