Reference Data, Global Context, and UI State Are Exceptions

Managing specialized data in Rails applications

Almost every Rails app has a method called current_user that exposes an object representing who is logged in. It’s also common to need a list of reference data, such as country codes, in order to build a drop-down menu or other piece of UI. Lastly, it’s common to need to persist UI state between requests, such as for a tabbed-navigation control. None of these make sense as part of an existing resource because we’d end up with every single model providing access to this data.

These are the exceptions to the one instance variable per view guideline. We can certainly provide access to data like this in helpers, and current_user is a very common one. We’ll talk about helpers later, but too many helpers can create view code that is hard to understand. When a piece of view code only uses instance variables, it becomes very easy to trace back where those instance variables got their values: the controller.

We don’t have any drop-downs in our app yet, but this is what it would look like to expose a list of country codes on a hypothetical manufacturer edit page: