Survey Says: Partial Variables

rubyonrails-core
1

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

2

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

3

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.

4

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