Question

I have a Google Chart’s ColumnChart in a Rails project. This is generated and populated in JavaScript, by calling a Rails controller action which renders JSON.

The chart displays a month’s worth of information for a customer.

Above the chart I have next and previous arrows which allow a customer to change the month displayed on the chart. These don’t have any functionality as it stands.

My question is, what is the best way to save the state of the chart, in terms of it’s current month for a customer viewing the chart.

Here is how the I was thinking of doing the workflow:

1. One of the arrows is selected.
2. This event is captured in JavaScript.
3. Another request to the Rails action rendering JSON is performed with an additional GET parameter
   passed, based on an data attribute of the arrow button (Either + or – ).
4. The chart is re-rendered using the new JSON response.

Would the logic around incrementing or decrementing the graphs current date be performed on the server side? With the chart’s date being stored in a session array defaulting to the current date on first load?

On the other hand would it make sense to save the chart state on the client side within the JavaScript code or in cookie, then manipulate the date before it’s sent to the Rails controller?

I’ve been developing with Rails for about 6 months and feel comfortable with it, but have only just recently started developing with JavaScript, using AJAX. My experience tying JS code together with Rails is some what limited at this point, so looking for some advice/best practices about how to approach this.

Any advice is much appreciated.

Answer 1

I’m going to go through a couple of options, some good, some bad.

First, what you definitely don’t want to do is maintain any notion of what month you are in in cookies or any other form of persistent server-side storage. Certainly sometimes server state is necessary, but it shouldn’t be used when their are easy alternatives. Part of REST (which Rails is largely built around) is trying to represent data in pure attributes rather than letting it’s state be spread around like that.

From here, most solutions are probably acceptable, and opinion plays a greater role. One thing you could do is calculate a month from the +/- sign using the current month and send that to the server, which will return the information for the month requested.

I’m not a huge fan of this though, as you have to write javascript that’s capable of creating valid date ranges, and most of this functionality will probably be on the server already. Just passing a +/- and the current month to the server will work as well, you’ll just have to do a bit of additional routing and logic to resolve the sign on the server to a different month.

While either of these would work, my preferred solution would instead have the initial request for the month generate valid representations of the neighbouring months, and returning this to the client. Then, when you update the graph with the requested data, you also replace the forward/backward links on the graph with the ones provided by the server. This provides a nice fusion of the benefits of the prior two solutions – no additional routing on the server, and no substantive addition to the client-side code. Also, you have the added benefit of being able to grey out transitions to months where no data was collected from the client (i.e. before they were a customer and the future). Without this, you’d have to create separate logic to handle client requests for information that doesn’t exist, which is extra work for you and more confusion for the customer.