When V is for Vexing: Patterns to DRY Up Your Views by Bruce Williams
So, I heard from more than one person that the second half of the morning JavaScript tutorial (which I skipped) was significantly better than the first half. Sorry, Thomas. With that in mind, I resolved to grind through the whole afternoon tutorial no matter what happened. Fortunately, it was pretty good stuff for people like me whole like their UI code all polished up and shiny. I even stayed when someone started drilling through concrete on the other side of the wall.
Bruce started out talking about MVC (Model View Controller). He pointed out that, in Rails, we end up with clean Ruby code in the M and C and crappy V code.
Views are hard to: master, explain, reuse, extend, test, agree on. True enough in my experience.
Bruce’s recommended plan of attack:
1) Choose a templating system that works for you
2) Find common patterns to extract into reusable code
3) Extract, abstract, repeat
There was a review of the major Rails view options. Bruce asked for a show of hands: the great majority of people use Rails’ default ERB-based template system; a few use Haml and Markaby. I’m going to list a summary of the tutorial’s summary — the RailsConf talks are going to be available online if you are dying to get all the details. If my motivation doesn’t flame out, I’ll link to them.
ERB: Like PHP in Ruby. Heavy, ugly, hard to abstract.
Markaby
Pros: concise, easy for Ruby developers
Cons: performance, trickly with layouts and helpers
DRYML (XML):
Pros: Very reusable, complex output from concise input
Cons: Complex, lot to learn, language onto itself
Haml
Pros: Concise and fast to type
Cons: Unusual, strict whitespace, not very reusable?
Liquid:
Pros: Great for user/designer collaboration
Cons: Time to extend filters/drop
Amrita2
Pros: Clean markup, fair WYSIWG
Cons: Conceptually different, tighter data-to-layout coupling
MasterView
Pros: Great for teams that need to support WYSIWG tools
Cons: Complex, requires generation
After the review and the lukewarm endorsement of ERB, we all anticipated the climatic: “Now, let me introduce the best view solution. The one that the Rails ninjas use.”
Turns out that Rails ninjas use the default ERB templates. Oh, well.
Bruce is really focused on finding patterns — standard design elements, controls. I guess that makes sense given that the tutorial is about DRY’ing up views.
View smells:
– Calling find() on a model
– Calling find() on an association
– Conditionals
– Complex inline map, sort, or select statements
– Assigning temp variable
We spent a lot of time talking about blocks to build content and as alternatives to if/else statements, helpers, and partials.
So instead of:
<% if @user.admin? %>
Admins see thislt;/p>
<% end %>
You do this:
<% admin_content do %>
Admins see thislt;/p>
<% end %>
You implement the blocks in Helpers, using the block& parameter and yield.
Rails has moved in this direction, too: <% start_form %> … <% end_form %> tags became <% form do % ... <% end %>.
I am too lazy to give specific code examples, but I’m a believer. Not that these blocks make views dramatically better, but they can help make your views into logical component assemblies instead of bastardized HTML markup, and they’re for sure easier to test. The approach is certainly more Ruby-like. And block helpers, unlike partials, have a programmatic Ruby API.
Bruce says: “approach Rails development like a language designer.”
– When you create an app, you are creating a language
– Everything you write is an API
– Implementation is the easy part, get the API (names) right first.
This advice rings true to me. If you want to work effectively with large teams, and create code that other people can use, you should follow his advice. I’ve never grasped what the Extreme Programming folks meant by “metaphor.” I suspect they should have said: “Use good names.”
Side note: if Ruby and Rails are old news to you, apparently the cool kids are into Haskell, OCaml, and Erlang.
Bruce mentioned FormBuilder. It’s in Rails and poorly documented, but looks handy. That led into his recommendation to read other people’s source code, especially Rails’ source. It’s clear enough that the code is often the direct answer to your questions. And you’ll learn something about coding.
The talk wrapped up with some speculation that our views will all become like Seaside — a bunch of classes that generate their own markup. I don’t know, maybe Bruce’s views will end up that way. It’s true that my UIs generally evolve in that direction. I replace repetitive markup and helper methods with full-fledged OO classes, too. But I really doubt that I’d want to start building my app that way. I’d wait to discover the need for more abstraction and build it in then.
Another side note: Bruce mentioned that one of his apps had (ah, can’t remember exactly) over 100 partials. Other people have mentioned Rails apps with hundreds of controllers, views, models. Are they hacks? Or am I just small-time!
