How do I simplify my views?

You may have heard people say that you shouldn’t use conditionals in your views. Maybe you’re wondering what that means. Maybe you’re wondering why?

I just want to change what I show based upon some criteria

The reason you should try to avoid conditionals in your views is that it makes them complicated. Conditionals anywhere are complicated, but often can’t be avoided (although they can be reduced). But in your views, they are doubly complicated, because a view is some frankenstein hybrid of static markup and dynamic code.

However, if at all possible, you want to move the conditionals further down the stack – through the controller, any intermediate layers (which I’ll get to some other time) and maybe to your models or even the database.

But, for now, let’s keep it simple and override a piece of the magic that Rails gives you.

Suppose you have a DocumentsController that shows a document (unsuprisingly). Your controllers might look something like this:

So in our ApplicationController we have some login logic – somehow, the user may have logged in and we’re storing their ID in a session cookie. The two protected methods – logged_in? and current_user are then available to all our other controllers, and as they are also helper_methods, they are available within our views.

Next we need to define our view for showing a document. But let’s add a (slightly contrived) constraint – if someone is logged in they always see the editor, if they are not logged in they just view the document. And the project owner insists that the URL does not change if you are editing it or if you are just viewing it.

Our view could look something like this:

Yes, it’s very contrived. Bear with me.

We’ve got a nasty if statement in that view.

Imagine if the form was more complicated than this. Imagine if the standard view was really complicated as well. What a mess that view template would be.

So let’s start over and look at the controller again.

We have now moved the conditional into the controller; one level down the stack.

Slight aside – I’ve used the “ternary operator” ?, which is common in many languages, but could easily have been rewritten as shown below – however I find that style verbose and careful use of the ternary operator quite easy to read:

So what we’re doing is loading the document, then calling render explicitly. Normally Rails does this for you magically – in an action called “show” it will call render action: ‘show’ automatically. The exception to this is if you call render by hand (as we are doing) or you perform a redirect. When we call render, we tell it which view we want to appear – if we’re logged in then render edit.html.erb, if we’re not logged in then render show.html.erb.

And with that, we can then have a nice simple show page and a nice simple edit form.

Truth be told, there are aspects of this style that I still wouldn’t use. But that’s more to do with the maintainability of large applications and making sure things are secured as my corporate masters would expect. So those are topics for a different day.

In the meantime, just remember to keep conditionals out of your views; move them into your controllers, or even further down the stack, if at all possible.

Do you know what to do but not how it works?

Ever wanted to understand why Rails views work the way that they do? Why variables from your controllers are visible inside your views?

Sign up below to get a free 5 part email course on how Ruby on Rails view rendering works and gain a deep understanding of the Rails magic.

We will send you the course, plus the occasional update from this web-site. But no spam, we promise, and it's easy to unsubscribe