@jon_duke said you guys might be working on a shared D3 library for visualization. I just wanted to check if that still going on. I was also curious as how it would be called from our apps. Would it be like:
We’re actually using the library in the latest bits in Hermes. It is inside a knockout binding but the code looks similar, albeit a little more complex, than your example.
var prevalenceByMonth = new jnj_chart.line();
prevalenceByMonth.render(binding, element, 1000, 200, {
xScale: d3.time.scale().domain(d3.extent(binding[0].values, function (d) {
return d.xValue;
})),
xFormat: d3.time.format("%m/%Y"),
tickFormat: d3.time.format("%Y"),
xLabel: "Date",
yLabel: "Prevalence per 1000 People"
});
I actually suggest we schedule a working session with @Chris_Knoll to walk through the library and talk about how we can make it as easy as possible to leverage. We’ve been talking a bit about hosting on a CDN and other approaches to re-use that would be worth-while to discuss in a group.
It would be helpful to host of CDN, so we all are working from a common place. Or at least have a separate project out there on github, so we can go by a specific version.
Is it specific to JNJ in any way? Just looking at the name.
And I promise I’m not trying to stir up the Angular/Knockout discussion, but I might prefer to keep any notion of data bindings out of d3 libraries, so that they could be used more across the board (e.g. people who may not be using any data bindings at all). Putting the bindings in there will pretty much force everyone to use knockout or roll their own. But if it must be, then I guess it must be.
If you have a file that you need to host in the OHDSI CDN contact me at evans@ohdsi.org
You can send a link to the file and I can download it or, if it’s a small file, you can just send it to me as an email attachment.
It is not specific to JNJ other than it was developed here, there are no rights maintained, we’ll rename that file as we distribute it to the CDN or github.
There actually is no data binding required in our charting library. From my example you would be calling the render method on the line chart. Our passing the binding into the function is just the way we are passing data into the render method, its just a normal javascript object which is called binding in this block of code, but can be called whatever you want.
Trying to model from your example, it would look like this:
var lineChart = new chart.line();
lineChart.render(data,selector);
Or something like that, I’m sure someone will correct me if that isn’t quite right.
Yes, that’s one, i think the same version of that file is in Hermes. @Frank can correct me on this, but I don’t think he had to make any code changes from the version from AchillesWeb when he used it in Hermes.
Long term goal of this JNJ_Chart library is to 1) rename it from JNJ_Chart and 2) host it in a CDN and allow it to be referenced as an AMD dependency in our apps so that you don’t have to worry about which version of the component we are using and where to pull it from.
Actually, I discovered that he did make some changes in order for it to work better in an ‘embedded’ context. You should pull the copy from Hermes:
And the use of it (if you incorporate it as an AMD module)
requirejs([‘jnj.chart’],function(charts) {
var lineChart = new charts.line();
lineChart.render(jsonData, element, width, height, options)
}
Note on things:
jsonData is the structure of data that the chart expects to render. Unfortunately, there’s no documenation on the data structure for this, but you can look at the datastructure from hermes, or the otuput of AchillesWeb to see how to use it. I’ms orry this isn’t easier.
element: This can be a string of a selector that jQuery will find a node (such as ‘#divId’), or can be an actual dom node. It’s used in a line like this:
$(target).append(offscreen);
(The offscreen in this codesnip is just an offscreen dom element that we pre-generate the chart into. We ran into problems pre-generating into hidden dom elements (you can’t get dimensions of SVG elements when they are hidden) so we create in an ‘offscreen’ context, then append the construted dom elements into the node you passed in as the ‘target’ parameter
width and height are just the physical size you want to give the SVG area. The charts will shrink to resize to the containing div, so think of the width/height as a ‘screen resolution’ which will govern the sizes of the fonts in the result, but the final chart will be squeezed into the containing div (if there is one). You should probably put each chart into a contining div. If the div resizes, the chart will as well.
Finally, Options gives you a place to override default values (such as how the x/y axis values should be formatted, css classes, number of ticks per axis, stuff like that. You probably wont’ need to modify the defaults, but there are options (pun intended) if you need them.