An open letter to Chris Henn on the topic of SeriesComponents in Ember

series_component.md

Dear Chris Henn,

I loved your talk at EmberConf this year. Thanks so much for sharing that with us!

I had recently spiked on replacing our graphing library with some components and happened upon a very similar solution to what you described. What I didn't know is that there was an existing grammar for these concepts. I knew a few terms like axes and series, so those became nouns (or components) in my world. My template looks like this:

{{#viz-chart as |d|}}
  {{viz-xaxis dimensions=d}}
  {{viz-yaxis dimensions=d}}
  
  {{viz-line data=droppedRequests color='orange' dimensions=d}}
  
  {{!-- a viz-area plus a viz-line give a nice "edged area" effect --}}
  {{viz-area data=cacheHits color='grey' dimensions=d}}
  {{viz-line data=cacheHits color='grey' dimensions=d}}
{{/viz-chart}}

viz-chart yields a ChartDimensions object and the axes and series register themselves with it. This is as opposed to you giving the whole dataset to your equivalent of viz-chart and having the various series slice it up.

One reason I chose this approach is that when the user toggles the visibility of a series, that series will deregister itself from the ChartDimensions, which can then adjust the scaling functions.

What do you think of this approach? As I watched your talk, I felt my version didn't align to the existing visualizations grammar, which worries me a little.

Cool, looks like a nice way to share the scales and dimensions among the child components.

A slight tweak to the approach could be passing the dimensions object down to child components the same as now, but leave registering and deregistering as a responsibility of the parent component. Child components would notify the parent component of their intent to register through actions, maybe something like a 'yExtentChanged'. This would be more verbose (you would have to subscribe to the actions of each child component), but it would give you more power over the resulting scales, as the parent component would be entirely in control.

This may or may not be valuable for how you plan to use the viz-chart component. I've run into situations where there are user facing controls to change the min/max values used to compute scales, and in that case having a little more control is nice.

But looks good! The existing approach is easy to understand and think about and seems like it works well.