Too evil! It'd be interesting to do a visualization of recurring
discussions on the list.
I want to talk about pros for _ as an object more, so here goes.
I think reusable charts need a state object that's serializable as
JSON, which means it can't contain functions as values. I'm not sure
the best way to deal with it, because currently d3 components are
functions with an internal state.
This doesn't necessarily need to be the same as the _ variable we're
discussing. It might be a pair of methods: chart.serialize() and
chart.initialize() for instance. It could also be the argument passed
in when generating a component:
d3.svg.axis( axis_json )
At some point you have to draw a line in the sand and say, "I'm sorry
functions, but it's time to JSON.stringify and you're not real data".
I tried to find a spec or outline of what John Hunter's "rich json
structure" looks like, but I couldn't find anything.
It looks like some poor souls have resorted to putting in code as an
array of strings to make IPython charts:
https://github.com/dgleebits/PythonSystemAdminTools/blob/master/d3jsBarChart.ipynb
There is a slight performance hit when accessing an object, but I'm
sure there are ways around it for tight loops.