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

June 24, 2013

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 rsocializejstag and rsocializedivtag (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 } }) %>

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 @jscustomoptions variable to your view layout) such as:

class ApplicationController < ActionController::Base
  before_filter :init_js_options


  def init_js_options
    @js_custom_options = {}


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.