railsconf2011: building bulletproof views

In rails we have the idea skinny controller as fat models. On the other side we have the wild west views… not always a good thing. This is why I wanted to attend the “building bulletproof views” during the afternoon at railsconf.

Speakers:

The way to clean up your views it not just creating better rails code. Although rails code is important it is just a part of what you can do to improve the overall code cleanliness. Using helpers properly, making good use of layouts and creating templates can be done with rails. But a large part also lies in the proper writing of HTML and using good practices in CSS.

Clean markup and style

The first thing the dynamic duo tackled was the easiest thing to fix… DO HTML AS IT IS A LANGUAGE not just mark-up. HTML, and HTML5 specifically has a lot of ways to clean up the view side of your application. Although most of the things mentioned during the talk were just best practices for HTML and CSS nowadays it is still a good idea to just walk through them.

When using using HTML5 (I suggest you do) they suggest you create a hierarchy with your DOM. Start out with basic data formatting in logical HTML and HTML5 elements. By doing that the structure will be kept simple and more accessible. This combined with a healthy sense of browser capability vs. keeping everything look exactly the same… basically progressive enhancement and graceful degradation.

A couple of nice quotes:

  • “Writing better markup will result in less code. Less code is less crap to maintain.”
  • “Don’t fight the browser. If your offended by a 10 pixel shift due to a scroll bar popping up your in need of a vacation!”

Another really great thing that came flowing from viewing HTML and CSS as a language instead of just markup was that you need to have coding standards for your project. This includes how to do write id names, class names and indenting. get the team in sync on this and get consensus on what you are doing. This will improve readability and overall cleanliness dramatically.

Optimization in CSS by using shorthands are actually also better to maintain and perform better. less code is less clutter to get in the way. And remember 0 is any zero, if it is either em, px or pt all are the same!

Another subject was code lint. We all know it, we have some of it and there are some tools to get that out. A lot were mentioned but basically it is a known pain for all people who work with HTML and CSS. There will be lint and you will have to keep an eye out for it so it doesn’t pile up too much.

Rails view that actually look good

Building layouts

layouts are a good part of what your view is actually going to look like. adding things like the MSIE html version tag is a good practice they pointed out they got from the HTML5 boilerplate. They thought it was good enough to be turned into a gem called ie_conditional_tag. They also mentioned including HTML5shim (or shiv, whatever you prefer) or modernizr to get your elements recognized by legacy browsers.

The duo also talked about the use of the HTML5 boilerplate. They concluded that a lot of the things inside of it are a good idea. But they also stated that some things might work for you, and some might not… It might be a good idea to create your own abstraction of modernizr as some parts that you might not use can actually make the rendering of your page a lot slower then you would like. Even without using it…

templates that don’t suck

This is not a new problem. we create beautiful back-end code in the models and controller. But when it comes down to view we tend to just throw it over the hedge to the designers and forget about it. That should actually not be the thing we should do. We need to get more involved into the views and don’t shove all the left over crap into that hole.

Display logic can actually become really complex and testing the end result of views can be really fragile! placing your logic in helpers, view classes and other locations can help a lot in cleaning up your code. Try to make your views as stupid as possible. A nice rule is to avoid Capital letters in your ruby code when your in a template. Another, if you need local assignment you probably need to place it somewhere else, in a helper for instance.

Again this pairs with writing consistent HTML. Thing like making sure your lines are not over 80 character might be a really good idea for your team. HAML is not actually a real solution to creating more beautiful templates. Default element is a div? That is actually not a good idea when your doing HTML5 where div should be a last resort. your end-code is also not that important so create well formatted template code and take a break on end result space-fucking and take a break ;-).

And don’t forget, use what works in your team instead of just taking the best practice as it is.

a nice rendering trick

we know:

render partial: pets/pet

we also know:

render partial: pet, locals: {pet: pet}

but you can also do this shorter and more beautiful:

render partial: pet, object: pet

or even better:

render pet

this also works with multiple objects:

render @pets

and multiple of different object types:

render [a_cat, a_dog, another_dog]

Don’t really care about rendering… rails magic is magic, trust it if you want. You don’t have to care! We tend to try and build our own more then we actually should!

how to do page titles

This a common problem. A lot of us set this as instance variables (as do I sometimes). But we don’t have to do it this way! We actually would like it to be more like separation of concerns.

How do we do that? You can use the content_for method to change the title from the template. In the layout you could then ask if there is content_for()? and have an alternative ready of you don’t want to add anything. This can even be done in another layer of abstraction in a helper method or something else.

block helpers

The content_for is a nice given block helper provided by rails. But you can also create your own. If you have a specific thing that needs to be rendered in a certain way you can create a block helper. This way you can do simple basic adaptations by adding just a tag or to do more complex rendering. just an example they gave:

def fancy_pants(&block)
  content_tag(:section,
    capture(&block),
    class: 'fancy-pants'
  )
end

how to do navigation?

It is easy to figure out where the user can go, navigation is easy that way. It is a lot harder to figure out where the user currently is. Just like the title we resort to assigning a variable to determine what we want to have “active”. not a very nice practice.

Bruce made a gem for it. Goose, just because he was a awesome navigator for Maverick. The idea is that your navigation becomes a nav_to method call for a navigation link and in your template you call nav_at to determine where you are. The navigation being in the layout and the call being in the template. It can also handle multi-level navigation and even more. So it’s more then just a gem to do really stupid stuff. A very nice and sleek idea but I still have some reservations about.

forms

John actually had an interesting idea… a form is just an ordered list. Why? Well the form actually has an order and is a list of things that one would need to complete. I think this is actually a good idea. I still need to figure out if it will actually help accessibility… but I still find it a good idea.

They also talked about form types. Basically this is important, especially for mobile usage as the keyboard will change for the user. In desktop browsers the support is not great yet but it does have a big impact for mobile usage. They found the dive into html5 a good reference for this

Next to HTML5 forms they also mentioned the formtastic gem. this is because fields and labels come in pairs, so why do that pattern over and over again.

don’t fear the object

I found this a very enjoyable part of the talk. Because front and back are moving more and more into the same domain there are some issues on both sides. Designers don’t dare to touch objects and developers find HTML and CSS just ugly things. Both are actually wrong and will need to understand and respect one another’s ideas and principles.

Using view classes is actually a good idea. View classes allow for proper object abstraction, these can be properly tested! Helpers are also testable but they are just basic functions. If you turn it into a class you can actually nicely group them and test them with nice stories. +1!

mobile interaction

The mobile interaction field is really different… basically because of the clumsy interaction tools and the small screen size you will need to do different things for a good user experience. There are a couple of things that could work. CSS media queries I already extensively touched in another blog post about media queries. Their idea was that this is not really efficient. The problem of load is completely valid.

Their idea is to use rails to output other data. Remove stuff that does not need to be there, create a separate view that is specifically made for mobile. This way you can also include other libraries like jQuery mobile. Although I can agree that this is a valid way to do this. But I personally prefer the media query approach as you do not create completely separate front-end’s for the same thing.

other stuff that was mentioned

Rails 3.1 asset management… Cool!

Compass and lemonade are good for some things, not for others.

sass bad, scss good!

ow… and the slides are up!

Advertisements

, ,

  1. Leave a comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: