generalize & spin off the chart registry

The proposal is to create a separate library (under this dc-js org or crossfilter org, though potentially it can be used without either), which takes care of the communication between charts that is currently handled by the undocumented (#676) dc.chartRegistry

It would probably use d3.dispatch (or a copy of it from the new modular d3 v4, since this has relevance without d3) to keep the array of listeners. So render and redraw become just events.

Also there are at least two common inter-chart events, various forms of brushing-and-linking that are not brushing-and filtering. One is just linked selection, where the charts have the same dimension or at least compatible dimensions (#681). The other is range/focus charts; in general there will be more than one focus chart (#820).

The more complicated idea is to abstract what a filter is, basically move dc.filters out from here, because many people use dc.js with a backend that is not crossfilter. Then there would be something that “renders” queries from those filters. (And we might hit #478 while we’re at it.)

[gordonwoodhull]

I made half an attempt here: chart.registry.js.

It works okay but it is verbose. I came to the conclusion that d3.dispatch is probably too low-level a tool for this, since really we want a whole interface of methods (some of them optional) on each chart.

Maybe that is fine, since it would be better for the chart registry to be free of dependencies.

[kum-deepak]

Thanks @gordonwoodhull!

I agree with the not spinning off part.

Once upon a time (when porting to ES6) I was considering splitting the library into the core, base charts, and not commonly used charts into separate libraries. However, I started realizing that a significant number of users will trade simplicity even if the cost is a bigger bundle size. Users who care about smaller sizes can achieve the same by creating their own bundles.