Refactor results page graph tabs data formatting strategies and add analytics call

[thostetler]

Adds graph-tab-active [Citations / Reads] GA interaction event for when tab is selected
Implements strategy laid out here: #2194 (comment)

[romanchyla]

Please check my comments next to the citation/reads

[romanchyla]

@thostetler I'm not sure about this part: facet.limit=2000 will limit results returned to 2000 rows; each of which may contain values >1 -- so at max we'll have 2000 datapoints for the graph, but having less than 2000 should be also OK; padding it to be 2K will make the graph somewhat normalized, but also will shrink it somewhat -- so I'm personally inclined to say no padding is needed.

The numRecords < MAX_RECORDS is not what we should do; It's OK to display 2000 datapoints even though numRecords will grow higher -- unless I'm missing something?

[thostetler]

I'm not sure which facet.limit=2000 I took that part from your original comment.

I agree with you, I thought it was unnecessary to reduce the data points, however that was how it was implemented before (

bumblebee/src/js/wraps/graph_tabs.js

Line 177 in edf3ec4

// a cut off of 2000

).
So I just did the same thing again using the new non-pivot incoming data.

I've added a commit that removes that loop and just maps the data directly from solr: 64ca10f

[romanchyla]

the same as above, with an additional comment that we should do finalData.push.... to avoid creating the array over and over which would be inefficient

as weird as it sounds, the data coming from solr can be used without modification

[romanchyla]

Thanks, I think now it's perfect -- only some failing unittests (if you could please look at those). AFAIK it's in good shape and can be merged. Thanks for the analytics events too.