generalize & spin off the chart registry

[gordonwoodhull]

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.

[gordonwoodhull]

Note this solution by @Fil and @pierreleripoll: https://observablehq.com/@pierreleripoll/vegasync

It's a step in the right direction because it isn't bound to any particular charting library.

On the implementation level, I have two critiques:

• d3-dispatch is somewhat verbose for this purpose, since you have to bind every method (render/redraw/etc is really an interface)
• The solution should not be bound to crossfilter, since the query provider might be something else (Apache Arrow, backend server, etc).

However it's a good starting point for discussion.

[kum-deepak]

I think in the dc-v5 branch, the ChartGroup has achieved the goals of this task. It is generic enough that non-dc charts can interact as well. This combined with FilterStorage can work with Crosfilter - without having a hard dependency on Crossfilter. This works with remote data sources. I think we can close it.

[gordonwoodhull]

Yes. The only part that is still missing is the “spin off” part.

At the time I had the idea that the chart registry should be a separate library so that people could connect charts in a standard way without using dc.js at all.

However, I am not sure if this goal is still relevant. With ES6 people can import just the chart registry, without bulking up their app. It doesn’t need to be a separate library anymore.

[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.