Fixing RSocialize: Where To Put the Custom Options in RSocialize?

I wrote a gem called RSocialize a while ago to help make it easier to install social media buttons on your Rails application.

Recently an issue was raised on Github regarding where to specify the custom options.

What are the custom options?

The RSocialize gem is basically a wrapper around a jQuery plugin called Sharrre. Sharrre allows you to customize certain options when you’re using it such as formatting the number style displayed on the social media button to something like “1.4M”.

Templates vs. custom options

The RSocialize gem by default uses certain default options as provided by Sharrre. If you use those, it’s pretty easy to have something setup right out of the box.

To allow users to use Sharrre’s custom options, I wrote the gem such that you can pass in custom option Hashes into the view helpers that the gem provides, namely rsocialize_js_tag and rsocialize_div_tag (you see the Github README file for more information).

Back to the Github issue

The issue is the custom option Hash is a Ruby variable. This means you can’t store it in the Rails coffeescript/Javascript asset files. You have to instantiate it in your Rails application somewhere.

Two quick and dirty ways to do this

First way: Define it right in the view helper

<%= rsocialize_js_tag(@js_custom_options = { demo1: { share: { googlePlus: true, facebook: true, twitter: true }, buttons: { googlePlus: {size: 'tall'}, facebook: {layout: 'box_count'}, twitter: {count: 'vertical', via: '\_JulienH'} }, hover: %Q[function(api, options){ $(api.element).find('.buttons').show(); }], hide: %Q[function(api, options){ $(api.element).find('.buttons').hide(); }], enableTracking: true } }) %>
</code>

Second way: Instantiate it in the Application Controller

The other way is to instantiate it in a place like the Application Controller (or any other place that allows you to pass the value of the @js_custom_options variable to your view layout) such as:

class ApplicationController < ActionController::Base
  protect_from_forgery
  before_filter :init_js_options

  private

  def init_js_options
    @js_custom_options = {}
  end
end

Conclusion

Both ways don't seem ideal to me...I was thinking of having the gem auto-install a method in Application Controller where it defines @js_custom_options as an empty Hash (as above, for now at least) so people could initialize it later.

If anyone has any thoughts on this, please feel free to give a shout out on Twitter or comment below.