Survey Says: Partial Variables

Hey guys,

I’m doing some work on partials and am trying to figure out what the
usage of the variables that are currently assigned is.

Consider a case where you have a partial named _user.html.erb. In Rails
2.3, the following variables are assigned:

  • user
  • options[:as] if options[:as] exists
  • object
    My question is whether these are all used at the same time. Reducing
    the number of variables assigned makes a performance difference that is
    particularly noticable in large collections. There are some things that
    I’m thinking about, but I want to hear what the normal usage is. Feel
    free to tell me this is crazy and people use all three all the time.
    Some options:
  • set options[:as] to default to :object. If options[:as] is
    specified, the object local would not be set.
  • set options[:as] to default to the partial name. If options[:as]
    is specified, the partial name would not be set. In this case, object
    would always be set separately.
  • a more radical option would be to deprecate the usage of object
    and default options[:as] to the partial name. This would guarantee that
    only a single known name would need to be set each iteration. I am
    told, however, that object is actually in use.
    Are either of these options palatable? Effectively, the question is
    whether object, the name of the partial, and a separate options[:as]
    are used all at the same time in the same partial.

Thoughts?

– Yehuda

Hey guys,

I’m doing some work on partials and am trying to figure out what the usage of the variables that are currently assigned is.

Consider a case where you have a partial named _user.html.erb. In Rails 2.3, the following variables are assigned:

  • user
  • options[:as] if options[:as] exists
  • object

Ohhh, what?! …all this time I’ve been using ‘user’ like a sucker when ‘object’ has been available?

My question is whether these are all used at the same time. Reducing the number of variables assigned makes a performance difference that is particularly noticable in large collections. There are some things that I’m thinking about, but I want to hear what the normal usage is. Feel free to tell me this is crazy and people use all three all the time. Some options:

  • set options[:as] to default to :object. If options[:as] is specified, the object local would not be set.
  • set options[:as] to default to the partial name. If options[:as] is specified, the partial name would not be set. In this case, object would always be set separately.
  • a more radical option would be to deprecate the usage of object and default options[:as] to the partial name. This would guarantee that only a single known name would need to be set each iteration. I am told, however, that object is actually in use.
    Are either of these options palatable? Effectively, the question is whether object, the name of the partial, and a separate options[:as] are used all at the same time in the same partial.

Thoughts?

My vote is to deprecate that smelly ‘object’ option :slight_smile: Is it actually mentioned in the API (I’ve never seen it)? Or is this a hangover from previous versions?

My other question about this is whatever solution we have for the :object => @user situation should generalize to the :collection => @users situation. I know that ‘user’ does this nicely, not sure about ‘object’.

Cheers,

Jason

Are either of these options palatable? Effectively, the question is whether
`object`, the name of the partial, and a separate options[:as] are used all
at the same time in the same partial.

I find your 3rd proposal perfectly acceptable. 'object' is possibly
in use but could probably be deprecated cleanly in 2.3.x. The catch
here would be to make sure you don't have false-positives in the
warnings.

People possibly are dependent on having something available under
multiple names for a single partial, but I don't think it'd be
intentional and they could always do :locals=>{:whatever=>youwant} to
work around it.

Personally, I’m a huge fan of treating partials as true method calls
and ensuring that all required objects are passed in as locals. I
can’t speak for others, but this optimization would not have a single
negative side effect for me.

-John