Typings: Consider Generics for Chart types

[kum-deepak]

After working for a few days on adding types, I have started to appreciate the philosophy behind d3 typings. Based on my improved understanding, I feel that we may add two generic type parameters into charts - representing output types of key and value accessors. While going through the code and usage patterns we can determine that only few combinations are valid for each chart type.

For example, a PieChart would expect keys to be string and values to be number. @gordonwoodhull your experience will help in making a comprehensive list of types each of the charts would support. I will start creating this list as a new issue for better tracking.

Most of the other accessors are easier to figure out - for example, title, label, radius, would support only one type.

[kum-deepak]

The typings of d3 are quite smart. The Selection has 4 generic parameters:

• Type of selected elements
• The datum that is bound
• Type of parent element
• The datum bound to the parent

Any or all of these can be set to any to disable associated type checking. If a selection is made on a Selection with a known type it will automatically figure out the two parameters related to the parent.

It can, in some cases, figure out the currently selected elements automatically, for example, if an element is selected like text. However, it will be unable to figure out if the selection is on text.label. It would need hints in these cases.

In the extreme top of the hierarchy _root we will need to start with a generic type and below that we can keep being specific.

Currently, the chart data is quite flexible, however, after refactoring we should be able to put some constraints on the chart data and accordingly to the type checking.