View Sandboxes for Rails

Designing HTML views is an iterative, interactive process by nature. And anything that slows down the iterations, slows down development.

I was working on a form recently where the steps to show it went something like this:

  1. Go to the home page
  2. Log in
  3. Click “New Thingit” (domain terms have been changed to protect the innocent)
  4. Click “Edit” on the Thingit
  5. Click “Settings”
  6. Click “Enable Facebook integration”
  7. Click “Save”
  8. Click “New Wodget”
  9. Fill in the “New Wodget” form
  10. Click “Save”
  11. Click “Edit” on the saved wodget

All this just to get to the “Edit” view of a Wodget. Once you got this far the iterations were a little tighter, but because the forms were presented via AJAX, you couldn’t just hit F5 to refresh the form after making a view change. You still had to take a few steps:

  1. Click “Cancel”
  2. Click “Edit”

All this rigmarole got in the way of quickly seeing the results of view tweaks.

The way I finally decided to address the issue was to create a “view sandbox” inside the app where I could easily fiddle with arbitrary views.

I created a routing section for the sandbox which would only be enabled in the “development” environment:

Then I created a very basic SandboxController, with an action dedicated to the view I wanted to play with:

The controller action created just enough example model data to keep the view happy.

Finally, I created a views/sandbox/edit_wodget.html.haml view corresponding to the action, which simply included the Wodget form partial.

With this in place, I was able to simply navigate to http://localhost:3000/sandbox/edit_wodget to experiment with changes to the view, hitting reload when I wanted to see the effect.

Maybe there’s a better way to do this, and if there is I hope you’ll clue me in. I present this in case anyone else has run into a situation where the change->preview->change roundtrip is just too darn slow.